NETGEAR R6220 random MAC problem

[pld]

Hi there,

After installing OpenWRT I found the following in the dmesg:

EEPROM data check failed: 0000
Invalid MAC address, using random address xx:xx:xx:xx:xx:xx

According to https://openwrt.org/toh/netgear/r6220 this could be a problem with bad erase blocks resulting different wifi calibration data location, The problem is supposed to have bean fixed on 19.07. I tried 19.07.0, 19.07.10 and 21.02.3. No luck. After reverting to stock firmware, router gets proper MAC. Thus, the problem seems to be related to OpenWRT only.

I do not know if this is significant but the OpenWRT description mentions:

EEPROM data check failed: ffff

but I get

EEPROM data check failed: 0000

Any suggestions how to get proper MAC and calibration data?

Thank in advance for any help.
Greg

[Borromini]

You can check the flash contents to see if the data has been relocated. See this topic:

R6260 - Low TX Power

Hi, I have recently installed OpenWrt on my R6260 and found that similarly to this post, I found that my TX Power could only be a maximum of 6dbm. Using the information on the post, I followed these steps: Download the image builder for the correct OpenWrt snapshot:openwrt-imagebuilder-ramips-mt7621.Linux-x86_64.tar.xz Apply the patch with the following command: patch -p1 < patch.patch Build the image for the R6260 and flash the sysupgrade bin through LUCI. Unfortunately no matter w…

[pld]

Hi,

I dumped mtd using both, stock firmware and OpenWRT. When using stock dumping mtd10 (factory) and mtd18 (ML6) was impossible. That is why I dumped mtdblock instead. All dumps are available at
http://yen.ipipan.waw.pl/~gs159090/MTD.txz

I do not know to much about calibration data. Compering the contents of Factory (mtdblock10@stock vs. mtd4@OpenWRT) I noticed that the contents of mtdblock10@stock is at the offset 0x20000 of mtd4@OpenWRT.

What should I do next?

[pld]

btw:

