I've been using OpenWRT 18.06 on a ACS1900WRT v2 router for a couple of weeks and it seems to work well but today I ran across a very odd problem.
If I initiate an automated backup (using rclone) from one wireless peer to another, the upload speed of the computer doing the backup gets capped at 3Mbps (down from 70Mbps) after a few minutes. When this happens, other peers work just fine.
Clues:
The NIC is called "D-Link DWA-192 AC1900 Wi-Fi USB 3.0 Adapter".
If I disconnect and reconnect the peer, the problem goes away.
I don't recall having this problem prior to migrating from dd-wrt to OpenWRT and I have never configured any QoS related stuff on OpenWRT. Are there any sort of defaults out of the box?
It sounds like WMM and maybe your program is tagging packets with CS1 DSCP or similar and the driver for your wifi NIC is deciding to send at very low rate. This probably has nothing to do with the router and everything to do with your computer and NIC driver.
It sounds like WMM and maybe your program is tagging packets with CS1 DSCP or similar and the driver for your wifi NIC is deciding to send at very low rate. This probably has nothing to do with the router and everything to do with your computer and NIC driver.
I toggled every single "Advanced" option in the NIC driver and it had no effect. One of the options was supposed to disabled QoS support and even that didn't help in the end.
Is there any way to verify your theory using logs or anything else of the sort?
Also, my internet connection is a DSL connection so I'm using 1492 MTU. Do I need to force the same MTU value across all interfaces? Or does this only apply on the pppoe interface?
It could be helpful to packet capture with wireshark and see what the packets look like, if they have a DSCP value on them. The MTU issue could also be part of it if you were backing up to a cloud or something, but you're just going peer to peer inside your LAN so I don't think that's it.
It could be helpful to packet capture with wireshark and see what the packets look like, if they have a DSCP value on them. The MTU issue could also be part of it if you were backing up to a cloud or something, but you're just going peer to peer inside your LAN so I don't think that's it.
I'm seeing DSCP values of "default" when the network is fine. Do we expect this value to change when the network goes bad?
I have a WDS setup with 2 routers, so another test I'm going to try is connecting the sending computer to the 2nd router. This should rule out the computer's wireless connection and should more definitively prove whether the router is at fault.
This is not what WMM is supposed to do, truely the AC_BK class simply has a lower probability to get airtime, so without competing traffic AC_BK should still saturate an otherwise idle link. But I note that there is a difference between "should" and actually does
Yes there was a case 5 years back or so where Comcast was sending all it's regular traffic with some odd dscp value and it was ruining people's bandwidth. It should have just worked but been bumped when more high priority traffic came through, but that's not what people were experiencing. Still it doesn't sound like the case here, since the observed dscp value is default not some low priority value like CS1
Ah comcast,,, they also did at one point in time mark "normal" traffic CS1 which would lead to thusly marked downloads to be very susceptible to any local wifi traffic in higher-priority ACs. And since normal traffic locally should be dscp marked CS0 (or rather unmarked ;)) any not specifically CS1's traffic will get priority (since WIFI is non-duplex RX or TX should not matter). So comcast has a "tradition" to employ dscp-markings that do not make sense outside their dscp-domain...
Further updates on this... when the network is in a bad state, I am seeing 3-6% packet loss when pinging the router. So the problem is definitely independent of the internet connection.
This could just as well be a software/driver bug as anything else. I just wish I had a consistent way to reproduce it.