You are not logged in.
Pages: 1
Hi, I need help diagnosing this issue with my WiFi connection.
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!
Last edited by dessaya (2020-03-25 03:49:33)
Offline
Please remove the image and post text as text instead of screenshots.
Check your journal/dmesg when the connection drops, post it in doubt.
Offline
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
Last edited by dessaya (2020-03-24 16:16:40)
Offline
have you read this: https://wiki.archlinux.org/index.php/Ne … ss#iwlwifi
i have to use "swcrypto=1" for mine to work correctly
Offline
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.
Offline
So i tried all options:
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.
Offline
What's the exact behavior/error for
Notebook pings 8.8.8.8: Nope
Timeout or no route?
MTU issue? Output of "ip l"?
Also:
systemctl list-unit-files --state=enabled
Offline
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.
Offline
The MTU is standard (so unlikely the problem) and you're not running concurrent network managing services.
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)
Offline
Thanks seth! I disabled docker (I was not using it anyway) and MAC address randomization this morning, and have not experienced any incidents so far... Looking good!
I'll wait a couple of days just in case before marking this as solved.
Offline
Well, it just happened again so no, the issue is not solved :-(
Offline
I have an X1C5 as well, and I was having a similar problem a while ago.
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?
Offline
Will try that. Thanks nixon!
Offline
Last night I replaced wpa_supplicant with iwd aaaand... I just had another incident. I had to run systemctl restart iwd to get it to work again.
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.
Last edited by dessaya (2020-03-31 19:46:33)
Offline
Pages: 1