With the update to 3.10, the DHCPv6 client no longer works reliably. While it does acquire an address, the address is lost 1 hour later (when it expires), even though renew requests are sent and replies are received.
Copying the old /usr/sbin/odhcp6c from a snapshot via schnapps makes DHCPv6 work again.
This is independent of https://gitlab.labs.nic.cz/turris/openwrt/issues/182 — applying that patch doesn’t fix my issue.
Can confirm. Restored version of odhcp6c from 3.9.6 works reliably, while 3.10 isn’t.
Which ISP are you using odhcp6c with? I’m with fiber7 and forwarded them an email I got from the odhcp6c developer — his guess is that the DHCPv6 unicast option is causing the trouble.
fiber7 as well - got here because they linked here from their status page. I did have occasional IPv6 connectivity issues before the 3.10 update though, but it resolved itself quickly enough or was mentioned on the status page, so I didn’t bother to dig further on these occasions - until now. I’m pretty sure it also worked right after the update, but I could be mistaken bcz I don’t usually notice the loss of IPv6 connectivity right away. Glad to hear they are working on it.
same issue here, 3.10.1 rc doesn’t solved it.
Is something related in dmesg or can you send us diagnostics, so we can take a look?
Nothing in dmesg. Wireshark captures show that odhcp6c unsuccessfully tries to contact the DHCPv6 server via unicast (this is an issue with the ISP).
I think odhcp6c should recover (i.e. fall back to broadcast) when it can’t reach the DHCPv6 server.
Anyway, fiber7 is working on a new DHCP platform, so they don’t want to make changes to the old one for the time being. Not sure whether the switch to the new platform happens before we could get a fix for odhcp6c in or not :).
Did you get an ETA for their new DHCP platform?
They said they’re hoping to roll it out in the next couple of weeks.
Just FYI: from day 1 (i.e. most definitely pre 3.10), my wan IPv6 address always disappears within 12 to 24 hours. I have never been able to get this working correctly.
My current status is that IPv6 is periodically up and down. It always works for 8–9 minutes and then it doesn’t for 1–2 minutes. (Tested via ping -6 -i 5 nic.cz, running for a long time.) I see nothing in the logs around those moments when it changes.
Some month or two ago the behavior was about the same as now, interrupted by the recently solved odhcp6c problem. Maybe the issue is something else than for other people in this thread; I can’t even dismiss the possibility of a problem on ISP’s side, and I can’t see how to go about localizing the problem (unfortunately I own no other IPv6-capable router).
As DHCPv6 was suspected, I looked at ip -6 route from the minutes when it worked and converted that into static IPv6 config (Foris WAN tab). However, this didn’t change the behavior noticeably. In the non-working periods there’s no default route in ip -6 route.
Hmm, the static IPv6 now seems to work OK as a workaround (half a day now). Maybe I made some silly mistake like not applying the configuration or something.
What is the current state in Turris OS 3.10.3? I’m with Init7 and since May, I’m not using my Turris as primary router anymore, because DHCPv6 was not working properly.
I haven’t noticed any related changes in the news, and I prefer to avoid experiments that are likely to disrupt real services (even if temporarily).
No change. For me the IPv6 address still disappears in less than 24 hours with 3.10.3.
Guys, thank you for your update.
@paja is aware of this issue and he’ll probably update odhcp6c and ask you for help, because we’re not able to reproduce your issue.
I had the same problem with Init7, IPv6 was just working for about one hour and then stopped. I changed odhcp6c and added a workaround option which allows ignoring of the Server Unicast Option, with that enabled, IPv6 works stable again.
But there seems to be another problem, either at Init7 or in odhcp6c. In the tcpdump trace I saw the following:
If you want, I can send you a pcap file.
My workaround has been merged in odhcp6c master. Can someone please update the package in Turris OS and maybe add a configuration option to enable that workaround? (Just add -U to odhcp6c command line parameters.)
Hello,
thanks for notifying us.
I see your pull request and I know that @paja updated odhcp6c a few days ago, but I don’t know how it went. At Monday we’ll look into it. We’ll keep you updated.
Don’t know if this could be a contributing factor: I’m running a configuration with a wan bridge. The WAN port is bridged with lan port 4 (for my cable/ISP’s IPTV box, which needs a DHCP address from an external server). Suggestions on how to configure extra logging for odhcp6c would be welcome.