OpenWrt 22.03.0-rc1 first release candidate

OpenWrt 22.03.0-rc2 and rc3 are causing on a Fritzbox 7412 bootloops due to a misdetected flash chip.

Until OpenWrt 22.03.0-rc1 the boot log states

[    8.397735] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xf1
[    8.402654] nand: Toshiba NAND 128MiB 3,3V 8-bit
[    8.407264] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64

but beginning with OpenWrt 22.03.0-rc2 the boot log states

[    8.420923] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xf1
[    8.425851] nand: Toshiba TC58NVG0S3HTA00 1G 3.3V 8-bit
[    8.431069] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128

The chip soldered on my device reads as Toshiba TC58BVG0S3HTA00, which has a different page organisation and it complains about fixable bit-flip detection and afterwards about uncorrectable ECC errors when it's handled like the N. Dunno yet how to fix, but haven't investigated further...

But rc2 and rc3 are not released yet, so...

Sounds like caused by this backport by @chunkeey
"kernel: add support for Toshiba TC58NVG0S3HTA00 NAND flash";a=commitdiff;h=ec45e1ff68d198aded784ad7712484c1474ede60;hp=144d9c4a43cb871756b8e96f9e8c6a1d3f1d915d

Sounds that there are Fritzboxes out there with different flash chips soldered on, the 7430 should be a sibling to the 7412. How to expand the patch to detect the right flash chip? (Can't speak C...) Completely reverting it is only the second best option I think, there is a reason for it...

letters, numbers and special character combined

I tried it again without keeping settings, WIFI Password still not working.

However, only phones (Oneplus 8 pro and Galaxy S22 Ultra, if it matters) can't connect to wifi, wrong password. My 5 years old laptop has no issue connecting. It is weird.

I had some problems that were solved with 30/30/30, in the case of this problem that you report, I had to change the encryption, but after a while, the problem was a lack of connection with the repeater
so I thought it was better to change wpad wolf basic to wpad mini
Beware of the process of changing packages.

Do you have WPA2 or 3 setup in the router?

Yup, that patch is missing the 5th ID byte entirely - both chips share the same first 4;

TC58NVG0S3HTA00 = 0x98 0xf1 0x80 0x15 0x72 (digikey datasheet, page 35)
TC58BVG0S3HTA00 = 0x98 0xf1 0x80 0x15 0xf2 (digikey datasheet, page 28)

but the last one is different and indicates number of "districts" (banks?), as well as the presence of an on-chip ECC engine in the BVG part.

Adding the extra byte to the matcher should clear that one up - it'd be ideal to add both parts explicitly, mind.


Had the same idea, added the missing 0x72 but left out a description for the B-model and built it this morning (my first build from sources...)
Nope, still remaining the detection of the wrong chip...
Actually I'm building a test (22.03.0-rc3) without the entire patch. But it's poking around...

Sidenote: qosify won't get downloaded for some unrecovered issues. The coresponding Makefile looks good at first sight...

Can confirm adding the missing bye doesn't work

Running 22.03.0-rc1/2/3 on Ubiquiti ER-X with no critical issues so far. However, I would to report a minor problem. When I enable hardware flow offload, RX/TX counters in ifconfig stop counting all packets/bytes, only some amount (?) of them.

Let me try to explain further below in more detail (WAN is on eth0):

  1. Hardware flow offload is disabled:
    a. Download a 100 MB file
    b. ifconfig shows 100MB+ of RX traffic on interface eth0

  2. Hardware flow offload is enabled:
    a. Download a 100 MB file
    b. ifconfig shows ~1MB of RX traffic on interface eth0

Some other observations:

  1. This is also observed on a vanilla factory default config with no changes to the default settings.
  2. In both cases traffic is incremented on the dsa interface.
  3. This lack of RX traffic activity propagates to all parts of luci UI, so you can't effectively see the uptick of traffic on the "traffic" tab of "Realtime graphs" page or on the "Interfaces" page when you perform the download.
  4. Software flow offload doesn't affect the correctness of traffic counters.
  5. Most of the traffic doesn't seem to be present even when I run tcpdump on e.g. eth0 or other interfaces. I see some traffic in the tcpdump output but I can't yet find a pattern in what is shown and what's not.

I filed a bug regarding that.
Feel free to add evidence / solutions to the bug.

cc @neg2led @castiel652

1 Like


have you updated the id_len field in the second row of the to 5 as well? (otherwise it would just match the first four bytes which would cause something like this to happen.)


      {"TC58NVG0S3HTA00 1G 3.3V 8-bit",
              { .id = {0x98, 0xf1, 0x80, 0x15, 0x72, } }, /* added 72 */
                SZ_2K, SZ_128, SZ_128K, 0, 5, 128, NAND_ECC_INFO(8, SZ_512), }, 
                //                         ^----- id_len (hope this alignes, it didn't seem to look right when posted)

      /* just for reference? not strictly needed if the oob detection works for this nand */
      {"TC58BVG0S3HTA00 1G 3.3V 8-bit",    
              { .id = {0x98, 0xf1, 0x80, 0x15, 0xf2, } }, /* added f2 */
                SZ_2K, SZ_128, SZ_128K, 0, 5, 64, NAND_ECC_INFO(8, SZ_512), },

Note: The patch that added the TC58NVG0S3HTA00 is in the the mtd 5.19-rc pull request:

if adding the 0x72 and changing the id_len to 5 is enough, then a patch should be sent upstream.

This is an expected behaviour and have been there for a long time with hw offloading enabled.

1 Like

I did a short test of 22.03.0-rc1/2/3 in an unprivileged lxc-container. Container has a config as in OpenWrt docs. dnsmasq refuse to start and system log gets these lines.

Sun May 29 17:37:00 2022 daemon.crit dnsmasq[1]: failed to seed the random number generator: No such file or directory
Sun May 29 17:37:00 2022 daemon.crit dnsmasq[1]: FAILED to start up
Sun May 29 17:37:00 2022 procd: Instance dnsmasq::cfg01411c s in a crash loop 6 crashes, 0 seconds since last crash

However, dnsmasq starts ok with cmd /etc/init.d/dnsmasq trace, as it seems to start without ujail, so no meaningful info gets to trace log in /tmp.

dnsmasq works fine with the same container config on the stable version OpenWrt 21.02.3.

My guess is, the failure relates to dnsmasq ujail setup of release canditates in a lxc-container. ujailed ntp process is fine in the container.

22.03.0-rc1/2/3 rootfs were made with the image builder with OpenWrt default configs, no custom configs were yet injected to the container system.

Thanks for mentioning that. Could you please specify some keywords to search for me to find a relevant issue/discussion or maybe you could even give a link to some mailing list thread/forum post to find out more? I would highly appreciate that since I was googling with different combinations of various keywords but unfortunately to no avail.

That's the missing bit, 'cause I don't know the meaning of the fields below the .id tag I didn't change 'em ( and didn't try to guess 'em either... )

What I can confirm without that patch 22.03.0-rc3 works just fine. Next trial tomorrow with your changed line...

Ok, if you want, you could have the "Reported-by:, Tested-by" tags of the patch that has to be sent upstream. Thing is, this requires your real name and e-mail. Yes, this name+e-mail will become public and spammer might pick them up.

Same deal for @hnyman, @neg2led I think you both suggested the fix? Please add a message with the tag to the issue for your contribution.

Did you check whether reading the fifth byte really works on a 7530 with the new flash chip? I never managed to read more than this four byte ID - or I did something wrong.

EDIT: OK, I did. And we have a problem now: With the five-byte ID, the flash chip on my 7530 is not properly detected.
EDIT2: Now that I added a printk() statement to check how long the ID is, I remember that I did that before when coming up with the patch. The ID len read in nand_base.c is only 4 bytes.

WPA2 - PSK/WPA3 -SAE Mixed Mode (Strong security) in Router

WPA2/WPA3-Personal in Phones.

Same settings for 21.02.3 and 22.03.0-rc1 or rc3. There is no issue for 21.02.3. but wrong wifi password for 22.03.0-rc1 or rc3. Something must have changed to cause this issue.

Agree. Something changed. The solution however is to use WPA2 only.

1 Like