OpenWrt 23.05.0 - First stable release

I recall differences landing in v23 in the wifi subsystem, i.e. renaming of devices to generic phy. Might be an idea to delete your wifi config (/etc/config/wireless) and rebuild from scratch.

Is there a way to regenerate the default wireless config file? If I delete it, it doesn't get replaced and I get an error in luci.

wifi config should regenerate the configuration: https://openwrt.org/docs/guide-user/network/wifi/basic#regenerate_configuration

1 Like

Thanks, unfortunately that only produces an empty file :confused:

Well, it seems the MT7615E driver was missing, probably wasn't included in the sysupgrade image.

1 Like

Again - if you are affected: please help to analyze the problem to find the root cause of issues. Make suggestions for a solution.

let me guess - Firefox was the problem? I get problems because of browser cache in firefox all the time. I still use it though because I trust it at least a 10th of the way I could throw it, the others, none of the way.

2 Likes

Yes, that is the problem, it is i known problem...
The last version with WAN LED:

> -----------------------------------------------------
> OpenWrt 19.07.10, r11427-9ce6aa9d8d
> -----------------------------------------------------
> root@OpenWrt:~#  ls /sys/class/leds/
> ath10k-phy0           tp-link:green:lan4    tp-link:green:wan
> ath9k-phy1            tp-link:green:qss     tp-link:green:wlan2g
> tp-link:green:lan1    tp-link:green:system  tp-link:green:wlan5g
> tp-link:green:lan2    tp-link:green:usb1
> tp-link:green:lan3    tp-link:green:usb2
> root@OpenWrt:~#

Here is the issue...

https://github.com/openwrt/openwrt/issues/12301

Don't generalize to all supported devices based on the MT7621 SoC (200+). The three incidents you reference are using different wifi chipsets, e.g. MT7615N (RT-AC85P), MT7915D (WAX202), MT7603E/MT7612E (MIR4A), with individual problems during upgrade.

3 Likes

Exactly. "Stable branch/release" is a term of art in software development that means "Thou shalt not add features on this branch; the only allowed changes are bug fixes." It has nothing to do with suitability for purpose, defects or operational issues.

6 Likes

If you want to have a crack at resurrecting it, you're welcome. You will need to reconcile what happened between ar71xx --> ath79 platform migration. Commit 4e4ee4649553ab536225060a27fc320bf54e458c removed the file mach-archer-c7.c which handled tp-link:green:wan.

Start digging in ar8327.c.

This complain still has nothing to do with this release.

You might ask @adrianschmutzler who might have a better idea.

With 23.05.0, with NanoPi R4S, ethernet TX/RX flow auto-negotiation seems not being respected.

In 23.05.0, ethernet RX/TX flow is always "off", even if auto-negociation is "on" and the connected switch also has auto-negociation set to "on" (to enable TX/RX flow control). More details here.

Is this an issue or is it by design? I've confirmed that in 22.03.5 R4S is correctly negotiating ethernet TX/RX and setting it to "on" as expected.

C7 v2 update: kernel logs fill with:

[56947.009216] ath10k_pci 0000:00:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0
[57240.007954] ath10k_pci 0000:00:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0
[58152.565465] ath10k_pci 0000:00:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0  arvif->paused: 0x0

Compare with 22.03.4 kernel logs:

[1382201.460553] ath10k_pci 0000:00:00.0: mac flush vdev 1 drop 0 queues 0x2 ar->paused: 0x0  arvif->paused: 0x0
[1382476.107888] ath10k_pci 0000:00:00.0: mac flush vdev 1 drop 0 queues 0x2 ar->paused: 0x0  arvif->paused: 0x0
[1383042.033998] ath10k_pci 0000:00:00.0: mac flush vdev 1 drop 0 queues 0x2 ar->paused: 0x0  arvif->paused: 0x0

I tried to upgrade my RT3200 from 22.03.5 to 23.05.0 with auc -y -b 23.05 -B 23.05.0 , but that did not go very well...
The luci-app-wireguard does not exist anymore (I just removed that one fro the upgrade) but after the upgrade:
-No 5 GHz wifi I guess the MT7915 modules/driver is missing?
-No usb (the usb port does not function properly).
-Weird comments on the blocks, something not fitting to the flash layout?
-Some issues with pins (see log file here below).

So I just installed the 'clean' UBI image for RT3200 and that worked without errors. I just manually restored the packages and settings and everything seems to work properly.
For new releases, it is probably best to start from scratch.
The updates to the RT3200 wifi are very welcome!

