[OpenWrt-Devel] [WDR3600] factory using WPS-button and tftp doesn't work anymore (new hardware?)

Leon George leon at georgemail.eu
Wed Jul 29 14:20:07 EDT 2015

Hash: SHA256

Hi :-)

the automatic flashing-process - holding down the WPS-button in order
to flash an image downloaded via TFTP - no longer works for certain
WDR3600-devices with hardware revision 1.5 that have only minor
(visible) differences to working devices with the same revision.

.. this is going to be long - sorry for that.
i'm trying to provide as many details as possible.

I'm working on a factory-process for TP-Link WDR3600.
Last week we have encountered an error where we were (
headache-english :-D ) not able to flash the last shipment using an
automated process.
There seems to be new hardware with the revision still being 1.5 but
the u-boot behaving differently.

- From the outside, these devices look quite similar - the only
differences we've found so far are:
- -there are four labels on the backside (as opposed to 3) the new one
showing custom SSIDs (much like the one on the Archer-C5)
- -a label on the inside on the yellow LAN-ports has a string "4FC-1",
which we have not seen yet - the working boards have "3FC-3"

The only way to flash our image to this new hardware is to either:
- -flash manually using the u-boot-prompt (t ; e; cp.b; reset)
- -upload it to the firmware-update-page of the stock-firmware
The images then boot and seem to be happy.

That, however, is not acceptable for a factory-process..
Turns out that our image was 6815748 bytes in size (we forked from
openwrt a while ago) which is not accepted by these new devices using
the existing process. The router instantly resets after the firmware
has been received (before hte flash is erased).
Have a look at "Flashing via TFTP" in
http://wiki.openwrt.org/toh/tp-link/tl-wdr4300 to see what we're doing
- - no magic involved :-)

'wrong_filesize.log' contains the serial-output when the file size is
not 'correct'.

So far, i've come to the conclusion that only files with size 8192512
/ $7D0200 (bigger than the rootfs-mtd!) make it past the tftp download.
I've tried padding the file with \x00 or \xFF. The file is then copied
to the flash but will not boot.
See 'successfull_flash.log' for the output.
Notice the 'boot up image' after the transmission. <----
You can see the error while booting at the end of that file (LZMA-length

The last thing i've tried, is to use an image produces from
OpenWRT-trunk - i gather you have introduced padding to the image
since our fork. That image would also NOT be copied to the flash.
Flashing does work if the file is padded to the 'magic' size but the
boot-issue remains.

I'm still working on this and will keep you informed - but if anyone
of you has an idea on how to address this issue.. any help would be
highly appreciated!

The next thing on my TODO-list is to see how the image can be modified
to make it boot. I'm comparing it to the firmware-upgrades from
TP-Link (which do work using this process).

But first: a good night's sleep :-p

hoping this might help someone,

kind regards,
nice evenings to you,

Leon M. George
Version: GnuPG v2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: successfull_flash.log
Type: text/x-log
Size: 3595 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150729/2fd442aa/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrong_filesize.log
Type: text/x-log
Size: 2792 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150729/2fd442aa/attachment-0001.bin>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list