Netgear WNDR3700v3 - overwriting board_data flash partition

[goni@…]

hello

flashing trunk over stock firmware seems to corrupt board_data partition causing a messed up CFE (bootloader) which makes it very hard to go back to stock after using openwrt.

the board_data contains the board_id, mac addresses of the router
and serial numbers.
the corruption of this vital info causing to router to be essentially bricked after trying to go back to stock unless you have ttl, luck and some creative ways to rescue the device.

some of the effects:
when the board_data partition is corrupted, cfe does not accept tftp images for flash because the board_id string does not match

[anonymous]

i can confirm that on dgnd3700v1 board_id=(empty) after openwrt test image.

[anonymous]

in my case tftp anyway accept orginal image, but i got mess in settings such as mac, cannot upgrade image over webgui etc.

[gz <goni@…>]

It is still relevant.

[hauke]

Have you tried to restore the board_data partition? The current partition parser should detect the partition if it is still there and prevent it form being overwritten.

[goni@…]

I've just restored to stock fw (sorta, compiled from GPL) and restored the partition via burn* tools provided by the fw.
I will test next week the recent trunk snapshot and check if the partition gets overwritten again using web upgrade.

My reason for going stock are the broknness of the latest snapshots and the general poor network throughput I'm getting versus the stock: ~65Mb/s vs ~105Mb/s wan to lan speeds.

[Zajec]

@goni / dgnd3700v1-owner: any news on that? Could you try OpenWrt build from trunk? As @Hauke explained, it should recognize board_data and not allow overwriting it.

[gz <goni@…>]

I'll have access to the router only on Friday,I will post an answer as soon as I can.

[gz <goni@…>]

I can confirm that the issue has been resolved.
I've just flashed today's snapshot (02.08.2013) over stock fw and the partition and it's content has been preserved by openwrt.

Any tips for getting back the high throughput I'm getting with stock fw?
(again, 55~65Mb/s instead of ~100Mbps as my ISP provides..)
or should I open a new ticket for this?

thanks

[hauke]

This was fixed some time ago.

You are talking about the WAN <--> LAN connection using NAT? It could be that your CPU is not fast enough, Broadcom uses some hardware supported NAT and OpenWrt does this all in software.

[SpOeK]

I'm also using a WNDR3700v3 with trunk and the board_data partition is not detected. After first boot (or during this first boot) the partition is wiped out. I've been able to restore board_data but it seems that the detection code is not working. Here is the previous flash layout with DD-WRT:

bootloader size: 262144
nvram size: 65536
sflash: Filesystem type: squashfs, size=0x623d53
partition size = 6497280
Creating 6 MTD partitions on "sflash":
0x00000000-0x00040000 : "cfe"
0x00040000-0x007e0000 : "linux"
0x0019dc00-0x007d0000 : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x007f0000-0x00800000 : "nvram"
0x007d0000-0x007e0000 : "ddwrt"
0x007e0000-0x007f0000 : "board_data"

And here after booting with OpenWrt trunk:

[    1.464000] 6 bcm47xxpart partitions found on MTD device bcm47xxsflash
[    1.472000] Creating 6 MTD partitions on "bcm47xxsflash":
[    1.480000] 0x000000000000-0x000000040000 : "boot"
[    1.484000] 0x000000040000-0x0000007f0000 : "linux"
[    1.492000] 0x00000004001c-0x000000040960 : "loader"
[    1.500000] 0x000000040960-0x00000013f000 : "kernel"
[    1.508000] mtd: partition "kernel" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    1.524000] 0x00000013f000-0x0000007f0000 : "rootfs"
[    1.528000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    1.544000] mtd: partition "rootfs" set to be root filesystem
[    1.548000] mtd: partition "rootfs_data" created automatically, ofs=0x340000, len=0x4b0000
[    1.556000] 0x000000340000-0x0000007f0000 : "rootfs_data"
[    1.564000] 0x0000007f0000-0x000000800000 : "nvram"

[Zajec]

SpOeK: I'm sorry for that, it's too bad bcm47xxpart didn't recognize board_data.

SpOeK: could you do something for me, please?
1) Restore your board_data
2) Boot DD-WRT
3) Dump your board_data partition and send it to me

