Well, the general issue here is that indication of M- and O-Flags in the
RA is not a 100% clear indicator of what the DHCPv6 support on the link
is. Especially in the ISP-case O in practice does also mean: do stateful
DHCPv6, but only ask for IA_PD and not IA_NA. Since this is all so
ambiguous
Focusing on the current dnsmasq code, I guess the take-home message here
is that we're probably better off to revert the code which adds RIOs,
for now, as the only RIOs we're sending are exactly the ones which
Steven suggests should be suppressed. Should probably re-visit the issue
of more
Hi Simon,
just stumbled upon this and wanted to add some notes about that because
I have some experience with RIOs from OpenWrt already. If you want to
send RIOs because you want to be compliant with RFC 6204/7084 you should
send them with the prefix that was delegated to the router running
Hi Ilya,
please see the link to the OpenWrt ticket in my last mail which goes
about what happens in detail.
I don't remember if the user actually posted what OS the host ran on but
it seemed to be some kind of server so probably something linux/unix?
To summarize the issue since the ticket
Hello,
it looks like there is an issue with the latest 2.44 version of Dnsmasq.
I recently upgraded the Dnsmasq on my router from 2.43 to 2.44 and it started
to refuse DNS-Queries from PCs in the LAN. Downgrading to 2.43 made it work
again.
This is the output of host on a PC in the LAN:
host