FS#1129 - WNR2000v3 crash due to button/LED/phy interaction #6075
Comments
|
mkresin: Hey Dave, would you please give the image at https://www.kresin.me/files/ a try. If you prefer to build an image on your own, the coresponding commit can be found in [[https://git.lede-project.org/?p=lede/mkresin/staging.git;a=summary|my staging tree]] |
|
DavePlatt: It looks like a good fix, Mathias. I cherry-picked your patch into a branch the same top-of-trunk I had been testing with, rebuilt, installed, and wireless now seems to be quite stable. I've been able to bring it up either unencrypted, or with PSK2 (the latter was near-instant death before) and one of my Nexus tablets is now happily downloading a few weeks' worth of updates from the Google Play Store. Functioning of the WiFi and WAN LEDs is as it should be. Also, thanks to changes in top-of-trunk since 17.0.4 was snapped, this image is just a hair smaller than the official one - small enough that the JFFS2 overlay works, and UCI updates aren't lost on every power-cycle. So, I'd say your change is a fine candidate for a pull request to master (assuming no one else sees a problem with it), and if it's possible for somebody to push a new WNR2000v3 image to the LEDE distribution site I think you'd make some people happy! Thanks very much for your quick fix on this! |
DavePlatt:
Hardware: Netgear WNR2000v3
Software: LEDE trunk as of 29 October 2017
Built from scratch, installed via TFTP or by sysupgrade from an old OpenWRT build (tried both). The current build barely fits with enough room for a small jffs config filesystem (works better than 17.0.4 which doesn't fit).
Problem noted: attempting to enable wireless results in the following behavior:
(1) Blue WIFI LED comes on
(2) A few seconds later, the green Power LED starts to flash rapidly
(3) System reboots. All configuration settings are lost.
Partial analysis: something is amiss with the button/LED configuration. Enabling WiFi appears to cause the system to mis-detect a button press on the RESET button. After a few seconds, the /etc/buttons.d/reset script is called, reporting a "timeout", and the script starts flashing the green LED to indicate "bypass" mode.
At this point, if anything resets WiFi (takes it down, does a network configuration change of any sort, or if hostapd tries to enable encryption) the false button-press on RESET is released. The /etc/buttons.d/reset script is called again with a "release" event, and a SEEN value of greater than 5 seconds. The script interprets this as a request for a factory reset, wipes the jffs, and reboots.
Ask me how much fun I had getting this far :-)
I looked at the button/LED GPIO configurations for this board, and don't see any specific problems (no overlaps).
Turning on the blue WAN LED manually (with e.g. echo default-on > netgear:blue:wlan/trigger) does not cause the false Power button-press to be detected, and turning it back off doesn't seem to cause a false factory reset. This leads me to suspect that the problem isn't in the main LED drive - rather, something about the setup which associates the LED with the wireless-MAC PHY drive (e.g. the trigger mode of phy0tpt) may be responsible. Perhaps the default mode actually drives several GPIOs, and one of these is the one used for Reset?
The quick workaround for the problem is to rename or remove /etc/buttons.d/reset, and install a dummy script in its place that does nothing. This sacrifices the reset-button functionality entirely, of course.
This behavior didn't exist in the old OpenWRT port I was running (a Designated Driver build).
The text was updated successfully, but these errors were encountered: