Failsafemode on Fritzbox4040 does not come up

I installed openwrt-23.05.0-ipq40xx-generic-avm_fritzbox-4040-squashfs-eva.bin.
During firewall setup, I accidentally locked myself out.
Now I'm trying to make it boot into failsafe mode, but it does not work.
I followed the docu here
and found some info here
but this wasn't of much help.
When powering on, all LEDs briefly light up (half a second), then the power LED blinks slowly. I tried pressing WPS and WLAN buttons at different times and in different combinations (right at the start, or after the flashing of all LEDs, both pressing and holding, and clicking the buttons rapidly, WPS only, WLAN only, and both keys at once... every time with a power cycle between attempts): nothing helps.
I do not get a rapidly blinking "Info" LED (or any other LED), the box just seems to boot normally until after some time the Power LED is on steadily.
Of course, ssh'ing into the box also doesn't work (yes, I know there's no DHCP, I set the IP of my computer to a static IP in the 192.168.1.(1-244) IP range).

Oh, and by the way.. there's also no packets sent to during bootup, according to tcpdump... contrary to the docu on the failsafe-page linked above.

Is Failsafe mode broken on image openwrt-23.05.0-ipq40xx-generic-avm_fritzbox-4040-squashfs-eva.bin?

you will need to perform these steps:

ps: obviously direct connection via ethernet between your PC and the router, and the router accepts ftp mode only for a short period after connecting/disconnecting it from the electricity supply

if you still can't load an Openwrt image you will have to go back to the original firmware and then try everything again (but only after trying the procedure mentioned above)

Updating via ftp (overwriting the old image) worked.

However, I'm still wondering: does this mean fail safe mode is broken with this image on this hardware? Or is the docu outdated?

fail save mode works if you still have ssh access to the router

the ftp update process works (almost always) ...

unfortunately on this router the two buttons do not activate (by default) the fail save mode it is possible to program the functioning of the two buttons if this is what you want

1 Like

I'd argue that a fail safe mode that requires ssh to trigger it isn't actually one.
(If I have ssh access, I don't need the fail safe mode).

But it works for me now doing an update via ftp.

Probably something worth changing in the docu of the 4040 (I don't have access there) at, or fixing in the image.


I've tested the failsafe mode with 23.05.0 on my 7520 and it works.

This is the bootloader phase, it's too early to press any buttons, since OpenWrt isn't starting yet.

After blinking slowly the power LED is on for a while then starts blinking again.
This is the time to press the button. Any button should work.

You should get the red "info" LED rapidly blinking, indicating the failsafe mode.

EDIT: Any reason, you didn't update to 23.05.3?

I know that if a person has access via ssh then they don't need a fail-save mode, for this case I programmed the behavior of the buttons to obtain something similar to a fail-save procedure

this is an example of how I set up the buttons and is based on the document:

uci show | grep button

system.@button[0].handler='logger "button WLAN push 0-3s; exec /root/switch_wifi"; /root/switch_wifi'
system.@button[1].handler='logger "button WLAN push 30-100s; exec /root/repair_network"; /root/repair_network'
system.@button[2].handler='logger "button WPS push 0-3s; exec /root/switch_wifi"; /root/switch_wifi'
system.@button[3].handler='logger "button WPS push 30-100s; exec /root/repair_network"; /root/repair_network'

this simple script is based on copying a known working
version of:


which need to be copied to:

mkdir /root/config/
cp /etc/config/network /root/config/network
cp /etc/config/firewall /root/config/firewall

at a time when everything works

which are copied back into the directory and restore basic connectivity/firewall (after pressing the button for more than 30 seconds)

cat /root/repair_network

logger "exec: /root/repair_network"
cp /etc/config/network /root/config/network.bad
cp /etc/config/firewall /root/config/firewall.bad
cp /root/config/network /etc/config/network
cp /root/config/firewall /etc/config/firewall
/etc/init.d/network restart
/etc/init.d/firewall restart

since it also happened to me that I was locked out of the router and had no choice but to proceed with ftp mode

hoping it is useful to you...

1 Like

OK, so had misunderstood you, sorry.
Makes sense, thanks for the detailed info about the setup you used! I will add that to my box. First step before every FW change then would be to update the backup-files, so it's easy to revert back.

1 Like

By the way, what's the current officially supported way to add button actions?
I've tried as suggested, but it does not trigger any action (wrote a log entry for debugging, this does not appear when pressing the button).
According to, hotplug buttons are deprecated. According to the docu, if I understand it right, configuring buttons in /etc/config/system with the button definitions are not supported anymore, and one would now have to edit the scripts in /etc/rc.button/* .. is this assumption correct?
(I do not have an /etc/hotplug.d/button/ directory either, this also seems to point towards hotplug button defintions not being supported anymore)

I don't see the point really. At least not to achieve having a "reset" button.

Yes, you can tamper with the scripts in rc.button to change the behavior of one of the buttons you have to do the reset.
But as soon as the overlay gets reset, your changes to the scripts are gone as well.

It only makes sense, if you bake the scripts into your image.
Using the imagebuilder for example.

Or you can just use the failsafe mode.
It's more flexible than factory reset.

The plan is not to reset the overlay FS, but to reset the last changes to the network config files, as ndcompact proposed.

I will use the following (adapted) script:

logger "exec: /root/"
# copy all backed up files back to /etc in the correct place
# typically, before modifications one would place the known to work /etc/config/network
# and /etc/config/firewall in /root/failsafe/config.
cp -r /root/failsafe/* /etc
/etc/init.d/network restart
/etc/init.d/firewall restart

Also of course the questions extends to any "change button functions" scenario, aside failsafe-related functions.

this should work fine and detect the two buttons on your router

opkg update
opkg install kmod-button-hotplug
mkdir -p /etc/hotplug.d/button
cat << "EOF" > /etc/hotplug.d/button/buttons
logger "the button was ${BUTTON} and the action was ${ACTION}"

or if you want to use your script "/root/"
by pressing one of the two buttons for a period greater than 30 seconds and less than 100 seconds,
I preferred a long time as a short press activates/deactivates the wifi, at most you choose the seconds to activate the scripts...


opkg update
opkg install kmod-button-hotplug
mkdir -p /etc/hotplug.d/button

cat << "EOF" > /etc/hotplug.d/button/00-button
source /lib/
do_button () {
    local button
    local action
    local handler
    local min
    local max
    config_get button "${1}" button
    config_get action "${1}" action
    config_get handler "${1}" handler
    config_get min "${1}" min
    config_get max "${1}" max
    [ "${ACTION}" = "${action}" -a "${BUTTON}" = "${button}" -a -n "${handler}" ] && {
        [ -z "${min}" -o -z "${max}" ] && eval ${handler}
        [ -n "${min}" -a -n "${max}" ] && {
            [ "${min}" -le "${SEEN}" -a "${max}" -ge "${SEEN}" ] && eval ${handler}
config_load system
config_foreach do_button button

and add the following lines to the file

config button
        option action 'released'
        option min '0'
        option max '3'
        option button 'rfkill'
        option handler 'logger "button WLAN push 0-3s; exec /root/switch_wifi"; /root/switch_wifi'

config button
        option action 'released'
        option min '30'
        option max '100'
        option button 'rfkill'
        option handler 'logger "button WLAN push 30-100s; exec /root/"; /root/'

config button
        option button 'wps'
        option action 'released'
        option min '0'
        option max '3'
        option handler 'logger "button WPS push 0-3s; exec /root/switch_wifi"; /root/switch_wifi'

config button
        option button 'wps'
        option action 'released'
        option min '30'
        option max '100'
        option handler 'logger "button WPS push 30-100s; exec /root/"; /root/'

logread | grep button
Fri Jun 14 07:31:03 2024 user.notice root: button WLAN push 0-3s; exec /root/switch_wifi

I would say not yet...

Does this mean that these will be executed in addition to those in /etc/rc.button?
Can this cause any race conditions or similar if I use two button trigger systems in parallel?
As an engineer, I would really like to understand the mechanism here. The docu is quite scarce here unfortunately.

Not yet deprecated, yes. But I should avoid to build software and own scripts based on an interface that will be deprecated some time soon (when the docu is correct), right? After all I'd like to try to write stable software that survives at least the next few OpenWRT releases.

I have proposed a simple solution, it's up to you to choose the most appropriate way...

No doubt. But I'm not looking for simple solution, I'm trying to understand how this works, so I can implement the best way. (These things always, always, always come back to bit you later on if you don't understand them, I learned the hard way).

Is there a system diagram or something like that somewhere, or anyone who understands how this works internally?

1 Like

I don't have enough information I can give you...

No worries, thanks for your help. Will try to take a look at the source code.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.