Interesting. My R7800 will slow to a crawl, with ping spike of up to 4000ms, when my notebook tries to ping the router when connected to it wirelessly. It doesn't happen immediately tho. and it's intermittent. Anyway good to know that it doesn't affect you. I'll continue to monitor and try to identify the issue.
1 Like
What do you get with iperf3 -c <iperf3server> -P 8 when wifi is slow? Add -R for reverse in a second test.
Didn’t try it tho. I even had problem loading the Luci login page. I would think iPerf will fail with timeouts.
I don't think the iptables rule installed by qca-nss-ecm is actually needed, but it possibly depends on your setup. The qca-nss-ecm init script enables netfilter on the bridge, which I believe is so nss can see and accelerate the traffic, so the rule should allow traffic on the bridge, which may otherwise be blocked by enabling nf on the bridge
However, the qca-nss-ecm firewall script seems to be broken as it's appending the rule to the end of the chain, after the reject rule, so it'll never match. In my case, this doesn't cause a problem as I have two other rules that allow lan to lan and wan to lan traffic so nothing is dropped.
If you don't have these rules then this could be why your port forwards aren't working, in which case, fixing qca-nss-ecm to inset rather than append the rules might fix the issue on fw3. I'm going to try and update with the latest fw4 changes later, so I'll see if I can figure out the nft syntax, iptables-translate seems to do a passable job here, worst case iptables-nft can probably be used...
I've included the relevant sections of my firewall config before, they should be default aside from the port forward
Summary
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option tcp_ecn '1'
option drop_invalid '1'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option log '0'
config forwarding
option src 'lan'
option dest 'wan'
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option dest_ip '192.168.1.2'
option dest_port '22'
option name 'mjn-SSH'
option src_dport '25051'
1 Like
So... I have a whole thread about my observations. You don't need to read it as it's blog like and I take tangents on unsuccessful attempts at figuring out what's wrong.
The short of it is, if I netperf using two wifi clients throught the AP (only), the netperf of one device almost always seems to slow to a crawl if not come to a complete stop. I don't need to wait anytime after boot to demonstrate this. This observation predates some of the Airtime Fairness (ATF) patches you mention; however, I do suspect it's related to ATF (early examples here).
It's very frustrating. I discovered one bug specific to my device (r7500v2) which didn't show ATF indication from iw list. This prevented me from changing ATF weights. I recently worked around that; however, nothing i try seems to show ATF working like it's claimed to work (example here). In fact, it seems like it isn't working at all or doing the exact opposite of what it claims. I can change the weights of one client to 1 and the other to 1000 and their is no change either clients netperf behaviour. I've played with settings in hostapd - this seems to have no effect.
I hope you find something - it's been difficult for me to test as this AP is in use sometimes 20 hrs per day.
Out of curiosity, did you assign a qdisc to the wlan interface you are testing? I like to assign fq_codel to the Wi-Fi interface as it should (hopefully) distribute outgoing traffic in a 'fairer' fashion, on top of the Wi-Fi interface's air-time fairness algo. If you did not, maybe it's good to test it?
i tried and i cant.
r7500v2 # tc -d -s qdisc show dev wlan0
qdisc noqueue 0: root refcnt 2
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
r7500v2 # tc qdisc add dev wlan0 root fqcodel
Error: Specified qdisc not found.
bah, this is embarrassing - i got it now fq_codel not fqcodel. Silly.
r7500v2 # tc qdisc add dev wlan0 root fq_codel
r7500v2 # tc -d -s qdisc show dev wlan0
qdisc fq_codel 8001: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 33786 bytes 94 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
new_flows_len 0 old_flows_len 0
EDIT: we might need to move this discussion to my thread as it's not specific to this topic.
Use this:
tc qdisc add dev wlan0 handle 8000: root fq_codel interval 100ms target 5ms flows 1024 quantum 1514 limit 10240
Replace wlan0 with your Wi-Fi interfaces.
1 Like
Alright, I'm testing now but the AP is in use so i have to be careful. I'll report back later today.
1 Like
The multiple rules are because qca-nss-ecm doesn't actually check if the rule exists before adding it, so if the firewall is reloaded for some reason, a new rule gets added.
I can see you've a default drop on the forward chain, so your settings are obviously different from mine. I had two rules allowing wan to lan and lan to lan forwarding and then a reject rule, so the physdev rule was appended after all those in my case, and never matched. It looks like it's the only rule in your case, so it's working as intended
If this is the case then I suspect that you may need to add some rules to allow the forwarded traffic. I've had to do this when adding rules manually, but fw3 has otherwise taken care of things for me, so I'm not too sure why it's not working in your case...
It's probably worth noting that physdev doesn't exist in nft, so there is no direct translation for the existing rule...
I might add that the forwarding works the way i want with fw3 and setting br-lan to promisc mode.
fw4 had some bugs which's fixed in master 2 hours ago... so it quite possible it works now too. I'm gonna wait with fw4 until the bugs are ironed out.
I also compared your config to mine and I see no difference, there's a reject further down on the forward chain.
This is after a reboot (yes the router rebooted again just now)
[ 51.938264] device eth1.1 entered promiscuous mode
[ 51.942927] device eth1 entered promiscuous mode
[ 60.818382] device wlan1 entered promiscuous mode
[ 67.664696] device wlan0 entered promiscuous mode
So yes, they do enter promisc mode by default... br-lan does not tho' unless you do it manually.
wan interface does it too? then why not br-lan? I do not get it
I really don't know why that mode is used. sorry
I don't know, maybe because br-lan is a bridge.
Btw, I'm trying without them now, everything seems to work fine so I wonder what use they actually do.
EDIT:
There's a script /etc/sysctl.d/qca-nss-ecm.conf that sets net.bridge.bridge-nf-call-iptables=1, if you set it to 0 instead promisc mode on br-lan isn't needed. I just tried it....
/etc/init.d/qca-nss-ecm also sets the above values so it's a tricky one to get pass...
net.bridge.bridge-nf-call-iptables apparently defaults to 0 in OpenWrt so why ecm sets it to 1 I have no idea... will keep on testing some more.
Also the /etc/init.d/qca* scripts looks a bit weird, especially /etc/init.d/qca-nss-drv
EDIT2:
The router sure doesn't like having net.bridge.bridge-nf-call-iptables set to 0, reboots after a while.
1 Like
I was reading and I saw the open sky hahaha. until I restart
I think a physdev rule is required for internal machines to hit external forward rules... I'm not sure exactly how to write it tho'.
ie. You want to connect to a minecraft server at mc.mydomain.com, mc.mydomain.com is forwarded to an internal machine on your lan ... that won't work with the settings without setting promisc mode on br-lan.
So we need a rule for that so promisc mode isn't needed anymore.
@ACwifidude One thing still plaguing the MASTER build is nlbwmon "running out of memory". Any word on a fix?
Follow the advice nlbwmon gives you via logread, and it will be fixed.
1 Like
Perhaps I should have worded it differently. I personally am aware of the end-user fix... but for a built in package that he includes, I figured it may be worth bringing up that it's still an issue that requires immediate end-user resolution... and if there's any word on it getting an included fix.
1 Like