Just because I ran out of things to try I'll update the BIOS, although I'm currently at 1.44 and the latest available version is 1.45 which does not include any related bugfix.
]]>I was using wireguard, and a systemctl restart of the wireguard connection would sometimes bring things back to normal. But not always. Turning on and off wifi would sometimes help.
In the end, I could never figure out what was wrong.
Just to try something, I switched to iwd. Ever since then I haven't had these routing/DNS/whatever-it-was problems with my wifi.
So if nothing else works for you, maybe give iwd a try?
]]>I'll wait a couple of days just in case before marking this as solved.
]]>Can you stop docker for an extended amount of time? (To rule out interference from there)
Also try to disable https://wiki.archlinux.org/index.php/Ne … domization (the LAN ./. WAN condition suggests you're doing sth. that your router doesn't like, but you still have a lease)
What's the exact behavior/error for
Notebook pings 8.8.8.8: Nope
Timeout or no route?
I'm pretty sure it's timeout / 100% packet loss. I have to wait for it to happen again to check.
MTU issue? Output of "ip l"?
$ ip l
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: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether 54:e1:ad:fa:e2:21 brd ff:ff:ff:ff:ff:ff
3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 60:f6:77:32:13:24 brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:dc:c8:59:1b brd ff:ff:ff:ff:ff:ff
5: br-632d604924e1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:ed:67:3e:b0 brd ff:ff:ff:ff:ff:ff
7: enp0s20f0u2u4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether f0:1e:34:13:db:99 brd ff:ff:ff:ff:ff:ff
Also:
systemctl list-unit-files --state=enabled
$ systemctl list-unit-files --state=enabled
UNIT FILE STATE VENDOR PRESET
autovt@.service enabled disabled
bluetooth.service enabled disabled
dbus-org.bluez.service enabled disabled
dbus-org.freedesktop.NetworkManager.service enabled disabled
dbus-org.freedesktop.nm-dispatcher.service enabled disabled
dbus-org.freedesktop.timesync1.service enabled disabled
display-manager.service enabled disabled
docker.service enabled disabled
gdm.service enabled disabled
getty@.service enabled enabled
NetworkManager-dispatcher.service enabled disabled
NetworkManager.service enabled disabled
systemd-timesyncd.service enabled enabled
remote-fs.target enabled enabled
paccache.timer enabled disabled
15 unit files listed.
Notebook pings 8.8.8.8: Nope
Timeout or no route?
MTU issue? Output of "ip l"?
Also:
systemctl list-unit-files --state=enabled
options iwlwifi bt_coex_active=0 swcrypto=1 11n_disable=8
and the problem persists.
I also did some experiments running ping between different devices in my home network during one of these incidents, because at this point I don't know if the cause is something in my laptop or the router:
Notebook pings router: OK
Notebook pings 8.8.8.8: Nope
Notebook pings Raspberry Pi inside home network: OK
Raspberry Pi pings notebook: OK
Raspberry Pi pings 8.8.8.8: OK
So my initial "data just stops flowing" assessment is not true. My notebook is still connected to local network.
I really don't know what to do. This is not a serious issue (because connection only drops for a minute) but it's really annoying, especially during a video call.
]]>have you read this: https://wiki.archlinux.org/index.php/Ne … ss#iwlwifi
i have to use "swcrypto=1" for mine to work correctly
Trying that right now! I tried bt_coex_active=0 and it didn't work. I'll also try 11n_disable=1 if swcrypto does not help.
]]>i have to use "swcrypto=1" for mine to work correctly
]]>Please remove the image and post text as text instead of screenshots.
Is it ok if I leave the link to the image for now? In the meantime I'll try to catch the incident again and paste the mtr output as text.
Check your journal/dmesg when the connection drops, post it in doubt.
Output of journalctl around the time of the event:
mar 23 21:25:50 x1 chromium.desktop[88427]: [88427:16:0323/212550.382195:ERROR:webrtc_video_engine.cc(3060)] Absent receive stream; ignoring clearing encoded frame sink for ssrc 0
mar 23 21:31:53 x1 wpa_supplicant[554]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-57 noise=9999 txrate=14400
mar 23 21:32:27 x1 chromium.desktop[88350]: [88350:90336:0323/213227.602349:ERROR:webrtc_event_log_manager_remote.cc(411)] Session ID already set.
mar 23 21:32:31 x1 wpa_supplicant[554]: wlp4s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-60 noise=9999 txrate=13000
dmesg shows nothing related I think... this is dmesg | grep 04:00:
[mar mar 24 13:06:29 2020] - pci 0000:04:00.0: [8086:24fd] type 00 class 0x028000
[mar mar 24 13:06:29 2020] - pci 0000:04:00.0: reg 0x10: [mem 0xec100000-0xec101fff 64bit]
[mar mar 24 13:06:29 2020] - pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0: Found debug destination: EXTERNAL_DRAM
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0: Found debug configuration: 0
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0: loaded firmware version 36.77d01142.0 op_mode iwlmvm
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8265, REV=0x230
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0: Applying debug destination EXTERNAL_DRAM
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0: Allocated 0x00400000 bytes for firmware monitor.
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0: base HW address: 60:f6:77:32:13:24
[mar mar 24 13:06:32 2020] - iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0
[mar mar 24 13:06:33 2020] - iwlwifi 0000:04:00.0: Applying debug destination EXTERNAL_DRAM
[mar mar 24 13:06:34 2020] - iwlwifi 0000:04:00.0: Applying debug destination EXTERNAL_DRAM
[mar mar 24 13:06:34 2020] - iwlwifi 0000:04:00.0: FW already configured (0) - re-configuring
[mar mar 24 13:06:34 2020] - iwlwifi 0000:04:00.0: Applying debug destination EXTERNAL_DRAM
[mar mar 24 13:06:34 2020] - iwlwifi 0000:04:00.0: Applying debug destination EXTERNAL_DRAM
[mar mar 24 13:06:34 2020] - iwlwifi 0000:04:00.0: FW already configured (0) - re-configuring
Check your journal/dmesg when the connection drops, post it in doubt.
]]>I have a Lenovo Thinkpad X1 Carbon 5th gen. My wifi card is:
04:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 88)
Subsystem: Intel Corporation Dual Band Wireless-AC 8265
Flags: bus master, fast devsel, latency 0, IRQ 137
Memory at ec100000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 60-f6-77-ff-ff-32-13-24
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] L1 PM Substates
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
My kernel is:
Linux x1 5.5.9-arch1-2 #1 SMP PREEMPT Thu, 12 Mar 2020 23:01:33 +0000 x86_64 GNU/Linux
I can connect and use wifi normally. Except it randomly just stops working. This is the output of mtr 8.8.8.8 during one of these incidents.
And that's all I could figure out. Wifi appears to still be associated to the router, routes are still in place but data just stops flowing. This happens at least once every day.
Sometimes I just wait for a minute and the card just starts working again. Sometimes I run systemctl restart NetworkManager and that fixes it, but not always. Sometimes I have to turn wifi off and on.
Is this a known issue? Is there something else I can do to debug it?
Thanks!
]]>