[Babel-users] Buggy routes exported by babeld

[Baptiste Jonglez]

Hi,

I've encountered a weird situation, which looks like a bug.

On a node that has Internet connectivity, when asking babeld to
redistribute all available IPv6 routes (with "redistribute ip ::/0
metric 256"), it starts to announce a /128 route for *each* IPv6 host
contacted over the Internet. That is, even a ping6 to a random host on
the Internet adds a /128 route into what babeld distributes.

Of course, these buggy route don't show up with "ip -6 route";
however, babed *does* seem to pick them from the kernel, see below.

I haven't been able to reproduce this behavior with IPv4.


Here is an excerpt, running babel with:

  babeld -C "redistribute ip ::/0 metric 256" -d 2 wlan0

The log below highlights how babeld reacts when running a simple
"ping6 git.wifi.pps.univ-paris-diderot.fr" while babeld is running (of
course, the behavior is similar for other hosts and other protocols):



…

My id 02:1c:26:ff:fe:bb:91:0e seqno 10979
192.168.2.106/32 metric 0 (exported)
2a01:6600:8081:1a01::1/128 metric 0 (exported)
::/0 metric 256 (exported)
2a01:6600:8081:1a00::1/128 metric 256 (exported)
2a01:6600:8081:1a01::/64 metric 256 (exported)
2001:7fd::1/128 metric 256 (exported)

Checking kernel routes.
Sending update to wlan0 for 2001:41d0:1:f19f::1/128.

My id 02:1c:26:ff:fe:bb:91:0e seqno 10979
192.168.2.106/32 metric 0 (exported)
2a01:6600:8081:1a01::1/128 metric 0 (exported)
::/0 metric 256 (exported)
2a01:6600:8081:1a00::1/128 metric 256 (exported)
2a01:6600:8081:1a01::/64 metric 256 (exported)
2001:7fd::1/128 metric 256 (exported)
2001:41d0:1:f19f::1/128 metric 256 (exported)

…


Note that 2a01:6600:8081:1a01::1/128 is this node's address. See how
babeld picked up a route to 2001:41d0:1:f19f::1/128 (in this case, it
has also previously picked 2001:7fd::1/128 up, which looks like one of
the root DNS servers). These routes should normally not appear at all,
since I doubt a route is created in the kernel each time a connection
is established.


My setup is a bit special, in that it involves a sit tunnel for IPv6
connectivity with the outside. Laptop A has 3 interfaces:

- eth0, which is configured via dhcpcd in the 192.168.2.0/24 range
  (there's a NAT on the box);

- wlan0, used in ad-hoc mode with babeld;

- tun1, a sit device providing IPv6 connectivity for the node through
  a tunnel. Note that this interface does not have a configured IPv6
  address (only eth0 has).

Here are the interfaces (the IPv6 address on eth0 is statically assigned):

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:90:f5:91:5b:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.106/24 brd 192.168.2.255 scope global eth0
    inet6 2a01:6600:8081:1a01::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::290:f5ff:fe91:5bdd/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:1c:26:bb:91:0e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21c:26ff:febb:910e/64 scope link 
       valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN 
    link/sit 0.0.0.0 brd 0.0.0.0
5: tun1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN 
    link/sit 0.0.0.0 peer 91.224.149.26
    inet6 fe80::c0a8:26a/64 scope link 
       valid_lft forever preferred_lft forever

And the routes:

  default via 192.168.2.254 dev eth0  metric 202 
  192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.106 metric 202

  2a01:6600:8081:1a00::1 dev tun1  proto static  metric 1024 
  2a01:6600:8081:1a01::/64 dev eth0  proto kernel  metric 256 
  fe80::/64 dev eth0  proto kernel  metric 256 
  fe80::/64 dev wlan0  proto kernel  metric 256 
  default via 2a01:6600:8081:1a00::1 dev tun1  proto static  metric 1024

The IPv6 routes related to tun1 were configured by hand.


I'm running babeld 1.3.5 on Archlinux, with linux 3.8.7, and iproute2
3.8.0.


Is there anything else I could provide? I would love to test without
the tunnel (in case it is the culprit), but I don't have native IPv6
connectivity.

Regards,
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20130422/aec09c98/attachment.pgp>