By looking at board_data I should be able to easily improve bcm47xxpart to detect this partition on your device as well. You can attach your dump or just sent it to me. It's zajec5 e-mail in GMail.

[Zajec]

I've analyzed 3 dumps of board_data from ticket:7198 (WNR3500L) and all of them have MPFR magic at 0x100. So there must be something different with the WNDR3700v3...

[SpOeK]

I've been reviewing the partition layout detection code and if I'm not mistaken, there is no BOARD_DATA_MAGIC signature in my board_data partition.

As a workaround, due to some boards having this board_data just before the nvram partition, now it adds the board_data partition in the nvram detection code if the classical method fails to do it. I do know that this patch is very focused in my model but it works for me. I'm attaching the patch and sending you the board_data dump.

[hauke]

This board_data partition is just used on some Netgear/Foxcom devices and your patch would add such a partition to all devices.

How did you restore the board data partition?

Could you please post the content of the restored board data partition?

[SpOeK]

Yes, I know that this would add a board_data partition for all devices. That's what I said:

I do know that this patch is very focused in my model but it works for me.

About restoring the partition, I have a spare WNDR3700v3 router from which I dumped the board_data. Then, using the CFE I flashed it into the "broken" router.

[SpOeK]

WNDR3700v3 board_data partition

[Zajec]

board_data patition syntax is following (bytes):

0x000 → 0x011: device id (followed by 0x00 in 0x12?)

0x040 → 0x045: MAC
0x046 → 0x04B: MAC
0x04C → 0x058: Serial number (followed by 0x00 in 0x59?)
0x06C → 0x073/0x74: PIN (followed by 0x00 sometimes)

0x100 → 0x103: MPFR magic (0x4D 0x50 0x46 0x52)
0x104 → 0x10B: Some header with flags/lengths
0x10C → .....: Some NVRAM

The problem with SpOeK's (WNDR3700v3's) board_data is that it doesn't contain MPFR magic. We can't really use device ID (unless we want WNDR3700v3 specific workaround). Using MAC/serial number/PIN is also not an option.

[Zajec]

On the other hand, we could use *part* of the device id focusing on that _NETGEAR.

WNR3500L:

0000:0000 | 55 31 32 48  31 33 36 54  39 39 5F 4E  45 54 47 45 | U12H136T99_NETGE
0000:0010 | 41 52 00 FF  FF FF FF FF  FF FF FF FF  FF FF FF FF | AR.ÿÿÿÿÿÿÿÿÿÿÿÿÿ

WNDR3700v3:

0000:0000 | 55 31 32 48  31 39 34 54  30 30 5F 4E  45 54 47 45 | U12H194T00_NETGE
0000:0010 | 41 52 00 FF  FF FF FF FF  FF FF FF FF  FF FF FF FF | AR.ÿÿÿÿÿÿÿÿÿÿÿÿÿ

WNDR4500v1:

001E:0000 | 55 31 32 48  31 38 39 54  30 30 5F 4E  45 54 47 45 | U12H189T00_NETGE
001E:0010 | 41 52 00 FF  FF FF FF FF  FF FF FF FF  FF FF FF FF | AR.ÿÿÿÿÿÿÿÿÿÿÿÿÿ

[Zajec]

I've just noticed one more thing. At 0x8000 there are usually also SSIDs and passwords. I found them on WNDR3700v3 and WNDR4500v1, but no WNR3500L.

WNDR3700v3:

0000:8000 | BD 0B 0D BD  01 00 0A 00  4E 45 54 47  45 41 52 31 | ½..½....NETGEAR1
0000:8010 | 32 00 BD 0B  0D BD 02 00  0D 00 62 61  73 69 63 6D | 2.½..½....basicm
0000:8020 | 6F 6F 6E 32  39 35 00 BD  0B 0D BD 03  00 0D 00 4E | oon295.½..½....N
0000:8030 | 45 54 47 45  41 52 31 32  2D 35 47 00  BD 0B 0D BD | ETGEAR12-5G.½..½
0000:8040 | 04 00 0D 00  62 61 73 69  63 6D 6F 6F  6E 32 39 35 | ....basicmoon295
0000:8050 | 00 BD 0B 0D  BD 00 00 00  00 FF FF FF  FF FF FF FF | .½..½....ÿÿÿÿÿÿÿ

