Wifi packet loss when connected to a specific router

aqeeliz · 2020-10-02 20:26:22

Hi,

I have kind of a weird problem with my wifi. It works fine with all connections, except for my home router. (All other machines - another laptop, mobile phones, anything else - work fine with the said router.)

I can connect to it, but soon start getting huge packet loss (more than 90%, reaching almost 100% in some cases), so that internet is not usable at all.

I just tried using bonjour with another laptop on same network, and that works fine. All messages were being sent / received fine while there was 100% packet loss with router. Also tried ping between two laptops, and there is 0% packet loss, so the issues seems to be just between the router and this laptop.

I am using NetworkManager, but can't see anything in it's logs, or dmesg -w, when packet loss starts or stops.

From lspci -v

5c:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)
        DeviceName: WLAN
        Subsystem: Intel Corporation Centrino Advanced-N 6235 AGN
        Flags: bus master, fast devsel, latency 0, IRQ 36
        Memory at d0200000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [c8] Power Management version 3
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [e0] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Device Serial Number <snipped>
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi

These are the services that I have currently enabled.

$ systemctl list-unit-files --state enabled
UNIT FILE                          STATE   VENDOR PRESET
avahi-daemon.service               enabled disabled     
bluetooth.service                  enabled disabled     
getty@.service                     enabled enabled      
httpd.service                      enabled disabled     
mariadb.service                    enabled disabled     
NetworkManager-dispatcher.service  enabled disabled     
NetworkManager-wait-online.service enabled disabled     
NetworkManager.service             enabled disabled     
postgresql.service                 enabled disabled     
sddm.service                       enabled disabled     
systemd-timesyncd.service          enabled enabled      
avahi-daemon.socket                enabled disabled     
remote-fs.target                   enabled enabled      

13 unit files listed.

Any suggestions?

Zod · 2020-10-02 20:52:55

Reboot the router and try again.

aqeeliz · 2020-10-02 21:17:48

Zod wrote:

Reboot the router and try again.

Problem didn't arise just today, it has been around for quite a while. Still, just to be safe, I did try rebooting the router, but no luck. Ping showed 25 successful packets, and then nothing.

I have also tried disabling 802.11n, it seems to have improved the situation a bit (less ratio of packet loss), but that can just be placebo or something random, not sure.

Zod · 2020-10-02 21:29:57

If I were to assume that there other devices on the network that have no problem with this router.

On the device that is having a problem...

$ ip link

$ ping -s 1500 -M do <default route ip>

$ ping -s 1500 -M do archlinux.org

Last edited by Zod (2020-10-02 22:42:36)

aqeeliz · 2020-10-03 07:32:47

Forgot to mention that I disabled 802.11n in router settings, not in laptop / local wifi settings.

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
    link/ether d0:bf:9c:57:dc:7b brd ff:ff:ff:ff:ff:ff
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 80:00:0b:59:28:1f brd ff:ff:ff:ff:ff:ff
    altname wlp92s0

$ ping -s 1500 -M do 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
...

Most of the time it was giving temporary failure in name resolution, but eventually got:

$ ping -s 1500 -M do archlinux.org
PING archlinux.org (138.201.81.199) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
...

Also tried:

$ ping -s 1450 -M do 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 1450(1478) bytes of data.
1458 bytes from 192.168.10.1: icmp_seq=93 ttl=64 time=1.63 ms
1458 bytes from 192.168.10.1: icmp_seq=94 ttl=64 time=1.94 ms
1458 bytes from 192.168.10.1: icmp_seq=95 ttl=64 time=1.72 ms
1458 bytes from 192.168.10.1: icmp_seq=96 ttl=64 time=3.35 ms
1458 bytes from 192.168.10.1: icmp_seq=97 ttl=64 time=2.43 ms
1458 bytes from 192.168.10.1: icmp_seq=98 ttl=64 time=2.12 ms
...
^C
--- 192.168.10.1 ping statistics ---
153 packets transmitted, 29 received, 81.0458% packet loss, time 153676ms
rtt min/avg/max/mdev = 1.505/2.159/3.657/0.541 ms

and for achlinux:

$ ping -s 1450 -M do archlinux.org
PING archlinux.org (138.201.81.199) 1450(1478) bytes of data.
From _gateway (192.168.10.1) icmp_seq=1 Frag needed and DF set (mtu = 1400)
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
...

