Strange ULA prefix in stock Beryl

Routers
21

Re-tested and able to confirm, tested 4.3.22 on a Shadow (GL-AR300M16).

I tested this by installing the latest firmware without keeping the settings, changed the WAN to PPPoE and IPv6 to ‘native’. My devices get a dysfunctional DNSv6 server assigned, both via IPv6-Router-Advertisements and the Stateless DHCPv6-Server. However, something changed because the server is now fd1b:801:b781::1.

No idea, where that is coming from. Furthermore, I am not sure if the GL.iNet team understands the severity of this issue at all. This blocks Internet surfing, all web services, I have no Internet access because of this, not to

This is because some network stacks do not expect a broken DNSv6 server and do not fallback to the DNSv4 server. A prominent and easy to test example is Ubuntu 16.04 LTS which still gets security updates via ESM. Although not widespread anymore, I mention this just as an easy to test example. There are thousands of stacks and apps out there which behave the same.

The workaround is to:
a) add a DNSv6 server like the link-local address of the GL.iNet in the client
b) disable IPv6 in the client and go for just IPv4
c) disable IPv6 in the GL.iNet

The latter is not good behavior if the Internet access is actually IPv6 based and uses translation techniques, sharing one IPv4 with several other users. I over-use then in an unexpected way that IPv4 address, even with each DNS query.

  1. How can we as community help?
  2. GL.iNet are you able to reproduce this issue?
  3. Should we report this issue in a different way (different channel or at OpenWrt)?

Although this was reported four years ago already, at that time the cause for the dysfunctional DNSv6 server was different, this scenario is still not regression tested by GL.iNet.

22

Is anyone able to confirm @aalmenar an my findings?

I analyzed a bit further. In the script /etc/init.d/gl_ipv6, to be more precise in set_lan_dns() the UCI variable glipv6.lan.lan_ip6addr is used. That is created from network.globals.ula_prefix. At the end the result is copied over to dhcp.lan.dns.

However, the DNSv6 server does not listen at that ULA and refuses any DNS queries. I have not found the culprit for that. Instead, I changed set_lan_dns() and hardcoded my ‘link local unicast address’ (the address is the one within fe80::/64). Now, the IPv6 Router Advertisements and the Stateless DHCPv6 sent that address. And that address works, answers to DNS queries.

If you do not dare to change that script, via SSH, you can go for

uci set dhcp.lan.dns='fe80::e695:…the remainder of your hardware MAC'
uci commit
service odhcpd restart

which has to be done after each restart. Therefore, changing the script prolongs better.