I have been using this for a week and no dropouts, tried all the likely places including airport WiFi. It seems to be up a little earlier on boot. Ping times to the AP don't seem to be as consistently low as I remember Intel wireless to be.
Would you both be able to share with me the make(s)/model(s) of access points you use?
@Community,
If there are any remaining concerns after the firmware update, please let me know and include what make(s)/model(s) of access points connected to while having any concerns.
I went through the process of updating the firmware on my Dell XPS 13 9360 which suffered from wifi connection breaking sometimes every 5 minutes - it seemed whenever a certain amount of data was transferred, the wifi would stop receiving/transmitting though apps would think the connection was still up. They just wouldn't get any data... I would have to turn on/off the wifi. Interestingly, the touchpad would also frequently lose its multi-touch capabilities, often immediately after restarting the wifi.
I run openSUSE Tumbleweed which has kernel 4.13.6 right now.
But whatever the causes and weird interactions, I updated to the latest firmware following the process above (using openSUSE equivalents) and lo and behold, the issues are gone completely! Wifi has been stable and the touchpad hasn't shown a single hiccup.
So: THANK YOU!
EDIT: you asked for access point info. I run a Archer C7 with OpenWRT 15.05.1 on it.
Like Jos I 'm also using a Dell XPS 13 9360 with Tumbleweed. And maybe Tumbleweed users are in luck. OpenSuse just released a new snapshot that perhaps fixes this particular issue. Except from the connection stopping after 10 minutes it was quite stable for many months and performed well.
I was filing a bug report for Tumbleweed just before i noticed the update. Technical details are here: bugzilla.opensuse.org/show_bug.cgi
In a nutshell: My specific issue seems to be fixed in WLAN.RM.4.4.1-00051-QCARMSWP-1(firmware-6.bin) which has been commited to the official linux firmware repository on 2017-10-09. That firmware update was added to the Tumbleweed snapshot today.
Replacing single firmware files should only be done for testing purpose in my opinion. In case an update for the firmware package is installed, all changes are lost or you are left with a mix of files.
What probably solved it for you Jos was that following the instruction from Justin you deleted the entire folder QCA6174. That resulted in firmware-6.bin not being found but instead loaded firmware-4.bin containing WLAN.RM.2.0-00180-QCARMSWPZ-1. Which is the same version as in the current Tumbleweed package.
As for Ubuntu: Both 16.04.3 (proposed repo) and 17.10 appear to have firmware-6.bin containing WLAN.RM.4.4-00022-QCARMSWPZ-2 which is the same as the one I had my issue with. So I wonder:
1. Do Ubuntu 17.10 users now have the same issue Jos and I had? so after 10 minutes the connection stops responding?
2. In case the package from 16.04.3 (proposed repo) lands as an update, will they also have this issue?
extra note In my understanding, if a firmware-6.bin is installed, it will be loaded instead of firmware-4.bin. Thats why some people on Arch simply deleted or renamed firmware-6.bin bbs.archlinux.org/viewtopic.php
Router: TP-Link Archer C7 v2 (rebranded router from my ISP) with LEDE Reboot 17.01.4
Thank you for sharing your experience and details here on the Dell Community. Glad to hear the firmware update helped you out.
@Hamkaas,
Thank you for your detailed account and questions. I actually don't know if owners with 16.04.3 and 17.10 are having the same issue. Due to your feedback, what we might do here is look into updating my firmware update post, as well as the official Dell knowledge base document, to include this latest firmware you found. I will work on that.
I followed the KB guide, but my wireless is still not working on many wifi networks (weird, because on some networks is working indeed).
Attached output from dmesg
[mer gen 31 12:06:10 2018] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[mer gen 31 12:06:10 2018] Bridge firewalling registered
[mer gen 31 12:06:10 2018] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[mer gen 31 12:06:10 2018] ip_tables: (C) 2000-2006 Netfilter Core Team
[mer gen 31 12:06:10 2018] Initializing XFRM netlink socket
[mer gen 31 12:06:10 2018] Netfilter messages via NETLINK v0.30.
[mer gen 31 12:06:10 2018] ctnetlink v0.93: registering with nfnetlink.
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-24b5655002d4: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-52995785ae2f: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-6134212654af: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-9a89a5518af9: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-cd2899cd3790: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-08687e20ae4f: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-91b48082c5ad: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-ae2a6b225cc2: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-ee073608dcb5: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-f1b59750ff89: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-684419f1679d: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
[mer gen 31 12:06:10 2018] IPv6: ADDRCONF(NETDEV_UP): br-995c1bc81218: link is not ready
[mer gen 31 12:06:11 2018] IPv6: ADDRCONF(NETDEV_UP): br-b6e431f70d4d: link is not ready
[mer gen 31 12:06:11 2018] IPv6: ADDRCONF(NETDEV_UP): br-c92e4f9aa0c2: link is not ready
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: enabling device (0000 -> 0002)
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[mer gen 31 12:06:12 2018] Non-volatile memory driver v1.3
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:3a:00.0.bin failed with error -2
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/cal-pci-0000:3a:00.0.bin failed with error -2
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: Direct firmware load for ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: could not fetch firmware file 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: kconfig debug 0 debugfs 1 tracing 1 dfs 0 testmode 0
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
[mer gen 31 12:06:12 2018] ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 20d869c3
[mer gen 31 12:06:14 2018] ath10k_pci 0000:3a:00.0: htt-ver 3.26 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
[mer gen 31 12:06:15 2018] ath: EEPROM regdomain: 0x6c
[mer gen 31 12:06:15 2018] ath: EEPROM indicates we should expect a direct regpair map
[mer gen 31 12:06:15 2018] ath: Country alpha2 being used: 00
[mer gen 31 12:06:15 2018] ath: Regpair used: 0x6c
[mer gen 31 12:06:15 2018] ath10k_pci 0000:3a:00.0 wlp58s0: renamed from wlan0
[mer gen 31 12:06:15 2018] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[mer gen 31 12:06:17 2018] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[mer gen 31 12:06:17 2018] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
[mer gen 31 12:06:26 2018] wlp58s0: authenticate with 32:91:8f:c6:70:62
[mer gen 31 12:06:26 2018] wlp58s0: send auth to 32:91:8f:c6:70:62 (try 1/3)
[mer gen 31 12:06:26 2018] wlp58s0: send auth to 32:91:8f:c6:70:62 (try 2/3)
[mer gen 31 12:06:26 2018] wlp58s0: send auth to 32:91:8f:c6:70:62 (try 3/3)
[mer gen 31 12:06:26 2018] wlp58s0: authentication with 32:91:8f:c6:70:62 timed out
[mer gen 31 12:06:48 2018] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
beurle
10 Posts
0
May 8th, 2017 02:00
I have been using this for a week and no dropouts, tried all the likely places including airport WiFi. It seems to be up a little earlier on boot. Ping times to the AP don't seem to be as consistently low as I remember Intel wireless to be.
I'd call it fixed!
Justin C
4 Operator
•
783 Posts
0
May 10th, 2017 16:00
@Bit101 and Beurle,
Glad to hear that, thank you for your feedback.
Would you both be able to share with me the make(s)/model(s) of access points you use?
@Community,
If there are any remaining concerns after the firmware update, please let me know and include what make(s)/model(s) of access points connected to while having any concerns.
jospoortvliet
3 Posts
0
October 22nd, 2017 04:00
Justin,
I went through the process of updating the firmware on my Dell XPS 13 9360 which suffered from wifi connection breaking sometimes every 5 minutes - it seemed whenever a certain amount of data was transferred, the wifi would stop receiving/transmitting though apps would think the connection was still up. They just wouldn't get any data... I would have to turn on/off the wifi. Interestingly, the touchpad would also frequently lose its multi-touch capabilities, often immediately after restarting the wifi.
I run openSUSE Tumbleweed which has kernel 4.13.6 right now.
But whatever the causes and weird interactions, I updated to the latest firmware following the process above (using openSUSE equivalents) and lo and behold, the issues are gone completely! Wifi has been stable and the touchpad hasn't shown a single hiccup.
So: THANK YOU!
EDIT: you asked for access point info. I run a Archer C7 with OpenWRT 15.05.1 on it.
hamkaas
13 Posts
0
October 24th, 2017 13:00
Hi Justin,
Like Jos I 'm also using a Dell XPS 13 9360 with Tumbleweed.
And maybe Tumbleweed users are in luck.
OpenSuse just released a new snapshot that perhaps fixes this particular issue.
Except from the connection stopping after 10 minutes it was quite stable for many months and performed well.
I was filing a bug report for Tumbleweed just before i noticed the update.
Technical details are here:
bugzilla.opensuse.org/show_bug.cgi
In a nutshell:
My specific issue seems to be fixed in WLAN.RM.4.4.1-00051-QCARMSWP-1(firmware-6.bin) which has been commited to the official linux firmware repository on 2017-10-09. That firmware update was added to the Tumbleweed snapshot today.
Replacing single firmware files should only be done for testing purpose in my opinion.
In case an update for the firmware package is installed, all changes are lost or you are left with a mix of files.
What probably solved it for you Jos was that following the instruction from Justin you deleted the entire folder QCA6174. That resulted in firmware-6.bin not being found but instead loaded firmware-4.bin containing WLAN.RM.2.0-00180-QCARMSWPZ-1. Which is the same version as in the current Tumbleweed package.
As for Ubuntu:
Both 16.04.3 (proposed repo) and 17.10 appear to have firmware-6.bin containing WLAN.RM.4.4-00022-QCARMSWPZ-2 which is the same as the one I had my issue with.
So I wonder:
1. Do Ubuntu 17.10 users now have the same issue Jos and I had? so after 10 minutes the connection stops responding?
2. In case the package from 16.04.3 (proposed repo) lands as an update, will they also have this issue?
extra note
In my understanding, if a firmware-6.bin is installed, it will be loaded instead of firmware-4.bin.
Thats why some people on Arch simply deleted or renamed firmware-6.bin
bbs.archlinux.org/viewtopic.php
Router: TP-Link Archer C7 v2 (rebranded router from my ISP) with LEDE Reboot 17.01.4
EDIT: formatting
Justin C
4 Operator
•
783 Posts
0
October 24th, 2017 18:00
@Jospoortvliet,
Thank you for sharing your experience and details here on the Dell Community. Glad to hear the firmware update helped you out.
@Hamkaas,
Thank you for your detailed account and questions. I actually don't know if owners with 16.04.3 and 17.10 are having the same issue. Due to your feedback, what we might do here is look into updating my firmware update post, as well as the official Dell knowledge base document, to include this latest firmware you found. I will work on that.
Thank you!
garakkio
2 Posts
0
January 31st, 2018 05:00
I followed the KB guide, but my wireless is still not working on many wifi networks (weird, because on some networks is working indeed).
Attached output from dmesg
garakkio
2 Posts
0
June 22nd, 2018 06:00
It looks like issue was solved after upgrading to Ubuntu 18.04
At least, a couple of wi-fi networks that were not previously working are working now.
I keep my fingers crossed...
Intro
15 Posts
0
September 22nd, 2018 05:00
It's still crashing for me under Ubuntu 18.4.1
More info at https://www.dell.com/community/Linux-Developer-Systems/XPS-13-9370-ath10k-pci-firmware-crash/m-p/6114945#M8568