root@OpenWrt:/dev# hexdump -C /dev/mtd4 
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00020000  03 76 0b 00 8c 3b ad 44  42 b8 03 76 c3 14 ff ff  |.v...;.DB..v....|
00020010  ff ff 03 76 c3 14 00 00  00 00 00 00 00 00 00 00  |...v............|
00020020  00 00 b0 07 80 00 60 7f  fd 9b ff ff ff ff ff ff  |......`.........|
00020030  ff ff ff ff 22 34 00 20  ff ff 00 01 00 00 00 00  |...."4. ........|
00020040  00 00 22 00 00 00 00 00  00 00 00 00 00 00 e0 01  |..".............|
00020050  82 00 00 94 40 ba c0 c9  23 00 00 00 c0 c9 23 00  |....@...#.....#.|
00020060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00020070  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000200a0  c8 c8 c8 c8 00 00 00 c8  c2 c6 c2 c2 c2 00 00 00  |................|
000200b0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000200f0  05 00 00 00 ae 00 67 88  00 00 00 00 00 00 00 00  |......g.........|
00020100  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00020120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 ff 20  |............... |
00020130  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00028000  62 76 01 00 8c 3b ad 44  42 bc 12 76 c3 14 00 00  |bv...;.DB..v....|
00028010  00 00 12 76 c3 14 00 00  00 00 ff ff ff ff ff ff  |...v............|
00028020  ff ff 37 d8 9d 40 ff 7f  fd 9b ff ff ff ff ff ff  |..7..@..........|
00028030  ff ff ff ff 22 fd 0a 00  ff ff b1 01 00 00 00 00  |...."...........|
00028040  00 00 ff d7 8c 8c 00 00  00 8c 00 00 00 8c e0 01  |................|
00028050  00 82 82 57 47 b2 7f 05  1d 00 00 00 7e 16 0a 00  |...WG.......~...|
00028060  00 00 82 e9 0a 00 00 82  e9 18 00 00 81 ed 17 00  |................|
00028070  00 80 f0 18 00 00 81 f6  1b 00 00 80 fe 1e 00 00  |................|
00028080  82 e2 0a 00 00 82 e2 1b  00 00 82 e8 1b 00 00 82  |................|
00028090  e6 1b 00 00 83 eb 1b 00  00 83 f2 1b 00 00 00 53  |...............S|
000280a0  c3 c3 00 00 00 00 c6 c6  c2 82 c6 c6 c2 82 00 00  |................|
000280b0  00 00 c6 c6 c4 00 00 00  00 00 00 00 00 00 84 83  |................|
000280c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000280f0  ff ff 0d 09 0d 10 a5 28  28 00 00 00 00 00 00 00  |.......((.......|
00028100  0f ca 74 c5 e8 07 30 3d  01 b0 08 26 00 0e 04 15  |..t...0=...&....|
00028110  00 8a 00 40 00 00 00 08  00 9d 08 00 12 c0 00 00  |...@............|
00028120  08 20 04 2a 90 00 00 24  01 04 54 08 d0 a0 28 20  |. .*...$..T...( |
00028130  ff ff ff ff ff ff ff 08  ff ff ff ff ff ff 00 00  |................|
00028140  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
000281e0  c0 81 82 c3 04 45 46 07  08 09 ff ff ff ff ff ff  |.....EF.........|
000281f0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00100000

[anon69880279]

Look this:

GitHub - jayanta525/openwrt-netgear-r6220-0x2de0000: Netgear R6220 AC1200...

or

GitHub - jayanta525/openwrt-netgear-r6220-100ins: Netgear R6220-100INS AC1200...

or

MT7603EN/MT7612EN Wifi Troubles on Netgear R6220

Sure. Ill start building now

or
test x-wrt
https://downloads.x-wrt.com/rom/

infos:

ramips: mt7621: r6220: add support for additional flash layouts

Netgear R6220: fix flash layout

[Borromini]

Looks like your wireless calibration data is at 0x20000 for the MT7603 radio (2,4 GHz) and at 0x28000 for the MT7612 radio (5 GHz).

The DTS specifies the same offsets (0x0 and 0x8000) for the calibration data on the factory partition, so that looks good:

&pcie0 {
        wifi@0,0 {
                compatible = "mediatek,mt76";
                reg = <0x0 0 0 0 0>;
                mediatek,mtd-eeprom = <&factory 0x8000>;
                ieee80211-freq-limit = <5000000 6000000>;
        };
};

&pcie1 {
        wifi@0,0 {
                compatible = "mediatek,mt76";
                reg = <0x0 0 0 0 0>;
                mediatek,mtd-eeprom = <&factory 0x0>;
                ieee80211-freq-limit = <2400000 2500000>;
        };

However, it looks like the factory partition is supposed to be at 0x2e00000, not 0x20000, so the addresses OpenWrt expects the calibration data to be at would be 0x2e00000 and 0x2e08000 respectively (taking the offsets into account), if I'm not mistaken:

                factory: partition@2e00000 {
                        label = "factory";
                        reg = <0x2e00000 0x100000>;
                        read-only;
                };

I'm not sure what's the best approach here. The 0x20000 partition is labeled as the kernel partition, so something's not right...

[anon69880279]

I think there should be a solution with this address story at 0x2e00000

edit original mtd10
hexedt
copy beginning of file ( 0 to FFFF ) and add to last of file
now there will be something in E0000 ( 0x2e00000 )

afterwards you will have to flash the modified mtd10 file

opkg update
opkg install kmod-mtd-rw
insmod mtd-rw.ko i_want_a_brick=1
dmesg | grep mtd-rw

copy with scp mtd10-modified to /tmp/tmp
cd /tmp/tmp

mtd write mtd10_modified factory

reboot
*
I have already used this method to change the MAC addresses of several boxes that had MAC address that did not correspond to the product label like my NewIfi D2

If you cannot add kmod-mtd-rw to build the module outside the OpenWRT-build-system, use
$ make CONFIG_MTD_RW=m
make -j4
flash

[lleachii]

@pld

a problem with bad erase blocks resulting different wifi calibration data location, The problem is supposed to have bean fixed on 19.07

Ummm, OpenWrt developers can't fix a device's bad flash. Maybe this was a slight mis-wording - but I thought I should note this.

Hopefully that area isn't corrupted.

[anon69880279]

-> lleachii

I looked at the contents of the mtd10 stock and mtd4 openwrt files
mtd10 ( 896 Ko ) is smaller than mtd4 ( 1024 Ko ) so there is nothing at 0x2e0000

[Borromini]

@lleachii

Ummm, OpenWrt developers can't fix a device's bad flash.

Well, OEM firmware takes relocated calibration data etc. into account while OpenWrt does not - but there's patches available for doing just that.

[janh]

@csharper2005 is currently trying to get the partition parser that would fix this issue upstreamed into the Linux kernel.

[csharper2005]

@janh

is currently trying to get the partition parser that would fix this issue upstreamed into the

Thanks for the announce. The patch was applied to mtd-next. I backported it to 5.10 and 5.15 kernel in this PR. We need a reviewer from OpenWrt team. After that we can apply the patch to all necessary devices.

[Borromini]

Would be better to open a separate PR for the backport, since you're widening the scope of the existing one. Will be more difficult to trace commits, too, and lots of other devices will benefit from this.

[pld]

I decided to increase the offsets to calibration data and MAC address by 0x2000. The device is running fine. According to this:

[    0.810611] Scanning device for bad blocks
[    1.286029] Bad eraseblock 368 at 0x000002e00000
[    1.436596] Bad eraseblock 480 at 0x000003c00000
[    1.516159] Bad eraseblock 536 at 0x000004300000
[    2.142906] 6 fixed-partitions partitions found on MTD device mt7621-nand
[    2.156425] Creating 6 MTD partitions on "mt7621-nand":
[    2.166843] 0x000000000000-0x000000100000 : "u-boot"
[    2.178167] 0x000000100000-0x000000200000 : "SC PID"
[    2.189460] 0x000000200000-0x000000600000 : "kernel"
[    2.200703] 0x000000600000-0x000002200000 : "ubi"
[    2.211587] 0x000002e00000-0x000002f00000 : "factory"
[    2.222985] 0x000004200000-0x000007e00000 : "reserved"

the factory partition is located at 0x2e20000.
Thanks for help.

[csharper2005]

Nice idea. I can also make a PR applies the changes to R6260. I need someone who have the device with bad blocks and ready to make tests.
upd. ready - https://github.com/openwrt/openwrt/pull/10038

[csharper2005]

Congrats! Can you share with me your mtd1 (SC PID) dump, please?

[pld]

Link above