[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#594676: marked as done (linux-image-2.6-amd64: Files Download Pb with the atl1c module and my ReadyNAS)

Your message dated Tue, 06 Dec 2011 05:18:18 +0000
with message-id <1323148698.7454.244.camel@deadeye>
and subject line Re: Files Download Pb with the atl1c module and my ReadyNAS
has caused the Debian Bug report #594676,
regarding linux-image-2.6-amd64: Files Download Pb with the atl1c module and my ReadyNAS
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
594676: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594676
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-image-2.6-amd64
Version: 2.6.32+27~bpo50+1
Severity: normal

Hi,

I have an eeepc 1201n with debian stable lenny+backports. So I'm using
the kernel 2.6.32-bpo.5-amd64. The Ethernet controller is driven by
the module atl1c. I'm using firestarter as firewall.

I have a file transfer problem between my NAS (readyNAS Duo from
Netgear); 

at first the symptoms:
- with firestarter installed (stopped or in use) I can connect my
eeepc to my NAS through FTP, CIFS or NFS. For example I can list or go
through my shares. But when I'm trying to download a file it is sooooo
slow. I get 12Ko in 10minutes...
- I can upload files from my eeepc to the NAS without problem with
"full speed".
- When I boot the eeepc under w7 I don't have any problem to download
files.
- I have two others computers on my LAN: a laptop with SID and the b44
module for the ethernet controller. With this laptop no problem at all
to download files from my NAS with firestarter installed. The other
one is a desktop station and I don't have any problem, too.

Now what I have done with the help of the debian.user.french list:
- the NAS has a MTU of 1500 (the software forces it). All the other
computers have an mtu of 1492. I don't choose it, my Netgear router
force it...When I set the mtu to 1500 on my eeepc with "ip link set
dev eth0 mtu 1500", then "ip route flush cache", I can dowload files
from my NAS without problem (firestarter installed and running). When
I set the both devices (eeepc and NAS) with a mtu to 1492, it doesn't
work at all.
- I have tested with the driver from realtek website and I get exactly
the same problem.
- I did capture with tcpdump. Guys of the debian.user.french mailing
list were surprised to see that lots of my packets were lost in my
"normal" configuration (firestarter installed, NAS mtu set to 1500 and
eeepc mtu set to 1492). And they see that my packets don't have a lot
of the normal TCP options (timestamp, selective ACK, window
scaling). So I check with sysctl if these options were enabled or not:
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 0
net.ipv4.tcp_window_scaling = 0
so they are disable on my "normal" configuration.
Then, I enable the options one by one and see that the
net.ipv4.tcp_timestamps option is a part of my problem:
with net.ipv4.tcp_timestamps = 0, eeepc_mtu=1492, NAS_mtu=1500 I get
problem to download files.
with net.ipv4.tcp_timestamps = 1, eeepc_mtu=1492, NAS_mtu=1500 I don't
have any problem to download files.

The program firestarter modifies the TCP options when it is
installed. 

It seems there is a problem for the atl1c module with the timestamps
option disabled and different mtus. On my other laptop with the b44
module, a mtu of 1492 and firestarter I don't have this problem
between it and the NAS.

Sorry for this loooonnng bug report. I can provide tcpdump captures if
necessary.

Best regards,
Guillaume

-- System Information:
Debian Release: 5.0.5
  APT prefers stable
  APT policy: (987, 'stable'), (985, 'stable'), (500, 'lenny'), (195, 'unstable'), (95, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6-amd64 depends on:
ii  linux-image-2.6.32-bpo 2.6.32-20~bpo50+1 Linux 2.6.32 for 64-bit PCs

linux-image-2.6-amd64 recommends no packages.

linux-image-2.6-amd64 suggests no packages.

-- debconf-show failed

--- End Message ---
--- Begin Message --- 
On Mon, 2011-12-05 at 11:30 +0100, giggzounetsmtp wrote:
> Ben Hutchings a écrit :
> > On Thu, 2011-12-01 at 11:33 +0100, giggzounetSMTP wrote:
> > [...]
> >> On my LAN my routeur always forces the mtu of my laptops to 1492. I have
> >> a laptop with debian sid and an eeepc with debian stable lenny. On this
> >> LAN I have a NAS (readyNAS duo of Netgear). With my laptop with sid I
> >> don't have any problem at all to upload/download file from my NAS with
> >> ftp/cifs/NFS and with firestarter installed. But with my eeepc (with
> >> ethernet atl1c) I get one:
> >> - with firestarter installed
> >> - with an mtu set to 1492
> >> I can't download file from my NAS through ftp/cifs/NFS. But I can upload
> >> without problem.
> >>
> >> So I have a little bit researched on the problem:
> >> - with mtu of 1500 on my eeepc the problem disappears. even firestarter
> >> is installed.
> >> - the net.ipv4.tcp_timestamps value ist set to 0 by firestarter. When I
> >> force it to 1 it works out of the box even with an mtu of 1492.
> > 
> > Please provide packet captures for your download attempts.  Use
> > 'tcpdump -i eth0 -w eeepc.pcap' (as root) on the eeePC to create the
> > file 'eeepc.pcap' (and press ^C to stop).  If you can install tcpdump on
> > the NAS, please run 'tcpdump -i eth0 -w nas.pcap' there at the same
> > time.  You can use wireshark to review these files before sending them
> > to us.
> > 
> > Please also provide the firewall rules that firestarter generates
> > ('iptables -vnL' will print these)
> > 
> > Ben.
> > 
> 
> Hi,
> 
> I can't install tcpdump on the NAS. On the eeepc I did:
> I'm connecting on the nas with ftp -p.
> Then I'm switching directory.
> And finnaly I start a "get".
> nothing is done, so I do "ctrl+c" then bye.
> 
> The tcpdump is in the pb_NAS.txt file.

I asked for a packet capture, not the text output.  I can work with
this, but it's harder to browse through.

> I did "iptables -vnL" and the results are in iptables.log.

That all looks fine.

So we have:

> 14:24:39.874317 IP (tos 0x0, ttl 64, id 46792, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.4.57933 > 192.168.0.5.10021: S, cksum 0x1e6a (correct), 2487174152:2487174152(0) win 5808 <mss 1452>
> 14:24:39.874537 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.5.10021 > 192.168.0.4.57933: S, cksum 0x39f4 (correct), 619233108:619233108(0) ack 2487174153 win 5840 <mss 1460>

I infer that the eeePC is at 192.168.0.4 and the NAS as 192.168.0.5.

The eeePC's TCP stack is claiming that it can accept a maximum segment
size of 1452 (MTU of 1492 minus the size of TCP/IP headers) while the
NAS is claiming that it can accept a maximum segment size of 1460 which
implies it is using a MTU of 1500 rather than 1492 as your router told
it to use.

Now this first connection is an FTP control connection where only small
packets are transferred; let's skip ahead to where the data connection
is opened:

[...]
> 14:24:56.351789 IP (tos 0x0, ttl 64, id 54058, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.4.37713 > 192.168.0.5.10071: S, cksum 0xcfd4 (correct), 2746536434:2746536434(0) win 5808 <mss 1452>
> 14:24:56.351998 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.5.10071 > 192.168.0.4.37713: S, cksum 0x21e7 (correct), 624461948:624461948(0) ack 2746536435 win 5840 <mss 1460>

Same MSS values as before

> 14:24:56.352053 IP (tos 0x0, ttl 64, id 54059, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.37713 > 192.168.0.5.10071: ., cksum 0x39c4 (correct), ack 1 win 5808
> 14:24:56.352194 IP (tos 0x10, ttl 64, id 46824, offset 0, flags [DF], proto TCP (6), length 46) 192.168.0.4.57933 > 192.168.0.5.10021: P, cksum 0x817a (incorrect (-> 0xa226), 110:116(6) ack 649 win 5808
> 14:24:56.356708 IP (tos 0x0, ttl 64, id 54863, offset 0, flags [DF], proto TCP (6), length 94) 192.168.0.5.10021 > 192.168.0.4.57933: P 649:703(54) ack 116 win 5840
> 14:24:56.395281 IP (tos 0x10, ttl 64, id 46825, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.57933 > 192.168.0.5.10021: ., cksum 0x4ea0 (correct), ack 703 win 5808
> 14:24:56.669462 IP (tos 0x0, ttl 64, id 59330, offset 0, flags [DF], proto TCP (6), length 1484) 192.168.0.5.10071 > 192.168.0.4.37713: . 1461:2905(1444) ack 1 win 5840
> 14:24:56.669630 IP (tos 0x8, ttl 64, id 54060, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.37713 > 192.168.0.5.10071: ., cksum 0x39c4 (correct), ack 1 win 5808
> 14:24:56.670399 IP (tos 0x0, ttl 64, id 59332, offset 0, flags [DF], proto TCP (6), length 1484) 192.168.0.5.10071 > 192.168.0.4.37713: P 4365:5809(1444) ack 1 win 5840
> 14:24:56.670505 IP (tos 0x8, ttl 64, id 54061, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.37713 > 192.168.0.5.10071: ., cksum 0x39c4 (correct), ack 1 win 5808

We receive 2 packets with sequence numbers 1461:2905 and 4365:5809.

We can infer that 2 packets with sequence numbers 1:1461 and 2905:4365
have been dropped because they are over-length.  The NAS should never
have sent packets this long because the eeePC told it to use an MSS of
1452 bytes.

> 14:24:59.723621 IP (tos 0x0, ttl 64, id 59333, offset 0, flags [DF], proto TCP (6), length 1492) 192.168.0.5.10071 > 192.168.0.4.37713: . 1:1453(1452) ack 1 win 5840
> 14:24:59.723820 IP (tos 0x8, ttl 64, id 54062, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.4.37713 > 192.168.0.5.10071: ., cksum 0x28c0 (correct), ack 1453 win 8712
> 14:24:59.724468 IP (tos 0x0, ttl 64, id 59334, offset 0, flags [DF], proto TCP (6), length 1492) 192.168.0.5.10071 > 192.168.0.4.37713: . 1453:2905(1452) ack 1 win 5840
[...]

After a few seconds the NAS tries doing the right thing.  Hooray!
But then it goes back to sending over-length packets which get dropped.
And so it makes very slow progress (but it would eventually work).

So the TCP stack on the NAS:
1. Advertises an incorrect MSS
2. Sometimes ignores the peer's MSS (possibly because of 1)

TCP timestamps add a further 12 bytes to the TCP header length, so the
MSS is reduced further if they are enabled.  Possibly this also avoids
the bug in the TCP stack on the NAS.

In conclusion, sorry, this is not our bug.  And TCP timestamps are a
Good Thing, so you should go ahead and enable them.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: