- HECnet - lists @ Update

TCP based bridge / router, what's the status?

by sampsa＠mac.com

Won't connect with that APN, unfortunately.. Sampsa On 29 Aug 2012, at 14:09, Saku Set l wrote: Sampsa, you can try to change your APN from "internet.saunalahti" to "internet4" --Saku On Mon, Aug 6, 2012 at 11:46 PM, Sampsa Laine <sampsa at mac.com> wrote: Mobile operator called Saunalahti, they're a virtual operator on top of one of the two major Finnish operators, Elisa. Speeds are amazing, middle of the woods, I get 6/3 Mbps up down on a 3G dongle hooked to my Draytek router, and like 12/5 on my iPad. 13 euros a month, unlimited bandwidth and as much speed as your device can drive. Oh and they've got a 4G base station in town, like 7 km away, should get like 40+ Mbps there. Then again, Helsinki cable operators are now offering 300/20 Mbps as their to product :) Sampsa On 6 Aug 2012, at 23:15, Gregg Levine wrote: Hello! Sampsa all kidding aside who did you pick? I can think of several of the names but probably not available where you are. Oh and the gang left Thursday last. They are around Dave's place.

12 years, 11 months

1
0
0 0

TCP based bridge / router, what's the status?

by setala＠gmail.com

Sampsa, you can try to change your APN from "internet.saunalahti" to "internet4" --Saku On Mon, Aug 6, 2012 at 11:46 PM, Sampsa Laine <sampsa at mac.com> wrote: Mobile operator called Saunalahti, they're a virtual operator on top of one of the two major Finnish operators, Elisa. Speeds are amazing, middle of the woods, I get 6/3 Mbps up down on a 3G dongle hooked to my Draytek router, and like 12/5 on my iPad. 13 euros a month, unlimited bandwidth and as much speed as your device can drive. Oh and they've got a 4G base station in town, like 7 km away, should get like 40+ Mbps there. Then again, Helsinki cable operators are now offering 300/20 Mbps as their to product :) Sampsa On 6 Aug 2012, at 23:15, Gregg Levine wrote: Hello! Sampsa all kidding aside who did you pick? I can think of several of the names but probably not available where you are. Oh and the gang left Thursday last. They are around Dave's place.

12 years, 11 months

1
0
0 0

TCP based bridge / router, what's the status?

by roll＠Stupi.SE

Not quite. The assumptions are that it's a datagram service with a fairly = low loss rate. It assumes order, and at-most-once delivery, though if that= Packets out of order makes it reset the adjacency, lost packets will be retransmitted by the session layer.... -P

12 years, 11 months

1
0
0 0

Node 4.249

by Paul_Koning＠Dell.com

OOPS. You're right of course. I was thinking about multiple Ethernet interfaces on DIFFERENT LANs. (Not different segments bridged, but not connected at L2, only at L3.) paul On Aug 28, 2012, at 7:44 PM, Johnny Billquist wrote: On 2012-08-28 17:58, Paul_Koning at Dell.com wrote: Maybe the thing to do is to turn on both interfaces -- that will give you a dual-link end node, which is something DECnet handles just fine. In fact, I've always argued that DECnet handles multiple connections to the same LAN much better than IP ever did, mostly because it addresses nodes rather than networks or interfaces. Uh... I would argue that that would be a very bad thing, as it means you'll have two interfaces with the same mac address... Sitting on the same network. I'm pretty sure I even have seen some DECnet documentation that just says "not supported", or even stronger words... Johnny paul On Aug 28, 2012, at 11:54 AM, Mark Benson wrote: I tried to run a similar setup and found that Debian/Ubuntu's 'network-manager' process makes a really horrific mess of managing 2 interfaces. I ripped it out of Debian and used file entries in /etc/network/interfaces and /etc/resolv.conf I have no idea if Ubuntu will spit it's brain out if you try that on 12.04 as it's ver dependent on it in the GUI. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson On 28 Aug 2012, at 13:37, Mark Wickens <mark at wickensonline.co.uk> wrote: I think I've found it. My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2. -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 11 months

1
0
0 0

TCP based bridge / router, what's the status?

by Paul_Koning＠Dell.com

On Aug 29, 2012, at 5:24 AM, Peter Lothberg wrote: ... DECnet over Ethernet, makes the assumption that unless there is a collition, the packet makes it to the receiver. Not quite. The assumptions are that it's a datagram service with a fairly low loss rate. It assumes order, and at-most-once delivery, though if that's violated I don't think things are likely to fail badly. It is actually tolerant of some pretty weird errors, for example a non-transitive network (A can see B and B can see C but A can't see C). That's rare in Ethernet bus networks and even less likely in modern switched networks, unless you misconfigure a firewall. And many other network architectures get seriously confused if this happens, but DECnet explicitly covers this case. DECnet over P-T-P links assumes there is underlaying reliable transport, eg, DDCMP. Running a ether bridge serving multiple nodes over TCP will cause problems like what Jonny outlines, basically it'sa head-of-line problem. Are you talking about congestion or head of line blocking? I'm not sure how you get from there to the problem that was seen. Multiple correlated packet losses? That might do it. But if the Bridge makes a mesh of TCP connections (one per destination) it will work.... -P paul

12 years, 11 months

1
0
0 0

TCP based bridge / router, what's the status?

by roll＠Stupi.SE

On 2012-08-06 18:18, Jarratt RMA wrote: Not sure I recall this particular conversation, but I am making (slow) progress on a user mode DECnet router that runs on Windows and Linux and which I intend to make friendly to those who do not have a fixed IP address (like me). Not sure if that is what you were referring to. I think there have been other discussions about tcp as a transport for traffic. I've personally not been very interested in this, since there are potential problems and issues with this. But it would in principle not be hard to convert the existing bridge program to use tcp instead if someone wanted to, but I won't be running that at my end... Right now I have the Ethernet Initialization sublayer about done for actual Ethernet connections. I still need to do an interface that will interop with Johnny's bridge program, this should be easy when I get to it, Stupidly simple, in fact. You'll get full ethernet frames in UDP packets. Pass them in and parse them, just like any other ethernet packet. As for sending them out, once you have the full ethernet packet, send it over UDP instead of out on the ethernet interface. when I do it I will add a periodic check that the IP address is still valid by checking against DNS (you would need to be registered on a dynamic DNS service like DynDNS). I believe Johnny does not do this in the bridge because of the temporary halt in packet processing this entails. Personally, this is a price I am willing to pay. I could make it asynch I suppose, but it is harder to do this in a portable manner. Correct. DNS resolution can take ages, especially when things gets wrong. Timeout are into minutes sometimes. You really do not want to block operation on that. Potential other problems if you go with tcp - a changed address means tearing down and reestablishing connections. You will have to make sure that the received can receive and process packets faster than a producer is sending them, or else you need to implement packet discarding, or else you'll get really weird problems because packets will appear, but way after they are considered dead by the sender. A typical example is if the sender is sitting on a gigabit ethernet, but the receiver is a lowly PDP-11 on a 10 Mbit ethernet segment. TCP never drops the packets. Instead you'll get into TCP flow control, which will block your writes or return with partial success. Another thing is that TCP is just a byte stream, so you need to somehow block/deblock your transmissions so that you deal with full packets at the receiving side. And if you implement packet drop, you might need to be able to resynch or drop data in ways that don't get only partial packets across. One problem here is that by the time the sender becomes aware of a problem, you are already very deep into the problem. In order to make it work smoothly, you need to detect and drop packets on the receiving side. But that's also tricky, since how do you know on the receiving side that there is more data coming before you have received it... Else you try to implement some signalling protocol outside of the data stream to tell this kind of information. Ah well, I could go on... Suffice to say that it's not because I'm opposed to the features that a TCP connection, or DNS resolution would give, but I prioritize something that I feel confident is working to features. And doing a proper solution with all these aspects is more work than I have cared to put into it. The bridge program is a hack. As Paul mention, pthreads would probably be a good start if you want to do something more intelligent. You need to start thinking asynchronously. Johnny Regards Rob On 6 August 2012 16:35, Sampsa Laine <sampsa at mac.com <mailto:sampsa at mac.com>> wrote: I remember there being some discussion about a bridge that would work over TCP (only requiring the server to have a port forward / static IP).. What's the status on this? My ISP (a 3G network that's blazing fast but short on IPs, which means I'm NAT'd on the outside of my network, thus not portwards are possible). Ideally I would like to just point at the server without them knowing anything about my originating IP, perhaps with some form of authentication. Sampsa DECnet over Ethernet, makes the assumption that unless there is a collition, the packet makes it to the receiver. DECnet over P-T-P links assumes there is underlaying reliable transport, eg, DDCMP. Running a ether bridge serving multiple nodes over TCP will cause problems like what Jonny outlines, basically it'sa head-of-line problem. But if the Bridge makes a mesh of TCP connections (one per destination) it will work.... -P

