OpenWrt 22.03.4 service release

22.03.5 has NOT been released. A tag has been created in the repo, but until the devs tell you otherwise, DO NOT try to install it.

5 Likes

it is released

Index of /releases/22.03.5/ (openwrt.org)

Your text only tell, it takes 2 days until all versions are build. It not change anymore or change again.

Building new version not happen every time. I only ask, what is fatal fail why new version need release.

I’m sure all will be revealed when it is officially announced. Patience.

It’s very likely about the UBI regression.

4 Likes

i dig it myself.

[OpenWrt Wiki] OpenWrt v22.03.5 Changelog

It has not been released. The release will be officially announced with a thread much like this one. The build system is likely still running. Please read the thread linked by @efahl -- it is very relevant.

6 Likes

Are you running router on a stick? Meaning, are you using the single ethernet port on the rpi4 for lan and wan, by using vlans in a managed switch (r7800 in my case)? I get no errors when using a rtl8153 dongle for wan, but since my internet is only 300mbps, router on a stick is fine for me maxing out at 500mpbs without using the 8153 usb to ethernet dongle

From a relative novice, I've just done a sysupgrade to 22.03.4 on my Mochabin and spun up no issues. Working well with my backed up settings from 22.03.3. How come people are talking about 22.03.5 already, seems very quick going from 22.03.4 to 22.03.5? Is it because of some issues people are having above.

Out of interest as well, does anyone know when support for the following packages will be included in the stable build?
• kmod-ath11k
• kmod-ath11k-pci
• ath11k-firmware-qca6390
These are the ones I think I need for the wireless on Mochabin to work, but is currently only available in Snapshot which I struggle with.

Router on a stick was my first configuration with the rpi4b, but I gave it up in favour for the UE300 solution. For me the 2 ethernet port configuration has an important advantage:

My internet access is via LTE with a Zyxel LTE4506 router (operated in bridge mode). My ISP assigns a public IP address via DHCP, which is changed at least once a day.

When the LTE4506 gets a new IP address, it sets the signal "Link down" at its LAN port. If the LTE4506 is connected to a managed switch, the switch does not transfer this "Link down" signal to the rpi4b (owrt router). So the rpi4b operates with an invalid IP address until the lease time is over. Result: no internet access.

With an UE300 as the second ethernet port the "Link down" signal arrives at the rpi4b and triggers an "ifup wan" (including a DHCP discover). The change from old/invalid IP address to new/valid IP address is less than 60 seconds. During the night hours this delay doesn't matter. At least for me.

1 Like

I never do it myself, but there is two methods install openwrt.
Update to old firmware or empty all and install openwrt over router flash.
Common methond is update old firmware with new.
Latest update fix some overflash problems and give minor fixing to others.
If i understand wrong, some will advice right.

It seems like 22.03.5 will be released in the next few days.

I wasn't expecting that as 22.03.4 released just a few weeks ago.

Can confirm and couldn't agree more. This images should be removed from the download page.

Spent a hours worth of time a couple weeks ago trying to recover a EA8300 setup as a dumb access point. Only to discover a couple days later when finally being able to invest some time on researching and checking the forums of this issue. If it had been removed it would of saved time.

Very surprised it's still currently listed and downloadable for both MR8300 and EA8300 even as of this post reply.

2 Likes

I upgraded to 22.03.4 on more than 10 devices and everything went well. I'll upgrade to 22.03.5 tomorrow if it's released. I don't know why and if a new release will come out that far, but for sure I know OpenWRT is really nice, and support is really good on this forum. Making Openwrt for such an impressive list of devices is for sure a difficult and time consuming process. I thank all the people working on Openwrt for their work. Thanks!!!

1 Like

Consider this as "bad luck". There are several thousands of device supported, tens of targets. At each release, there is necessarly some bugs remaining that prevent some device(s) to run. Well this time it was EA/MR8300. Next time it will be another device. Before upgrading, consider reading release announcement and wiki ... you'll never known what can happened.
Furthermore, there is a lot (I mean a lot !) of files available for download that will never run, and sometimes can't even been flashed. I think of images for very old devices (4/32). There are more or less supported, and image builder continue to build theses images, even if they are not usable. It's up to the user to think about this.

While it is up to the user to think about this right now, I am sure it would be possible to somehow come up with a technical solution, at least for the 4/32 devices. Flash size is usually entered into the ToH, so could the firmware selector not cross-check its availability based on the toh?

Also, building all these images for devices that cannot even be flashed increases buildtime of image builders a lot, no?

As for devices that are buggy (like EA/MR8300), I am not sure how a automated mechanism could look like for disabling them in releases, but is it really that hard? Obviously, the easy, but lazy way out is to tell users to read release notes...

