[CUWiN-Dev] Boatload of WRAP node problems

[Seth Price]

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.

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.

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




On Aug 31, 2005, at 1:58 PM, David Young wrote:

> On Wed, Aug 31, 2005 at 11:25:08AM -0500, Seth Price wrote:
>
>> As I have mentioned before, I just moved into the Race and Washington
>> intersection and I am having issues with my connection. I'm not sure
>> how many of these are isolated to my node (10.0.150.205), and how
>> many are related, so I'll lump them into one email.
>>
>> - wdogctl is using ~100% of my cpu time, all the time. top
>>
>
> I have patched wdogctl to fix that.  This may be behind some of the
> other problems.
>
>
>> - node continually sends out packets. Judging by the lights on the
>> switch, some of them are broadcast, most are not. And yes, I see
>> these continually when both desktops are in Sleep mode.
>>
>
> Please find out what it is sending.  It is normal for it to send  
> broadcast
> UDP packets on port 9191 all of the time.  That is the routing  
> protocol
> running.
>
>
>> - Node "freezes" randomly. I've seen it go for about an hour and
>> freeze, and I've seen it go overnight without freezing (only once
>> though). I say "freezes" because although it won't respond or route,
>> but I can see that it's ethernet interface is very active by the
>> blinkenlights on the switch. SSH sessions stop responding and the
>> ping to the node goes from < 1 ms to nothing. I can reset it simply
>> by pulling the plug for a second. More top and ping info is avl if
>> requested.
>>
>
> The best way to figure this out is to attach to the serial console.
>
>
>> - My connection is extremely unreliable. It goes out for very short
>> stretches, and it goes out for very long stretches. Yesterday I left
>> "ping google.com" going for a while on my desktop to see if I could
>> come up with any interesting stats. Here is a sampling of the kinds
>> of errors that I get (watch the ICMP seq # to see where I cut and
>> pasted, generally I only get one or two dropped packets, 10% of the
>> time):
>>
>
> I can tell from the "destination unreachable" and "ttl exceeded"  
> messages
> that something goes wrong with the routing.  Your packets are hopping
> north on Race Street before they go south again.  They are probably
> coming south through your router and looping back north.
>
>
>> 36 bytes from 10.0.216.146: Destination Host Unreachable
>>
>
> This is a node about a block north of you.
>
>
>> 36 bytes from 10.22.228.254: Destination Net Unreachable
>>
>
> I guess the default route went away.  That is the IP on your node's
> ethernet.
>
>
>> - Both web connections and ssh connections to my node take about 30
>> seconds to get an initial response, then they generally work fine.
>> With intermittent pauses.
>>
>
> Due to wdogctl chewing CPU, I bet.
>
>
>> - I occasionally get DNS entries that direct me to the chambana.net
>> server homepage. CNN.com became chambana.net yesterday, for example.
>>
>
> This is a misconfiguration of the chambana.net DNS server.
>
>
>> - Before I got the node's wireless interface online, the RouteViz web
>> GUI showed only my node and a single horizontal green line to the
>> right. It was like my node was connected to something off screen (no
>> matter how far I zoomed out). It was rather confusing.
>>
>
> Probably a stub route.  I can filter those so that routeviz never
> sees them.
>
>
>> - Now that my node is connected to the mesh, the routeviz images are
>> 404 errors.
>>
>
> No idea.
>
> Dave
>
>
> -- 
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
>
>
>