ipv6 default route messed up after installing aiccu (sixxs)

[Lukas P.]

Installed aiccu on a fresh raspbian from the raspberrypi.org website.
Logged in with sixxs tunnel with subnet attached.

Suddenly the computers in my local network (has only ipv4 from provider) get ipv6 addresses, but can only connect inside the ipv6 subnet, not globally.

On the rpi I then find that eth0 has also gotten assigned an ipv6 address from the sixxs-subnet and that this is set as the default route for ipv6 packets.

ip -f inet6 routes show outputs:
::/96 dev sit0 metric 256
2001:4dd0:ff00:0xxx::/64 dev sixxs proto kernel metric 256
2001:4dd0:ff00:8xxx::/64 dev eth0 proto kernel metric 256 expires 86390sec
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev sixxs proto kernel metric 256
default via fe80::226:22ff:fe14:d168 dev eth0 proto ra metric 1024 expires 80sec

The 'aiccu test' command gives the following insight: i can ping and traceroute the tunnel endpoint, but packets to other global hosts do not get routed through it.

Adding 'default via 2001:4dd0:ff00:0xxx::1 dev sixxs proto kernel metric 256' and deleting the other default makes me able to connect globally over ipv6 again, but after a short time the lease (?) gets renewed and the old default is back again.

This is very annoying since it renders sixxs useless.

I initially discovered this bug on my old raspbian install. It occured after the last update of aiccu. With it also came the new interface sit0. I thought that the bug may be due to usual os breakdown over time and because of that reinstalled raspbian from a newly downloaded image. Now i find (as discribed above) that the bug ist still there.

Do you need any additional information from me?
I'm currently not at home (where my rpi is), will add the output of 'uname -a' and other requested information tonight.

This is my first bug report, so I'm sorry for any mistakes in advance.
I filed the bug here and not on the debian bug system because I thought it may be something rpi related. Was that right?

Greetings,

Lukas

[peter green (plugwash)]

Have you tried the tunnel on any other (non-pi) system?
Have you contacted sixxs about the problem?

[Jeroen Massar (massar)]

Which host is fe80::226:22ff:fe14:d168 ? is that the local system?

Check with 'arp -an' if a similar MAC address is found for a IPv4 host to identify it better.

Also check:
ip -6 ro show
ip -6 nei show
ip ro show
ip nei show
ip tun show

etc

Note that AICCU (at least the original version) does not setup routes, hence, it is unlikely

[Lukas P. (lukas-gibix)]

Hey,

fe80::226:22ff:fe14:d168 is the local system, eth0 has the MAC address 00:26:22:14:d1:68.

Requested command outputs:

-> with aiccu off (after fresh reboot, disabled aiccu autostart for debugging):

ip -6 ro show:
default via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.21

ip -6 nei show:
[no output]

ip ro show:
default via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.21

ip nei show:
192.168.178.20 dev eth0 lladdr 00:26:22:14:d1:68 REACHABLE
192.168.178.1 dev eth0 lladdr 00:15:0c:50:a5:6d REACHABLE

ip tun show
[no output]

-> after starting aiccu:

ip -6 ro show:
::/96 dev sit0 metric 256
2001:4dd0:ff00:0xxx::/64 dev sixxs proto kernel metric 256
2001:4dd0:ff00:8xxx::/64 dev eth0 proto kernel metric 256 expires 86394sec
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev sixxs proto kernel metric 256
default via fe80::226:22ff:fe14:d168 dev eth0 proto ra metric 1024 expires 84sec

To clarify:
2001:4dd0:ff00:0xxx::2 is the tunnel endpoint,
2001:4dd0:ff00:8xxx/64 is the allocated subnet

ip -6 nei show:
fe80::226:22ff:fe14:d168 dev eth0 lladdr 00:26:22:14:d1:68 router STALE

ip ro show:
default via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.21

ip nei show:
fe80::226:22ff:fe14:d168 dev eth0 lladdr 00:26:22:14:d1:68 router STALE
192.168.178.20 dev eth0 lladdr 00:26:22:14:d1:68 REACHABLE
192.168.178.1 dev eth0 lladdr 00:15:0c:50:a5:6d REACHABLE