The solution is to manually build and remove some options. I was able to do this for an old device recently. It works beyond expectations.

They do. I have mixed feelings about this. As long as a device can be supported, it should be. But at some point it should be dropped. There is a minimum (8/64 for example) requirement for a release. When the device doesn't meet the requirement it should be skipped from image building. In fact some automatic generated images can't even be flashed. It should be up to the user to create its own build, assuming he understands that his device is outdated.

You may have forgotten the OpenWrt is not a commercial product. I quote the licence: "OpenWrt is free software, provided AS-IS and without any warranty." and "Support may be provided on a voluntary basis by developers and fellow users, but is not guaranteed.".

1 Like

If these images are known to not work, why not simply remove them, sure, there are probably others in the same situation we don't know of. But these we know, and if we know we should remove them.

These are not unpopular devices, the MR8300, EA8300 and EA6350.

1 Like

Unfortunately the same story as with 22.03.03: Both 22.03.04 and 22.03.03 for DLINK DIR-885L H/W A1 F/W Ver.: 1.00 have the same issue - no proper working 5GHz wifi due not correct firmware out of the box with fresh Openwrt. Only 2.4 GHz is working correct.
I have described the fix here D-Link 885L/R A2 - OpenWrt 18.06.2 - upgrade - #8 by _Searcher
Also unfortunately on 22.03.3 5GHz with my fix still is not stable and I really missed any proper embedded watchdog to catch all radio0 and radio1 fails.
Currently I am using self written procd script to catch: iwinfo wlan0 info Signal "unknown" but unfortunately it is not the full case for wifi radio interfaces failing and it is still required to restart interfaces from time to time manually until better watchdog will be created.

Additional info about device: (with modified brcmfmac4366b-pcie.bin)

[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: D-Link DIR-885L
...
[    2.030807] bcma-host-soc 18000000.axi: bus0: Found chip with id 53030, rev 0x00 and package 0x00
...
[   11.525729] brcmfmac 0000:01:00.0: enabling device (0140 -> 0142)
[   11.651711] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366b-pcie for chip BCM4366/3
[   11.662879] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4366b-pcie.dlink,dir-885l.bin failed with error -2
[   11.820888] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4366b-pcie.dlink,dir-885l.txt failed with error -2
[   11.832167] brcmfmac 0000:01:00.0: Direct firmware load for brcm/brcmfmac4366b-pcie.txt failed with error -2
[   12.094237] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366b-pcie for chip BCM4366/3
[   12.103014] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[   12.114338] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/3 wl0: Jan  8 2016 12:54:07 version 10.10.69.3309 (r610991) FWID 01-c47a91a4
[   12.138412] pci 0001:00:00.0: enabling device (0140 -> 0142)
[   12.144180] brcmfmac 0001:01:00.0: enabling device (0140 -> 0142)
[   12.261867] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366b-pcie for chip BCM4366/3
[   12.270577] brcmfmac 0001:01:00.0: Direct firmware load for brcm/brcmfmac4366b-pcie.dlink,dir-885l.bin failed with error -2
[   12.285872] brcmfmac 0001:01:00.0: Direct firmware load for brcm/brcmfmac4366b-pcie.dlink,dir-885l.txt failed with error -2
[   12.297152] brcmfmac 0001:01:00.0: Direct firmware load for brcm/brcmfmac4366b-pcie.txt failed with error -2
[   12.556513] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366b-pcie for chip BCM4366/3
[   12.565394] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[   12.576812] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/3 wl0: Jan  8 2016 12:54:07 version 10.10.69.3309 (r610991) FWID 01-c47a91a4
[   12.620189] kmodloader: done loading kernel modules from /etc/modules.d/*
[   16.768595] bgmac_bcma bcma0:5 eth2: Link is Up - 1Gbps/Full - flow control off

starting with the bad hardware news: Broadcom WiFi chips (that this device has) have a general warning of being a major culprit with OpenWRT.

continuing with bad maintenance news:
The low forum activity of that particular device looks like that device misses reasonable attention since quite a long time. The few forum posts further look like the package was ported from Archer c5 v2, which uses yet another Broadcom WiFi chip, which would explain the weird WiFi post installation step you describe.

I am wondering a bit, how this device package made it into release state, considering Wifi is still broken as you describe it (+ has no warning note on its Wiki page).

Not sure, if you would want to fill the gap as dev or consider getting a different device or wave goodbye to 5GHz as the state of that device plus the very low forum activity does not look promising to lead to a happy end any time soon.

22.03.5 has been released.

2 Likes