Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Add Andrew Kim's hardware UI changes to the base build. #6

woodrow opened this Issue · 10 comments

3 participants

  • package wifitoggle, as-is
  • package restorefactory, with some configuration
  • LED configuration?

LED Configuration Notes

From the Netgear setup guide

LED      Activity            Description
-------  ------------------- ---------------------------------------------------
Power    Solid Amber         Starting up
         Solid Green         Ready/operating
         Blinking Green      Firmware corrupted
         Blinking Amber      Firmware is upgrading
         Off                 No power
2.4 GHz  Off                 2.4 GHz radio is off
         Solid Green         2.4 GHz radio is on
         Blinking Green      Data transfer over 2.4 GHz radio
5 GHz    Off                 5 GHz radio is off
         Solid Blue          5 GHz radio is on
         Blinking Blue       Data transfer over 5 GHz radio
USB      Off                 No USB device connected/device was removed safely
         Solid Green         USB device connected and ready
         Fast Blinking Green USB device in use
Internet Off                 Interface down (no link)
         Solid Amber         Interface up (link detected)
         Blinking Amber      Running DHCP
         Solid Green         IP address obtained via DHCP; ready
         Blinking Green      Data transfer over WAN interface
LAN 1-4  Solid Green         Link up at 1000 Mbps
         Blinking Green      Data transfer over LAN port at 1000 Mbps
         Solid Amber         Link up at 10/100 Mbps
         Blinking Amber      Data transfer over LAN port at 10/100 Mbps
         Off                 No link detected

Button  Description
------- -----------
WLAN    Toggles the 802.11 radios on and off (indicated by the LEDs above)
Factory Reset config (i.e. /etc) to factory settings

I think we're currently lacking the Internet LED and WLAN switch behavior (and maybe USB as well).


I've included wifitoggle and restorefactory in the build. How should i test?

@woodrow woodrow was assigned

For restorefactory, the following shell script needs to be added into /etc/uci-defaults with executable privilege.

uci set system.@restorefactory[0].button=BTN_0 
uci set system.@restorefactory[0].action=pressed
uci set system.@restorefactory[0].timeout=5     
uci commit system

For wifitoggle, the following shell script needs to be added into /etc/uci-defaults with executable privilege.

uci set wifitoggle.@wifitoggle[0].button=BTN_2
uci set wifitoggle.@wifitoggle[0].timer=0
uci commit wifitoggle

Adding these scripts make button configuration automatic upon booting.
Also, the LED configuration is fixed on Backfire 10.03.1-rc4 or above according to this page:

I'm still not sure about the USB LED configuration though.


I just flashed my router with the new build, and both buttons seem to work fine now.


Awesome. Closing issue.

@ssundaresan ssundaresan closed this

To add the WAN led color change upon successful DHCP, it should be a matter of creating /etc/udhcpc.user with the following contents:


set -o nounset
set -o errexit

[ -z "${1:-}" ] && echo "Error: should be run by udhcpc" && exit 1

if [ "$interface" = 'eth1' ]; then        
        if [ "$1" = 'deconfig' ] || [ "$1" = 'nak' ]; then
                echo 0 > /sys/devices/platform/leds-gpio/leds/wndr3700\:green\:wan/brightness
        elif [ "$1" = 'bound' ] || [ "$1" = 'renew' ]; then
                echo 255 > /sys/devices/platform/leds-gpio/leds/wndr3700\:green\:wan/brightness

Unfortunately due to some hotplug issues, this isn't called when the link goes down (indeed, udhcpc doesn't know that the link's gone down).

@woodrow woodrow reopened this

After some poking around, including writing a simple hacked up example ( based on some examples floating around on the 'net, I can confirm that link state changes for eth1 are indeed being sent to the RTMGRP_LINK rtnetlink multicast group. Thus, the problem seems to be in hotplug2.

I added a generic/bogus rule to the top of /etc/hotplug2.rules:

QWERTYUIOP is unset {              
        print-event QWERTYUIOP

and it doesn't dump anything about interface state, so it doesn't appear to be a rules problem.


in hotplug2's netlink.c:12

int netlink_init() {        
        netlink_socket = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_KOBJECT_UEVENT); 
        return netlink_socket;

We can see that it's only listening to the NETLINK_KOBJECT_UEVENT family, which doesn't appear to contain link state events.

Looks like we need to look into an alternate tool (netplug, ifplugd, etc.).


I can confirm that the /etc/udhcpc.user script noted in #6 (comment) works properly when used with the netplug package we are porting. netplug is like hotplug but listens to the RTMGRP_LINK group which carries link state updates.

netplug requires changes to /sbin/ifup script -- notably to avoid calling /sbin/ifdown immediately upon execution to (presumably) reset the interface in question. More documentation on the changes required to have netplug work properly shall be forthcoming.


The following have been accomplished as of quirm:

  • package wifitoggle, as-is
  • package restorefactory, with some configuration

We are punting on netplug and the LEDs for now. Removing quirm milestone and renaming issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.