Forums

Is there anybody using ipv6 op de vuduo? I encounter a very strange problem:

I can't get ipv6 working using ifup on mu vuduo (clean flash date July 6th, 2012, both 2.1 and 3.0). After the fresh install directory /proc/sys/net/ipv6/conf/eth0 is missing. ifup -f eth0 gives a ipv4 adres only. After ethtool -r eth0 i get a directory and a working ipv6-address. Then ifup -f eth0 again and both the directory and the ipv6 address are gone again. See below! I am curious whether any of you guys see the same behaviour? (maybe only vuduo?)

Rob Meerwijk


root@vuduo:/proc/sys/net/ipv6/conf# ls -ltr
dr-xr-xr-x 0 root root 0 Jul 11 00:38 lo
dr-xr-xr-x 0 root root 0 Jul 11 00:38 default
dr-xr-xr-x 0 root root 0 Jul 11 00:38 all
root@vuduo:/proc/sys/net/ipv6/conf# ethtool -r eth0
root@vuduo:/proc/sys/net/ipv6/conf# ls -ltr
dr-xr-xr-x 0 root root 0 Jul 11 00:38 lo
dr-xr-xr-x 0 root root 0 Jul 11 00:38 default
dr-xr-xr-x 0 root root 0 Jul 11 00:38 all
dr-xr-xr-x 0 root root 0 Jul 11 00:47 eth0
root@vuduo:/proc/sys/net/ipv6/conf# ifup -f eth0
udhcpc (v1.19.4) started
Sending discover...
Sending select for 192.168.178.21...
Lease of 192.168.178.21 obtained, lease time 864000
/etc/udhcpc.d/50default: Adding DNS 192.168.178.1
root@vuduo:/proc/sys/net/ipv6/conf# ls -ltr
dr-xr-xr-x 0 root root 0 Jul 11 00:38 lo
dr-xr-xr-x 0 root root 0 Jul 11 00:38 default
dr-xr-xr-x 0 root root 0 Jul 11 00:38 all

root@vuduo:/proc/sys/net/ipv6/conf# ifup -f eth0
udhcpc (v1.19.4) started
Sending discover...
Sending select for 192.168.178.21...
Lease of 192.168.178.21 obtained, lease time 864000
/etc/udhcpc.d/50default: Adding DNS 192.168.178.1
root@vuduo:/proc/sys/net/ipv6/conf# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1D:EC:01:9B:C4
inet addr:192.168.178.21 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11218 errors:0 dropped:2243 overruns:0 frame:0
TX packets:4836 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7650473 (7.2 MiB) TX bytes:478123 (466.9 KiB)
Interrupt:16

root@vuduo:/proc/sys/net/ipv6/conf# ethtool -r eth0
root@vuduo:/proc/sys/net/ipv6/conf# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:1D:EC:01:9B:C4
inet addr:192.168.178.21 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 2001:980:5b5f:1:21d:ecff:fe01:9bc4/64 Scope:Global
inet6 addr: fe80::21d:ecff:fe01:9bc4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11315 errors:0 dropped:2271 overruns:0 frame:0
TX packets:4875 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7659528 (7.3 MiB) TX bytes:483178 (471.8 KiB)
Interrupt:16
Edited by robadouche, 12 July 2012 - 21:57.

One of the team members runs completely on IPv6, but he's on holiday atm... I've never heard him complain about anything though.

I just put my DM800se OpenPLi 3.0 on ipv6, i just added these lines to /etc/network/interfaces:

iface eth0 inet6 static
address 2001:610:600:xxxx::3
netmask 64
gateway 2001:610:600:xxxx::1

root@dm800se:/etc/network# ping -6 www.google.com
PING www.google.com (2a00:1450:4007:801::1012): 56 data bytes
64 bytes from 2a00:1450:4007:801::1012: seq=0 ttl=52 time=22.162 ms
Edited by gjstroom, 14 July 2012 - 22:52.

I see the same thing with openpli-3.0 on both dm500hd and vu ultimo..quite strange.

I see the same thing with openpli-3.0 on both dm500hd and vu ultimo..quite strange.

Why do you want to use the ifup scripts ?
If you add the ipv6 settings to /etc/network/interfaces and do a '/etc/init.d/networking restart' it works...

One of the team members runs completely on IPv6, but he's on holiday atm... I've never heard him complain about anything though.

That would be me

- Yes it works
- No not with the standard scripts

I have a dedicated script that puts the ipv6 adresses on the interface explicitly.

It can be done without that, you have to make sure radv is "on" then (sysctl) and use a radvd server on the network.

Configuring it manually would work of course. Don't really need ipv6 on the stb's, but for the sake of a fully functioning ipv6 network here, what needs to be done to get the dreambox to pick up it's address information from radvd at boot? ethtool -r eth0 will reneg the physical link and when the interface is restarted it will work.. Just at boot time it doesnt.

I have native ipv6 in my network, radvd running and all other clients picks up their ipv6 addresses, routes and dns without any issues.
Edited by spock, 15 July 2012 - 16:17.

Sysctl is your friend... enable accept_ra, which apparently is "off" on the stb kernels. If it's on, and it still doesn't work, there is typically a problem with your radvd server's configuration.
Edited by Erik Slagter, 15 July 2012 - 16:27.

Tried that too, after boot I see this:

root@vuultimo:~# sysctl -a | grep accept_ra
sysctl: error reading key 'net.ipv4.route.flush': Permission denied
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.accept_ra_defrtr = 1
net.ipv6.conf.all.accept_ra_pinfo = 1
net.ipv6.conf.all.accept_ra_rtr_pref = 1
sysctl: error reading key 'net.ipv6.route.flush': Permission denied
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.default.accept_ra_defrtr = 1
net.ipv6.conf.default.accept_ra_pinfo = 1
net.ipv6.conf.default.accept_ra_rtr_pref = 1
net.ipv6.conf.lo.accept_ra = 1
net.ipv6.conf.lo.accept_ra_defrtr = 1
net.ipv6.conf.lo.accept_ra_pinfo = 1
net.ipv6.conf.lo.accept_ra_rtr_pref = 1

eth0 doesn't get listed, just like for original poster.

so with ethtool -r eth0:

root@vuultimo:/proc/sys/net/ipv6/conf# ethtool -r eth0
root@vuultimo:/proc/sys/net/ipv6/conf# sysctl -a | grep accept_ra
sysctl: error reading key 'net.ipv4.route.flush': Permission denied
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.accept_ra_defrtr = 1
net.ipv6.conf.all.accept_ra_pinfo = 1
net.ipv6.conf.all.accept_ra_rtr_pref = 1
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.default.accept_ra_defrtr = 1
net.ipv6.conf.default.accept_ra_pinfo = 1
net.ipv6.conf.default.accept_ra_rtr_pref = 1
net.ipv6.conf.lo.accept_ra = 1
sysctl: error reading key 'net.ipv6.route.flush': Permission denied
net.ipv6.conf.lo.accept_ra_defrtr = 1
net.ipv6.conf.lo.accept_ra_pinfo = 1
net.ipv6.conf.lo.accept_ra_rtr_pref = 1
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.accept_ra_rtr_pref = 1

And then it works.

Hmm, yeah, I think I know what's the problem. I have made a fix for that long ago, but for lack of interest in ipv6 it never got included.

The problem is that some startup script does this "ip addr flush dev eth0" or even on dev lo. If you're only using ipv4 that doesn't hurt, but if you're using ipv6 it completely ruins the ipv6 system. You cannot flush ipv6 link local addresses from interfaces without all sorts of trouble. The only way to get out of the spoiled state is to bring the interface down and up. I tend to do that with: ip link set dev eth0 down; ip link set dev eth0 up, but the ethtool method apparently also works. So the solution is to replace the "ip addr flush dev eth0" by "ip addr flush dev eth0 scope global". Maybe you can try it, and if it works okay, we can include it in the image. The problem is that I can't test it myself, because I have my own interface setup script.

You were right, these two files did "ip addr flush dev":

root@vuultimo:/etc# grep -r "ip addr flush" *
udhcpc.d/50default:					  ip addr flush dev $interface
wpa_supplicant/functions.sh:				  ip addr flush dev "$WPA_IFACE" 2>/dev/null

After adding "scope global", the problem is gone. Not sure if the change is needed in wpa_supplicant functions.sh, but I added it anyway. (I'm on wired)
Edited by spock, 15 July 2012 - 17:12.

I will push the change to the feed shortly.
Edited by Erik Slagter, 15 July 2012 - 17:14.

Sounds good, thanks!

Great! Thanks for the help.

Rob Meerwijk

The change has been delayed somewhat because the package that the change has to be applied to cannot be directly modified by us (long story...) I will have to resolve that first.

Just like with ipv6 in general, no rush!

Well I shouldn't have said "shortly" before overseeing the consequences

Just noticed your commit. My manual fix was overwritten when I updated the stb, and now it's no longer working, "scope global" was not added to the udhcpc script like the commit seems to be supposed to do. Did it work for you?

The fix is right, but the way to get it into the image may not be (yeah, openembedded is VERY complex, especially with OE-core-3). I was going to check an re-apply anyway.

Sorry, I think I might have overwritten my own fix by myself as I was trying to fix something else with busybox.

Apart from it's complexity I've found openembedded a lot of fun to play with, it's quite easy to make fixes and adjustments for personal needs when building the image myself. Everything just seems to fall into place and work, but I have to admit I still have a lot to learn.

I can't understand why this change didn't work though, it all looks good.