12 years, 11 months

1
0
0 0

Node 4.249

by bqt＠softjar.se

On 2012-08-28 18:08, Mark Wickens wrote: I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ------------------------------------------------------------------------------- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ------------------------------------------------------------------------------- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de-configure it from an OS point of view. The bridge uses the specified interface for it's bridging. That is, DECnet packets will only be sent and received from that interface. UDP does not have an interface that specifies which network interface to use. You normally do not have any control over this aspect for UDP packets. The UDP transport that the bridge use is just plain UDP. And the destinations are all the non-local destinations specified in the config file. Exactly which network interface traffic to those destinations exit on is something up to your UDP/IP implementation. (Just clarifying that detail a little more...) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 11 months

1
0
0 0

Node 4.249

by bqt＠softjar.se

On 2012-08-28 17:58, Paul_Koning at Dell.com wrote: Maybe the thing to do is to turn on both interfaces -- that will give you a dual-link end node, which is something DECnet handles just fine. In fact, I've always argued that DECnet handles multiple connections to the same LAN much better than IP ever did, mostly because it addresses nodes rather than networks or interfaces. Uh... I would argue that that would be a very bad thing, as it means you'll have two interfaces with the same mac address... Sitting on the same network. I'm pretty sure I even have seen some DECnet documentation that just says "not supported", or even stronger words... Johnny paul On Aug 28, 2012, at 11:54 AM, Mark Benson wrote: I tried to run a similar setup and found that Debian/Ubuntu's 'network-manager' process makes a really horrific mess of managing 2 interfaces. I ripped it out of Debian and used file entries in /etc/network/interfaces and /etc/resolv.conf I have no idea if Ubuntu will spit it's brain out if you try that on 12.04 as it's ver dependent on it in the GUI. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson On 28 Aug 2012, at 13:37, Mark Wickens <mark at wickensonline.co.uk> wrote: I think I've found it. My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2. -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 11 months

1
0
0 0

Node 4.249

by Paul_Koning＠Dell.com

I think compile time change is plenty. My comment was really speculation, and even if true it doesn't sound like something that needs the flexibility of a runtime config setting. paul On Aug 28, 2012, at 4:58 PM, Rob Jarratt wrote: The multiplier can easily be changed. It is currently a #define BCT3MULT 3. It could be made a configurable parameter instead. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 28 August 2012 20:35 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Node 4.249 BTW, the adjacency timeout rules in the routing spec are tuned for good quality physical links. So Ethernet adjacencies allow two consecutive lost packets, but no more -- the timeout is 3x the hello interval. I wonder if bridged connections should be more tolerant. If both sides are regular DECnet implementations that isn't an option, but Rob's router could use a different multiplier to derive the broadcast listen timer value. That would help if these bridged connections are prone to drop more packets but you can still reasonably expect no more than N in a row to be lost. If so, the multiplier could be changed to N+1. paul On Aug 28, 2012, at 3:30 PM, Rob Jarratt wrote: The problem stopped around the time of your first email, so I guess you fixed it. My user mode router is not reporting adjacency up and down any more. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Mark Wickens Sent: 28 August 2012 17:08 To: hecnet at update.uu.se Subject: Re: [HECnet] Node 4.249 I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ---------------------------------------------------------------------- ------ --- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ---------------------------------------------------------------------- ------ --- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de- configure it from an OS point of view.

12 years, 11 months

1
0
0 0

Node 4.249

by robert.jarratt＠ntlworld.com

The multiplier can easily be changed. It is currently a #define BCT3MULT 3. It could be made a configurable parameter instead. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 28 August 2012 20:35 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Node 4.249 BTW, the adjacency timeout rules in the routing spec are tuned for good quality physical links. So Ethernet adjacencies allow two consecutive lost packets, but no more -- the timeout is 3x the hello interval. I wonder if bridged connections should be more tolerant. If both sides are regular DECnet implementations that isn't an option, but Rob's router could use a different multiplier to derive the broadcast listen timer value. That would help if these bridged connections are prone to drop more packets but you can still reasonably expect no more than N in a row to be lost. If so, the multiplier could be changed to N+1. paul On Aug 28, 2012, at 3:30 PM, Rob Jarratt wrote: The problem stopped around the time of your first email, so I guess you fixed it. My user mode router is not reporting adjacency up and down any more. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Mark Wickens Sent: 28 August 2012 17:08 To: hecnet at update.uu.se Subject: Re: [HECnet] Node 4.249 I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ---------------------------------------------------------------------- ------ --- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ---------------------------------------------------------------------- ------ --- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de- configure it from an OS point of view.

