My stock beryl shows:
network.globals.ula_prefix='dd6d:4920:6bc5::/48'
which somehow also results in:
dhcp.lan.dns='dd6d:4920:6bc5:0000:0000:0000:0000:0001'
Which seems… strange / wrong; but I’m not an expert in IPv6.
Can anybody confirm this is right / wrong?
Thanks!
This format is correct, dd6d:4920:6bc5:0000:0000:0000:0000:0001 can be simplified to dd6d:4920:6bc5::1
Yeah, this I know. But considering this was hard-coded / computed; shouldn’t this be a local address (i.e. falling in fd00::/8)?
It would seem that whatever software computed the dd6d… address somehow derived it from a fd6d… one (which would be correct).
For sure, none of my devices belong to dd6d:4920:6bc5::/48
Ideas?
Same issue here with my GL.iNet White with firmware 3.201. My address range in not in the ULA range either. I got something in dd21. ULA has to be in fc00::/7. This is a factory-reset device, just with IPv6 enabled. Does anyone know where this is created in the source code? Looks like some bits got shifted or lost. The original OpenWrt code starts with fd always.
That picture is from this OpenWrt wiki entry: NAT6. Which script in the world of GL.iNet triggers that; is that open-source?
I guess, that replacement was triggered because I changed (not in LuCI but in your Web interface) the IPv6 LAN mode from ‘native’ to ‘NAT6’ and then back again to ‘native’. In the native mode, such a ULA does not make sense and even confuses my LAN clients not to use the global prefix from upstream. Consequently, the issue report would be undoing that change when going back from ‘NAT6’ to ‘native’ in the GL.iNet Web interface.
Anyway, which script in the world of GL.iNet triggers that; is that open-source? If it is on GitHub, I could create a Pull request.
You can modify the script
/etc/init.d/gl_ipv6
Great. Thank you! That saved me a lot of time searching myself. Do you spot the mistake and reported that internally? set_lan_relay overwrites the ULA. Instead it has to use the ULA backup.
--- /etc/init.d/gl_ipv6 (3.201-release)
+++ /etc/init.d/gl_ipv6 (working copy)
@@ -148,10 +148,5 @@
set_lan_relay()
{
- local ula_prefix=`uci get glipv6.globals.origin_ula_prefix`
- if [ "$ula_prefix" = "auto" ];then
- uci set network.globals.ula_prefix="auto"
- else
- uci set network.globals.ula_prefix="$(echo "$ula_prefix" | sed -e "s/^./d/")"
- fi
+ uci set network.globals.ula_prefix=`uci get glipv6.globals.origin_ula_prefix`
uci set network.lan.ip6assign="64"
uci set network.lan.ip6hint="0000"
Or do I have to report this myself via another support channel; which channel do you suggest?
I just reported internally.
I ran into the same issue with a GL-AXT1800 today. Very strange. Addresses starting with ‘dd’ are not ULA addresses and a host will not treat them as such. ULA addresses are only within fd00::/8. +1 for fixing this please.
This issue has been fixed and you can get snapshot firmware from this link:
https://github.com/gl-inet/gl-infra-builder/actions/runs/2652515513
Not fixed. The code of the script changed, yes. I can see that. However, the ULA is still changed after each start. And, this time, I do not know which script or line of code does it. Any idea? At runtime, I am able to change the ULA via LuCI (and UCI of course). But after a reboot, the ULA is broken again.
uci get glipv6.globals.origin_ula_prefix
gives the correct ULA, always. Something else sets network.globals.ula_prefix with that ddxx somewhere.
Did you test the snapshot firmware in the link above?
Went for snapshot 0815, did no keep settings, and now the issue is not reproducible anymore. Not sure what happened because I know the code of line which did that. And I did not change that. Anyway, solved. 
IIRC, in some code paths the ULA prefix was saved for later restore (when switching from Native to NAT6 or something like that). Maybe it was saved before the upgrade and restored from there?
Did the firmware upgrades this time and back then, without keeping the settings.
Ah, sorry I had the impression you kept them. Then I’m not sure really, I haven’t seen it happening since.
After testing 4.3.7 on a beryl it happens again this behavior.
Cannot tell if this was the behavior in early 4.x releases