Latency/Jitter Issues on Dynalink DL-WRX36 w/ 23.05.4

Installing and Using OpenWrt Network and Wireless Configuration
1

I've set up the DL-WRX36 with version 23.05.4 as an access point — no firewall, full port bridge. From a functionality standpoint, everything seems to be working well, but I'm encountering a performance issue.

The access point is about 12 feet away, placed on a shelf below my existing AC-based access point. When connecting from my AX-capable laptop (running Linux), I'm seeing inconsistent latency. Specifically, when running simple ICMP pings to the AP while I'm also connected to it, the response times fluctuate between roughly 3-15ms and 35-50ms with each ping.

2.4GHz:

64 bytes from x.x.x.x: icmp_seq=1 ttl=64 time=4.99 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=64 time=34.8 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=5.06 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=33.0 ms

5GHz

64 bytes from x.x.x.x: icmp_seq=3 ttl=64 time=19.1 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=64 time=52.0 ms
64 bytes from x.x.x.x: icmp_seq=5 ttl=64 time=2.11 ms
64 bytes from x.x.x.x: icmp_seq=6 ttl=64 time=47.2 ms
64 bytes from x.x.x.x: icmp_seq=7 ttl=64 time=14.5 ms
64 bytes from x.x.x.x: icmp_seq=8 ttl=64 time=43.9 ms

In contrast, when connecting to my AC-based access point (which I plan to replace) running stock TP-Link firmware, I'm consistently getting 1-3ms pings when pinging the Dynalink AP (on the same wired network).

This latency fluctuation occurs whether I'm pinging the Dynalink itself or another device on the wired network, suggesting it’s not related to ICMP response de-prioritization. The AP isn't under any load, as I'm only testing with a couple of clients. Pinging from a wired client to the AP yields a consistent sub-ms response, as expected.

Has anyone else experienced this, or have any suggestions? Given that the issue occurs on both 2.4GHz and 5GHz, interference seems unlikely, especially since the other AP doesn’t show similar behavior.

I’ve also tested both WPA3 and WPA2, but there’s no noticeable difference. Additionally, there’s no significant CPU activity on the AP, so it doesn't appear to be under strain. It does feel like something related to the radio configurations, but I don't know what. Maybe something related to the CPU? It is worth noting that this is setup using WDS, so I'm not sure if that has something to do with it. But so far, there are no other APs connected to it.

Any thoughts or help would be appreciated.

2

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
3

Here is the output (removing any private details). Note that one of the radios is currently disabled as I was forcing a client to move from one to the other for testing purposes. This isn't related to the issue.

root@wireless-ap-1:~# ubus call system board
{
	"kernel": "5.15.162",
	"hostname": "wireless-ap-1",
	"system": "ARMv8 Processor rev 4",
	"model": "Dynalink DL-WRX36",
	"board_name": "dynalink,dl-wrx36",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.4",
		"revision": "r24012-d8dd03c46f",
		"target": "ipq807x/generic",
		"description": "OpenWrt 23.05.4 r24012-d8dd03c46f"
	}
}
root@wireless-ap-1:~# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fd0b:711e:44e9::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'wan'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr 'x.x.x.x'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option gateway 'x.x.x.x'
	list dns 'x.x.x.x'

root@wireless-ap-1:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi'
	option channel '48'
	option band '5g'
	option htmode 'HE80'
	option txpower '28'
	option country 'US'
	option cell_density '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/soc/c000000.wifi+1'
	option channel '7'
	option band '2g'
	option htmode 'HE40'
	option txpower '26'
	option country 'US'
	option cell_density '0'
	option disabled '1'

config wifi-iface 'wifinet0'
	option device 'radio0'
	option mode 'ap'
	option ssid 'xxxxxxx'
	option encryption 'psk2'
	option wds '1'
	option key 'xxxxxxx'
	option network 'lan'

config wifi-iface 'wifinet1'
	option device 'radio1'
	option mode 'ap'
	option ssid 'xxxxxxx'
	option encryption 'psk2'
	option wds '1'
	option key 'xxxxxxx'
	option network 'lan'
	option disabled '1'

root@wireless-ap-1:~# cat /etc/config/dhcp

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

root@wireless-ap-1:~# cat /etc/config/firewall

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'
4

Make channel auto, both APs in Ch36 will battle for airtime.

5

This had a very negative effect on things. Even rebooted to allow it to come up clean. The client is constantly losing the connection to the AP now in auto mode, and the latency is far worse, lower txpower, intermittent non-responsive pings.

4 bytes from x.x.x.x: icmp_seq=12 ttl=64 time=9.37 ms
64 bytes from x.x.x.x: icmp_seq=13 ttl=64 time=26.6 ms
From x.x.x.x icmp_seq=14 Destination Host Unreachable
From x.x.x.x icmp_seq=15 Destination Host Unreachable
From x.x.x.x icmp_seq=16 Destination Host Unreachable
64 bytes from x.x.x.x: icmp_seq=22 ttl=64 time=26.4 ms
64 bytes from x.x.x.x: icmp_seq=23 ttl=64 time=41.3 ms
From x.x.x.x icmp_seq=24 Destination Host Unreachable
From x.x.x.x icmp_seq=25 Destination Host Unreachable
...
From x.x.x.x icmp_seq=35 Destination Host Unreachable
From x.x.x.x icmp_seq=36 Destination Host Unreachable
64 bytes from x.x.x.x: icmp_seq=37 ttl=64 time=1076 ms
64 bytes from x.x.x.x: icmp_seq=38 ttl=64 time=62.2 ms
64 bytes from x.x.x.x: icmp_seq=39 ttl=64 time=108 ms
64 bytes from x.x.x.x: icmp_seq=40 ttl=64 time=2056 ms

This doesn't feel like interference because the issue is happening on both 2.4 and 5GHz ranges. And I did a survey before assigning the frequencies and I'm not in an apartment complex, so not super dense here.

6

Do you have 2 dhcp servers in your network?

7

No, and this one is disabled and turned off. I've got a static MAC and get the same address no matter whether I connect to one AP or the other.

I tried setting the CPU governor to performance, didn't seem to change anything either. I was just curious if there was some sort of frequency hopping going on with the CPU that might be causing this, but it didn't change anything even when consistently running at max freq.

8

With posted firewall setup you should not be able to ping at all, and your dhcp server is enabled. So it is something else with conflicting ip responding=your pings.

9

The firewall is disabled and turned off. Per my initial post, it's essentially a dumb AP right now. The DHCP server is disabled and turned off too.

DNSmasq, firewall, and odhcpd are disabled from a service standpoint, and the firewall zones were all removed. I also removed the DHCP and DNS profiles under "DHCP and DNS".

.. also, the latency shows up whether I ping itself (connected to it wirelessly) or whether I ping something else on the wired network. In any case, if there were two authoritative DHCP servers, so long as I was getting a unique and unused address on the same network, it wouldn't matter. But that isn't really the case here. My firewall is the only thing responding with a DHCP response.

10

Here is output from a nmap of the Dynalink AP:

tarting Nmap 7.80 ( https://nmap.org ) at 2024-09-25 15:44 CDT
Nmap scan report for x.x.x.x
Host is up (0.0025s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

~$ sudo nmap -sU -p 67 x.x.x.x
Starting Nmap 7.80 ( https://nmap.org ) at 2024-09-25 15:45 CDT
Nmap scan report for x.x.x.x
Host is up (0.0020s latency).

PORT   STATE  SERVICE
67/udp closed dhcps
MAC Address: F4:52:46:xx:xx:xx (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds
11

If you sysupgrade you lose access to the system. Dump ap guide has precise instructions how to neutralize firewall and dnsmasq.

Change the radio to VHT80, maybe client is somewhat incompatible with wifi6? Also is it in US region, because if it is in etsi you get very little overlap.

12

Well, I haven't done any sysupgrade on the system yet. The only thing I did add was iperf3 to do some basic testing. I'm happy to reset it and follow different instructions. I suspect the firewall, dhcp, and dnsmasq is unrelated, but I can try it.

So, I've tried putting in VHT80 mode (AC) and in N mode fat channel. It improved things, but I'm still getting consistent spikes to 40-50ms every 10 seconds or so, both in 2.4GHz and 5GHz. I also tried connecting with a iPhone 12 both before making these changes and after. I was seeing the latency all over the place pinging my gateway when connected to the AP in AX mode, but then also experiencing a fair amount of latency after the changes to. It feels like it made it better, but I don't think this is a client issue given two different clients using totally different OS, drivers and chipsets are having issues with this. Clearly it is worse in AX mode though.

13

Firewall and dhcp are not involved in 2s delay.
You have to disable dhcp server on lan, and allow in/out in lan zone, optionally drop l3 forward, bridge traffic passes at l2 undisturbed by fw4.
Your settings are very simple and as such correct and interoperable.

First test ping with default double nat, then add your config few undoable steps at a time.
2s ping is unbelievably bad, 30x around globe or 10x to geostationary satellite...

14

Thanks for your thoughts on the issue. I believe I may have found and resolved the problem. While I still can't explain the issue with my iPhone 12 (which seems to have been a red herring), the real cause appeared to be a Linux kernel driver issue with my Intel AX201. I was running kernel 5.15 and upgraded to 6.8, which seems to have fixed the connection issue in AX modes. The upgrade clearly brought in a new driver.

I had booted into Windows 11 on the same laptop, and everything was working fine there, which led me to suspect the kernel drivers for the wireless adapter were the culprit. So, your suggestion about a compatibility issue was spot on—it was likely a bad kernel driver. I'll mark this as solved.

Worth noting for everyone this was Linux Mint 21.3 running the latest default kernel patch. So despite it being a relatively modern OS, the kernel driver for the AX adapter was clearly buggy.

I did also walk through the OpenWRT guide for making it into a dumb AP. I think those were basically the steps I took before, but in any case I had gone through a reset and went through everything clean.

1 Like
15

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.