[CUWiN-Dev] Boatload of WRAP node problems

Seth Price seth at pricepages.org
Sat Sep 3 10:03:02 CDT 2005 

What confuses me is what is the difference between the 169.254.A.B  
address and the 10.0.A.B address? Why are they both needed? Are  
different As and Bs chosen for each just to confuse people?
~Seth


On Sep 2, 2005, at 10:22 PM, tom wrote:

> Ah ok, yes that explains it then. The 169.254.x.x addresses are the  
> IPv4
> addresses for the wireless interfaces, and so I use them to navigate
> from one node to the next, and they use them to talk to one another --
> the addresses themselves are actually decided upon by some algorithm
> based on I believe the Mac address of the interface. I don't know what
> happens when there are more than 255 * 255 nodes in a mesh, but I  
> don't
> think we've got to worry about that yet ;)
>
> On Fri, 2005-09-02 at 15:43 -0500, Seth Price wrote:
>
>> I believe that is my node. Although I'm not sure why each node needs
>> a 169.254.A.B address or how said address is decided upon...
>>
>> I should have been in the cluster for about a week now.
>> ~Seth
>>
>>
>> On Sep 2, 2005, at 3:24 PM, tom at anotherwastedday.com wrote:
>>
>>
>>> Hey Seth --
>>>
>>> I noticed a new node popped up on the Race St. cluster, IPv4 address
>>> 169.254.140.67. That doesn't have anything to do with you, does it?
>>>
>>> Tom
>>>
>>>
>>>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> CU-Wireless-Dev mailing list
>>>> CU-Wireless-Dev at lists.cuwireless.net
>>>> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>

More information about the CU-Wireless-Dev mailing list