You are not logged in.
Pages: 1
Hi,
for a few weeks now, I've had the issue that my internet connection stops working after some time. This has happened to me while the laptop was disconnected from power as well as when connected to power. Although I think in the latter case, it would usually happen after not using it for a few minutes (however before it goes into hibernate or something).
While searching the internet, I have come across two similar problems: 1. WiFi card goes into power save mode or, 2. the network card is trying to roam to another frequency (ie. having both a 2.4 and 5 ghz network with the same ESSID).
Perhaps also worth noting is that I moved into a coworking space a few weeks ago (which could coincide with the date it started working unreliably -- I don't recall the exact date it started).
What I did:
- Observed dmesg, but nothing was shown there before and after the connection stopped working
- I can work around the issue by restarting netctl-auto: sudo systemctl restart netctl-auto@wlp2s0.service
- iwconfig shows that Power Management is on, but I don't see here that it suspended or something (see below).
Does anybody have an idea what else I could try? Or how I could determine with certainty whether power or roaming might be an issue or not?
Thanks a lot.
- Reto
wlp2s0 IEEE 802.11 ESSID:"WeWork"
Mode:Managed Frequency:5.54 GHz Access Point: 84:18:3A:B9:E6:CC
Bit Rate=144.4 Mb/s Tx-Power=22 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=48/70 Signal level=-62 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Last edited by rethab (2018-11-06 11:38:47)
Offline
The typical cause are concurrent network managing services:
systemctl list-unit-files --state=enabled
Otherwise, please post a complete journal (including kernel messages, ie. you'll require root permissions or wheel group membership)
Do you have an AP that announces the same SSID on 2.4 & 5GHz?
Offline
$ sudo systemctl list-unit-files --state=enabled
UNIT FILE STATE
autovt@.service enabled
docker.service enabled
getty@.service enabled
iptables.service enabled
systemd-timesyncd.service enabled
remote-fs.target enabled
6 unit files listed.
$ sudo journalctl
Nov 08 14:59:06 asus-war-machine rtkit-daemon[1179]: Supervising 3 threads of 1 processes of 1 users.
Nov 08 15:00:26 asus-war-machine kernel: asus_wmi: Unknown key cf pressed
Nov 08 15:23:03 asus-war-machine kernel: wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by 84:18:3a:b9:e5:dc
Nov 08 15:23:49 asus-war-machine kernel: wlp2s0: Limiting TX power to 30 (30 - 0) dBm as advertised by 84:18:3a:b9:e5:dc
Nov 08 15:26:00 asus-war-machine sudo[1579]: rethab : TTY=pts/7 ; PWD=/home/rethab ; USER=root ; COMMAND=/usr/bin/journalctl
--> a little before 15:26 I noticed that the connection was gone
I'm connected to "WeWork" and it seems to be announced only on 5GHz (there's one with another name on 2.4GHz):
$ sudo iw wlp2s0 scan | egrep 'SSID|freq' | grep -B 1 WeWork$
freq: 5620
SSID: WeWork
--
freq: 5220
SSID: WeWork
--
freq: 5560
SSID: WeWork
--
freq: 5240
SSID: WeWork
--
freq: 5580
SSID: WeWork
--
freq: 5320
SSID: WeWork
--
freq: 5540
SSID: WeWork
--
freq: 5700
SSID: WeWork
--
freq: 5520
SSID: WeWork
--
freq: 5180
SSID: WeWork
--
freq: 5320
SSID: WeWork
Offline
Did you check the signal quality right when this happens?
There's no other NM service, but at 15:23:49 there's a TX power increase request - by the same MAC as before (do these APs share a common MAC?)
Does the connection auto-re-establish if you wait a while?
What's the netctl service status and the output of "ip a" and "ip r" when you run into a connection loss?
Offline
I compared the MAC addresses of all APs that advertise for this ESSID and none seems to share it.
From what I noticed, the signal quality seems to drop a bit, but from my understanding, values around 65-70 should still be okay? (in the sense that I should get some connection).
Regarding auto-reconnecting: This morning that was the case twice. However just a few minutes ago, it didn't reconnect after 2-3 minutes. So I checked the signal quality, which was around my daily average of 65. Once I restarted netctl-auto, the connection was there again.
netctl-auto status:
● netctl-auto@wlp2s0.service - Automatic wireless network connection using netctl profiles
Loaded: loaded (/usr/lib/systemd/system/netctl-auto@.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2018-11-14 10:47:14 CET; 6h ago
Docs: man:netctl.special(7)
Process: 650 ExecStart=/usr/bin/netctl-auto start wlp2s0 (code=exited, status=0/SUCCESS)
Tasks: 3 (limit: 4915)
Memory: 7.3M
CGroup: /system.slice/system-netctl\x2dauto.slice/netctl-auto@wlp2s0.service
├─ 772 wpa_supplicant -q -B -P /run/wpa_supplicant-wlp2s0.pid -i wlp2s0 -D nl80211,wext -c/run/netctl/wpa_supplicant-wlp2s0.conf -W
├─ 774 wpa_actiond -p /run/wpa_supplicant -i wlp2s0 -P /run/netctl/wpa_actiond-wlp2s0.pid -a /usr/lib/netctl/auto.action
└─1247 dhcpcd -4 -q -t 30 -K -L wlp2s0
Nov 14 10:47:18 asus-war-machine dhcpcd[1198]: DUID 00:01:00:01:22:41:69:ca:e4:a7:a0:f3:aa:c5
Nov 14 10:47:18 asus-war-machine dhcpcd[1198]: wlp2s0: IAID a0:f3:aa:c5
ip a:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether e4:a7:a0:f3:aa:c5 brd ff:ff:ff:ff:ff:ff
inet 10.46.104.137/21 brd 10.46.111.255 scope global noprefixroute wlp2s0
valid_lft forever preferred_lft forever
inet6 fe80::e6a7:a0ff:fef3:aac5/64 scope link
valid_lft forever preferred_lft forever
3: br-350a6a44f790: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:f6:9a:87:53 brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-350a6a44f790
valid_lft forever preferred_lft forever
inet6 fe80::42:f6ff:fe9a:8753/64 scope link
valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:7b:f6:2a:62 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: br-6cd54dc273d2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:7b:54:9d:6e brd ff:ff:ff:ff:ff:ff
inet 172.20.0.1/16 brd 172.20.255.255 scope global br-6cd54dc273d2
valid_lft forever preferred_lft forever
6: br-7e9b14db1997: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:5d:33:82:fb brd ff:ff:ff:ff:ff:ff
inet 172.19.0.1/16 brd 172.19.255.255 scope global br-7e9b14db1997
valid_lft forever preferred_lft forever
8: veth00e0dff@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-350a6a44f790 state UP group default
link/ether de:c3:31:7c:fd:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::dcc3:31ff:fe7c:fda3/64 scope link
valid_lft forever preferred_lft forever
10: veth292724e@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-350a6a44f790 state UP group default
link/ether 56:33:3e:db:f9:eb brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::5433:3eff:fedb:f9eb/64 scope link
valid_lft forever preferred_lft forever
ip r
default via 10.46.104.1 dev wlp2s0 proto dhcp src 10.46.104.137 metric 302
10.46.104.0/21 dev wlp2s0 proto dhcp scope link src 10.46.104.137 metric 302
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-350a6a44f790 proto kernel scope link src 172.18.0.1
172.19.0.0/16 dev br-7e9b14db1997 proto kernel scope link src 172.19.0.1 linkdown
172.20.0.0/16 dev br-6cd54dc273d2 proto kernel scope link src 172.20.0.1 linkdown
Offline
Pages: 1