The OpenWrt community is proud to announce the fourth release candidate of the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year.
Changes between OpenWrt 21.02.0-rc3 and 21.02.0-rc4
Linux kernel: updated to version 5.4.137 (from 5.4.124 in v21.02.0-rc3)
mt76: Update to version 2021-06-06 (from 2021-05-15 in v21.02.0-rc3)
wireguard: Update with recent Linux stable fixes
exfat: Update to version 5.12.3 (from 5.10.1 in v21.02.0-rc3)
failsafe: Fixes failsafe network configuration with swconfig and DSA: FS#3866
odhcpd: fix invalid DHCPv6 ADVERTSIE with small configured leasetime
ugps: parse $GPZDA and $GPGLL sentences, improve interoperability with kplex
netifd: WDS with bridge-vlan fixed
New devices MikroTik RouterBOARD 912UAG-2HPnD and Joy-IT JT-OR750i
Device fixes for TP-Link CPE, MikroTik RouterBOARDs and AVM FRITZRepeater 1200
Some packets from IPv6 streams are getting dropped in software and hardware flow offloading FS#3373
Hi. I just upgraded my home network to RC4 from RC3. Something seems to be broken with wireless range extending and WDS with RC4. After the upgrade, the wireless range extender can't connect to the base station.
How is it determined which new devices get added to a new release candidate? I would have liked to have the additional devices that were added to the realtek target supported. These are inexpensive readily available devices (Netgear GS308T v1 and Netgear GS310TP v10).
Thanks to hauke and the rest of the OpenWrt developers.
D-Link DIR-878 Rev. A1
WLAN: MediaTek MT7615N
Same problem mentioned in RC3 tested/mentioned previously,
Within the first eight hours of testing, encountered an android smartphone on 5 GHz WiFi displaying: Connected, no internet.
Signal strength was excellent.
Connecting to 2.4 GHz WiFi then switching back to 5 GHz resolved issue.
Did not notice anything in the system log corresponding to error.
Disclaimer: I'm not an OpenWrt developer and can't speak for the project.
This is decided on a case by case basis, the patches need to be small and non-invasive enough (so far typically the case for new rtl838x devices) to be deemed safe - then you need to get the attention of a developer (by providing a tested pull request/ patch against openwrt-21.02 or ideally naming the commits that could be cherry-picked unchanged). In the end, it comes down to raising interest for adding these devices to a developer and convincing them that the changes are low-impact and safe to apply at this stage (not creating new problems that would need fixing).
I confirm that RC4 broke something on Archer C60 v2. After upgrading, the repeater was never able to connect to the router and clients became very slow to establish a connection.
Reverting to RC3 solved the problem.
Updated on my WRT32X, running great. 5GHz wifi stalled a couple times on my iPhone where I had to turn off/on the wifi in phone settings, hasn't done that at all on my ThinkPad. Weird.
Using a USB 3.0 exFAT formatted drive now, the new version in kernel 5.4 is quite fast. Getting 120 MB/s read/write (maxing gigabit LAN basically) and CPU impact isn't large. This is a very viable filesystem option now for external storage. This also puts storage faster than almost all new routers tested by recent Dongknows reviews.
Everything else working great, DSA, Samba4, Adblock, SQM cake (500Mbit cable maxed), Irqbalance, etc.
Below is a package list I'm running for anyone curious:
Our community mesh network has still some errors with ipq40xx devices and the switch. The switch just freezes/breaks, not sure what exactly is happening. WiFi is still working and ip is still showing all interfaces as active.
OLSR is announcing:
OLSR: sendto IPv4 'Resource temporarily unavailable' on interface eth0.22
So the tx direction seems broken:
When the message does not fit into the send buffer of the socket, send() normally blocks, unless the socket has been placed in non-blocking I/O mode. In non blocking mode it would return EAGAIN inthis case."EAGAIN is the error code tied to "Resource temporarily unavailable" https://linux.die.net/man/2/send
It is often appearing if links changes happen. Rebooting switches that are connected to the device or adding new links.
There is also some similar issue that has to do with segmentation. I hoped that already a DSA driver would replace the sw-driver. However, that will not happen. I already wrote with another openwrt dev. This issue is very hard to reproduce but it happened several times (Fritz!Box 4040, Fritz!Box 7530). Maybe someone else also experienced similar issues?