Bug 418691

Summary:	ath5k requires reduced MTU to work with git, rsync
Product:	[Fedora] Fedora	Reporter:	Adam Goode <adam>
Component:	kernel	Assignee:	John W. Linville <linville>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	8	CC:	cebbert, davej, mcgrof
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	2.6.24.2-7.fc8	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-19 20:43:04 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Goode 2007-12-10 19:36:37 UTC

Description of problem:

I am using ath5k on a Thinkpad T41p.

Nearly all network traffic seems to be fine, but when I rsync or git pull, some
initial control traffic gets through and then it hangs. I must ctrl-c the program.




Setting mtu to 1498 fixes the problem for rsync.

ath5k_pci 0000:02:02.0: Atheros AR5213 chip found (MAC: 0x56, PHY: 0x41)
ath5k_pci 0000:02:02.0: RF5111 5GHz radio found (0x17)
ath5k_pci 0000:02:02.0: RF2111 2GHz radio found (0x23)

Version-Release number of selected component (if applicable):
kernel-2.6.23.8-63.fc8

Comment 1 John W. Linville 2007-12-10 19:47:34 UTC

I doubt if it makes a difference, but please try at least -80.fc8 (the last 
round of wireless updates for .fc8):

   http://koji.fedoraproject.org/koji/buildinfo?buildID=26862

Comment 2 Luis R. Rodriguez 2007-12-10 19:49:15 UTC

Hmm, interesting. Are you forcing the driver to 11M ? Right now the driver will
get you large packet loss at higher rates. I'm curious if your issues 'also' go
away at when you force driver to 11Mbps:

iwconfig wlan0 rate 11M

Comment 3 Adam Goode 2007-12-11 17:27:35 UTC

Nope, neither 11M setting nor -80.fc8 make any difference. But mtu 1498
continues to work perfectly.

Comment 4 Adam Goode 2008-01-08 20:24:48 UTC

kernel -85.fc8 still has the same problem.

Comment 5 John W. Linville 2008-01-22 20:07:20 UTC

Could there be an ethernet LAN using VLAN tagging somewhere between you and 
the Internet?

Comment 6 Adam Goode 2008-01-23 02:47:02 UTC

I don't think so. The wireless machines are directly on the Internet.

We can ping other local addresses with another machine with this:

 ping -M do -s 1472 ...

With IP + ICMP + payload = 20 + 8 + 1472 = 1500. That works fine using ipw2200.


On the ath5k machine, if mtu is 1500, then a ping payload of 1472 or 1471
results in no remote response. Ping payload of 1470 works.

Comment 7 John W. Linville 2008-02-14 18:50:31 UTC

Do you see the >1470 payload ICMP frames at the other host?  I would be 
curious to know if the frames are getting dropped on Tx or Rx.

Comment 8 Adam Goode 2008-02-15 22:06:56 UTC

I have tried ping both ways. The frames are dropped only on Tx. Rx works fine.

Comment 9 Adam Goode 2008-02-19 20:30:21 UTC

Seems kernel-2.6.24.2-7.fc8 fixes this problem! I can ping and rsync works with
MTU 1500 (the default).

I did get a panic at one point, though. Couldn't see the output since X was
running, and it hasn't happened since.

Comment 10 John W. Linville 2008-02-19 20:43:04 UTC

Wow, you are quick! :-)

FWIW, I think it this patch fixes the problem:

   ath5k: correct padding in tx descriptors

I was going to ask you to test it, but you beat me to it.  Thanks for the 
report!