Tue Oct 17 11:05:13 2023 kern.err kernel: [    0.401305] mt7622-pinctrl 10211000.pinctrl: invalid group "pwm_ch7_2" for function "pwm"
Tue Oct 17 11:05:13 2023 kern.err kernel: [    0.414148] mt-pmic-pwrap 10001000.pwrap: unexpected interrupt int=0x1
...
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    0.590927] 4 fixed-partitions partitions found on MTD device spi2.0
Tue Oct 17 11:05:13 2023 kern.err kernel: [    0.597330] OF: Bad cell count for /spi@1100d000/flash@0/partitions
Tue Oct 17 11:05:13 2023 kern.err kernel: [    0.603624] OF: Bad cell count for /spi@1100d000/flash@0/partitions
...
Tue Oct 17 11:05:13 2023 kern.err kernel: [    0.911032] mtk-wdt 10212000.watchdog: IRQ index 0 not found
...
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    1.990656] ubi0: attaching mtd3
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.293745] ubi0: scanning is finished
Tue Oct 17 11:05:13 2023 kern.warn kernel: [    2.301854] ubi0 warning: 0xffffffc00856a8f4: cannot reserve enough PEBs for bad PEB handling, reserved 18, need 20
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.313907] ubi0: attached mtd3 (name "ubi", size 125 MiB)
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.319407] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.326298] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.333096] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.340051] ubi0: good PEBs: 1000, bad PEBs: 0, corrupted PEBs: 0
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.346146] ubi0: user volume: 6, internal volumes: 1, max. volumes count: 128
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.353368] ubi0: max/mean erase counter: 4/1, WL threshold: 4096, image sequence number: 1229978775
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.362501] ubi0: available PEBs: 0, total reserved PEBs: 1000, PEBs reserved for bad PEB handling: 18
Tue Oct 17 11:05:13 2023 kern.notice kernel: [    2.371810] ubi0: background thread "ubi_bgt0d" started, PID 514
...
Tue Oct 17 11:05:13 2023 kern.debug kernel: [    8.039142] mt7915e 0000:01:00.0: assign IRQ: got 146
Tue Oct 17 11:05:13 2023 kern.info kernel: [    8.044358] mt7915e 0000:01:00.0: enabling device (0000 -> 0002)
Tue Oct 17 11:05:13 2023 kern.debug kernel: [    8.050467] mt7915e 0000:01:00.0: enabling bus mastering
Tue Oct 17 11:05:13 2023 kern.info kernel: [    8.056017] mt7622-wmac 18000000.wmac: HW/SW Version: 0x8a108a10, Build Time: 20190801210006a
Tue Oct 17 11:05:13 2023 kern.info kernel: [    8.056017]
Tue Oct 17 11:05:13 2023 kern.info kernel: [    8.162449] mt7622-wmac 18000000.wmac: N9 Firmware Version: _reserved_, Build Time: 20220630094834
Tue Oct 17 11:05:13 2023 kern.debug kernel: [    8.172120] mtk-pcie 1a143000.pcie: msi#0 address_hi 0x0 address_lo 0x44db50c0
Tue Oct 17 11:05:13 2023 kern.warn kernel: [    8.232181] mt7915e 0000:01:00.0: Direct firmware load for mediatek/mt7915_rom_patch.bin failed with error -2
Tue Oct 17 11:05:13 2023 kern.warn kernel: [    8.242126] mt7915e 0000:01:00.0: Falling back to sysfs fallback for: mediatek/mt7915_rom_patch.bin
Tue Oct 17 11:05:13 2023 kern.warn kernel: [    8.995496] mt7915e: probe of 0000:01:00.0 failed with error -12

1 Like

That's not how we solve problems around here. The correct way is to identify the source of any issues and fix them.

FWIW, I've been continuously running aribtrary main checkouts on my Unifi 6 Lite's over the last year, including around the time when 23.05 was forked off. I haven't noticed any issues with the WiFi.

This doesn't mean that there can't be bugs, in particular bugs related to specific devices. But those bugs won't get magically fixed if every user crawl back to some older version. Someone with an affected device has to hit the bug and report it. Preferably with a bit more information than "MT7621 has massive problems with WiFi " without even mentioning which device or wifi chip this refers to.

10 Likes

I've updated to 23.05.0 a Belkin RT1800 and two Netgear WAX202, and I installed it on a new D-Link DAP-X1860, all MT7621+MT7915 devices. They're all running perfectly, including the WiFi.

Thank you very much for the new release guys.

I see those are screenshots. Do you have a web link to provide to see those changes in the readable format that you have posted?

Thanks - but I'm a bit confused about the support of the TurrisOmnia device. Is it supported with the new release (again) or not?
It is not listed in the table of hardware, on its device page still the 22.03.2 version is stated as current, BUT an image exists if one browses "all firmware".

I updated C7 v2 and hit a wireless issue. This C7 is a WDS client. Deleted wireless config for it to regen back to default. Reconfigured and it is working again.

I suspect it now needs ESSID field to be filled, previously I only had BSSID configured with blank ESSID and it works with 22.03.05. So heads up if anyone hit this too.

Also updated a EA7500v2 (MT7621 :slightly_smiling_face:) and this one was super smooth.

Surprisingly it can now download at the subscribed full 1 Gbps speed when before it can achieve only half-speed and this is without any software or hardware offloading.

1 Like