Created attachment 880859 [details] dmesg before fault, just rebooted. Description of problem: When copy a large file over wifi using either scp of sftp the transfer fails before the file transfer completes. Version-Release number of selected component (if applicable): uname -a Linux d830 3.13.7-100.fc19.x86_64 #1 SMP Mon Mar 24 21:53:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Every time. Steps to Reproduce: 1.Open a terminal window. 2.Start an scp transfer of a large file (ex.Fedora-Live-Desktop-x86_64-19-1.iso) 3. Actual results: The transfer will stall before the files is completed. Expected results: The file should be correctry copied. Additional info: There is some inconsistency as to when it fails. Sometimes it fails at less than 10Mb, sometimes as much as 200Mb gets tranfered before is fails. There doesn't seem to be any usefull information in dmesg and messages. But attached anyway. lspci | grep WLAN 0c:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01)
Created attachment 880860 [details] dmesg after wifi was down for 10 minutes.
Created attachment 880861 [details] dmesg after manual reset of lan. (Off then ON)
Created attachment 880862 [details] messages file while this mess is going on. With reference to the messages file, the fault occured at 10:53.
The router is a Linksys E1200, Firmware Version: 1.0.03. (latest available)
I'm not sure what could be the reason. But there is a disconnection: Mar 31 11:03:57 d830 NetworkManager[452]: <info> (wlan0): device state change: activated -> unavailable (reason 'none') [100 20 0] Mar 31 11:03:57 d830 NetworkManager[452]: <info> (wlan0): deactivating device (reason 'none') [0] Mar 31 11:03:57 d830 kernel: [ 1104.226553] wlan0: deauthenticating from c0:c1:c0:dc:08:33 by local choice (reason=3) Mar 31 11:03:57 d830 NetworkManager[452]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 759 Mar 31 11:03:57 d830 kernel: [ 1104.228316] cfg80211: Calling CRDA to update world regulatory domain And later: Mar 31 11:03:58 d830 NetworkManager[452]: <info> WiFi hardware radio set disabled Mar 31 11:03:58 d830 NetworkManager[452]: <info> WiFi now disabled by radio killswitch Is that really triggered by copying large files? Did you do anything with the machine while copying? This seems suspicious to me: Mar 31 10:47:14 d830 systemd-logind[453]: Removed session c1. And before that there are some gnome-session problems. I can also see this: Mar 31 10:59:00 d830 kernel: [ 806.286135] perf samples too long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 https://bbs.archlinux.org/viewtopic.php?id=170471
The NetworkManager messages at 11:03 was because I manualy reset the wifi to get the connection back. Note that the wifi was down for 10 minutes already. The fault occurred at 10:53. The only thing going on is scp in a terminal window on the gnome3 desktop. The "perf samples too long" message happened 6 minutes after the failure. I have no idea if it's related. At that time I was copying the messages file and capturing dmesg output, again in the terminal window. As I mentioned there is no entry in the log at the time of failure. Is there a way to enable more verbose logging?
Did more tests: I tried copying the file over NFS to see if it would work. It did not and also failed in the same manner (nothing in the logs). This test should exonorates SSH as a possible problem. Being curious as to why NetworkManager doesn't see this failure, I installed wireshark to monitor the wlan. During an scp transfer from my server to my laptop, many packets fly by, as expected. When the failure happens, the last packets are a half dozen retransmit request packets from the server. However, other network trafic from other systems on the network are still captured. Various IGMP and ARP packets to and from my server, office desktop, printer and router can be seen. This would indicate that the wan is still up and the hardware driver is still working properly, and probably why NetworkManager is still happy. Found that this problem is not restricted to scp, sftp or NFS, but generally occurs any time there is a sustained high bandwidth demand on the wlan. Such as web sites with large amounts of data, or when downloading torrents. Could this be an IP stack issue. Perhaps a buffer overun situation? I wish I had some logs to send you or even better, if you could replicate the problem on your system. Let me know if I can help in any way.
Created attachment 881914 [details] dmesg run level 2 Tried copying the file at run level 2 since this would take a lot of baggage out of the way. The transfer still failed. $ who -r run-level 2 2014-04-02 13:21 $ scp server:Fedora-Live-Desktop-x86_64-19-1.iso . Fedora-Live-Desktop-x86_64-19-1.iso 5% 53MB 0.0KB/s - stalled -
Created attachment 881915 [details] The latest message file at run level 2.
All the logs from comment 8 and comment 9 look OK. NetworkManager connects and everything looks like it's fine. The 'dmesg' output also looks OK, there are no errors and the assocation with the AP goes wel. The problem is likely either in the kernel driver or the b43 open-source firmware, or with rate control. Over to the kernel to diagnose that.
[ 11.405110] ssb: Found chip with id 0x4311, rev 0x01 and package 0x00 [ 11.405125] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x11, vendor 0x4243) [ 11.405137] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x0A, vendor 0x4243) [ 11.405149] ssb: Core 2 found: USB 1.1 Host (cc 0x817, rev 0x03, vendor 0x4243) [ 11.405161] ssb: Core 3 found: PCI-E (cc 0x820, rev 0x01, vendor 0x4243) ... [ 13.002630] b43-phy0: Broadcom 4311 WLAN found (core revision 10) [ 13.018046] b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8 [ 13.025200] b43 ssb0:0: Direct firmware load failed with error -2 [ 13.025206] b43 ssb0:0: Falling back to user helper [ 13.025231] b43 ssb0:0: Direct firmware load failed with error -2 [ 13.025236] b43 ssb0:0: Falling back to user helper [ 13.025329] Broadcom 43xx driver loaded [ Features: PMNLS ] [ 13.510253] b43 ssb0:0: Direct firmware load failed with error -2 [ 13.510261] b43 ssb0:0: Falling back to user helper [ 13.552659] cfg80211: Calling CRDA for country: CA [ 13.554969] cfg80211: Regulatory domain changed to country: CA [ 13.554974] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 13.554977] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) [ 13.554980] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) [ 13.554982] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 13.554985] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) [ 13.554987] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) [ 13.606739] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' ... [ 32.276097] b43-phy0: Loading OpenSource firmware version 410.31754 [ 32.276106] b43-phy0: Hardware crypto acceleration not supported by firmware [ 32.325089] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 33.914709] wlan0: authenticate with c0:c1:c0:dc:08:33 [ 33.932312] wlan0: send auth to c0:c1:c0:dc:08:33 (try 1/3) [ 33.933949] wlan0: authenticated [ 33.935026] wlan0: associate with c0:c1:c0:dc:08:33 (try 1/3) [ 33.938639] wlan0: RX AssocResp from c0:c1:c0:dc:08:33 (capab=0x411 status=0 aid=3) [ 33.938953] wlan0: associated [ 33.938983] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Just upgraded to latest kernel. Problem still occurs. $ uname -a Linux d830 3.13.11-100.fc19.x86_64 #1 SMP Wed Apr 23 20:10:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.14.4-100.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
Upgraded to new kernel as requested. $ uname -a Linux d830 3.14.4-100.fc19.x86_64 #1 SMP Tue May 13 15:00:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux scp over wifi still fails miserably both in graphical or multi-user run level.
Installed and booted the debug kernel. $ uname -a Linux d830 3.14.4-100.fc19.x86_64.debug #1 SMP Tue May 13 14:46:53 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux When scp fails, nothing is written in the message file.
Created attachment 898788 [details] dmesg result after failure.
Created attachment 898790 [details] journalctl -k Did a fresh net-install of fc20. $ uname -a Linux d830 3.14.4-200.fc20.x86_64 #1 SMP Tue May 13 13:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux The only this I did was setup SSH keys copy my host file over and attempted the dreaded scp file copy. This was the result. scp server:Fedora-Live-Desktop-x86_64-19-1.iso . Fedora-Live-Desktop-x86_64-19-1.iso 15% 149MB 0.0KB/s - stalled $ lspci | grep WLAN 0c:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01)
Created attachment 915912 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Replaced my Broadcom wifi card with an Intel ($10 on ebay) $ lspci | grep Network 0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Kedron] Network Connection (rev 61) The wifi connection is now solid and about 30% faster. The Broadcom card made a satisfying crackling sound when I crushed it in my bench vise. Problem solved.