[LEDE-DEV] ar71xx: Need advice on parsing specific board config data on TP-Link TL-WR942N

Piotr Dymacz pepe2k at gmail.com
Mon Feb 20 23:33:29 PST 2017

Hello Sergey,

2017-02-21 0:00 GMT+01:00 Sergey Studzinski <serguzhg at gmail.com>:
> I'm currently working on LEDE port for TP-Link TL-WR942N v1 N450 router.
> Hardware is mostly like Archer C59 QCA9561 platform but no 5GHz ac
> radio and two USB2.0 ports.
> Most work is already done against 17.01-rc2 and there is working
> factory and sysupgrade images.

Please, base your work on master branch.

> Special thanks to Henryk Heisig and Felix Fietkau for their work!
> Pecularities are found with MAC and some other specific board config
> data which are not stored on first
> mtd0(u-boot) partition like on Archers but right after rootfs
> partition in a slightly different format (ASCII instead
> of binary). Due this router starts with random MACs now.

Just checking, have you tried to look for MAC in binary format in
whole flash dump?


> root at LEDE:~# hexdump -C /dev/mtd4
> 00000000  00 00 00 16 00 00 00 00  4d 41 43 3a 38 34 2d 31  |........MAC:84-1|
> 00000010  36 2d 12 34 2d 56 78 2d  9a bc 2d de f0 0a ff ff  |6-F9-12-34-56...|

TP-Link surprises me with every new device...


> Is there already special parser for this data somewhere in LEDE tree
> or should we write new one?

We have a shell function mtd_get_mac_ascii() in [1] and some boards
under ar71xx target utilize it [2]. But I'm sure it won't work with
such format - equal sign as separator is hardcoded there.
Maybe we can extend it, add another one parameter with separator and
keep it as "=" by default, for backward compatibility. You would also
need to take a look at macaddr_canonicalize() function and check if it
can work with this MAC format.

> Or can we move this data on the second mtd0 sector on the first boot
> and have it mostly like and
> compatible with Archer C59/c60 code? BTW factory u-boot fits on first
> 64kbytes and second 64K
> sector is completely 0xFF.


IMHO, overwriting any kind of factory data in flash should be at the
very end of list with possible solutions/workarounds, especially if we
are talking here about second sector of flash, just after the U-Boot

As I can see, "fs-boot" partition in factory firmware for this device
is 128 KB size and I'm pretty sure not without a reason. I can imagine
someday TP-Link will release update for this device with U-Boot image
bigger than 64 KB and from that point our image will start breaking
user's devices.

[1] https://github.com/lede-project/source/blob/master/package/base-files/files/lib/functions/system.sh#L11
[2] https://github.com/lede-project/source/blob/master/target/linux/ar71xx/base-files/etc/board.d/02_network#L483


More information about the Lede-dev mailing list