I can easily reproduce this when moving between 2 MOXes 5g wlan with an android phone.
(It connects to first WLAN OK(router with WAN), then you move to other MOX and then back and the phone is effectively DNS confused )
Note that with stable OpenWRT on an old TP-link WDR4300 router this doesn’t happen, so it seems knot or resolver are the prob.
(I am seriously tempted to use the same config with just dnsmasq as DNS+DHCP - is there a safe howto how I can just use dnsmasq on latest Turris for DNS without knot and resolver? I don’t mind dnssec for now (if it helps figuring out a problem either in knot or resolver OR ruling it out of the troubleshooting game completely). )
If the problem only starts after moving among the WLAN stations, I don’t think it can be because of DNS resolver itself. Normally I’d recommend starting by verifying some DNS-less stuff, e.g. ping 1.1.1.1, but I’m not aware of such things being easy to do on a phone.
EDIT: actually, https://1.1.1.1/ is a working site, and a reasonable browser should show at least something even without DNS.
that’s the funny thing
that if I apply the workaround in the above thread with options tag … (so yes, those devices work with 8.8.8.8 but not with my other dns server(pi-hole) )
then moving between WLANs just happens and the phone is connected.
From time to time same happens even with the same WLAN, but a 100% reproduction case that happens instantly is to move between two MOXes.
And the bad thing is that I see this behaviour with most of my devices(even windows 10 clients) so the dhcp options tag ‘googledns’ is not a solution for me
OK, if I understand it correctly assigning 8.8.8.8 with DHCP works around the problem for you, like
list dhcp_option '6,8.8.8.8'
(or maybe there’s some other way I don’t know of)
… but I don’t understand how pi-hole is related to this – I thought you were using (almost-)default DNS setup from MOX.
correct, dhcp option 6 pointed to google works around the problem
the pi-hole in the setup is the funny part, since with stable openwrt with same option 6 pointed to pi-hole(which then goes to google) works properly.
With mox/turris it doesn’t (even though it should transitively get to same google packets).
Well that said, it seems I will just have to go and do some tcpdumps on mox and on the clients (which on android will be a bit weird, but let’s hope the mox internet gateway will have everything) to figure out the best course of action.
Alt. I am still curious if I’d have only dnsmasq if it will work - how can I try this hypothesis?
resp. I got intrigued about the default knot redirection of dns to itself in the network to work as cache - how does that work?
(since I am always specifying option 6 in dhcp - is it next in line?)
The only redirection of DNS to Turris is via that DHCP option, I believe. If you always overrode that to something that does not redirect to Turris (could be e.g. pi-hole forwarding to Turris), I don’t think you’re using a resolver from Turris. tcpdump should show where the packets really go.
So I found a workaround - create a dummy relayd device on top of JUST LAN network,
it seems the dhcp requests don’t get properly relayd
So a " Protocol: Relay bridge" in Network interface is all that is needed + 1 wasted IP from internal range.
It is kinda weird, since I hoped if everything is in the same bridge device the traffic gets properly resent, but it seems dhcp(with options) needs special handling
the confusing part is that stable OpenWRT doesn’t need this relayd running on top (in fact I don’t even have it installed on old router) and forwards packets properly, where Turris(resp. latest OpenWRT trunk?) on a bridge doesn’t forward all the packets - is this a feature? or a bug?
OK, small update - so all this happened only because "LuCI extensions
Several addional tabs and controls for the advanced LuCI interface. " was installed along - so I guess if one removes relayd from that package cluster, so it becomes safe(and won’t introduce this weird behaviour of not forwarding dhcp anymore), it’d be cool.
Alt. it makes sense to warn about this change of default bridge behaviour!
OK - so above works only if the MOX is in “Computer” mode, if I have it as a router, I am back to original issue and even the relay bridge doesn’t work
I have the same issue on WiFi with TO4. I guess it start with TO4 beta10. After reboot all is usually working fine but the problem regards missing DNS resolver is starting after 2-3 days again.
Update to the RC yesterday. Let see if it is working better now.
Still the same issue here.
)