Negative real time speed rate not yet fixed
Yes, unfortunately, the wire speed on my FritzBox 4040 with OpenWrt 21.02 dropped to about 650 Mbps, and with versions 19.07 it was over 900 Mbps.
3 Likes
Excuse the offtopic but that rate menu does not appear either on my x86 or on a wdr3500.
Is there a specific package for this functionality?
Been using bwmon for time being, but that screenshot looks more promising.
On topic, been using the 21.02 snapshots for a bit, haven't encountered any irregularities so far with my config.
Great work as always.
In RC1. If I change the timezone in Luci, then Luci deletes NTP server and client settings from system config file. But the checkbox in luci are afterward still set as usual with client=on and server=off. But the system config file only has the ntp servers left?
Are you sure the ânegative download rateâ isnât actually upload speed without definition as it say so in the headline?
I believe this is normal behavior. Luci is programmed to remove some config options when they are set to the default value. It is simply that the default system config file has extra lines that are not necessary.
However in the future....I would like to see the config files and LuCI be better in sync, so that LuCI is not removing things every time you save config....
Comments come to mind. I stopped using the GUI years ago as I like to have multiple possible configurations by commenting out the stanzas for configurations not currently in use.
2 Likes
Hi
Anyone knows progress on DSA for IPQ40xx boards, or where I can track progress?
This is killer feature for me, as I need working VLAN on WAN to actually get internet (No sucess on getting this to work on current OpenWRT builds, I'm kinda newbie, still a lot to learn).
This depends if the package was updated after branch-off, which is the case of znc package.
You can update the package yourself, compile it, then it test it, and send pull request. And in the end, you can even become a package maintainer. 
Contributions are highly appreciated.
But this time, I chery-picked update from master branch and in the next RC it will be updated.
I don't have access to the main repository. You need to ask someone else, but I think the faster approach are:
- You can send a pull request to OpenWrt repository via GitHub.
- You can send the patch to the openwrt-devel mailing list.
Oh, it's already in master, I'm just trying to get someone to add it to the 21.02 branch 
Have someone else experienced a lot more WAN LED activity (compared to 19.07.7) when installing 21.02-RC1.
I have split the WAN LED so I have one LED for Tx and one LED for Rx and it is only the Rx that flashes a lot more. Tx doesnât flash at all if no actual traffic are sent by any device.
It feels based on the frequency like the new kernel flashes the Rx LED for every port scan that comes in because during the experimenting phase I had the router connected to a LAN port on my operational router and then the WAN light on the test router (21.02-RC1) never flashed without any actual data troughput . So it only does that when connected to the real internet.
i can definately say that on my clients facebook videos sometimes start stopping. never happened on v19. linksys wrt3200acm
this happened wifi and wired as well.
Ok, but what package add on is that measurement function to begin with because that isnât something that the OpenWRT has installed as standard?
I have a TP Link wr841n-v13 router that I have upgraded to the RC, and I notice that there are repeatedly long periods of command line non-responsiveness when I connect in via ssh. It will come back after 10-20s and be fine.
It is not a general network issue, as my ssh connections to other routers on the network are not impacted.
Not sure how to debug it.
It is coming from luci-app-nft-qos
WRT3200ACM here with intermittent connectivity issues with 21.02.0 RC1 also. My network also goes out every few minutes or so and comes back. This is happening on wired too.
There is a recent commit revert being discussed on mailing list ( [PATCH] mvebu: 5.10: fix DVFS caused random boot crashes (openwrt.org)) that has to do with CPU frequency causing issues with MVEBU. Does anyone know if this is what would also be responsible for causing these intermittent network issues on 21.02.0 for MVEBU devices?
Unfortunately this has not been usable for me and I had no choice but to go back to most recent Davidc502 build (pre-DSA) and zero issues there.
1 Like
Different Marvell CPU (37xx), I have seen no issues with a rango on a master image.