Upgrading to 18.06.2 on WRT54GS v3.0 (BCM5352E)

Installing and Using OpenWrt
1

Hello!

The WRT54G old wiki page does not answer all my questions regarding the binary to be chosen and the procedure to be applied, when upgrading from Backfire 10.03.1.

The router is a WRT54GS v3.0 with a BCM5352E chipset, 8MB flash and 32MB RAM.

According to the Table of Hardware, that device is eligible for installing 18.06.2, but not for upgrading to 18.06.2.

Furthermore, the WRT54G wiki page requires a .trx file to be uploaded as binary through the GUI. However, I cannot find released binaries other than .bin for the WRT54Gx in the Open-WRT 18.06.2 repository.

Does it mean that I cannot upgrade from Backfire 10.03.1 GUI ?
What is then the right procedure to be completed in order to have 18.06.2 installed on the router? Which binary shall I choose?

Thank you.

2

The bad news is that the WRT54GS is effectively unsupportable with current, secure Linux, for anything but the most basic functionality. With only 32 MB of RAM, it will have stability problems with any kind of load past the most basic routing functions. With only a 200 MHz SoC, it can't handle much in terms of throughput. The Broadcom wireless is very outdated, dating back to 2005, nearly 15 years ago and numerous changes in 802.11 specs and unresolved security issues.

While the recommendation would be to purchase a new device with at least 16 MB of flash and at least 128 MB of RAM (good-quality units start at around US$20), you certainly can give it a try. Most people that have any luck getting anything to run on the WRT54 units build or assemble their own images.

Backfire, from 2010, is, at this time known to have multiple, serious security flaws in the kernel, 802.11 protocols, and third-party firmware used in the assembly of the OpenWrt OS at that time. (This pretty much goes for anything prior to v17, and v17 will shortly be falling from support.)

Backfire is also too old to be upgraded to 18.06 or master/snapshots and retain existing configuration, as it was configured very differently back then. Installing "fresh" is the only reasonable option. The current wiki page is https://openwrt.org/toh/linksys/wrt54g

sysupgrade may work, though it looks like that wiki page hasn't been touched in years. @lleachii may have some insight, as I believe he has one or more of these on the bench

1 Like
3

http://downloads.openwrt.org/releases/18.06.2/targets/brcm47xx/legacy/openwrt-18.06.2-brcm47xx-legacy-standard-squashfs.trx

Warning, your device will behave with extreme resource constraints on 18.06.2.

5

Thank you Jeff for the comprehensive answer.
Thank you lleachii for the link to the .trx file.

Here is where I got lost:

  • According to the Table of Hardware, I should upload a build with "linksys-wrt54gs" included in its name.

  • According to the WRT54G old wiki page, I should upload a build with .trx in its extension.

What shall I choose between:

  1. wrt54gs-squashfs.bin

  2. standard-squashfs.trx

Thank you.

6

The *.bin variants just offer a 32 byte device header (h/w id) over the generic *.trx. OpenWrt's sysupgrade helper is supposed to strip it away transparently (but there was a bug breaking this in the 2016-2018 time frame, which means you may have to strip it manually, if you are on an affected build and can't flash a newer version). Content and functionality is identical.

7

Thank you slh for the quick answer.

According to you, why the Table of Hardware states that I cannot upgrade through sysupgrade on my WRT54GS v3.0?

If the warning is still valid, how should I install 18.06.2 without sysupgrade?

8

Please forget my question, I see that someone updated the table. Such a ban has been removed.

However, after having read you, I still wonder why the Table of Hardware recommands to flash the router with a .bin and not a .trx file, when there is no need for the 32 Byte header to be present, right ?

Better asking before than grumbling later.

9

:face_with_raised_eyebrow:

@slh took a great effort to explain why above. I also provided you a link to exactly how I flashed my device.

Are you still having issues upgrading?

10

The WRT54GS v3 dataentry shows what is available for downloading on downloads.openwrt.org.
There is no specific trx available, neither in 18.06 nor in 17.01 nor in snapshots.

Apart from the non-availability of a specific trx file, the WRT54GS v3 devicepage does mention a bin, not a trx. Same for the oldwiki page you linked in your first posting.

1 Like
11

From the other forum post (but using the 18.06.2 file):

cd /tmp
wget http://downloads.openwrt.org/releases/18.06.2/targets/brcm47xx/legacy/openwrt-18.06.2-brcm47xx-legacy-standard-squashfs.trx
mtd write /tmp/openwrt-18.06.2-brcm47xx-legacy-standard-squashfs.trx linux && reboot

Ensure the file is not larger then your flash space!!!

12

