search

dankamongmen / libnetstack

Small library around rtnetlink to track networking stack elements
https://nick-black.com/dankwiki/index.php/Libnetstack
Apache License 2.0
10 stars 0 forks source link

Default routes don't seem to be getting enumerated #23

Closed dankamongmen closed 5 years ago

dankamongmen commented 5 years ago

I used to see default routes in our output, but I don't seem to anymore:

[IPv4] 254.0.0.0/0 unicast boot metric 254 prio 254 in 254 out 4
[IPv4] 10.10.0.0/24 unicast kernel metric 254 prio 254 in 254 out 6
[IPv4] 10.14.78.32/32 unicast boot metric 254 prio 254 in 254 out 4
[IPv4] 10.21.0.0/16 unicast boot metric 254 prio 254 in 254 out 4
[IPv4] 10.23.0.0/16 unicast boot metric 254 prio 254 in 254 out 4
[IPv4] 10.42.0.0/24 unicast kernel metric 254 prio 254 in 254 out 3
[IPv4] 10.88.0.0/24 unicast kernel metric 254 prio 254 in 254 out 30
[IPv4] 100.64.42.0/23 unicast kernel metric 254 prio 254 in 254 out 2
[IPv4] 192.168.55.0/24 unicast kernel metric 254 prio 254 in 254 out 4
[IPv4] 192.168.123.0/24 unicast boot metric 254 prio 254 in 254 out 6
[IPv4] 10.10.0.0/32 broadcast kernel metric 255 prio 255 in 255 out 6
[IPv4] 10.10.0.70/32 local kernel metric 255 prio 255 in 255 out 6
[IPv4] 10.10.0.255/32 broadcast kernel metric 255 prio 255 in 255 out 6
[IPv4] 10.42.0.0/32 broadcast kernel metric 255 prio 255 in 255 out 3
[IPv4] 10.42.0.1/32 local kernel metric 255 prio 255 in 255 out 3
[IPv4] 10.42.0.255/32 broadcast kernel metric 255 prio 255 in 255 out 3
[IPv4] 10.88.0.0/32 broadcast kernel metric 255 prio 255 in 255 out 30
[IPv4] 10.88.0.2/32 local kernel metric 255 prio 255 in 255 out 30
[IPv4] 10.88.0.255/32 broadcast kernel metric 255 prio 255 in 255 out 30
[IPv4] 100.64.42.0/32 broadcast kernel metric 255 prio 255 in 255 out 2
[IPv4] 100.64.43.31/32 local kernel metric 255 prio 255 in 255 out 2
[IPv4] 100.64.43.255/32 broadcast kernel metric 255 prio 255 in 255 out 2
[IPv4] 127.0.0.0/32 broadcast kernel metric 255 prio 255 in 255 out 1
[IPv4] 127.0.0.0/8 local kernel metric 255 prio 255 in 255 out 1
[IPv4] 127.0.0.1/32 local kernel metric 255 prio 255 in 255 out 1
[IPv4] 127.255.255.255/32 broadcast kernel metric 255 prio 255 in 255 out 1
[IPv4] 192.168.55.0/32 broadcast kernel metric 255 prio 255 in 255 out 4
[IPv4] 192.168.55.78/32 local kernel metric 255 prio 255 in 255 out 4
[IPv4] 192.168.55.255/32 broadcast kernel metric 255 prio 255 in 255 out 4
[IPv6] ::1/128 unicast kernel metric 254 prio 256 in 254 out 1
[IPv6] fe80::/64 unicast kernel metric 254 prio 256 in 254 out 2
[IPv6] fe80::/64 unicast kernel metric 254 prio 256 in 254 out 6
[IPv6] fe80::/64 unicast kernel metric 254 prio 256 in 254 out 3
[IPv6] fe80::/64 unicast kernel metric 254 prio 256 in 254 out 4
[IPv6] fe80::/64 unicast kernel metric 254 prio 256 in 254 out 30

I checked, and if we're kicking a message, it's happening before vnetstack_print_iface().

dankamongmen commented 5 years ago

I think it's this one:

GOT A GATEWAY!
 [IPv4] 254.0.0.0/0 unicast boot metric 254 prio 254 in 254 out 4

all the other "GOT A GATEWAY" (temporary debugging aid) messages correspond to output:

GOT A GATEWAY!
 [IPv4] 192.168.123.0/24 unicast boot metric 254 prio 254 in 254 out 6
GOT A GATEWAY!
 [IPv4] 254.0.0.0/0 unicast boot metric 254 prio 254 in 254 out 4
GOT A GATEWAY!
 [IPv4] 10.14.78.32/32 unicast boot metric 254 prio 254 in 254 out 4
GOT A GATEWAY!
 [IPv4] 10.21.0.0/16 unicast boot metric 254 prio 254 in 254 out 4
GOT A GATEWAY!
 [IPv4] 10.23.0.0/16 unicast boot metric 254 prio 254 in 254 out 4
[schwarzgerat](0) $ ip -4 r  l t all  | grep via
default via 192.168.55.1 dev iw7260 
10.14.78.32 via 192.168.55.173 dev iw7260 src 192.168.55.254 
10.21.0.0/16 via 192.168.55.183 dev iw7260 
10.23.0.0/16 via 192.168.55.183 dev iw7260 
192.168.123.0/24 via 10.10.0.1 dev tun1 
[schwarzgerat](0) $

but i don't have anything for 254.0.0.0/0, and this is always the first route returned.

dankamongmen commented 5 years ago

OK, I think I've found the problem. We have our offset table, where 0 means unset. But 0 is also of course a valid offset. We could either:

(1) use pointers, with NULL as a sentinel, requiring a recompute on copy, or (2) bias the offsets by 1, making 0 our sentinel, or (3) initialize them all to -1, making the appropriate MAXINT our sentinel

both 1 and 3 require o(n) operations, though 1 only requires them on copy. 2 seems the best?

dankamongmen commented 5 years ago

[IPv4] default unicast boot metric 0 prio 0 in 0 out 4

works again!