[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0810201319590.7072@wrl-59.cs.helsinki.fi>
Date: Mon, 20 Oct 2008 13:57:38 +0300 (EEST)
From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To: Jarek Poplawski <jarkao2@...il.com>
cc: olon@...izon.net, Netdev <netdev@...r.kernel.org>
Subject: Re: 2.6.27 seems to break something with DSL (fwd)
On Sat, 18 Oct 2008, Jarek Poplawski wrote:
> Olon wrote, On 10/17/2008 10:11 PM:
>
> > I can confirm this issue.
> > I'm using a westell dsl modem, and going from 2.6.26.5 to .27. I found that I
> > couldn't connect to most websites either.
> > This modem is in passthrough mode and not nat.
>
> Could you try this?:
> echo 0 > /proc/sys/net/ipv4/tcp_sack
>
> It looks like it helped in a similar problem here:
> http://bugzilla.kernel.org/show_bug.cgi?id=11721
In this case there are some other things as well... as connections get
successfully established...
Analysis of the case from tcp side:
gnu.org)
- Established ok, request (at least 2422 bytes) is sent and acked,
response never arrives (or tcpdump didn't get them)... Is this our
fault at all?
kernel.org)
2421 request sent and acked, then long delay and at :54.621879 we close
the socket (or the app exits), the response to fin indicates that ~2896
bytes were sent by the kernel.org but they never arrived (or for some
reason tcpdump didn't catch them). Is this our fault?
www.news.com)
Connection to 216.239.122.102 successful, working as expected (a quick
look only, no in depth check per field :-)).
Connection to 216.239.122.178, well, it's miserable... We send 2424 and
it gets acked. They send some with funny fragmentation (and 1:1461
missing anyway):
14:30:24.262465 IP (tos 0x0, ttl 245, id 22541, offset 0,
flags [+], proto: TCP (6), length: 764) 216.239.122.178.80 >
96.246.106.2.36303: P 1461:2185(724) ack 2424 win 27588
14:30:24.270508 IP (tos 0x0, ttl 245, id 22541, offset 744, flags [none],
proto: TCP (6), length: 756) 216.239.122.178 > ...
...which we'll respond (and probably queue that too into ofo queue) and
we ack 1 which is the right thing to do. ...and tcpdump is too short to
see retransmission of 1:1461 if they ever would come. Afaict we did
nothing wrong here...
Olon, please don't wrap lines next time if you include tcpdumps... :-)
--
i.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists