You are not logged in.
Pages: 1
Topic closed
Hello
I'm struggling with frequent on Dell XPS 13 bought in october 2016.
Initially, running Windows 10, the laptop already has disconnection issues. Switching to Arch didn't help.
The symptoms are the following: every quarter or so the wifi connection is lost. The browser, on next page load, spins waiting for the data but there's no progress.
I usually open the network tool, turn off and on again the wifi. Alternativaly, I click on the network I use, then it tries to connect again, but sometimes it fails: turning off and on again the whole wifi is safer.
Here is a sample of the dmesg -H when the issue arises:
[ +0.466341] ath10k_pci 0000:3a:00.0: Unknown eventid: 90118
[ +0.054378] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[ +0.788269] ath10k_pci 0000:3a:00.0: Unknown eventid: 90118
[ +0.044298] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[ +0.060132] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[ +4.868726] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[ +4.892182] wlp58s0: authenticate with 00:24:d4:6a:70:54
[ +0.046545] wlp58s0: send auth to 00:24:d4:6a:70:54 (try 1/3)
[ +0.001920] wlp58s0: authenticated
[ +0.003112] wlp58s0: associate with 00:24:d4:6a:70:54 (try 1/3)
[ +0.003721] wlp58s0: RX AssocResp from 00:24:d4:6a:70:54 (capab=0x411 status=0 aid=2)
[ +0.002784] wlp58s0: associated
[ +0.000068] IPv6: ADDRCONF(NETDEV_CHANGE): wlp58s0: link becomes ready
[Sep 9 03:14] wlp58s0: deauthenticating from 00:24:d4:6a:70:54 by local choice (Reason: 3=DEAUTH_LEAVING)
[ +1.744910] ath10k_pci 0000:3a:00.0: Unknown eventid: 90118
[ +0.011859] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[ +0.062103] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
At first I thought this was the issue:
[Sep 9 03:14] wlp58s0: deauthenticating from 00:24:d4:6a:70:54 by local choice (Reason: 3=DEAUTH_LEAVING)
but now I think it's due to me turning off the wifi.
I tried to turn off power saving as told in Network interfaces, after reading the Random disconnections page. It didn't work and I'm looking for others options.
EDIT : initial state above, topic name and content changed as per loqs suggestions
hi
My wifi connection stops frequently, and I spotted exactly the Cause #1 described in the doc https://wiki.archlinux.org/index.php/Wi … figuration
To disable power saving, I used https://wiki.archlinux.org/index.php/Po … interfaces and did:
sudo vi /etc/udev/rules.d/70-wifi-powersave.rules
and put the following in it:
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*", RUN+="/usr/bin/iw dev %k set power_save off"
However, since, the file is still there and I'm still getting disconnected frequently.
/usr/bin/iw is existing...
Did I miss something? Is there something to check the application of the rule?
Any help welcome... These frequent disconnections are really a pain!
cheers
cluelessjoe
Last edited by cluelessjoe (2017-10-02 21:32:01)
Offline
Welcome to the arch linux forums cluelessjoe. If you run the command manually on the network interface does it resolve the disconnects?
Offline
hi loqs
Thanks for the reply
I tried to run the command manually but I didn't manage to figure out the proper replacement for %k...
thanks again
Offline
writing_udev_rules.html#strsubst
The most common operators are %k and %n. %k evaluates to the kernel name for the device, e.g. "sda3" for a device that would (by default) appear at /dev/sda3.
Offline
I saw that, but then when looking at /dev I didn't see "wlan*" or similar
acpi_thermal_rel fb0 mei0 psaux tty1 tty24 tty39 tty53 ttyS1 vcsa2
autofs fd mem ptmx tty10 tty25 tty4 tty54 ttyS2 vcsa3
block full memory_bandwidth pts tty11 tty26 tty40 tty55 ttyS3 vcsa4
btrfs-control fuse mqueue random tty12 tty27 tty41 tty56 uhid vcsa5
bus gpiochip0 net rfkill tty13 tty28 tty42 tty57 uinput vcsa6
char hidraw0 network_latency rtc tty14 tty29 tty43 tty58 urandom vfio
console hpet network_throughput rtc0 tty15 tty3 tty44 tty59 v4l vga_arbiter
core hugepages null shm tty16 tty30 tty45 tty6 vcs vhci
cpu initctl nvme0 snapshot tty17 tty31 tty46 tty60 vcs1 vhost-net
cpu_dma_latency input nvme0n1 snd tty18 tty32 tty47 tty61 vcs2 video0
cuse kmsg nvme0n1p1 stderr tty19 tty33 tty48 tty62 vcs3 watchdog
disk kvm nvme0n1p2 stdin tty2 tty34 tty49 tty63 vcs4 watchdog0
dri log nvme0n1p3 stdout tty20 tty35 tty5 tty7 vcs5 zero
drm_dp_aux0 loop-control nvme0n1p4 tpm0 tty21 tty36 tty50 tty8 vcs6
drm_dp_aux1 mapper port tty tty22 tty37 tty51 tty9 vcsa
drm_dp_aux2 media0 ppp tty0 tty23 tty38 tty52 ttyS0 vcsa1
so I'm a bit lost here :$
Last edited by cluelessjoe (2017-09-09 08:54:17)
Offline
Offline
Thanks a lot again, really nice to point out the documentation like this (I should have seen it though :$)
So I did:
iw dev
phy#0
Unnamed/non-netdev interface
wdev 0x6
addr (snip)
type P2P-device
txpower 0.00 dBm
Interface wlp58s0
ifindex 2
wdev 0x1
addr (snip)
type managed
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 20.00 dBm
and then
sudo /usr/bin/iw dev wlp58s0 set power_save off
Is this ok? Is there a way to figure out if this worked?
A few side questions:
- how to make sure this udev qualifier matches my wifi "ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*""?
- are there some logs anywhere to figure out if this is picked up?
However, since, I had another wifi interruption, so it looks like it's failing. Did i do something wrong? Any other hint maybe? I checked the bios: there's no "power saving" config regarding Wifi.
Offline
Is this ok? Is there a way to figure out if this worked?
A few side questions:
- how to make sure this udev qualifier matches my wifi "ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*""?
- are there some logs anywhere to figure out if this is picked up?
$ udevadm test /class/net/wlp58s0
This will not match your rule as the interface name has been changed due to persistant device naming. See the note on the referenced wiki page.
However, since, I had another wifi interruption, so it looks like it's failing.
If you ran the command manually and had an interruption anyway then I would advise against attempting to fix the udev rule as the command the udev rule triggers does not appear to resolve your issue.
I would suggest renaming your topic to reflect the issue such as "frequent wiki diconnections". What specific symptoms due you experience during a disconnection?
If you are using a network manager what is its status during the disconnect? What is the status of the interface/link? Is any power management software in use?
Offline
Is there a way to figure out if this worked?
Yes. Instead of running /usr/bin/iw, run a *script*, which logs what it's doing, using e.g. the "logger" command.
Offline
hi again & thanks once more
I've changed the title of the topic + provided some background on the issue. Maybe you can figure out stuff out of it (mostly: it was behaving the same with windows 10 before I installed Arch).
Regarding yours questions:
- If you are using a network manager what is its status during the disconnect?
I'm running no network manager AFAIK
- What is the status of the interface/link?
Here is the state when wifi is down:
iw dev
phy#0
Unnamed/non-netdev interface
wdev 0xa
addr 9c:b6:d0:17:2d:9b
type P2P-device
txpower 0.00 dBm
Interface wlp58s0
ifindex 2
wdev 0x1
addr 9c:b6:d0:17:2d:9b
type managed
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 20.00 dBm
iw dev wlp58s0 link
Connected to 00:24:d4:6a:70:54 (on wlp58s0)
SSID: freebox_JPA
freq: 2462
RX: 961758 bytes (3902 packets)
TX: 344102 bytes (2018 packets)
signal: -52 dBm
tx bitrate: 1.0 MBit/s
bss flags: short-slot-time
dtim period: 2
beacon int: 96
iw dev wlp58s0 station dump
Station 00:24:d4:6a:70:54 (on wlp58s0)
inactive time: 53 ms
rx bytes: 979916
rx packets: 4102
tx bytes: 353454
tx packets: 2095
tx retries: 0
tx failed: 0
beacon loss: 0
beacon rx: 1068
rx drop misc: 10
signal: -51 dBm
signal avg: -50 dBm
beacon signal avg: 206 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 144.4 MBit/s MCS 15 short GI
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 2
beacon interval:96
short slot time:yes
connected time: 786 seconds
Is any power management software in use?
- not that I know of
@brebs
I'll look into logger later, I've to go for now. More ASAP.
Offline
BTW, ip link show wlp58s0 gave, when wifi isn't available:
2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 9c:b6:d0:17:2d:9b brd ff:ff:ff:ff:ff:ff
Offline
Hi
Well, the issue is still here but I learnt stuff.
First of all, I spotted this log before losing the connection:
Sep 13 21:52:31 joe wpa_supplicant[584]: wlp58s0: WPA: Group rekeying completed with 00:24:d4:6a:70:54 [GTK=CCMP]
There was actually a bug around this: https://bugs.debian.org/cgi-bin/bugrepo … bug=651199 which should be solved by now. Still, it may be linked to WPA/WPA2.
While digging in, I also found https://wiki.archlinux.org/index.php/Ne … .28WiFi.29 . I locked the BSSID in the connection, but it didn't neither in the end. So I removed it.
And I now use
nmcli r wifi off/on
to restart the wifi, way faster.
By looking at the logs, this kind of logs is typical before losing connection:
Sep 13 23:12:30 joe wpa_supplicant[584]: wlp58s0: WPA: Group rekeying completed with 00:24:d4:6a:70:54 [GTK=CCMP]
Sep 13 23:22:30 joe wpa_supplicant[584]: wlp58s0: WPA: Group rekeying completed with 00:24:d4:6a:70:54 [GTK=CCMP]
Sep 13 23:26:58 joe dbus[435]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
Sep 13 23:26:58 joe systemd[1]: Starting Network Manager Script Dispatcher Service...
Sep 13 23:26:58 joe dbus[435]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Sep 13 23:26:58 joe systemd[1]: Started Network Manager Script Dispatcher Service.
Sep 13 23:26:58 joe nm-dispatcher[20305]: req:1 'connectivity-change': new request (0 scripts)
Sep 13 23:26:58 joe nm-dispatcher[20305]: req:1 'connectivity-change': completed: no scripts
Sep 13 23:32:30 joe wpa_supplicant[584]: wlp58s0: WPA: Group rekeying completed with 00:24:d4:6a:70:54 [GTK=CCMP]
Could the dispatcher thingy be part of the issue? I'll look into it later.
Being a bit fed up with the issue, could something like the TP-Link N300 Wireless Mini USB Adapter resolve it?
Any help welcome :$
BTW, for the logger bit, I didn't get what I should do...
thanks in advance for any help
Offline
I got another disconnection and this time the logs are pretty clean:
-- Logs begin at Sun 2016-11-13 22:09:53 CET. --
Sep 13 23:42:30 joe wpa_supplicant[584]: wlp58s0: WPA: Group rekeying completed with 00:24:d4:6a:70:54 [GTK=CCMP]
Sep 13 23:52:30 joe wpa_supplicant[584]: wlp58s0: WPA: Group rekeying completed with 00:24:d4:6a:70:54 [GTK=CCMP]
In the browser, on page load, I get a "Server not found", while the wifi indicator is still fine (good signal).
nmcli dev gives:
DEVICE TYPE STATE CONNECTION
docker0 bridge connected docker0
wlp58s0 wifi connected freebox_JOE
lo loopback unmanaged --
Really looks like "WPA: Group rekeying completed" is part of the issue... I always get at least one before loosing the wifi.
Any idea?
Offline
Hello,
I just buy a DELL XPS 13 with ubuntu and changed it for ArchLinux.
Installation done correctly except some wifi random deconnections...
Installation of xfce4, copy some large files et again deconnections during the ftp copy...
This problem is very borring!!!
So, I'm searching like you...
Offline
Hello,
It seems that I found the solution !!! (I'm using the wifi to copy over 90Gb of data during the night and no disconnection issue for the time being).
# Getting information from software & hardware (sorry, the result of some command lines are in French)
My laptop is a DELL XPS 13 9360 (075B) (Serial number = 745TGH2)
Network wifi card: QCA6174 802.11ac Wireless Network Adapter from Qualcomm Atheros
with the firmware version after resolution = WLAN.RM.4.4.1-00051-QCARMSWP-1
With ArchLinux up-to-date (2017 - Sept - 23th) : GNU/Linux 4.12.13-1-ARCH x86_64
Situation after the resolution:
$ uname -a
Linux XPS13 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43 UTC 2017 x86_64 GNU/Linux
$ sudo pacman -S lshw
...
$ sudo lshw|head -8
xps13
description: Ordinateur Portable
produit: XPS 13 9360 (075B)
fabriquant: Dell Inc.
numéro de série: 745TGH2
bits: 4294967295 bits
fonctionnalités: smbios-3.0 dmi-3.0 smp vsyscall32
configuration: boot=normal chassis=laptop family=XPS sku=075B uuid=44454C4C-3400-1035-8054-B7C04F474832
$ sudo lshw -c network
*-network
description: Interface réseau sans fil
produit: QCA6174 802.11ac Wireless Network Adapter
fabriquant: Qualcomm Atheros
identifiant matériel: 0
information bus: pci@0000:3a:00.0
nom logique: wlp58s0
version: 32
numéro de série: 9c:b6:d0:e9:1d:f3
bits: 64 bits
horloge: 33MHz
fonctionnalités: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=ath10k_pci driverversion=4.12.13-1-ARCH firmware=WLAN.RM.4.4.1-00051-QCARMSWP-1 ip=192.168.0.21 latency=0 link=yes multicast=yes wireless=IEEE 802.11
ressources: irq:291 mémoire:dc000000-dc1fffff
-1- Update the BIOS (I did it, but it didn't solve the problem...)
- Go to the DELL Support website and download the last BIOS version (it's a .EXE file)
- Copy this file in an USB stick (it's working with an USB stick formated in FAT32)
- Reboot your laptop and press F12 during the boot with your USB stick pluged in
- Goto "Flash BIOS", select the file .EXE and launch the flash procedure.
- Now my BIOS version is 2.2.1
Source of information:
https://www.dell.com/support/article/fr … ts?lang=en
-2- Manual update of the Linux Wifi driver/firmware (I did it, and it solved the problem !!!)
- Download the last firmware version:
- all files into a zip: https://codeload.github.com/kvalo/ath10 … zip/master
sudo pacman -S wget
wget https://codeload.github.com/kvalo/ath10k-firmware/zip/master -O ath10k-firmware-master.zip
- or manually from the source: kernel.org
- https://wireless.wiki.kernel.org/en/use … k/firmware and follow the link related to your hardware (QCA6174 for me)
- Unzip the file
sudo pacman -S file-roller p7zip zip unzip
unzip ath10k-firmware-master.zip
- Backup you original firmware files (recommended):
sudo tar czvf ~/QCA6174_Original.tgz /lib/firmware/ath10k/QCA6174
- Replace the new firmware folder related to your hardware (QCA6174 for me) to your ArchLinux firmware folder and remane/copy the firmware files with the correct name for the system:
ls /lib/firmware/ath10k/
sudo rm -R /lib/firmware/ath10k/QCA6174
ls /lib/firmware/ath10k/
sudo cp -R ath10k-firmware-master/QCA6174/ /lib/firmware/ath10k/
ls /lib/firmware/ath10k/
sudo mv /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin_WLAN.RM.2.0-00180-QCARMSWPZ-1 /lib/firmware/ath10k/QCA6174/hw3.0/firmware-4.bin
sudo mv /lib/firmware/ath10k/QCA6174/hw3.0/4.4/firmware-6.bin_WLAN.RM.4.4-00022-QCARMSWPZ-2 /lib/firmware/ath10k/QCA6174/hw3.0/4.4/firmware-6.bin
sudo mv /lib/firmware/ath10k/QCA6174/hw3.0/4.4.1/firmware-6.bin_WLAN.RM.4.4.1-00051-QCARMSWP-1 /lib/firmware/ath10k/QCA6174/hw3.0/4.4.1/firmware-6.bin
sudo cp /lib/firmware/ath10k/QCA6174/hw3.0/4.4.1/firmware-6.bin /lib/firmware/ath10k/QCA6174/hw3.0/
- Reboot your system
- check if your system correctly used the new firmware
sudo lswh -c network | grep WLAN.RM.4.4.1-00051-QCARMSWP-1
Source of information:
https://www.dell.com/support/article/fr … te?lang=en
https://github.com/kvalo/ath10k-firmware
Offline
Awesome, that did it I had been notified only of your first post, I'm so glad I looked again The driver update did the trick (so far at least). Thx a lot!
Offline
Share the knowledge, share the power
Free & Open : Share GNU/Linux
Offline
Just like to say that Luc33's fix also works for the Dell XPS 9370. I was getting periodic disconnections (about every 2.5 hours weirdly) but on updating the driver (the latest as of writing is firmware-6.bin_WLAN.RM.4.4.1-00119-QCARMSWP-1) it is now holding the connection (so far so good...!). This is a fix I'm applying to a box running Fedora actually, but I've picked up lots of helpful advice on the Arch forums that is applicable to numerous distros: so just want to say a big thanks and hopefully someone else searching for this solution will find the bounty here on Arch.
Offline
Glad to hear, taking the opportunity to close this old topic.
Closing.
Offline
Pages: 1
Topic closed