ip tun show:
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc

-> after turning aiccu off again

ip -6 ro show:
::/96 dev sit0 metric 256
2001:4dd0:ff00:8xxx::/64 dev eth0 proto kernel metric 256 expires 86395sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::226:22ff:fe14:d168 dev eth0 proto ra metric 1024 expires 85sec

ip -6 nei show:
fe80::226:22ff:fe14:d168 dev eth0 lladdr 00:26:22:14:d1:68 router STALE

ip ro show:
default via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0 proto kernel scope link src 192.168.178.21

ip nei show:
fe80::226:22ff:fe14:d168 dev eth0 lladdr 00:26:22:14:d1:68 router STALE
192.168.178.20 dev eth0 lladdr 00:26:22:14:d1:68 REACHABLE
192.168.178.1 dev eth0 lladdr 00:15:0c:50:a5:6d REACHABLE

ip tun show:
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc

As far as I understand AICCU somehow has to configure some dhcp, since I never explicitly told the system there was a subnet allocated to the tunnel or to give out leases for that subnet on the network. But I could not spot the dhcp server in the processes list: (the dhclient config seemd unsuspicious to me, but I obviously have no experience with the topic)

pi@rpi ~ $ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
[ ... things and stuff in brackets run by root ... ]
root 156 0.0 0.5 2884 1272 ? Ss 01:53 0:00 udevd --daemon
root 281 0.0 0.4 2880 996 ? S 01:54 0:00 udevd --daemon
root 286 0.0 0.4 2880 996 ? S 01:54 0:00 udevd --daemon
root 1553 0.0 0.2 1748 504 ? S 01:54 0:0...

[Jeroen Massar (massar)]

> default via fe80::226:22ff:fe14:d168 dev eth0 proto ra metric 1024 expires 80sec

It states 'proto ra' which indicates it received that prefix from a Router Advertisement. Typically that is the radvd process, hence check /etc/radvd.conf.

You could also check with a:
  grep 2001:4dd0:ff00:8 /etc/*

Also, please provide your aiccu.conf (stripping out the password of course) maybe somebody patched in a setupscript there and also check your /etc/network/interfaces.

> As far as I understand AICCU somehow has to configure some dhcp,

AICCU does not do that, not per default at least. There is good reason to: it opens up the network too much which could have security implications.

Next to that, as prefixes by SixXS are static, just configuring them in both /etc/network/interfaces and /etc/radvd.conf is much cleaner from a system POV.

[Lukas P. (lukas-gibix)]

Hey,

shame on me. I made an embaressing mistake ...

I too thought there must be some router advertisement around, but I did not find any radvd process or radvd.conf on my pi.

A while ago I had aiccu set up on my laptop and also an ipv6 dhcp server (wide-dhcp6), but I uninstalled them both, so I took for granted that my laptop wouldn't send out RA any more - but there was still a radvd running on it, that was what was causing the problems. I disabled it and now everything works as it should.

The only mistery that is left for me is the following:

Why did the pi only configure itself according to the RAs of my laptop when aiccu was running and totally ignored them when aiccu was not started yet?

Greetings!

[Jeroen Massar (massar)]

> Why did the pi only configure itself according to the RAs of my laptop when aiccu was running

Because AICCU loads the IPv6 module, which per default is not enabled on Raspbian.

And as the module is loaded, RA gets processed and you end up at your route.

Note that in #3 you show:
> ip -6 ro show:
> default via 192.168.178.1 dev eth0

Even though you are asking only for IPv6 routes, you get IPv4 ones back. Which should be seen as a bug in 'ip' btw IMHO.

[Jeroen Massar (massar)]

Marking as invalid as it is not a bug in AICCU, but unexpected behaviour in Raspbian which does not enable IPv6 in 2014, nor in 2015 like every other distro on the planet.

[Lukas P. (lukas-gibix)]

Wow, thank you Jeroen!
Wasn't expecting a reply any more.

Thanks also for the explanation.

You are a hero :)