After upgrading to 4.3.7 (release 4, sha bed878…) I’m experiencing issues with my chromecast and netlink wifi extender, as well as poor internet service eg. twitter streams/threads not loading, google searches not loading, not receiving messages in messaging apps
Chromecast:
Factory reset the chromecast, ‘Home’ app finds it and sets it up, chromecast connects to wifi, ‘Home’ app can’t finish the set up saying that it can’t find it on the network
Wifi extender:
Doesn’t seem to get an IP, logread -f output shows DHCP discover, offset, discover, offer, … repeat
I reset and then updated my Mango from 3.216 to 4.3.7r4 about a week ago, and I’m seeing something similar…
Several devices (including one of three identical make/model phones and one of two identical make/model tablets, and three of twenty IOT devices) consistently can’t connect to Wifi; others have had transient failures during the week.
logread shows that the non-working devices send a DHCPDISCOVER and the Mango replies with DHCPOFFER, but the devices don’t respond with DHCPREQUEST (so the Mango doesn’t get to send a DHCPACK).
I assume that the DHCPOFFER is being sent, since most of my 30+ devices are getting a connection, and when I turn on logging there’s no difference between the DHCP options requested/sent for the working/failing devices. I’m currently looking at the options that differ between the old and new DHCP configuration files but nothing obvious has popped up so far.
Other symptoms that are possibly related: The “Clients” page in the Mango’s Admin Panel used to be stable; under 4.3.7 some devices stay in the “Online” section but others jump back and forth to “Offline” every few seconds. And in “Wireless” section of the LUCI interface, the “Connected stations” list shows an appropriate number of clients but most of them have a hostname of “?” and a MAC address of “00:00:00:00:00:00” or “40:00:00:00:00:00” , and all are missing the Signal/Noise and RX/TX Rate information.
I might try the 4.3.7 nightly to see if anything changes for the better, but if it doesn’t work I may have to revert to 3.216.
Nope, the nightly build was no better so I switched back to 3.216.
It would be interesting to try plain OpenWRT (to isolate whether the problem is in OpenWRT or GL-iNet’s user-friendly layer on top of it) but I can’t afford any more downtime at the moment.