12 years, 11 months

1
0
0 0

Node 4.249

by robert.jarratt＠ntlworld.com

I am working on it right now, working on the Update Process so that other routers know how to route back to me. I am hoping to have a basic router that works on a LAN and against the bridge at the other end in the next week or so. At this stage it will be Windows only (can run on your desktop or as a Windows service) and various parts of the spec won't be fully implemented. I had an earlier version running on a Raspberry Pi, but I suspect it will take a day or two longer to get it working on there again. Right now I have the Ethernet Initialization Layer done, the Decision Process coded (and tested to some degree), and I have started on the Update and Forwarding processes which are the least well developed. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Gregg Levine Sent: 28 August 2012 20:35 To: hecnet at update.uu.se Subject: Re: [HECnet] Node 4.249 On Tue, Aug 28, 2012 at 3:30 PM, Rob Jarratt <robert.jarratt at ntlworld.com> wrote: The problem stopped around the time of your first email, so I guess you fixed it. My user mode router is not reporting adjacency up and down any more. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner- hecnet at Update.UU.SE] On Behalf Of Mark Wickens Sent: 28 August 2012 17:08 To: hecnet at update.uu.se Subject: Re: [HECnet] Node 4.249 I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ---------------------------------------------------------------------- ------ --- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ---------------------------------------------------------------------- ------ --- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de- configure it from an OS point of view. Hello! Funny you should mention that reason behind that card, Mark, I had plans utilizing that idea, but I shelved them for the moment, when I realized that there would be a big problem. Namely the fact that my DSL device is getting on in years, and I'm not all sure what would happen when I tried any of that. Next: Rob you've mentioned several times a user mode router. Presumably for Decnet issues of course. When will it become an available option and on what platforms? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

12 years, 11 months

1
0
0 0

Node 4.249

by gregg.drwho8＠gmail.com

On Tue, Aug 28, 2012 at 3:30 PM, Rob Jarratt <robert.jarratt at ntlworld.com> wrote: The problem stopped around the time of your first email, so I guess you fixed it. My user mode router is not reporting adjacency up and down any more. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens Sent: 28 August 2012 17:08 To: hecnet at update.uu.se Subject: Re: [HECnet] Node 4.249 I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ---------------------------------------------------------------------------- --- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ---------------------------------------------------------------------------- --- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de- configure it from an OS point of view. Hello! Funny you should mention that reason behind that card, Mark, I had plans utilizing that idea, but I shelved them for the moment, when I realized that there would be a big problem. Namely the fact that my DSL device is getting on in years, and I'm not all sure what would happen when I tried any of that. Next: Rob you've mentioned several times a user mode router. Presumably for Decnet issues of course. When will it become an available option and on what platforms? ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again."

12 years, 11 months

1
0
0 0

Node 4.249

by Paul_Koning＠Dell.com

BTW, the adjacency timeout rules in the routing spec are tuned for good quality physical links. So Ethernet adjacencies allow two consecutive lost packets, but no more -- the timeout is 3x the hello interval. I wonder if bridged connections should be more tolerant. If both sides are regular DECnet implementations that isn't an option, but Rob's router could use a different multiplier to derive the broadcast listen timer value. That would help if these bridged connections are prone to drop more packets but you can still reasonably expect no more than N in a row to be lost. If so, the multiplier could be changed to N+1. paul On Aug 28, 2012, at 3:30 PM, Rob Jarratt wrote: The problem stopped around the time of your first email, so I guess you fixed it. My user mode router is not reporting adjacency up and down any more. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens Sent: 28 August 2012 17:08 To: hecnet at update.uu.se Subject: Re: [HECnet] Node 4.249 I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ---------------------------------------------------------------------------- --- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ---------------------------------------------------------------------------- --- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de- configure it from an OS point of view.

12 years, 11 months

1
0
0 0

Node 4.249

by robert.jarratt＠ntlworld.com

The problem stopped around the time of your first email, so I guess you fixed it. My user mode router is not reporting adjacency up and down any more. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Mark Wickens Sent: 28 August 2012 17:08 To: hecnet at update.uu.se Subject: Re: [HECnet] Node 4.249 I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ---------------------------------------------------------------------------- --- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ---------------------------------------------------------------------------- --- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de- configure it from an OS point of view.

12 years, 11 months

1
0
0 0

Node 4.249

by mark＠wickensonline.co.uk

I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? Both interfaces are on the same segment as the router. What sessions are you seeing on the router? On the router I see the following sessions: ------------------------------------------------------------------------------- Private IP :Port #Pseudo Port Peer IP :Port Ifno Status ------------------------------------------------------------------------------- 192.168.1.126 4711 4711 130.238.19.25 4711 3 0 192.168.1.127 4711 4711 130.238.19.25 4711 3 0 Where 192.168.1.126 is eth0 and 192.168.1.127 is eth2 And what did the routing table on the machine running the bridge look like, if you have two interfaces? No idea on this one. The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... OK, that probably explains it. I thought the bridge was tied to that particular interface. It's worth pointing out that what I'm doing it probably daft - the 2nd card was installed to use for a SIMH instance, so I should probably de-configure it from an OS point of view.

12 years, 11 months

1
0
0 0

Node 4.249

by Paul_Koning＠Dell.com

Maybe the thing to do is to turn on both interfaces -- that will give you a dual-link end node, which is something DECnet handles just fine. In fact, I've always argued that DECnet handles multiple connections to the same LAN much better than IP ever did, mostly because it addresses nodes rather than networks or interfaces. paul On Aug 28, 2012, at 11:54 AM, Mark Benson wrote: I tried to run a similar setup and found that Debian/Ubuntu's 'network-manager' process makes a really horrific mess of managing 2 interfaces. I ripped it out of Debian and used file entries in /etc/network/interfaces and /etc/resolv.conf I have no idea if Ubuntu will spit it's brain out if you try that on 12.04 as it's ver dependent on it in the GUI. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson On 28 Aug 2012, at 13:37, Mark Wickens <mark at wickensonline.co.uk> wrote: I think I've found it. My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2.

12 years, 11 months

1
0
0 0

Node 4.249

by md.benson＠gmail.com

I tried to run a similar setup and found that Debian/Ubuntu's 'network-manager' process makes a really horrific mess of managing 2 interfaces. I ripped it out of Debian and used file entries in /etc/network/interfaces and /etc/resolv.conf I have no idea if Ubuntu will spit it's brain out if you try that on 12.04 as it's ver dependent on it in the GUI. -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson On 28 Aug 2012, at 13:37, Mark Wickens <mark at wickensonline.co.uk> wrote: I think I've found it. My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2.

12 years, 11 months

1
0
0 0

Node 4.249

by bqt＠softjar.se

On 2012-08-28 14:37, Mark Wickens wrote: I think I've found it. My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2. I run the bridge with a configuration targetting eth0, and my router has the IP address for eth0 mapped via port 4711 to the outside world, but when I checked the NAT sessions table on the router I could see sessions for both eth0 and eth2. As soon as I ran $ ifconfig eth2 down I could see on SLAVE adjacency up messages. So there is something fishy going on with multiple network cards, might be worth trying to get to the bottom of this and then documenting what the issue is. I'm not totally clear on your setup. You have two interfaces, eth0 and eth2. I think I got that. And the bridge program is using eth0 for it's bridge. But how does your ethernet looks like? Is both eth0 and eth2 connected to the same physical network? Is the router on that same segment as well? What sessions are you seeing on the router? And what did the routing table on the machine running the bridge look like, if you have two interfaces? The bridge program does not try to do anything clever with the UDP packets, so they will be sent on any interface, based on your routing table. It might sound as if your router/NAT was pointing at the IP address of eth0, but the default entry of the routing table on your machine would be using eth2. But this is all wild guessing right now... Johnny

12 years, 11 months

1
0
0 0

Node 4.249

by mark＠wickensonline.co.uk

I think I've found it. My HP Microserver running Ubuntu 12.04 has two network cards in: eth0 and eth2. I run the bridge with a configuration targetting eth0, and my router has the IP address for eth0 mapped via port 4711 to the outside world, but when I checked the NAT sessions table on the router I could see sessions for both eth0 and eth2. As soon as I ran $ ifconfig eth2 down I could see on SLAVE adjacency up messages. So there is something fishy going on with multiple network cards, might be worth trying to get to the bottom of this and then documenting what the issue is. Mark.

12 years, 11 months

1
0
0 0

Node 4.249

by mark＠wickensonline.co.uk

On 26/08/12 20:00, Johnny Billquist wrote: On 2012-08-26 20:13, Rob Jarratt wrote: (sending again as I sent this from the wrong account, apologies if you get a duplicate) As I work on my user mode DECnet router I sometimes leave it running for a while just to see that it is stable over the longer term. During those runs I have noticed that the adjacency 4.249 frequently drops out only to come back a few seconds later. This does not happen with any other adjacency. Before I go investigating, is there something unusual about this node? I can see the same at my end right now as well. It's not always like this, so I guess there is something going on with area 4? Johnny 4.249 is SLAVE which serves up the http://hecnet.eu website. I've had some weird stuff happening lately at this end, including the bridge program dying at times. Currently, for example, http://slave.hecnet.eu/area-list.html is reporting no connectivity which is backed up by operator.log: %%%%%%%%%%% OPCOM 27-AUG-2012 22:48:51.79 %%%%%%%%%%% Message from user DECNET on SLAVE DECnet event 4.18, adjacency down

12 years, 11 months

1
0
0 0

Any DECnet Routing Protocol Experts Out There?

by Paul_Koning＠Dell.com

Good to hear that. "Check" to me was always a rather odd thing to find in a protocol specification. But I implemented it as instructed. I don't remember if it ever caught any bugs in the code I worked on, but it did seem to be a useful set of consistency checks so I didn't complain about it. paul On Aug 25, 2012, at 7:13 PM, Rob Jarratt wrote: I found a bug in my adjacency processing that made other adjacencies use index 0 in the decision database, I think that is what has been causing the Check failures.

12 years, 11 months

1
0
0 0

Node 4.249

by bqt＠softjar.se

On 2012-08-26 20:13, Rob Jarratt wrote: (sending again as I sent this from the wrong account, apologies if you get a duplicate) As I work on my user mode DECnet router I sometimes leave it running for a while just to see that it is stable over the longer term. During those runs I have noticed that the adjacency 4.249 frequently drops out only to come back a few seconds later. This does not happen with any other adjacency. Before I go investigating, is there something unusual about this node? I can see the same at my end right now as well. It's not always like this, so I guess there is something going on with area 4? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

12 years, 11 months

1
0
0 0

Node 4.249

by robert.jarratt＠ntlworld.com

(sending again as I sent this from the wrong account, apologies if you get a duplicate) As I work on my user mode DECnet router I sometimes leave it running for a while just to see that it is stable over the longer term. During those runs I have noticed that the adjacency 4.249 frequently drops out only to come back a few seconds later. This does not happen with any other adjacency. Before I go investigating, is there something unusual about this node? Regards Rob

12 years, 11 months

1
0
0 0

Any DECnet Routing Protocol Experts Out There?

by robert.jarratt＠ntlworld.com

I found a bug in my adjacency processing that made other adjacencies use index 0 in the decision database, I think that is what has been causing the Check failures. -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Paul_Koning at Dell.com Sent: 25 August 2012 22:55 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Any DECnet Routing Protocol Experts Out There? You process address 0 exactly as any other level 1 routing message entry. Then in the forwarding process of an L1 router, if the destination is out of area, use entry 0 to decide how to forward the packet. Why do you get failures from Check? I don't see how you could get that. paul On Aug 25, 2012, at 4:36 PM, Rob Jarratt wrote: I am working on a user mode DECnet router and I have a question about the Level 1 Routing message. Specifically, sometimes I receive a level 1 routing message with routing information for destination address 0. The spec says this represents the "nearest level 2 router". What I am not clear about is how this is supposed to be treated in the Decision Process, specifically Section 4.7.3 item F in the specification. The reason I ask is that if I blindly accept address 0 I think it corrupts the hop and cost tables, because the Check process then gets failures. Thanks Rob

12 years, 11 months

1
0
0 0

Any DECnet Routing Protocol Experts Out There?

by Paul_Koning＠Dell.com

You process address 0 exactly as any other level 1 routing message entry. Then in the forwarding process of an L1 router, if the destination is out of area, use entry 0 to decide how to forward the packet. Why do you get failures from Check? I don't see how you could get that. paul On Aug 25, 2012, at 4:36 PM, Rob Jarratt wrote: I am working on a user mode DECnet router and I have a question about the Level 1 Routing message. Specifically, sometimes I receive a level 1 routing message with routing information for destination address 0. The spec says this represents the nearest level 2 router . What I am not clear about is how this is supposed to be treated in the Decision Process, specifically Section 4.7.3 item F in the specification. The reason I ask is that if I blindly accept address 0 I think it corrupts the hop and cost tables, because the Check process then gets failures. Thanks Rob

12 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet