| 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
| ||
|
Message-ID: <4FBBC5CB.20201@hp.com> Date: Tue, 22 May 2012 09:58:51 -0700 From: Rick Jones <rick.jones2@...com> To: Miklos Szeredi <miklos@...redi.hu> CC: Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: tcp timestamp issues with google servers On 05/22/2012 08:54 AM, Miklos Szeredi wrote: > Eric Dumazet<eric.dumazet@...il.com> writes: > >> On Tue, 2012-05-22 at 17:25 +0200, Miklos Szeredi wrote: >> >>> So it appears. The IP address is certainly registered to Google. >> >> Good, but you could have a middlebox doing transparent proxying. >> >> The SYNACK could be send by this box. > > Okay. Is there a way to find out whether there is a middlebox or not? The source IP in the trace was a 192.168 IP - is it possible/desirable to reproduce the problem without the device doing NAT in the path? What is your "public" IP address? Given that, and the IP address to which you are connecting, it should be possible to validate the RTT you are seeing. If the geographic/topological location of the destination Google IP address is far enough from your public source IP that would show whether the RTT you are seeing is even physically possible and so could suggest there is a middlebox (other than your NAT), though it couldn't show there was not a middlebox. rick jones -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists