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: <20080827175012.580efae1@tux>
Date:	Wed, 27 Aug 2008 17:50:12 -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 Wed, 27 Aug 2008 23:32:34 +0300 (EEST)
"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:

> Ok. Though this all opens more questions than answers... :-(, why isn't 
> there any traffic in neither of the tcpdumps then (not in the client's
> nor in the server's).

	Very strange. In this topic, I saw the discussion about some
routers messing with traffic and frto related stuff, right? My server
is behind some routers that I don't know (because it's not me who
controls these routers). So if the problem is with some of these
routers, I'm afraid we can do nothing about that.

> I don't think it was bad at all... :-) I just meant that there wasn't any 
> other visible traffic, which is very very strange because nothing port 995 
> related (or anything else) seems to happen during the nmap... Which 
> network interfaces the server has? Could things get routed through some 
> other iface during the time of trouble (and during the nmap solution), 
> that would explain why it isn't visible in the tcpdump which is for the 
> specific interface.

fraga@...eporto ~$ ip route list
10.1.0.6 dev tun2  proto kernel  scope link  src 10.1.0.5 
10.195.195.1 dev tun1  proto kernel  scope link  src 10.195.195.2 
192.168.102.0/24 via 10.1.0.6 dev tun2 
200.211.201.0/24 dev eth1  proto kernel  scope link  src
200.211.201.248 189.38.0.0/16 dev eth0  proto kernel  scope link  src
189.38.18.122 default via 189.38.18.121 dev eth0 

	Well, if that's the problem I'll be very ashamed for wasting
your time. Anyway, eveything should go to eth0 interface, through
189.38.18.121 gateway.

	The eth1 interface (200.211.201.248) is an old interface which
we do not use anymore. So I'm right now deactivating it (I should do
that for a long time ago). Let's see if the problem remains or not
(although I have other servers with multiple interfaces and everything
is fine, since, as far as I understand, what matters is the default
gateway -- I think that there's no reason to Linux send something to
eth1 interface since there's only one default gateway).

	Anyway I'm dropping eth1 interface. I'll wait a few days before
confirming if that's the problem or not.

	Thanks again.

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