Firmware-recovery without having to use the reset-button.

[Oliver]

Hey,

The Linksys WRT54G boot-loader has a nice feature, called "boot_wait", that causes the boot-loader to listen for incoming TFTP at a fixed IP-address for a few seconds after power-on, before continuing to start the OS. If it receives a valid firmware during that window, it'll write it to flash and restart. This seems ideal for Ubiquiti-hardware, which will often be mounted at difficult to reach places, where pressing reset during power-on isn't that easy.


Grtz,

Oliver

[UBNT-keba]

You can set that wait parameter by using serial cable and configuring RedBoot cfg

[Oliver]

Hey Keba,

Ah, thanks, I didn't know that Redboot already offered the feature. Still, not all of your hardware provides an easily accessible serial port. I have PS5's, for example. It should also be user-friendly to configure, ideally from the web-interface. Not everyone knows their way around in the boot-loader or on the shell.

Is there a tool to modify the Redboot config flash-area from the command-line instead of a serial console? Thanks!


Regards,

Oliver

[Oliver]

Hey Keba,

I have since figured out that Redboot has a telnet-server and on your devices listens to telnet on port 9000, after booting into recovery-mode. Unfortunately, it seems to stop responding to any network-traffic after accepting one telnet-connection.

Telnet would be the ideal way to access Redboot on your hardware. Any idea why it doesn't work? Meanwhile, I'll keep trying.


Grtz,

Oliver

[UBNT-keba]

There is no telnet on. It could be that you are connecting to debugger port it is not telnet protocol. We will think about easier reset procedure as well. I let you know the conclusion.

[Oliver]

Hey Keba,

Ok, thanks! Maybe you should consider enabling Redboot telnet-access during the boot-window as well. It's a great feature. :-)


Grtz,

Oliver

[westbywest]

There is no telnet on. It could be that you are connecting to debugger port it is not telnet protocol. We will think about easier reset procedure as well. I let you know the conclusion.

Has there perhaps been any progress on this? Having the ability to trigger recovery mode remotely, e.g. by telnetting to port 9000 during a boot-wait interval, would GREATLY assist in situations where the hardware sits at the top of a very tall mast.

[westbywest]

For some follow-up, I poked around a Nanostation M5 that I'd flashed with OpenWRT. Looks like the device uses u-boot as bootloader, not Redboot.

Atheros AR71xx SPI Controller driver version 0.2.4
m25p80 spi0.0: mx25l6405d (8192 Kbytes)
7 cmdlinepart partitions found on MTD device spi0.0
Creating 7 MTD partitions on "spi0.0":
0x000000000000-0x000000040000 : "u-boot"
0x000000040000-0x000000050000 : "u-boot-env"
0x000000050000-0x000000150000 : "kernel"
0x000000150000-0x0000007b0000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=250000, len=560000
0x000000250000-0x0000007b0000 : "rootfs_data"
0x0000007b0000-0x0000007f0000 : "cfg"
0x0000007f0000-0x000000800000 : "EEPROM"
0x000000050000-0x0000007b0000 : "firmware"

Likewise, here are contents of u-boot-env, i.e. the u-boot configuration options.

root@nsm5-e:~# cat /dev/mtd1
d��ethaddr=0xDE:0xAD:0xBE:0xEF:0xFF:0xeefilesize=690000fileaddr=80010000bootdelay=4baudrate=115200mtdids=nor0=ar7240-nor0partition=nor0,0mtddevnum=0mtddevname=u-bootserverip=192.168.1.254stdin=serialstdout=serialstderr=serialethact=eth0mtdparts=mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)bootcmd=bootm 0x9f050000bootargs=console=ttyS0,115200 root=31:03 rootfstype=squashfs init=/initipaddr=192.168.1.20u-boot),64k(u-boot-env),1024k(kernel),6528k(rootfs),256k(cfg),64k(EEPROM)bootcmd=bootm 0x9f050000(NVRAM),64k(ART)ethact=eth0partition=nor0,0mtddevnum=0mtddevname=u-boot

I see the options expecting a TFTP server at 192.168.1.254, with local IP 192.168.1.20, and these are consistent with instructions provided for firmware recovery.
http://www.ubnt.com/wiki/Firmware_Recovery

But, is there no way to override u-boot's dependency on the reset button, or is this effectively hard-coded/wired?