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."
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.
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.
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.
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/bloghttp://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.
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/bloghttp://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.
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
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.
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
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.
