diary at Telent Netowrks

Grandmaster, cut faster#

Tue, 06 Mar 2018 22:28:59 +0000

No Nix content at all this week, as all I've done is flash (please refer back to blog post title) my TL-WR842ND back to the factory firmware in preparation for figuring out how to get NixWRT onto it.

There's some discussion of how to do this on the OpenWRT wiki - attach router to wired network, configure a tftp server to answer on 192.168.1.66 and respond to requests for a file called wr842ndv1_tp_recovery.bin which was previously downloaded from the TP-Link site, then turn the router on while holding RESET and wait for stuff to happen.

As always, however, there is a wrinkle. The firmware I downloaded was a ZIP which contained a file called wr842ndv1_en_3_12_25_up_boot(130322).bin, and according to most sources (most sources parrot the OpenWRT wiki)

in case the file name of this firmware file does contain the word “boot” in it, you need to cut off parts of the image file before flashing it:

specifically, remove the first 131584 bytes. Why that number? It doesn't say.

This is what binwalk is for

[dan@carobn:~]$ nix-shell -p python27Packages.binwalk --run "binwalk /tmp/wr842.bin"
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             TP-Link firmware header, firmware version: 1.-3012.3, image version: "", product ID: 0x0, product version: 138543105, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 8258048, kernel length: 512, rootfs offset: 872767, rootfs length: 1048576, bootloader offset: 7077888, bootloader length: 0
110592        0x1B000         U-Boot version string, "U-Boot 1.1.4 (Mar 22 2013 - 09:09:03)"
110768        0x1B0B0         CRC32 polynomial table, big endian
131584        0x20200         TP-Link firmware header, firmware version: 0.0.3, image version: "", product ID: 0x0, product version: 138543105, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 8126464, kernel length: 512, rootfs offset: 872767, rootfs length: 1048576, bootloader offset: 7077888, bootloader length: 0
132096        0x20400         gzip compressed data, has original file name: "vmlinux.bin", from Unix, last modified: 2013-03-22 01:11:22
1180160       0x120200        Squashfs filesystem, big endian, lzma signature, version 3.1, size: 4675579 bytes, 562 inodes, blocksize: 65536 bytes, created: 2013-03-22 01:24:41

So there you are: the emergency tftp restore expects an image with a TP-Link firmware header followed by a kernel followed by a filesystem - which roughly corresponds with the description of mtd5 in the openwrt flash layout - but the image on the TP-Link site prefaces that with about 128k of something that might be U-boot, which roughly corresponds with the layout of the entire flash chip

Going forward this is relevant insofar as it means we really have two problems not just one

Currently thinking: we can tackle problem 2 first. Let's put OpenWRT on the machine (then at least I have ssh available) and then build a kernel/fs I can start with kexec and iterate on that until I know it works on the hardware. Once we have the right code then we can start figuring out how to put it at the right offset.