Opened 5 years ago
Closed 4 years ago
#13733 closed defect (fixed)
Netgear WNDR3700v3 - overwriting board_data flash partition
Reported by: | goni@… | Owned by: | hauke |
---|---|---|---|
Priority: | high | Milestone: | Chaos Calmer 15.05 |
Component: | packages | Version: | Trunk |
Keywords: | wndr3700v3, board_data, trunk, barrierbreaker, cfe | Cc: |
Description
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
Attachments (2)
Change History (26)
comment:1 Changed 5 years ago by anonymous
comment:2 Changed 5 years ago by anonymous
in my case tftp anyway accept orginal image, but i got mess in settings such as mac, cannot upgrade image over webgui etc.
comment:3 Changed 5 years ago by gz <goni@…>
It is still relevant.
comment:4 Changed 5 years ago by hauke
- Owner changed from developers to hauke
- Status changed from new to assigned
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.
comment:5 Changed 5 years ago by 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.
comment:6 Changed 5 years ago by 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.
comment:7 Changed 5 years ago by gz <goni@…>
I'll have access to the router only on Friday,I will post an answer as soon as I can.
comment:8 Changed 5 years ago by 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
comment:9 Changed 5 years ago by hauke
- Resolution set to fixed
- Status changed from assigned to closed
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.
comment:10 Changed 4 years ago by SpOeK
- Resolution fixed deleted
- Status changed from closed to reopened
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"
comment:11 Changed 4 years ago by 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.
comment:12 Changed 4 years ago by 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...
comment:13 Changed 4 years ago by 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.
Changed 4 years ago by SpOeK
comment:14 follow-up: ↓ 15 Changed 4 years ago by 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?
comment:15 in reply to: ↑ 14 Changed 4 years ago by 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.
comment:16 Changed 4 years ago by 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.
comment:17 Changed 4 years ago by 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.ÿÿÿÿÿÿÿÿÿÿÿÿÿ
comment:18 Changed 4 years ago by 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?
comment:19 Changed 4 years ago by 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
comment:20 Changed 4 years ago by 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)
comment:21 Changed 4 years ago by 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?
comment:22 Changed 4 years ago by 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"
comment:23 Changed 4 years ago by Zajec
Hooray, thanks for testing!
Hauke: can you close it?
comment:24 Changed 4 years ago by hauke
- Resolution set to fixed
- Status changed from reopened to closed
Thank you for reporting and Zajec for fixing this issue.
The fix was applied in r39249.
i can confirm that on dgnd3700v1 board_id=(empty) after openwrt test image.