Bug 418691 - ath5k requires reduced MTU to work with git, rsync
ath5k requires reduced MTU to work with git, rsync
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-10 14:36 EST by Adam Goode
Modified: 2008-02-19 15:43 EST (History)
3 users (show)

See Also:
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 15:43:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Goode 2007-12-10 14:36:37 EST
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 14:47:34 EST
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 14:49:15 EST
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 12:27:35 EST
Nope, neither 11M setting nor -80.fc8 make any difference. But mtu 1498
continues to work perfectly.
Comment 4 Adam Goode 2008-01-08 15:24:48 EST
kernel -85.fc8 still has the same problem.
Comment 5 John W. Linville 2008-01-22 15:07:20 EST
Could there be an ethernet LAN using VLAN tagging somewhere between you and 
the Internet?
Comment 6 Adam Goode 2008-01-22 21:47:02 EST
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 13:50:31 EST
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 17:06:56 EST
I have tried ping both ways. The frames are dropped only on Tx. Rx works fine.
Comment 9 Adam Goode 2008-02-19 15:30:21 EST
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 15:43:04 EST
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!

Note You need to log in before you can comment on or make changes to this bug.