[FS#1129] WNR2000v3 crash due to button/LED/phy interaction

[LEDE Bugs]

A new Flyspray task has been opened.  Details are below. 

User who did this - Dave Platt (DavePlatt) 

Attached to Project - LEDE Project
Summary - WNR2000v3 crash due to button/LED/phy interaction
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - High
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - 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).



More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=1129