Turris OS 3.10 breaks ipv6

My ipv6 configuration doesn’t work anymore after update to 3.10 (dual-stack). In systemlog if find the following error:

2018-05-13 17:37:56 notice netifd: Interface ‘wan6’ is enabled
2018-05-13 17:37:56 notice netifd: Network alias ‘eth1’ link is up
2018-05-13 17:37:56 notice netifd: Interface ‘wan6’ has link connectivity
2018-05-13 17:37:56 notice netifd: Interface ‘wan6’ is setting up now
2018-05-13 17:37:56 notice netifd: Interface ‘wan’ is now up
2018-05-13 17:37:56 notice netifd[]: wan6 (2311): ./dhcpv6.sh: eval: line 1: json_for_each_item: not found

here is the content of /etc/config/network:

config switch
option name ‘switch0’
option reset ‘1’
option enable_vlan ‘1’

config switch_vlan
option device ‘switch0’
option vlan ‘1’
option ports ‘0 1 2 3 5’

config switch_vlan
option device ‘switch0’
option vlan ‘2’
option ports ‘4 6’

config interface ‘wan’
option ifname ‘eth1’
option proto ‘dhcp’

config interface ‘wan6’
option ifname ‘@wan
option proto ‘dhcpv6’
option ip6assign ‘64’

config interface ‘loopback’
option ifname ‘lo’
option proto ‘static’
option ipaddr ‘127.0.0.1’
option netmask ‘255.0.0.0’

config interface ‘lan’
option ifname ‘eth0 eth2’
option force_link ‘1’
option type ‘bridge’
option proto ‘static’
option ipaddr ‘10.2.1.1’
option netmask ‘255.255.255.0’
option ip6assign ‘64’
option ip6hint ‘2’

Content of /etc/config/dhcp

config dnsmasq
option domainneeded ‘1’
option localise_queries ‘1’
option rebind_localhost ‘1’
option expandhosts ‘1’
option authoritative ‘1’
option leasefile ‘/tmp/dhcp.leases’
option resolvfile ‘/tmp/resolv.conf.auto’
option readethers ‘1’
option local ‘/fmf.netz/’
option domain ‘fmf.netz’
option rebind_protection ‘0’
option localservice ‘0’
option port ‘53’

config dhcp ‘lan’
option interface ‘lan’
option start ‘100’
option limit ‘150’
option leasetime ‘12h’
option dhcpv6 ‘server’
option ra ‘server’
option ra_management ‘0’
list dns ‘XXXXX’
list dhcp_option ‘6,10.2.1.1’
list domain ‘fmf.netz’

config dhcp ‘wan’
option interface ‘wan’
option ignore ‘1’

config odhcpd ‘odhcpd’
option maindhcp ‘0’
option leasefile ‘/tmp/hosts/odhcpd’
option leasetrigger ‘/usr/sbin/odhcpd-update’

config host
option mac ‘7c:2f:80:38:44:71’
option ip ‘10.2.1.2’

config dhcp ‘lan_Guest’
option start ‘100’
option leasetime ‘12h’
option limit ‘150’
option interface ‘lan_Guest’
list dhcp_option ‘6,10.2.2.1’
option dhcpv6 ‘server’
option ra ‘server’
option ra_management ‘0’
list dns ‘XXXX’
list domain ‘fmf.netz’

PS: i don’t use kresd but only dnsmasq - hope this shouldn’t interfere

how did you notice, are you using a ip6-only service?
like they say on zkill: nothing of value was lost :wink:

otherwise i am not sure if you can (or should) use same domain for different networks.

I think in the network config option ip6assign ‘64’ should be option reqprefix '64'.
ip6assign is used to assign already existing IPv6 prefixes that you have somehow optained (usually through DHCPv6).
reqprefix on the other hand is used to tell the router (that is on the other side of that interface) that you want to have a /64 prefix which then will be assigned to that interface through DHCPv6.

Because there is no interface that have requested an IPv6 prefix or provides a static usable prefix the dhcpv6.sh script probably doesn’t know where to get the prefix for assignment to the clients and so generates that error.

Nope, it’s an error that will be fixed in 3.10.1: https://gitlab.labs.nic.cz/turris/openwrt/issues/182

@paja I still can’t see this update in standard branches (RC, daily, nightly, test) – any idea what’s best to do for users in the meantime? Downgrade to Turris OS to 3.9?

We hope that this is fixed in the nightly branch (also it should be in daily and test), but it will be also in RC, which we’d like to release soon. :wink:

So when I look at filenames in https://repo.turris.cz/omnia-nightly/packages/base/ I look at a bad place? (the old version is shown there)

@paja bumped release (so after date there is release version 11), because he tried to update libubox to the latest version, but what I know it broke many things, so we decided to keep the old version and decided to fix odhcp6c.

2 Likes

Oh, thanks, I didn’t understand that by reading the issue.

It’s in RC. Does IPv6 work for you now? Now I’m stuck with another problem:

2018-05-30 23:08:52 info kernel[]: [   43.601350] mvneta f1034000.ethernet eth1: Link is Up - 100Mbps/Full - flow control off
2018-05-30 23:08:52 info kernel[]: [   43.601371] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
2018-05-30 23:08:52 err odhcp6c[4276]: Failed to send DHCPV6 message to ff02::1:2 (Address not available)

Ping through WAN to v6 link-local address of the ISP’s device does work, so it still seems to be a problem with DHCP, though I can’t see where…