Le mardi 06 décembre 2011 à 05:21 +0000, Debian Bug Tracking System a
écrit :
> This is an automatic notification regarding your Bug report
> which was filed against the linux-2.6 package:
>
> #594676: linux-image-2.6-amd64: Files Download Pb with the atl1c module and
> my ReadyNAS
>
> It has been closed by Ben Hutchings <b...@decadent.org.uk>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings
> <b...@decadent.org.uk> by
> replying to this email.
>
>
> pièce jointe message de courriel
> > -------- Message transféré --------
> > De: Ben Hutchings <b...@decadent.org.uk>
> > À: 594676-d...@bugs.debian.org
> > Sujet: Re: Files Download Pb with the atl1c module and my ReadyNAS
> > Date: Tue, 06 Dec 2011 05:18:18 +0000
> >
> > 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.
> >
> pièce jointe message de courriel
> > -------- Message transféré --------
> > De: giggz <giggzounets...@googlemail.com>
> > À: Debian Bug Tracking System <sub...@bugs.debian.org>
> > Sujet: linux-image-2.6-amd64: Files Download Pb with the atl1c
> > module and my ReadyNAS
> > Date: Sat, 28 Aug 2010 11:23:23 +0200
> >
> > 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
> >
> >
Ok Thx for your detailed answer!
Regards,
GiGGz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