$ ping -s 1400 -M do archlinux.org
PING archlinux.org (138.201.81.199) 1400(1428) bytes of data.
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
ping: local error: message too long, mtu=1400
...

$ ping -s 1300 -M do archlinux.org
PING archlinux.org (138.201.81.199) 1300(1328) bytes of data.
1308 bytes from archlinux.org (138.201.81.199): icmp_seq=1 ttl=56 time=160 ms
1308 bytes from archlinux.org (138.201.81.199): icmp_seq=2 ttl=56 time=159 ms
1308 bytes from archlinux.org (138.201.81.199): icmp_seq=3 ttl=56 time=158 ms
1308 bytes from archlinux.org (138.201.81.199): icmp_seq=4 ttl=56 time=158 ms
1308 bytes from archlinux.org (138.201.81.199): icmp_seq=5 ttl=56 time=159 ms
1308 bytes from archlinux.org (138.201.81.199): icmp_seq=6 ttl=56 time=159 ms
^C
--- archlinux.org ping statistics ---
10 packets transmitted, 6 received, 40% packet loss, time 9041ms
rtt min/avg/max/mdev = 158.300/158.724/160.004/0.586 ms

Zod · 2020-10-03 12:26:55

As a test you could do..

# ip link set dev wlo1 mtu 1300

Setting this won't survive a reboot, and you can always set it back to 1500 the same way.

The wiki article for jumbo frames describes a way to set the mtu via a systemd service unit for a given interface. I'm playing around with it but not yet got it to work automajicly.

Edit: I guess the real question is why is 1300, I tested mine and its at 1420 and I have my mtu for wlan0 set to 1450.
The reason we are doing this is to avoid packet fragmentation, ordinarily I would only recommend something like this if you were going over a vpn tunnel.

Last edited by Zod (2020-10-03 12:34:21)

aqeeliz · 2020-10-05 06:20:15

Zod wrote:

As a test you could do..
# ip link set dev wlo1 mtu 1300

Tried it, it didn't help either.

As you can see from ping response in previous message, even with 1300, there were packet drops, I cancelled after 10, so there were only 4 drops, but if I had continued, the drops would've probably continued for next 50-100 packets, and then few connected packets and so on.

seth · 2020-10-05 06:35:22

2.4GHz connection? Try to disable bluetooth.

aqeeliz · 2020-10-05 08:26:24

seth wrote:

2.4GHz connection? Try to disable bluetooth.

I tried disabling that, but not much difference.

Also, if BT was interfering, my connection with other computer should also effect, but there is no packet loss when this laptop connects with that, only when this connects with the router.

seth · 2020-10-05 12:49:03

Not if ad-hoc is on 5GHz or (necessarily) a vastly different channel.

Try passing "iwlwifi.disable_11ac iwlwifi.disable_11ax iwlwifi.11n_disable iwlwifi.swcrypto" to the kernel.

aqeeliz · 2020-10-08 16:56:36

seth wrote:

Not if ad-hoc is on 5GHz or (necessarily) a vastly different channel.
Try passing "iwlwifi.disable_11ac iwlwifi.disable_11ax iwlwifi.11n_disable iwlwifi.swcrypto" to the kernel.

These are passed during boot, at the end of 'linux' line, right? Because when I do that, iwlwifi module isn't loaded at all. What can I be doing wrong?

seth · 2020-10-08 19:36:00

https://wiki.archlinux.org/index.php/Ke … le_options

Are you sure the module isn't loaded at all? ("lsmod | grep iwlwifi")
Is there an error in the dmesg/journal (eg. because the iwlwifi module crashed or similar)

Maybe get us a station dump, https://wiki.archlinux.org/index.php/Ne … _interface

aqeeliz · 2020-10-09 04:41:22

seth wrote:

https://wiki.archlinux.org/index.php/Ke … le_options
Are you sure the module isn't loaded at all? ("lsmod | grep iwlwifi")
Is there an error in the dmesg/journal (eg. because the iwlwifi module crashed or similar)
Maybe get us a station dump, https://wiki.archlinux.org/index.php/Ne … _interface

As per dmesg value for iwlwifi.11n_disable and iwlwifi.swcrypto were wrong,

I changed it to

iwlwifi.disable_11ac iwlwifi.disable_11ax iwlwifi.11n_disable=1 iwlwifi.swcrypto=1

and iwlwifi is loaded now.

But still the same issue.

dmesg output, just in case:

$ dmesg | grep iwlwifi
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=491f0445-cbe6-4767-b587-e0d249f60a6b rw quiet nvidia-drm.modeset=1 iwlwifi.disable_11ac iwlwifi.disable_11ax iwlwifi.11n_disable=1 iwlwifi.swcrypto=1
[    0.043442] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=491f0445-cbe6-4767-b587-e0d249f60a6b rw quiet nvidia-drm.modeset=1 iwlwifi.disable_11ac iwlwifi.disable_11ax iwlwifi.11n_disable=1 iwlwifi.swcrypto=1
[   11.744957] iwlwifi 0000:5c:00.0: can't disable ASPM; OS doesn't have ASPM control
[   11.750663] iwlwifi 0000:5c:00.0: loaded firmware version 18.168.6.1 6000g2b-6.ucode op_mode iwldvm
[   11.750694] iwlwifi 0000:5c:00.0: Direct firmware load for iwl-debug-yoyo.bin failed with error -2
[   11.903401] iwlwifi 0000:5c:00.0: CONFIG_IWLWIFI_DEBUG enabled
[   11.903405] iwlwifi 0000:5c:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[   11.903406] iwlwifi 0000:5c:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[   11.903408] iwlwifi 0000:5c:00.0: Detected Intel(R) Centrino(R) Advanced-N 6235 AGN, REV=0xB0
[   11.941497] iwlwifi 0000:5c:00.0 wlo1: renamed from wlan0
[   12.974509] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   13.274373] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   13.383705] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   13.682387] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   20.130284] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   20.432921] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   20.546681] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   20.844896] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   27.156092] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0
[   27.454767] iwlwifi 0000:5c:00.0: Radio type=0x2-0x1-0x0

seth · 2020-10-09 05:54:41

pacman -Qi linux-firmware

aqeeliz · 2020-10-09 06:50:30

seth wrote:

pacman -Qi linux-firmware

$ pacman -Qi linux-firmware
Name            : linux-firmware
Version         : 20200916.00a84c5-1
Description     : Firmware files for Linux
Architecture    : any
URL             : https://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary
Licenses        : GPL2  GPL3  custom
Groups          : None
Provides        : None
Depends On      : None
Optional Deps   : None
Required By     : None
Optional For    : linux
Conflicts With  : None
Replaces        : None
Installed Size  : 567.76 MiB
Packager        : Laurent Carlier <lordheavym@gmail.com>
Build Date      : Tue 29 Sep 2020 12:45:56 PKT
Install Date    : Wed 07 Oct 2020 17:29:16 PKT
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

seth · 2020-10-09 06:54:52

Nope.
(Because of the only failing firmware message I thought it might be just that)

Take a station dump from a working and a non working connection - maybe we can spot a significant difference.

Arch Linux

#1 2020-10-02 20:26:22

Wifi packet loss when connected to a specific router

#2 2020-10-02 20:52:55

Re: Wifi packet loss when connected to a specific router

#3 2020-10-02 21:17:48

Re: Wifi packet loss when connected to a specific router

#4 2020-10-02 21:29:57

Re: Wifi packet loss when connected to a specific router

#5 2020-10-03 07:32:47

Re: Wifi packet loss when connected to a specific router

#6 2020-10-03 12:26:55

Re: Wifi packet loss when connected to a specific router

#7 2020-10-05 06:20:15

Re: Wifi packet loss when connected to a specific router

#8 2020-10-05 06:35:22

Re: Wifi packet loss when connected to a specific router

#9 2020-10-05 08:26:24

Re: Wifi packet loss when connected to a specific router

#10 2020-10-05 12:49:03

Re: Wifi packet loss when connected to a specific router

#11 2020-10-08 16:56:36

Re: Wifi packet loss when connected to a specific router

#12 2020-10-08 19:36:00

Re: Wifi packet loss when connected to a specific router

#13 2020-10-09 04:41:22

Re: Wifi packet loss when connected to a specific router

#14 2020-10-09 05:54:41

Re: Wifi packet loss when connected to a specific router

#15 2020-10-09 06:50:30

Re: Wifi packet loss when connected to a specific router

#16 2020-10-09 06:54:52

Re: Wifi packet loss when connected to a specific router

Board footer