Hi!

If you ever wanted to do update your WRT remotely without losing customized files (like ssh keys, wink stored on it, the following tiny .c program might help. (Credits go to mjn3 and his trx replacement for all information about the trx file structure and an example of how to work with it.) It copies a file supplied on stdin into the trx firmware image's otherwise unused third partition and updates the checksum accordingly. It does this mmapping the firmware image and thus works on the WRT itself.

If you attach a tar file to the image,

(cd / && tar cz /my/files*
   | trx_update_payload openwrt-linux.trx -)

the payload can be extracted on the first boot after flashing by a simple shell command like:

cd /
&& dd if=/dev/mtdblock/1
      bs=4
      skip=$(($(trx_update_payload
                /dev/mtdblock/1 --ofs)/4))
| tar xz

- no additional tools needed. Just keep in mind that the payload data must not be too much, else you'll nuke your nvram data. It the program is not compiled with NDEBUG defined, it'll warn you if this would happen.

I really don't know if it's the best way to do it but it "works for me(TM)".

Greetings,

  Gunter

Unused partition?

You may wish to review this: http://openwrt.org/forum/viewtopic.php?p=3123#3123

Hi!

Ok, I did, but what was said there did not contratict my previous assumptions about how OpenWRT works - or I still didn't get it completely... :-/

The thread referenced by you just states that the trx gets dumped as-is into the linux partition, by default it contains 2 partitions, the kernel and the squashfs root.

Mh, and looking at the kernel code I do now see the problem: The start of the OpenWRT partition is not calculated by the size of the trx file but by the squashfs's offset and actual size. So the jffs2 will overwrite the third trx partition, if present, depending on actual data sizes, block sizes and the size of the payload appended to the trx.

So I guess if I modify the find find_root() function in the flash bootstrap code to consider the payload size as well, and enlarge the space reserved for the quashfs accordingly, I'm safe?

Greetings,

  Gunter

The point is simply that there's no unused space --
[ bootloader ] [ firmware ] [ jffs2 ] [ nvram ]

Between the end of firmware (technically the end of squashfs) and the start of nvram is the openwrt jffs2 partition. This is your root filesystem. This stores all files/packages not contained within squashfs.

If you create a larger firmware, then the openwrt/jffs2 partition will shrink as a result. Your suggestion of adding backup files to the firmware doesn't seem practical.

Why would I want to create a larger firmware if it means a smaller jffs2 partition? Specifically, why would I want to add a tar.gz backup to the firmware when the files contained in the backup need to be uncompressed to the (now smaller) jffs2 partition be used? It just seems like there are better places to store your backup without creating reserved space in the already small flash chip for a backup which will probably only be used once.

Hi!

Mh, maybe I got the terminology wrong. I understood the layout of the partitions on the flash chip, I was talking about an unused data chunk in the trx file. The trx "partition table" has space for 3 entries, of which only 2 are actually used by mjn3's trx replacement. (offset 0 = a pointer to the kernel, offset 1 = a pointer to the squashfs) My tool makes offset 3 a pointer past the squashfs' end and allows data to be put there.

I now see that this may fail the way the kernel currently calculates the (flash chip) partition sizes, but so far it worked and now I know where to fix it proactively.

The point is, I must remotely administrate and update a bunch of WRTs, accessing them via insecure channels, and need a way to rescue their ssh keys - their identity, so to speak - accross firmware updates. So we talk of only about 1 k of space in my case. I'd be happy if you'd have a better idea of how to achieve this. :-) I first thought about putting the keys into the nvram, but didn't consider this to be such a bright idea...

Greetings,

  Gunter