WNDR4500v1:

001E:8000 | BD 0B 0D BD  01 00 0A 00  4E 45 54 47  45 41 52 35 | ½..½....NETGEAR5
001E:8010 | 32 00 BD 0B  0D BD 02 00  10 00 63 6C  65 76 65 72 | 2.½..½....clever
001E:8020 | 76 61 6C 6C  65 79 35 31  34 00 BD 0B  0D BD 03 00 | valley514.½..½..
001E:8030 | 0D 00 4E 45  54 47 45 41  52 35 32 2D  35 47 00 BD | ..NETGEAR52-5G.½
001E:8040 | 0B 0D BD 04  00 10 00 63  6C 65 76 65  72 76 61 6C | ..½....cleverval
001E:8050 | 6C 65 79 35  31 34 00 BD  0B 0D BD 00  00 00 00 FF | ley514.½..½....ÿ

Some magic + flags we can see:
BD 0B 0D BD 01 00 0A 00 before default SSID for 2G
BD 0B 0D BD 02 00 0D 00 or BD 0B 0D BD 02 00 10 00 before password for 2G
BD 0B 0D BD 03 00 0D 00 before SSID for 5G
BD 0B 0D BD 04 00 0D 00 or BD 0B 0D BD 04 00 10 00 before password for 5G
BD 0B 0D BD 00 00 00 00 ends

It's easy no notice that:

0x00 → 0x03: magic 0xBD 0x0B 0x0D 0xBD (BD may stand for board data)
0x04 → 0x04: entry number (0x00 means last)
0x05 → 0x05: unknown
0x06 → 0x06: length (like 0x10 == 16 for "clevervalley514" - including \0)
0x07 → 0x07: unknown

Maybe we could read at 0x8000 and check for that BD 0B 0D BD?

[gz]

The most important info in the board_data is the device id *_NETGEAR. Without this, you can't flash images using cfe's tftp

[Zajec]

Hauke: can u backport:
​http://git.infradead.org/l2-mtd.git/commit/41623cdb472fc0ccda96da80425e6d3aac7147a5
​http://git.infradead.org/l2-mtd.git/commit/2761762265647a0a6f3aba17c519a97533414a31

(This first one may already by in OpenWrt)

[Zajec]

Above patches are already in OpenWrt, they were commited in:

commit 188021a18c27dc529e94a2d6ee39a7e5f222db60
Author: hauke <hauke@3c298f89-4303-0410-b956-a3cf2f4a3e73>
Date:   Sun Jan 12 18:50:45 2014 +0000

    brcm47xx: update mtd drivers

Builds from trunk (​http://downloads.openwrt.org/snapshots/trunk/brcm47xx/) should now detect board_data partition correctly.

Can you guys confirm that, please?

[SpOeK]

Works for me. Thanks!

[    1.540000] Creating 7 MTD partitions on "bcm47xxsflash":
[    1.540000] 0x000000000000-0x000000040000 : "boot"
[    1.550000] 0x000000040000-0x0000007e0000 : "firmware"
[    1.560000] 0x00000004001c-0x000000040960 : "loader"
[    1.560000] 0x000000040960-0x00000013dc00 : "linux"
[    1.570000] mtd: partition "linux" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    1.580000] 0x00000013dc00-0x0000007e0000 : "rootfs"
[    1.590000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    1.610000] mtd: device 4 (rootfs) set to be root filesystem
[    1.610000] mtd: partition "rootfs_data" created automatically, ofs=0x370000, len=0x470000
[    1.620000] 0x000000370000-0x0000007e0000 : "rootfs_data"
[    1.630000] 0x0000007e0000-0x0000007f0000 : "board_data"
[    1.640000] 0x0000007f0000-0x000000800000 : "nvram"

[Zajec]

Hooray, thanks for testing!

Hauke: can you close it?

[hauke]

Thank you for reporting and Zajec for fixing this issue.

The fix was applied in r39249.