[CUWiN-Dev] Rev. 4085 disappearing default routes
tom
tom at anotherwastedday.com
Tue Jul 18 17:08:06 CDT 2006
I put a build of rev. 4085 made by Dan Blah on the downtown Urbana network
today. There's some funkiness with the routing that I don't understand.
Some of the time nodes seem to lose their default routes:
# route get default
route: writing to routing socket: not in table
This seems to happen at random to all the nodes, I can't figure out why
they'll occasionally just lose them and then, a few minutes later, have
figured it out again.
Even when the default route is correct, however, there seems to be other
problems that prevent any traffic from successfully navigating the network
(pinging out, say).
As an example, the node at 115 W. Main St. correctly thinks it's default
route is 169.254.230.110, the IMC. However, it routes traffic to the IMC
through the library, which is a pretty poor decision. It might think it's a
better link, though, and would be forgiven if that actually worked, but
traffic doesn't ever make it to the IMC's node ("no route to host").
Below is a routing table for the 115 W Main node when the default route is
missing (I would include a more useful example of when it isn't missing, but
it's been gone for a while now that I actually need it... if it comes back,
I'll send it along).
# netstat -r
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu
Interface
10.0/16 localhost UGRS 33192 lo0
10.177.40/24 169.254.237.68 UG1 - ath0
10.177.40.254 169.254.237.68 UGH1 - ath0
10.177.80/24 link#2 UC - sip0
127/8 localhost UGRS 33192 lo0
localhost localhost UH 33192 lo0
169.254/16 link#1 UC - ath0
169.254.177.226 169.254.237.68 UGH1 - ath0
169.254.230.110 169.254.237.68 UGH1 - ath0
169.254.237.68 00:02:6f:20:ed:44 UHLc - ath0
224.0.0.5 localhost UGH1 33192 lo0
224.0.0.6 localhost UGH1 33192 lo0
224.0.0.9 localhost UGH1 33192 lo0
Internet6:
Destination Gateway Flags Refs Use Mtu
Interface
::/104 localhost UGRS - lo0
::/96 localhost UGRS - lo0
localhost localhost UH 33192 lo0
::127.0.0.0/104 localhost UGRS - lo0
::224.0.0.0/100 localhost UGRS - lo0
::255.0.0.0/104 localhost UGRS - lo0
::ffff:0.0.0.0/96 localhost UGRS - lo0
2001:db8::/32 localhost UGRS - lo0
2002::/24 localhost UGRS - lo0
2002:7f00::/24 localhost UGRS - lo0
2002:e000::/20 localhost UGRS - lo0
2002:ff00::/24 localhost UGRS - lo0
fc00::/7 localhost UGRS - lo0
fdb4:542d:dc11:77: fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:39f fe80::202:6fff:fe2 UG1 - ath0
fdb4:542d:dc11:39f fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:b0c fe80::202:6fff:fe2 UG1 - ath0
fdb4:542d:dc11:b0c fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:b0e fe80::202:6fff:fe2 UG1 - ath0
fdb4:542d:dc11:b0e fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:b11 fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:b12 fe80::202:6fff:fe2 UG1 - ath0
fdb4:542d:dc11:b12 fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:b15 link#2 UC - sip0
fdb4:542d:dc11:b15 00:00:24:c2:b1:50 UHL - lo0
fdb4:542d:dc11:b23 fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:ba1 fe80::202:6fff:fe2 UG1 - ath0
fdb4:542d:dc11:ba1 fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:ec2 fe80::202:6fff:fe2 UGH1 - ath0
fdb4:542d:dc11:ec2 fe80::202:6fff:fe2 UGH1 - ath0
fe80::/10 localhost UGRS - lo0
fe80::%ath0/64 link#1 UC - ath0
fe80::202:6fff:fe2 fe80::202:6fff:fe2 UGH1 - ath0
fe80::202:6fff:fe2 fe80::202:6fff:fe2 UGH1 - ath0
fe80::202:6fff:fe2 00:02:6f:20:ed:46 UHL - lo0
fe80::202:6fff:fe2 fe80::202:6fff:fe2 UGH1 - ath0
fe80::%sip0/64 link#2 UC - sip0
fe80::200:24ff:fec 00:00:24:c2:b1:50 UHL - lo0
fe80::%lo0/64 fe80::1%lo0 U - lo0
fe80::1%lo0 link#3 UHL - lo0
fe80::230:95ff:fef fe80::202:6fff:fe2 UGH1 - ath0
ff01:1::/32 link#1 UC - ath0
ff01:2::/32 link#2 UC - sip0
ff01:3::/32 localhost UC - lo0
ff02::%ath0/32 link#1 UC - ath0
ff02::%sip0/32 link#2 UC - sip0
ff02::%lo0/32 localhost UC - lo0
HSLS is running, all the nodes can ping each other just fine, there's plenty
of HSLS traffic and linkstate info. So I'm a little stumped, especially
because nothing of this sort was happening with revision 4074 (0.7.0rc1).
Did something change that might cause this? Thanks for any input...
Tom
More information about the CU-Wireless-Dev
mailing list