netdev - Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080827184205.225a1b06@tux>
Date:	Wed, 27 Aug 2008 18:42:05 -0300
From:	Dâniel Fraga <fragabr@...il.com>
To:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
Cc:	David Miller <davem@...emloft.net>, thomas.jarosch@...ra2net.com,
	billfink@...dspring.com, Netdev <netdev@...r.kernel.org>,
	Patrick Hardy <kaber@...sh.net>,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility
 workaround

On Thu, 28 Aug 2008 00:25:31 +0300 (EEST)
"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:

> Sure, but that still doesn't explain at all why the expected traffic 
> doesn't show up anywhere (ie., the working mail after nmap resolution). 
> Such a router cannot prevent us tcpdumping both ends. My point is that we 
> would always see the packet at least in the sending end's tcpdump. And, 
> would we have the traffic from the end-point tcpdumps, we could trivially 
> figure out what the middlebox did to the traffic. 

	Ok.

> Agreed, it shouldn't happen. Do you have a static setup for the IPs or is 
> there dhcp component which could in theory cause some routing table 

	Static setup. But there were traces of a multipath config I
used before and completely forgot (below).

> alterations, again I find that unlikely but in the meantime I start to run 
> out of ideas how the client and server can speak with each other without 
> leaving any traces about it (I hope you really used exactly the tcpdump 
> command you told in the mail linking to those stall logs).

	Yes, you can believe me. Anyway, I disabled the eth1 interface.
And there's more! We never had 2 links on this server, although I was
always prepared to use multipath and ip route policy (since the plans
were to have 2 links). I had 2 commands which I suspect maybe could be
messing everything:

#ip rule add from ${link0} lookup 1
#ip route add 0/0 via ${gw0} table 1

#ip rule add from ${link1} lookup 2
#ip route add 0/0 via ${gw1} table 2

	I deleted all of this. I just use this if I had to links from
two ISPs and decided to load balance between them. As it isn't the
case...

> There's some NAT somewhere btw because the client uses 192.168.0.2 as 
> source address but I don't think that currently has some relevance (it 
> might timeout some connections after an idle period, which is usually
> of configurable length).

	Yes, in my client machine, I'm behind a D-Link 524 router.
Anyway, give me some days, I'll test with these new changes for a week
at least before confirming the problem was solved (and with both frto
and htb enabled).

	If it's really this old Mulitpath misconfiguration, I apologize
for my error and the length discussion. Anyway, it's good to register,
in the case someone do the same error as me.

	Well, let's wait to see if the problem has gone.

	Thank you very much.

-- 
--
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