Strange one.. My MT6000 running 23.05.5 r24106 has been running fine for a few weeks now.. Then suddenly this evening I am having issues with the WIFI - on my phone it will connect, but regularly disconnect - while my smart tv wont even connect..
Log entries showing disconnects for 1 device (phone)
Fri Nov 1 23:21:57 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Nov 1 23:21:57 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Nov 1 23:21:57 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Fri Nov 1 23:21:57 2024 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx auth_alg=open
Fri Nov 1 23:21:57 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Fri Nov 1 23:21:57 2024 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Fri Nov 1 23:21:58 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Fri Nov 1 23:22:02 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Nov 1 23:22:02 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Fri Nov 1 23:22:02 2024 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx auth_alg=open
Fri Nov 1 23:22:02 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Fri Nov 1 23:22:02 2024 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Fri Nov 1 23:22:36 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Fri Nov 1 23:22:47 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Nov 1 23:22:47 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Fri Nov 1 23:22:47 2024 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx auth_alg=open
Fri Nov 1 23:22:47 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Fri Nov 1 23:22:47 2024 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Fri Nov 1 23:23:29 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
Fri Nov 1 23:23:59 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: authenticated
Fri Nov 1 23:23:59 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated (aid 1)
Fri Nov 1 23:23:59 2024 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx auth_alg=open
Fri Nov 1 23:23:59 2024 daemon.info hostapd: phy1-ap0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Fri Nov 1 23:23:59 2024 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED xx:xx:xx:xx:xx:xx
Fri Nov 1 23:24:52 2024 daemon.notice hostapd: phy1-ap0: AP-STA-DISCONNECTED xx:xx:xx:xx:xx:xx
I have restored a backup from a couple of days ago, just rule out any changes, but it makes no difference.. Is the logging telling us anything?
I sometimes see this also happen, though it often happens when i sysupgraded some old iot devices want to lease the same lan ip at the same time, i think there may be some type of race condition going on between devices being stuck on a client sided reseverd lease and devices which want a new lease.
What i often do is first restart dnsmasq and then wifi can you check if it still persists then?
Very similar, if not exactly the same symptoms will occur if your Internet connection is down.
Standard "user" devices will almost all do a "Captive Portal Detection" on connecting to a wireless network. If a Captive portal is detected you will get a login page, if there is no Internet at all, the user device will disconnect and look for more wireless networks it may know about, before cycling round to yours again - giving the type of logs you are seeing.
Worth checking...
I spent till way too late night trying to get to the bottom of the issue, including reinstalling the firmware (had to go via uboot and OEM firmware as it wouldnt come back up at one point).. Things seemed better with the latest snapshop firmware, but then this morning Im seeing random dropouts again..
Its not been a month yet since I purchased the router, and I really dont want to return it, as it ticks all the boxes.. But if its not resolved by the end of this weekend I will have no option but to return it to Amazon, just in case its a hardware issue.
I did a quick google on this (CPD) and somebody said turning off "rebind protection" might .. I'd turned mine off to see how things go.. (getting desperate, so willing to try anything)
That is probably not going to do anything and if it does it is masking a serious problem.
It could be a hardware problem, or even overheating (check the vents are clear), but I doubt it.
This means, I think, that the client device has actively disconnected, rather than been dropped by the router. As I mentioned, this is what would happen if the client device could not detect either a captive portal or an active Internet feed.
Does it work for some devices?
Have you by any chance enabled OWE (Opportunistic Wireless Encryption), but not enabled owe_transition? A client device that does not correctly support OWE would disconnect to try unencrypted... ( I have seen some older Android versions do this, for example).
If dhcp is not working, it will give the same result.
How are you accessing the router, with your PC? Does it have a static ip address? Does it have Internet access?
I connect to the router over ethernet, the desktop got a static IP address and internet access has been working just fine, so seems to only effect WIFI devices.
Temporarily change the desktop to dhcp and see if it still works.
You have a lot of extra dns entries in the dnsmasq config. If you got any of these wrong, dns might not be working (ie the dns given by dhcp). This would have the same CPD result.
Its has been changed to DHCP and I got a new IP just fine:
Log showing I changed from 192.168.0.5 (static) to 192.168.0.123 (DHCP)
DHCP Log entries for desktop
Sat Nov 2 11:04:14 2024 daemon.info dnsmasq-dhcp[1]: DHCPRELEASE(br-lan) 192.168.0.5 2c:f0:5d:99:11:08
Sat Nov 2 11:04:21 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 192.168.0.5 2c:f0:5d:99:11:08
Sat Nov 2 11:04:21 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.0.123 2c:f0:5d:99:11:08
Sat Nov 2 11:04:21 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 192.168.0.5 2c:f0:5d:99:11:08
Sat Nov 2 11:04:21 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.0.123 2c:f0:5d:99:11:08
Sat Nov 2 11:04:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 192.168.0.5 2c:f0:5d:99:11:08
Sat Nov 2 11:04:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.0.123 2c:f0:5d:99:11:08
Sat Nov 2 11:04:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.0.123 2c:f0:5d:99:11:08
Sat Nov 2 11:04:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.0.123 2c:f0:5d:99:11:08 Server
No, both DNS and IP are set to DHCP on the desktop. I have no idea what is running on port 5054, if anything.
I did not add any of those, they must have been included in the fresh install of OpenWRT I did last night..?. I will delete them all, as I wouldnt expect any DNS requests to be forwarded.
When I deleted the forwards I lost DNS on the router, adding 127.0.0.1#5053 back got it working again.. I do have adblock installed on the router, but it is disabled, could it be the reason the forward are there?
I initially installed " HTTPS DNS Proxy" in order for me to potentially set up adblock + HTTPS DNS Proxy at a later stage, but I thought I had disabled both services.. That might explain why the entries were in the forward.. I have disabled the service and will monitor.
Yes you quite right. I have gone back to the current snapshot for the MT6000 with no additional software installed - then I will monitor and see what is going on. Thanks for your suggestions so far.
