Bug 1014843

Summary: wifi dies during sftp transfer
Product: [Fedora] Fedora Reporter: Dano <dano57ca>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: dcbw, dennis
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-11 03:09:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Comment none

Description Dano 2013-10-02 22:12:58 UTC 
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0
Build Identifier: 

During an sftp transfer between my Dell D830 laptop(wifi) and my server(wired), if I open another window, the wifi dies. It doesn't seem to matter what I open. Firefox, FileManager, sudoku... whatever. The transfer rate drops from ~3.5MB/s down to >10KB/s within seconds. Restarting NetworkManager restores the transfer after a few seconds but just until another window is opened. After restarting NetworkManager in this fashion 4-5 times, a reboot is required to restore wifi. This happens both on my Dell D830 and on my older HP N6000. I have also tried different routers, a D-Link and a Cisco. No difference.

Reproducible: Always

Steps to Reproduce:
1. Open a terminal window and start an sftp transfer (a larger file gives you more time to experiment)
2. Open another program (ie. firefox)

Actual Results:  
The transfer will stall.

Expected Results:  
The sftp transfer should continue in the background while rumming other programs. Wifi should stay up.


I suspect this problem has been around for a long time. I've had wifi drop issues since FC12. It's just recently that I (accidentally) figured out how to consistently reproduce the problem.
Comment 1 Dano 2013-10-08 22:18:45 UTC 
# uname -r
3.11.3-201.fc19.x86_64

cut/paste from 
cat /var/log/messages

kernel: [   12.854456] b43-phy0: Broadcom 4311 WLAN found (core revision 10)
kernel: [   12.869057] b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8
kernel: [   12.876248] Broadcom 43xx driver loaded [ Features: PMNLS ]

cut/paste from 
#lspci -vn

0c:00.0 0280: 14e4:4311 (rev 01)
	Subsystem: 1028:0007
	Flags: bus master, fast devsel, latency 0, IRQ 17
	Memory at f1ffc000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Power Management version 2
	Capabilities: [58] MSI: Enable- Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Express Legacy Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [13c] Virtual Channel
	Kernel driver in use: b43-pci-bridge

When wifi dies, nothing appears in messages or wpa_supplicant.log until

cfg80211: Calling CRDA to update world regulatory domain

This can take 1 minute of more after wifi dies. As if NetworkManager is unaware the wifi has gone down until it tries to use it.

Found that during an sftp transfer, simply moving or resizing an existing window on the desktop kills he connection.

Clicking on the "Activities" tab during an sftp transfer will also kill the connection.

If you need any other information, I'm happy to help.
Comment 2 Dano 2013-10-09 00:26:36 UTC 
Created attachment 915778 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Comment 3 Dano 2013-10-11 03:09:42 UTC 
Installed KDE and found that sftp transfers are rock solid under KDE. I can only reproduce the wifi failure using the GNOME desktop.

I will file a bug report under gnome-software.