I just switched provider … previous one had fixed IPv6 prefix to
delegate, this one only dynamic IPv6 prefix to delegate.
I use OpenWRT router.
I have many linux based devices and all of them get a global IPv6
address delegated and default IPv6 gateway from OpenWRT router in router
advertisement except CoreELEC devices…
Previously I manually gave a fixed IPv6 address and default route to make IPv6 work.
I can still manually do this but the dynamic provider IPv6 address range
may at any time change.
I read about a trick to create and edit /etc/sysctl.d/ipv6.conf and
systemctl restart systemd-sysctl but such does not help. In fact
sysclt shows these values correct.
I think somehow the network dhcp client part is not working for
IPv6. Most other linux based devices I have use other dhcp client
software.
Any hint? Perhaps I should find a dhcpcd implementation for CoreELEC?
Similar issue here, I used to have V6 SLAAC address but after upgrade to 19.4 (also tried 19.5, built myself as I need to tweak some kernel parameters) it breaks. I can have SLAAC and DHCPV6 addresses but ping6 does not works, after reboots it works for a while then ping6 stops from working.
Btw, have you tried CE setting in menu, set connection IPV6 to auto?
sigh…so we are in the same trap here bro.
I’m thinking about openwrt, what’s your firmware version? I recently update to 22.03.RCxx, it used to work on 21.02…
emmm, I did some research and I think openwrt is not the culprit.
My wired win10 PC and wireless laptop can both obtain V6 addresses with DHCPV6 under the same openwrt router config, my android phones can obtain also V6 addresses with SLAAC, so the router config is OK.
Another thread with similar issue on forum (even the same box as me), it motioned wireless but I am using wired connection on my X96 max+:
@avin
sure : tcpdump shows the advertisements, and, sure : all other devices (including various linux ones) assign a global address from such advertisements … for some reason the CoreELEC IPv6 client DHCP implementation seems to ignore them.
That’s why in OP I wondered if one can find an alternative (e.g. ISC) client DHCP implementation for CoreELEC.
It used to work like charm… back to 19.2 maybe, from the v6 address containing “ff:fe” flag I can say it is done by SLAAC, no DHCPv6.
Now it can get an SLAAC generated and an DHCPV6 address, the DHCPv6 one “sometimes” work, by saying “work” I mean you can ping6 or use mtr tranceroute etc. but the SLAAC one never work, you ping6 to the SLAAC address from another client under same lan results in 100% packet loss.
I think some commits after 19.2 cause this.
To assemble a global address even SLAAC needs to know a public subnet prefix. This prefix, when dynamic, is typically learnt and updated from Router Advertisements (see RFC 4862). A static public subnet prefix (if one has static prefixes to delegate) can also be configured manually.
When talking about DHCP I meant: the v6 client part. Some implementations (like dhcpcd) implement this part just fine (and it works with OpenWRT router). But the CoreELEC connman seems (as you say) to have worked and seems to meanwhile be broken now. I cannot tell about 19.2 since back then (previous provider) I had a static public subnet prefix to delegate. Today (current provider) a dynamic one.
openwrt actually has two approaches for dhcpv6 handling, default is dnsmaq for DNS+DHCPv4 and odhcpd for DHCPV6 only, but you can delete odhcpd and dnsmasq then install dnsmasq-full to handle both v4 and v6 DHCP. Just Google for answer.
Maybe you need to reconfig openwrt router, I haven’t done it myself though as I have only one router and am working from home.
Annnd, did some more researches, not so sure if it is 100% caused by CE: Dnsmasq-full vs odhcpd for IPv6 (DHCPv6/SLAAC)
@avin
Thanks a lot for the OpenWRT forum link. So OpenWRT offers full dnsmasq as alternative to default odhcpd. The problem there, however, if I read correctly, is that global v6 addresses disappear, whereas, in my case global v6 addresses never appear to begin with. That’s not exactly the same. Also, there is probably a good reason why odhcpd is default.
Like you I am hesitant to try the full dnsmasq as it may affect the majority of clients and perhaps fix the few CoreELEC devices. In fact, CoreELEC itself works (even without global v6 address) so functionality-wise there is not much gain. Also, the provider leased dynamic prefix has a decent lifetime so there is a workaround (as explained) to choose and assign manually (like SLAAC would do automatically).
This all somehow reminds me of Postel’s law “be conservative in what you send, be liberal in what you accept”. The principle is essential to vendor and implementation independent networking cooperation. Many bugs or protocol miscommunications relate to this law.
So it seems odhcpd may not adhere to the law in that it sends RAs which at least one client (CoreELEC) does not accept. But then it also seems CoreELEC may not adhere to the law in that many other clients do accept them.
As such I would rather prefer CoreELEC to provide a client alternative than having to resort to a server alternative which may affect multiple other clients. Some working client alternatives are known and changing one single client software has less or no potential impact on all other clients.
This is why a dhcpcd or other working CoreELEC alternative could provide solution without collateral damage. I hope such alternative (or connman fix or tweak) might be considered by the CoreELEC developers.
From my understanding LibreELEC/CoreELEC both adopt connman as network config interface, and always use most recent upstream codes commits, so it is also possible the issue of connman. I think there should be some debug settings in connman that if turned on can reveal more for the issue, but I am not very familiar with this…
As for the benefits of obtaining IPV6 for CE, mine is to speed up P2P torrent download speed for aria2 on the box. When IPV6 was OK, I can see V6 peers during download, but now they are gone. Now it is not an big issue as I have public V4 address, but ISPs in my area begin to restrict on public V4 addresses assignment, so in the near future this will become a headache.
@avin
I have OpenWRT router announcing dynamic global prefix and default route and local DNS server address, and then, I have a (gentoo) Linux server running radvd announcing fd00::/64 prefix (in which I use some static addresses for local DNS convienience in LAN (e.g. ssh) connections). I have run connman in debug mode (and rsyslog-ed to local syslog server and also saved in a screen terminal log).
It seems CoreELEC connman does see the RA’s from the Linux server but not those from the OpenWRT router. Perhaps one reacts quick enough. But even the Linux server fd00::/64 RAs do not result in a SLAAC address.
Other hosts on LAN process both just fine. The debugs do not mention anything about the dynamic global prefix RAs. It could be the packets are not processed or it could be they are silently ignored.
I considered building (as I often successfully did) own CoreELEC 19.5-Matrix_rc2 myself (and tweaking connman output) but, today, I run into soms compilation issues. The standard connman debugs are rather fine though (if you have source code at hand).
I also looked at connman git log but see no recent commits documenting RA handling changes. Same for odhcp6c git log.
Right now I think (looking at both source codes) CoreELEC connman relies on Router Advertisement reply from its ICMPv6 solicitation but OpenWRT odhcp6c does not react to them. It just reacts to strictly Neighbor Discovery ones. On the other hand OpenWRT odhcp6c consistently periodically sends Router Advertisement and I sped them up and slowed down Linux server ones. But to no avail. It seems the periodical Router Advertisements hardly hit any connman code.
Since we are trying to figure out this issue and it’s on weekend, I decided to compile a openwrt firmware with both dnsmasq-full and odhcpd-full for my router to change the server for handling DHCPV6, in this way I can easily switch config back if anything went wrong.
Good thing is it only took an additional of around 200kb space.
I managed to switch the DHCPV6 server to dnsmasq-full using similar config found in this thread googled: Configuring DNS using dnsmasq DHCP and dynamic IPv6 firewall rules
My win10 PC and android phones all get DHCPV6/SLAAC addresses normally, CE running on X96 max+ too gets an SLAAC address with “freshly-booted” router and lasts for more than 12 hours (the lease time I set). I tried to restart dnsmasq and lan interface, then ping6 in CE fails again.
So by combining what we have found so far this issue is caused by connman.
For reference if any other people encountered the same, I found a simple trick to make IPV6 address work again :
Disable DHCPV6 address assignment on router/gateway
ssh to CE and type
systemctl restart connman
Then using ifconfig or ip to confirm the V6 address is gone, and repeat step 1(this time enable DHCPV6 on your router) and 2.
I tried several times, this brings IPV6 back on CE at a rate of about 60%. ping6, mtr, traceroute all work. I can access box’s global V6 address using my phone on mobile network with traffic rule opened on router.
Maybe this is not a guaranteed action, but just give it a shot.
If it fails ,then a router reboot can make IPV6 on CE works, as long as your V6 prefix stays…
Answers being more or less : there is no dynamic v6 public global connman support, and, no ELEC or connman developer can check and test it anyway … contributions welcome.
Perhaps I will try to contribute
I think both default OpenWRT odhcp6c and default CoreELEC connman could do better in trying to interoperate.
connman has hardcoded RTR_SOLICITATION_INTERVAL 4 seconds and RS_REFRESH_TIMEOUT 3 seconds whereas odhcp6c has default RA periodic interval between 200 and 600 seconds. This is a factor 100 mismatch (between triggered and periodic) and either odhcp6c could react upon solicitation triggered or connman could make solicitation intervals configurable, and, idealiter, could process the periodic RAs rather unconditionally.
Luckily there often happen to exist some reasonable workarounds which fit particular people’s setup and requirements.
I personally would prefer and suggest CoreELEC (and LibreELEC for that matter) considers to offer choice in client IPv6 addressing software, or, someone fixes connman RA handling.
update: I set odhcp6c random default RA interval between 2 and 3 seconds but even that does not result in connman global IPv6 address assignment. So I guess the periodic and triggered RAs are different (perhaps different link-local multicast destination?) which makes communication fail even easier.
Oh, so good news and bad news mixed in your discoveries…
good news is you have located the reason, bad news is compiling connman is way beyond my abilities…
If you can make a patch to connman, will I be able to try it on my local build?
@avin
I need understanding of the protocols and both odhcp6c and connman implementations.
I tested RA flags in OpenWRT odhcp6c and SLAAC on/off but it all does not seem to help.
So maybe odhcp6c gets some aspects of these flags a bit too strict for connman to accept.
But the most challenging obstacle is thorough testing and avoiding regressions.
It may be better to (if somehow possible) file a defect against connman and/or odhcp6c.
But that may also end up in a mutual argument that the other party is wrong.
Finally, there may be unclear specifications in RFC and both parties may argue to adhere to RFC.
I’ll try to see if I can file such defects.
No worry, take your time. I think this is already a “niche” demand so maybe the dev team here is not be so interested in it. LibreELEC I remembered even positioned itself as “running on ipv4 only behind NAT”…
Let me know if you need my assistance on anything. I am not a developer but I can at least compile openwrt and CE to my needs.
fwiw: I am testing Nexus 20 and the IPv6 addressing is just fine there…
link-local address is fe80::ff:fe0a:e01/64
and CoreELEC gets router advertised prefixes and slaac sets interface addresses fd00::ff:fe0a:e01/64
and aaaa:bbbb:cccc:dddd:0:ff:fe0a:e01/64
from the prefixes fd00::/64
and aaaa:bbbb:cccc:dddd::/64
Well in my case CE on X96 Max+ can get SLAAC or DHCPV6 addresses fine, with ifconfig or ip I can see v6 addresses are there, and if upstream op has V6 prefix updated from ISP, CE box can also update the v6 address prefix!
the thing is ping6 fails, so basically v6 route fails… tested on 19.4 and 19.5 nightly but no Nexus 20, so I need to try the cutting edge one?
