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: <20080815183511.1c81be23@tux>
Date:	Fri, 15 Aug 2008 18:35:11 -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>, sr@...urenet.de,
	netfilter-devel@...r.kernel.org, kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility
 workaround

On Fri, 15 Aug 2008 10:06:39 +0300 (EEST)
"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi> wrote:

> I would be better to have tcpdump running at least a bit back (2-3 windows 
> back is long enough for me), but obviously that might not be possible 
> option because it occurs so rarely. ...It should be possible to have 
> tcpdump restarted once in a while to avoid a one huge log if you'd just 
> keep running tcpdump from beginning.

	Ok.

> What do you mean by "come back alive"...? ...In eth0 log I found this 

	I mean, it isn't stalled anymore. When it stalls, fetchnews
stops and stay stalled forever. When it come back alive, it resumes
(but it will only do that if I do something to restore the connection).

> connection 189.38.18.122.995 > 192.168.0.2.35477, the ip matches with 
> abusar's. But I'm not sure if the connection in the tunnel is the 
> interesting one, since it's going to/from port 119 but the ip addresses 
> (10.195.195.2 and 10.195.195.1) don't tell anything to me, I guess you 
> know their meaning (ie., if 10.195.195.2 is the one with which the 
> connection stalls)? ...You're probably right that this wasn't very useful 
> log, the longest "stall" I find is only 1.111328 seconds long (and it 
> might be due to some processing that is made by 10.195.195.2).

	Ok:

10.195.195.1 is my local VPN IP (tun1)

10.195.195.2 is the remote VPN IP (on the server)

192.168.0.2 is my local IP (eth0)

189.38.18.122 is the server's IP

	Should I use tcpdump on the server too or is it sufficient to
use on my client machine?

	Thank you very much 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