Bug#478062: This has a work around
Ah, there were some other bug reports as well to discover...
On Tue, 6 May 2008, Damon L. Chesser wrote:
> I received an email from Ilpo Järvinen asking me to set F-RTO to off in
> sysctl. I could not get the syntax right in that file to boot with that
> option off so I ran
> echo 0 >/proc/sys/net/ipv4/tcp_frto and I then ran a test page through the
> cups web front end. It printed.
The command you used was exactly what I was asking for (I don't know what
else you expected to work). :-)
So the problem was 100% reproducable for you with FRTO (I'm still catching
up the details here :-))?
> I don't know who Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> is, but a quick
> google shows he appears to be a kernel developer.
Yeah, you found out a right one. :-)
I suspect there's some corner case which might be buggy in kernel, but
there are other possibilities currently as well. I'd like to get this
fixed if it's a kernel bug, and think about work-arounds if it seems to be
elsewhere (end-point or middlebox). It might be that those devices just
blantantly discard any out-of-order segments, it could explain this kind
of phenomena, but we'll soon see what's doing.
> What exactly do you want me to do to assist you pinning this down? I
> know the
> words "tcpdump" but I never ran it, it looks like you want me to run
> tcpdump -some switches. After perusing the man file, I thought it best to
> just ask you what options would be best to be run. Keep in mind I have one
> box on my net that is running a vpn to a business that I do NOT want sniffed,
> so I would think that host printerIP would be best?
Thanks a lot for the help. Yes, it's possible to get basically all
unrelated things filtered out, and I'm ok even with a log that has
IP-addresses anonymized (e.g., with sed afterwards) if you feel a need
to do so.
Turn FRTO back on (set the tcp_frto to 2). Then run this command (as
superuser):
tcpdump -i <interface> -w frtoprob.log host <printerip> and host <localinterfaceip>
...That will exclude everything else but stuff between the relevant hosts,
you will get a file called frtoprob.log. Please change those <>-marked
parts so that they match you setup. I suppose that printerip should be
192.168.200.150 for your case (based on debian bug). ...Then just
reproduce the problem.
Please wait at least minutes before ctrl-c:ing the tcpdump! If you really
want to capture the whole flow, you can keep the tcpdump running until the
connection between <localinterfaceip> and <printerip> has disappeared
from netstat's output (might take considerable amount of time, 20mins or
so if it slowly makes progress whole the time), though I think I can
determine the problem pattern with somewhat less than that, e.g., 5mins
during the problem should probably be enough.
You can evaluate the generated log afterwards with tcpdump -r frtoprob.log
(superuser rights are no longer mandatory, as long as the generated log
file is accessable for an ordinary user). I'd like a verbose log, use this
cmd:
tcpdump -tt -vvv -n -r frtoprob.log > frtoprob.txt
(You could add
| sed -e 's|<printerip>|prnt|g' -e 's|<localifaceip>|myip|g'
there before redirection if you would want to hide the ip addresses too,
but since you have one in debian bug too, I suspect you don't feel that
necessary).
Send what is in the frtoprob.txt, preferrable in such format that there
won't be extra newlines (yes, the lines are long) :-). The generated
output doesn't contain even any payload between the printer and your
machine, just protocol headers printed out (the binary dump would contain
part of the payload), not to speak of anything between any other hosts.
...I hope I wasn't overly verbose here. :-)
I suppose you're willing to test some kernel patch as well if that becomes
necessary?
--
i.
Reply to: