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.