Bug 177088

*** Bug 177087 has been marked as a duplicate of this bug. ***

Sorry!

*** This bug has been marked as a duplicate of 177087 ***

aarrggh, crossed deduplication

I doubt Fedora Legacy is going to do anything about this, but I'll put it in the
DEFER pile in case it'd be investigated during the next kernel update.

You might need to run 'tcpdump -vvv -s0' on the TCP packets to figure out
whether there's anything wrong with them on the wire (compared to FC3 for
example), or whether it's just a kernel bug.

My Macs write fine to Fedora Core 3 machines, using scp, afp, or smb.  And all
three protocols fail writing to the Fedora Core 1 machine, so it definitely
looks like a TCP/IP problem.  It even affects afp over IP from MacOS 9...

Is there anything obviously wrong with the following output?  This is
from tcpdump -vvv -s0 -- verily is the Mac client, corpus the FC1 server.

12:09:43.770160 verily.anatomy.usyd.edu.au.58602 >
corpus.physiol.usyd.edu.au.ssh: . [tcp sum ok] 1661709111:1661710559(1448) ack
3896295592 win 65535 <nop,nop,timestamp 2235871481 171142927> (DF) [tos 0x8] 
(ttl 63, id 55090, len 1500)
12:09:43.770182 corpus.physiol.usyd.edu.au.ssh >
verily.anatomy.usyd.edu.au.58602: . [tcp sum ok] 1:1(0) ack 4344 win 60816
<nop,nop,timestamp 171143077 2235871481> (DF) [tos 0x8]  (ttl 64, id 61384, len 52)
12:09:43.770736 verily.anatomy.usyd.edu.au.58602 >
corpus.physiol.usyd.edu.au.ssh: . [tcp sum ok] 4344:5792(1448) ack 1 win 65535
<nop,nop,timestamp 2235871482 171143077> (DF) [tos 0x8]  (ttl 63, id 55091, len
1500)
12:09:43.770757 corpus.physiol.usyd.edu.au.ssh >
verily.anatomy.usyd.edu.au.58602: . [tcp sum ok] 1:1(0) ack 5792 win 63712
<nop,nop,timestamp 171143077 2235871482> (DF) [tos 0x8]  (ttl 64, id 61385, len 52)
12:09:43.771388 verily.anatomy.usyd.edu.au.58602 >
corpus.physiol.usyd.edu.au.ssh: . [tcp sum ok] 7240:8688(1448) ack 1 win 65535
<nop,nop,timestamp 2235871482 171143077> (DF) [tos 0x8]  (ttl 63, id 55093, len
1500)
12:09:43.771403 corpus.physiol.usyd.edu.au.ssh >
verily.anatomy.usyd.edu.au.58602: . [tcp sum ok] 1:1(0) ack 5792 win 63712
<nop,nop,timestamp 171143077 2235871482> (DF) [tos 0x8]  (ttl 64, id 61386, len 52)

This is from an scp that's giving me 22KB/s throughtput...

Here's a trace from an scp to an FC3 machine (nonsense), which gives me 4.4MB/s
throughput.

12:13:51.178459 IP (tos 0x8, ttl  64, id 44133, offset 0, flags [DF], proto 6,
length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok]
1448:2896(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797>
12:13:51.178476 IP (tos 0x8, ttl  64, id 43499, offset 0, flags [DF], proto 6,
length: 52) nonsense.ssh > verily.anatomy.usyd.edu.au.58619: . [tcp sum ok]
1:1(0) ack 2896 win 32768 <nop,nop,timestamp 4134478797 2235871976>
12:13:51.178488 IP (tos 0x8, ttl  64, id 44134, offset 0, flags [DF], proto 6,
length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok]
2896:4344(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797>
12:13:51.178502 IP (tos 0x8, ttl  64, id 44135, offset 0, flags [DF], proto 6,
length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok]
4344:5792(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797>
12:13:51.178514 IP (tos 0x8, ttl  64, id 43501, offset 0, flags [DF], proto 6,
length: 52) nonsense.ssh > verily.anatomy.usyd.edu.au.58619: . [tcp sum ok]
1:1(0) ack 5792 win 32768 <nop,nop,timestamp 4134478798 2235871976>
12:13:51.177372 IP (tos 0x8, ttl  64, id 44136, offset 0, flags [DF], proto 6,
length: 1500) verily.anatomy.usyd.edu.au.58619 > nonsense.ssh: . [tcp sum ok]
5792:7240(1448) ack 1 win 65535 <nop,nop,timestamp 2235871976 4134478797>

Are there any TCP/IP parameters I could try tweaking on the FC1 machine?

One more bit of information - it seems to be a TCP problem rather than an IP
one, since I can do a flood ping from the Mac to the FC1 machine and get nearly
a thousand 1500 byte pings a second through.

I'm hunting through my old TCP/IP texts, but it's been ten years since I studied
any of this stuff, so any pointers would be appreciated.

I found a workaround that confirms my belief it's a TCP problem.  I enabled a
DDP only netatalk share on the FC1 server, and the Mac writes fine to that,
using Appleshare over Appletalk DDP instead of over IP.  That's not a solution
for OSX 10.4 machines (10.4 doesn't support DDP), but hopefully by the time that
becomes critical I'll have managed the move to FC4.

I took a quick look at those traces, conclusions:
 - there don't appear to be TCP options level issues that I could see though you
could try disabling TCP timestamps if that'd be causing issues (echo 1 >
/proc/sys/net/ipv4/tcp_timestamps).  You might also want to test other TCP features 

 - in the non-working case, it takes around 0.5 milliseconds more to send each
TCP segment (look at the spacing of timestamps as the left)

 - corpus sends "ack 5792" two times, implying that the packet sent at 
12:09:43.771388 by verily might have been corrupted or gotten lost.

Any further debugs you might do can probably be done without '-vvv' option, as
there's less (useless) information that way.

You may also want to verify that Apple sets TCP_NODELAY socket option in the
applications you're testing, see:
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html

Changing the timestamps setting didn't help, but thanks for looking at this. 

I've also confirmed that Appleshare over IP is slow even when Macs are booted
into OS 9 - which is really strange, since the OS X and Mac System 9 TCP/IP
implementations should be completely different.

I'm just bemused now.  I don't think it can be an ethernet problem, as there's a
switch in the way and the Macs and my FC1 server interoperate fine with other
servers or Windows/Linux clients.  It can't be some Appleshare weirdness, as it
affects scp and smb as well.  Did the dog bark in the night?

Not really a security issue.