Posted: Fri Nov 29, 2019 9:06 Post subject: Packet drop on br0 interface rx
device : WR941ND v6
configure AP (bridging LAN to WLAN) no firewall, VPN , QoS
Build : 40750 / 40863 (same issue on other tested 41xxx builds)
I have constantly dropped packages on the bridge interface RX queue up to 10%. I have checked on other AP on the same network (with other non dd-wrt/openwrt firmware) that show 0 dropped packages on the bridge interface. Is it possible to get some more detailed info from dd-wrt on this interface with the available shell commands ?
Possible reason I want to exclude:
1. packet buffer is to small, packets are dropped and not buffered.
2. wrong packet size (MTU) or other packet problem on the WLAN (VLAN...)
The (W)LAN and WAN interfaces have 0 dropped packets and the issue is only on the RX br0, on my knowledge it is WLAN to LAN destination bridging.
Openwrt also has this problem with some builds. The first packet seems always to drop but for me its not only bridge related. even vanilla so without cfe sfe qos or anything enabled. Tried to find out what gives the problem by compiling myself its a hit and miss. I guess its a kernel related issue or some kind of patch that introduced this.
Openwrt also has this problem with some builds. The first packet seems always to drop but for me its not only bridge related. even vanilla so without cfe sfe qos or anything enabled. Tried to find out what gives the problem by compiling myself its a hit and miss. I guess its a kernel related issue or some kind of patch that introduced this.
If this issue exists in openwrt AND dd-wrt then it is not (WLAN) chipset driver related, as they use different drivers to my knowledge. Then it could be a bridge interface issue. If this is true, any LAN to LAN transfer would not trigger frame dropping (assuming CPU load is ok, SFE support is ok). The interfaces should drop packets if the involved buffer runs full or the packet does not fit into the buffer for some reason (assuming any filtering / firewalling is inactive)
I'm curious how many have the same.
Just ping to a domain or ip and see if you lose 1 packet, Its always 1 doesnt matter if i do ping -w 6 or ping -w 100 i only lose 1 so i guess its the first packet.
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Sat Nov 30, 2019 18:24 Post subject:
I don't know what the difference is. If I just ping 8.8.8.8 normally without -w 6, it just pings until I hit CTRL-C with no packet loss on my E4200v1. Are you sure it's DD-WRT and not your ISP? _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
I don't know what the difference is. If I just ping 8.8.8.8 normally without -w 6, it just pings until I hit CTRL-C with no packet loss on my E4200v1. Are you sure it's DD-WRT and not your ISP?
Im very sure because when i flash another firmware that doesnt have the problem its gone -w 6 means ping 6 times you can put any number. But i dont understand why it sends 1 extra packet if it loses it. Anyway.. i dont think it gives me connection issues so i'm fine with it. _________________ Linksys EA8500
Im very sure because when i flash another firmware that doesnt have the problem its gone -w 6 means ping 6 times you can put any number. But i dont understand why it sends 1 extra packet if it loses it. Anyway.. i dont think it gives me connection issues so i'm fine with it.
I think, your problem is a little bit different. I have 0% ping loss. I don't have connection issues, so it is not critical on the devices connected.
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Sat Nov 30, 2019 21:20 Post subject:
Looks like it is a bug introduced in 2.6.38 Linux kernel. Not seeing it on FreshTomato ARM (2.6.36) on R7000. What kernel version does your device run (uname -a)? FWIW, I think I had 10 dropped on RX on br0 on my E4200v1, BUT, all of my settings are tweaked and not default. That is something to look at.... _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
I know for me, I use ebtables on the E4200 to block wireless access to router management since I didn't want to muck around with figuring out working iptables rules and because I wanted to specifically block wireless access, not wired, since I have no other APs on the LAN side and I don't have remote management enabled. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Sun Dec 01, 2019 18:33 Post subject:
So, it's "normal". I was trying to backtrack to see if there were any patches to the kernel anywhere upstream for the issue and came up short. I don't know if setting the txqueuelen to a higher value will do you any good or not. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
So, it's "normal". I was trying to backtrack to see if there were any patches to the kernel anywhere upstream for the issue and came up short. I don't know if setting the txqueuelen to a higher value will do you any good or not.
The br0 interface shows 0 errors on the RX queue. I do not see any possibility with the "on board" tools to break it down to a specific port, protocol, frame type or whatever causes frame drops on the RX of br0. It must be a special frame that is dropped, because ping and download does not increase the drop counter, but periodically transmitted packets get dropped. All the mobile clients are conneceted to this router, that makes it nearly impossible to catch the source / service loosing packages.
root@DD-WRT:~# ping -w 6 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=58 time=11.358 ms
64 bytes from 8.8.8.8: seq=1 ttl=58 time=11.528 ms
64 bytes from 8.8.8.8: seq=2 ttl=58 time=11.407 ms
64 bytes from 8.8.8.8: seq=3 ttl=58 time=11.472 ms
64 bytes from 8.8.8.8: seq=4 ttl=58 time=11.499 ms
64 bytes from 8.8.8.8: seq=5 ttl=58 time=11.529 ms
--- 8.8.8.8 ping statistics ---
7 packets transmitted, 6 packets received, 14% packet loss
round-trip min/avg/max = 11.358/11.465/11.529 ms
Code:
root@DD-WRT:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=58 time=11.350 ms
64 bytes from 8.8.8.8: seq=1 ttl=58 time=11.939 ms
64 bytes from 8.8.8.8: seq=2 ttl=58 time=11.468 ms
64 bytes from 8.8.8.8: seq=3 ttl=58 time=11.531 ms
64 bytes from 8.8.8.8: seq=4 ttl=58 time=11.426 ms
64 bytes from 8.8.8.8: seq=5 ttl=58 time=11.721 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 11.350/11.572/11.939 ms
WLAN client to WAN
Code:
ping -w 6 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=14.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=15.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=12.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=14.3 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=14.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=14.3 ms
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 12.140/14.212/15.188/0.972 ms
WLAN client to LAN client
Code:
ping -w 6 192.168.1.108
PING 192.168.1.108 (192.168.1.108) 56(84) bytes of data.
64 bytes from 192.168.1.108: icmp_seq=1 ttl=64 time=24.1 ms
64 bytes from 192.168.1.108: icmp_seq=2 ttl=64 time=1.23 ms
64 bytes from 192.168.1.108: icmp_seq=3 ttl=64 time=3.49 ms
64 bytes from 192.168.1.108: icmp_seq=4 ttl=64 time=3.63 ms
64 bytes from 192.168.1.108: icmp_seq=5 ttl=64 time=4.02 ms
64 bytes from 192.168.1.108: icmp_seq=6 ttl=64 time=3.55 ms
--- 192.168.1.108 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 1.235/6.676/24.117/7.852 ms
WLAN client to WLAN client
Code:
ping -w 6 192.168.1.110
PING 192.168.1.110 (192.168.1.110) 56(84) bytes of data.
64 bytes from 192.168.1.110: icmp_seq=1 ttl=64 time=5.37 ms
64 bytes from 192.168.1.110: icmp_seq=2 ttl=64 time=48.9 ms
64 bytes from 192.168.1.110: icmp_seq=3 ttl=64 time=46.4 ms
64 bytes from 192.168.1.110: icmp_seq=4 ttl=64 time=54.2 ms
64 bytes from 192.168.1.110: icmp_seq=5 ttl=64 time=52.3 ms
64 bytes from 192.168.1.110: icmp_seq=6 ttl=64 time=54.5 ms
--- 192.168.1.110 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 5.373/43.644/54.534/17.357 ms
LAN client to WAN
Code:
ping -w 6 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=11.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=12.0 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=11.9 ms
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 11.705/11.906/12.024/0.097 ms
64 bytes from 192.168.1.110: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 192.168.1.110: icmp_seq=2 ttl=64 time=21.2 ms
64 bytes from 192.168.1.110: icmp_seq=3 ttl=64 time=23.4 ms
64 bytes from 192.168.1.110: icmp_seq=4 ttl=64 time=25.5 ms
64 bytes from 192.168.1.110: icmp_seq=5 ttl=64 time=27.4 ms
64 bytes from 192.168.1.110: icmp_seq=6 ttl=64 time=29.3 ms
--- 192.168.1.110 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 2.217/21.548/29.397/9.032 ms
LAN client to LAN client
Code:
ping -w 6 192.168.1.108
PING 192.168.1.108 (192.168.1.108) 56(84) bytes of data.
64 bytes from 192.168.1.108: icmp_seq=1 ttl=64 time=0.222 ms
64 bytes from 192.168.1.108: icmp_seq=2 ttl=64 time=0.234 ms
64 bytes from 192.168.1.108: icmp_seq=3 ttl=64 time=0.233 ms
64 bytes from 192.168.1.108: icmp_seq=4 ttl=64 time=0.232 ms
64 bytes from 192.168.1.108: icmp_seq=5 ttl=64 time=0.233 ms
64 bytes from 192.168.1.108: icmp_seq=6 ttl=64 time=0.236 ms
--- 192.168.1.108 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5127ms
rtt min/avg/max/mdev = 0.222/0.231/0.236/0.018 ms
