Opened 11 years ago

Closed 11 years ago

#725 closed defect (fixed)

ASUS WL-500gP: OpenWRT failsafe mode does not work/inaccessible

Reported by: greve@… Owned by: developers
Priority: high Milestone: 0.9/rc6
Component: base system Version:
Keywords: wl-500gp, failsafe, reset, boot_wait Cc:


The ASUS WL-500gP is one of the devices for which the reset button does not work. From "The reset button does not work (due largely to mis-mapped /proc/sys/reset)". This makes the OpenWRT failsafe mode inaccessable.

Given that the device also does not support JTag as a recovery method, this means two layers of security are missing, which is quite bad as even comparatively simple problems with the nvram settings will brick the entire device for good.

boot_wait does not seem to have the desired effect (e.g. waiting for tftp), and as the ASUS WL-500gP is also reportedly difficult to get into hardware failsafe mode as long as there is a firmware/configuration that looks functional (CRC checksum works out), people have started ground flashing PIN 9 to force a CRC error to then get into hardware failsafe mode the next time.

This is not good -- there should be a way to recover from broken nvram variables without voiding the warranty. So one or all of these issues should be resolved for this device, which seems one of the most popular OpenWRT devices.

Attachments (0)

Change History (6)

comment:1 Changed 11 years ago by Ivoshiee

It is the same with Motorola WE800G.

Only thing you can do is to find out where the reset button is on:

Please use the GPIO utility from to figure out which GPIO the reset button is on...

comment:2 Changed 11 years ago by Jeroen Dekkers <jeroen@…>

The place of the reset button is already described on the wiki:

To copy from the page:
"gpio 0 = RESTORE button (reset) (00 = unpressed, 01 = pressed)
gpio 1 = Power LED (enable = off, disable = on)
gpio 4 = EZ SETUP button (similar to linksys "button"?) (00 = unpressed, 01 = pressed)"

I've just confirmed with the GPIO utility that this information is correct.

comment:3 Changed 11 years ago by degenerated

does anyone (developers) identified where is the problem? i mean the folder/file of source? i have some programming knowledge... if i could help in anything?...

comment:4 Changed 11 years ago by pltsi

FreeWRT has implemented a correction for WL-500gP in the broadcom-diag module:

I browsed the current OpenWRT codes and try to describe the modules affected below.

White russian branch: A new patch for the kernel is needed. Current patch without the correction is here:

Buildroot-ng branch: Change needs to be made in diag package:

Could someone add this correction please? It would be good to have the failsafe option available. I guess the same applies for Motorola WE800G, but I haven't looked that up.

comment:5 Changed 11 years ago by anonymous

Getting the device ID from nvram is not good idea. The main reason of failure of WL-500gP is corrupted nvram variables, including device ID. IMHO, device ID should be compiled in firmware.

comment:6 Changed 11 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in [5146]

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.