[CUWiN-Dev] Boatload of WRAP node problems

[David Young]

On Wed, Aug 31, 2005 at 03:21:51PM -0500, Seth Price wrote:
> Here is the dump from tcpdump on the node (minus ssh overhead):
> 
> $ tcpdump
> tcpdump: verbose output suppressed, use -v or -vv for full protocol  
> decode
> listening on sip0, link-type EN10MB (Ethernet), capture size 96 bytes
> 08:35:48.294429 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 816
> 08:35:48.294907 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 816 [hlim 1]
> 08:35:48.626557 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 240
> 08:35:48.627385 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 440
> 08:35:48.628224 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 240 [hlim 1]
> 08:35:48.629056 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 440 [hlim 1]
> 08:35:48.776802 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 420
> 08:35:48.777193 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 420 [hlim 1]
> 08:35:48.851196 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 432
> 08:35:48.851641 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 432 [hlim 1]
> 08:35:49.487435 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 72
> 08:35:49.487772 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 72 [hlim 1]
> 08:35:49.636559 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 240
> 08:35:49.637385 IP 10.22.228.254.hsls > ALL-ROUTERS.MCAST.NET.hsls:  
> UDP, length: 440
> 08:35:49.638219 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 240 [hlim 1]
> 08:35:49.639050 fe80::20d:b9ff:fe01:afe8.hsls > ff02::2.hsls: UDP,  
> length: 440 [hlim 1]
> 
> It looks like it is all HSLS traffic over both IPv4 and IPv6. I had  
> thought that I had read somewhere that it only needed one hello per  
> second, and I assumed that they were only sent over the wireless  
> interface. Seems I was wrong.

Hellos have always been sent over the wire interface, too.  I do expect
two Hellos per interface (one sent by IPv6, one sent by IPv4), but I did
not expect four.

I install a "virtual interface" into hslsd for the "stub" routes.
I expected to find that those are sending Hellos, even though they are
not supposed to; that would be easy enough to fix.  It wasn't so.

The actual reason is that we send number-of-transports x
number-of-address-families hellos on each interface.  where
number-of-transports = number-of-address-families.  That is, we route
both IPv4 and IPv6, and we send routing control messages by both IPv4
and IPv6.  |{IPv4, IPv6} x {IPv4, IPv6}| = 4.

> Should I head over to your office some time to work on the serial  
> console part of it? It'll probably need to stay hooked up to it over  
> night before it goes into whatever crash condition is the problem.  
> Though I should probably figure out some serial console setup for  
> myself, I've been needing one lately.

Now that we have a WRAP node in the office, I will try to duplicate
the hang.

> What should I do about the routing problems to help you out?

Collect information.  BTW, there are a bunch of debug knobs you can tweak
for the routing in /etc/rc.conf.d/hslsd.  See the -l and -L options.
They are described in src/hsls/README.

It occurred to me today that the ETX for a new adjacency may not
be set to a middle or high value, so that new adjacencies look like
super-desirable routes.  That would wreck havoc on the routing every
time a node rebooted.  It would help to explain why your node would
try to route through a northern node instead of taking a direct route
southward to the Internet gateway.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933