You are not logged in.
Hi Arch community
I've tried everything I can think of but I'm hoping the hive mind will help me find the solution!
Symptom:
My wifi is currently unusable because - while it still stays connected, the packet loss goes up to 100% every few seconds for a period of 5-10 seconds. It seems to only happen when opening a connection:
For example, I might type
ping 216.58.212.78and then I have to wait 5-10 seconds before the output begins appearing, after which it is very regular. Packet loss is shown at the bottom as (say) 67% after 10 pings.
This only happens when I connect to my router at home (a Virgin Media Super Hub 3.0) and not to the wireless hotspot on my phone. It also only seems to happen to my Arch laptop and not to any other devices in the house connected to that router.
Things I have tried:
Disabling power saving on the adapter
Disabling systemd-resolved
Switching from NetworkManager to wicd and back
Disabling IPv6 (my router and ISP don't support it)
Disabling DHCP and statically configuring my IP
Picking one of the two BSSIDs associated with my router in the NetworkManager settings
Resetting my router to factory settings
Booting from the lts kernel
Moving closer to the router
None of these have any effect on the issue. Everything was working fine until yesterday - I do install pacman updates every day so it could have been an update I got yesterday.
Some output from various commands that might help:
systemctl list-unit-files --state=enabled
UNIT FILE STATE
org.cups.cupsd.path enabled
autovt@.service enabled
dbus-org.freedesktop.NetworkManager.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
dbus-org.freedesktop.resolve1.service enabled
display-manager.service enabled
docker.service enabled
gdm.service enabled
getty@.service enabled
NetworkManager-dispatcher.service enabled
NetworkManager.service enabled
ntpd.service enabled
org.cups.cupsd.service enabled
systemd-resolved.service enabled
tlp-sleep.service enabled
tlp.service enabled
org.cups.cupsd.socket enabled
remote-fs.target enabled
fstrim.timer enabled
19 unit files listed.iw dev
phy#0
Unnamed/non-netdev interface
wdev 0x4
addr 9c:b6:d0:e6:9c:a9
type P2P-device
txpower 0.00 dBm
Interface wlp58s0
ifindex 2
wdev 0x1
addr 9c:b6:d0:e6:9c:a9
ssid Twin Peaks
type managed
channel 6 (2437 MHz), width: 20 MHz, center1: 2437 MHz
txpower 20.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcoltx-bytes tx-packets
0 0 0 0 0 0 0 00lspci -v (relevant section)
3a:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
Subsystem: Bigfoot Networks, Inc. QCA6174 802.11ac Wireless Network Adapter
Flags: bus master, fast devsel, latency 0, IRQ 135
Memory at dc000000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit-
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Virtual Channel
Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [178] Latency Tolerance Reporting
Capabilities: [180] L1 PM Substates
Kernel driver in use: ath10k_pci
Kernel modules: ath10k_pciI haven't seen anything consistently appearing in the output of journalctl and dmesg during the issues and everything I did see appears to be a red herring, but please let me know if there's anything in particular I should be looking for.
Thanks so much in advance for all your help!!
Last edited by pedantic_git (2019-03-29 16:04:09)
Offline
For reference - I found the solution.
It was because I had dozens of unused bridge networks configured, left over from various docker-compose environments. I think it was something like whenever the router was doing a multicast, my machine was freezing up as all the bridge networks scrambled to reply simultaneously, but that's just a speculation. Cleaning them up with
docker network purgefixed the problem completely for me.
Offline