and here it gets slightly tricky, if not using sysupgrade but mtd directly, as the target partition envelope might (depending on if the currently running firmware was using squashfs-gzip or already migrated to squashfs-lzma) actually be firmware, instead of linux - taking a different brcm47xx device (WL-500gP v1) as example (see the lzma loader in front of the actual linux; recent'ish master/ HEAD):

[    1.003037] physmap platform flash device: 02000001 at 1c000000
[    1.009199] physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x001301
[    1.019754] physmap-flash.0: Found an alias at 0x800000 for the chip at 0x0
[    1.019795] physmap-flash.0: Found an alias at 0x1000000 for the chip at 0x0
[    1.019830] physmap-flash.0: Found an alias at 0x1800000 for the chip at 0x0
[    1.019877] Amd/Fujitsu Extended Query Table at 0x0040
[    1.025221]   Amd/Fujitsu Extended Query version 1.3.
[    1.030362] number of CFI chips: 1
[    1.054424] 3 bcm47xxpart partitions found on MTD device physmap-flash.0
[    1.061213] Creating 3 MTD partitions on "physmap-flash.0":
[    1.067018] 0x000000000000-0x000000040000 : "boot"
[    1.080625] 0x000000040000-0x0000007f0000 : "firmware"
[    1.091838] 3 trx partitions found on MTD device firmware
[    1.097326] Creating 3 MTD partitions on "firmware":
[    1.102511] 0x00000000001c-0x000000000928 : "loader"
[    1.113294] 0x000000000928-0x00000012a000 : "linux"
[    1.124080] 0x00000012a000-0x0000007b0000 : "rootfs"
[    1.134957] mtd: device 4 (rootfs) set to be root filesystem
[    1.140744] 1 squashfs-split partitions found on MTD device rootfs
[    1.147187] 0x000000530000-0x0000007b0000 : "rootfs_data"
[    1.158461] 0x0000007f0000-0x000000800000 : "nvram"

--
Edit: no, devices of this vintage and hardware constraints aren't a sensible choice (for anything) these days, CPU performance, 100 MBit/s ports and RAM size are severe constraints - and the b/g WLAN hardware (while reliable via b43) being just a waste of airtime compared to today's 802.11n/ac/ax successors.

1 Like
13

You gave me the necessary answers at the time. I thank you for that. I come back to the 32 bytes difference between a .bin and a .trx file. You talk about a header, should I conclude that deleting the first 32 bytes of a .bin and renaming the file to .trx is the right thing to do? Or is the header somewhere else in the binary?

As you warned me that this could happen, in my case, the command

sysupgrade /tmp/targets/brcm47xx/legacy/openwrt-19.07.7-brcm47xx-legacy-linksys-wrt54gs-squashfs.bin

returns an error and requires a .trx file, without this 32 bytes header.

By the way, if it's of any use to someone else reading the thread, in order to install the firmware image in the temporary directory, you should now do this:

  • download the binary from openwrt.org to a computer with bash;
  • using the scp utility, push the binary to the /tmp directory of the router.

If the router has been reset before, the root account must be configured with a password to activate the ssh/scp daemon.

The version of wget installed on Backfire does not support SSL, while the URL http://downloads.openwrt.org now redirects to https. It is therefore impossible to download directly the firmware image from inside the router with wget.

If an administrator wants to give me write access to the WiKi, I could add this information.

14

dd bs=32 skip=1 if=foo.bin of=foo.trx

15

Thank you very much. Thanks to your explanation, it was easy for me to remove the first 32 bytes of the .bin file, and drop the new binary renamed .trx in the /tmp/ folder of the router.

However, I was not able to update the firmware.

In an effort not to brick the router, I prefer to ask questions first, rather than experiment.

sysupgrade did not work. Here is the error I get back.

BusyBox v1.15.3 (2011-11-24 02:12:13 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 Backfire (10.03.1, r29592) ------------------------
  * 1/3 shot Kahlua    In a shot glass, layer Kahlua 
  * 1/3 shot Bailey's  on the bottom, then Bailey's, 
  * 1/3 shot Vodka     then Vodka.
 ---------------------------------------------------
root@OpenWrt:~# sysupgrade /tmp/openwrt-19.07.7-brcm47xx-legacy-linksys-wrt54gs-squashfs.trx 
Saving config files...
Switching to ramdisk...
Performing system upgrade...
Image too big for partition: linux
Image check failed.
Upgrade completed
Rebooting system...
client_loop: send disconnect: Broken pipe

The upgrade didn't happen at all, it seems. The router rebooted, the root password remained stored, and the router still displays the same firmware version:

cat /etc/openwrt_release 
DISTRIB_ID="OpenWrt"
DISTRIB_RELEASE="10.03.1"
DISTRIB_CODENAME="backfire"
DISTRIB_DESCRIPTION="OpenWrt Backfire 10.03.1"

By the way, for those who might find it useful, the scp command to push the firmware into the router's temporary directory is:

scp -oKexAlgorithms=+diffie-hellman-group1-sha1 openwrt-19.07.7-brcm47xx-legacy-linksys-wrt54gs-squashfs.trx root@192.168.1.1:/tmp/

The -o option temporarily allows the ssh client to negotiate encryption with an obsolete method, otherwise our newer machines can no longer find a common language with the ssh server installed on older versions of OpenWrt.

16

Have you tried to upgrade through every version released (not every service release!) since 2010 so the firmware are moving through the years as they are supposed to have been doing with migration support instead of a timetravel leap from 2010 to 2019?

17

I think your suggestion makes sense, especially when upgrading a distribution through incremental installation of new packages. But here, as far as I understand the OpenWrt upgrade process, it is about rewriting the contents of a flash memory, not updating packages. I hope I'm not wrong, but I see this process as very similar to updating a BIOS: you erase what was there before and put a new binary blob in its place. So you never try to update the BIOS in successive steps.

Of course, the devil is in the details, and I don't reject your advice a priori. I'll wait for others to confirm it though. Especially because flashing the firmware is always a risk, and multiplying the manipulations, if not strictly necessary, only increases it. This is the first reason why I take so much care to ask the questions first, to listen to the more experienced people, and only then do it.

If it helps some to diagnose why sysupgrade is failing, here is what I find in the kernel messages at boot time:

Creating 5 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "cfe"
0x00040000-0x003f0000 : "linux"
0x000bd400-0x00270000 : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x003f0000-0x00400000 : "nvram"
0x00270000-0x003f0000 : "rootfs_data"

As a side comment, I will add that I want to upgrade this WRT54GS rather than trash it, because my use case (WAN capped at 30Mb/s, routing rules using only iptables, no need for WiFi) probably keeps this device above the usability threshold.

Anyway, thanks for having shared your thoughts.