OpenWrt 22.03.0-rc1 first release candidate

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

@neg2led

have you updated the id_len field in the second row of the https://elixir.bootlin.com/linux/latest/source/include/linux/mtd/rawnand.h#L1416 to 5 as well? (otherwise it would just match the first four bytes which would cause something like this to happen.)

ie:

      {"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: https://lore.kernel.org/lkml/165343125723.3997.9953251172151290451.pr-tracker-bot@kernel.org/T/

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 daemon.info 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

May I ask, why there is currently both an unanounced 22.03 rc2 and unannounced 22.03 rc3 on the download servers?
Did something go wrong when trying to build rc2?

1 Like

Today I dug a little bit around while the computer was busy, found a pdf from Toshiba listing both chips and their familys. According to that the N-type is the standart no-ECC flash chip and the B-type is a so-called benand flash, that has some built-in ECC engine. According to that Q&A pdf they should be pin-, electrical- and mostly command-compatible - which we proved wrong. I could imagine that for some odd reasons we get the ECC-Bits read out without recognising it - which the chip alters - and so we detect a bit flip due to a double-ECC-check...

My 7412 honors the fifth tag, so altering the id_len from 4 to 5 and adding a ", 0x72" solved the problem for me, a fix near a typo... Should be tested with a device that has the N-model to be shure not to break things there.

Oh and I needn't to be mentioned, was just stumbling across and said "ouch", @hnyman and you @chunkeey belongs the honor to point me in the right direction and solved that issue. Thanks!

3 Likes

There was a problem when rc2 was tagged and it wasn't reflecting the correct version number or opkg repository paths.

2 Likes

FYI, discord automatically provides RSS feeds - https://forum.openwrt.org/c/announcements/14.rss is the feed for the announcements category.

(It's listed on the contact page, but I just wanted to point out that it was a "right now" thing, not an "in the future" thing :slight_smile:)

1 Like

FYI, the forum is running Discourse, not Discord. :slight_smile:

6 Likes

Yeup just informing, for me the RC3 doesnt work at all on my Raspberry pi 4B

I lose connection all the time, the Pi have internet because i can ping but lan stops working after some minutes. Rolled back to Rc1 and now it works as it should.

Not sure what happens there tho.

I have the rpi4b in rc3 and it doesn't happen to me from the disconnections

successfully installed on tp-link c50 v4
problems with WAN MAC and pppoe connection disconnects after applying settings in interfaces section and not connected only by restart router
and i fell luci is slow and put a load on device