DNS broken on certain Linux distros, with OpenWRT on RPi4

[ui424]

Describe the bug

Forum thread showing some others affected, also with Raspberry Pi 4.

Queries from Debian Linux (including fresh installs) that use its inbuilt glibc (ping, traceroute, wget etc) fail almost always (~2% success rate on ethernet i.e. stable low ping low jitter connection), when querying OpenWRT 24.10 via its IP address of 192.168.1.1. Dig and nslookup work because they do not use this method.

On Rocky Linux (RHEL-based) ping works but with a ~5 second delay every time. Modifying resolv.conf as below removes this delay.

Debian output: ~$ ping google.com ping: google.com: Temporary failure in name resolution

Adding either options single-request or options single-request-reopen to Debian's resolv.conf fixes the issue. Descriptions of these options are as follows:

single-request (since glibc 2.10) Sets RES_SNGLKUP in _res.options. By default, glibc performs IPv4 and IPv6 lookups in parallel since glibc 2.9. Some appliance DNS servers cannot handle these queries properly and make the requests time out. This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process).

single-request-reopen (since glibc 2.9) Sets RES_SNGLKUPREOP in _res.options. The resolver uses the same socket for the A and AAAA requests. Some hardware mistakenly sends back only one reply. When that happens the client system will sit and wait for the second reply. Turning this option on changes this behavior so that if two requests from the same port are not handled correctly it will close the socket and open a new one before sending the second request.

OpenWrt version

r28427-6df0e3d02a

OpenWrt release

24.10.0

OpenWrt target/subtarget

bcm27xx/bcm2711

Device

Raspberry Pi 4 Model B Rev 1.5

Image kind

Official downloaded image

Steps to reproduce

Use online firmware selector to build and download squashfs image with packages: base-files bcm27xx-gpu-fw bcm27xx-utils ca-bundle dnsmasq dropbear e2fsprogs firewall4 fstools kmod-fs-vfat kmod-nft-offload kmod-nls-cp437 kmod-nls-iso8859-1 kmod-sound-arm-bcm2835 kmod-sound-core kmod-usb-hid libc libgcc libustream-mbedtls logd mkf2fs mtd netifd nftables odhcp6c odhcpd-ipv6only opkg partx-utils ppp ppp-mod-pppoe procd-ujail uci uclient-fetch urandom-seed cypress-firmware-43455-sdio brcmfmac-nvram-43455-sdio kmod-brcmfmac wpad-basic-mbedtls kmod-usb-net-lan78xx kmod-r8169 iwinfo luci kmod-usb-net-rtl8152

Install Debian without GUI and without any NetworkManager or equivalent (i.e. the default).

Attempt to ping several domains (google.com, bing.com, etc) in succession from Debian SSH. Usually they fail.

Actual behaviour

~$ ping google.com
ping: google.com: Temporary failure in name resolution

Add options single-request-reopen to Debian /etc/resolv.conf

~$ ping google.com
PING google.com(ams16s30-in-x0e.1e100.net (2a00:1450:400e:805::200e)) 56 data bytes
64 bytes from ams16s30-in-x0e.1e100.net (2a00:1450:400e:805::200e): icmp_seq=1 ttl=58 time=11.3 ms
64 bytes from ams16s30-in-x0e.1e100.net (2a00:1450:400e:805::200e): icmp_seq=2 ttl=58 time=10.9 ms
64 bytes from ams16s30-in-x0e.1e100.net (2a00:1450:400e:805::200e): icmp_seq=3 ttl=58 time=11.0 ms

Expected behaviour

Ping, traceroute etc (anything using Linux glibc resolving) work correctly.

Additional info

No response

Diffconfig

Terms

• [x] I am reporting an issue for OpenWrt, not an unsupported fork.

[rucketeg]

Maybe https://github.com/openwrt/openwrt/issues/16261 is related? Can you try if running ethtool -K eth0 rx-gro-list off on the openwrt router fixes the issue?

[ui424]

Maybe #16261 is related? Can you try if running ethtool -K eth0 rx-gro-list off on the openwrt router fixes the issue?

It does. Thank you again.

[schuettecarsten]

You can also try to set "gro" option for your eth0 device: https://github.com/openwrt/netifd/pull/14

[leleargo]

I'm experiencing the same problem on openwrt snapshot x86/64 and I temporarily solved it with ethtool -K eth0 rx-gro-list off

[vgdh]

I use openwrt x64 in peoxmox VM and I have this issue when the client is LXC debian. on alpine it work flawlessly.