From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 2FFB71381F3 for ; Sat, 7 Sep 2013 15:42:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8B643E0BBB; Sat, 7 Sep 2013 15:42:05 +0000 (UTC) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 34580E0AD5 for ; Sat, 7 Sep 2013 15:42:03 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ez12so1961414wid.8 for ; Sat, 07 Sep 2013 08:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=G+DR+gnT36GjSotHs5ruRhWh6EsR8Mbrggm7ab7yt78=; b=w8FejYgxgCRRASDngOxWPWyqcNTorNP6fFe6jNlYmwcyexSFLyQ5IIAskLqbL9C551 GU0Ibdt8ahK3ZoiGf3DqAWMNLvOF1yRC27P3mYLCfxahWSCmYHgvyBG1dfYQYnlN1ojN QJazJhbjOETrnNDjjVQb3MV40mCqqlWZNluV3Pv6xFxu7+8vLEr93LvWg2E0ENQQlJ69 z5gPfZAlDJJT/XC30n0lf02ZSdxfp8zwoIo8lcVz+0frKBzM7RMzhdZg9mHQbK06eF4m dKmc37jLlNP+FQdHpOy+i0w0MfwWmshnQjltOZ5aCHEsv6NqizZ2NAe7+RwthT4erDSu Qzhg== X-Received: by 10.181.11.163 with SMTP id ej3mr2403752wid.47.1378568522870; Sat, 07 Sep 2013 08:42:02 -0700 (PDT) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id fz8sm4441971wic.0.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Sep 2013 08:42:02 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Can't ping remote system Date: Sat, 7 Sep 2013 16:41:40 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.7-gentoo; KDE/4.10.5; x86_64; ; ) References: <201309031635.11591.michaelkintzios@gmail.com> In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4182006.4bPgor3YRp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201309071641.59772.michaelkintzios@gmail.com> X-Archives-Salt: ad27deb6-8a7a-486a-9923-a7e9b4811a51 X-Archives-Hash: aae68ce01980e7cb815b4a7e84189414 --nextPart4182006.4bPgor3YRp Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thursday 05 Sep 2013 14:17:14 Grant wrote: > > +1 on Alan's hunch. I have not used Squid to comment on the specifics > > and also Grant stated that another proxy gave him similar symptoms.=20 > > From my limited knowledge a proxy could be stalling because of cache > > configuration problems, like running out fs space, or inodes and also > > running out of memory if it has to process simultaneous requests from > > too many clients at a time. If the problem also manifests when the > > clients are within the same subnet, then this is unlikely to be a > > network issue. >=20 > Which hunch was that? I snipped a lot above but I couldn't find it in > there. It was Alan's statement that this problem is not related to your AT&T route= r. > It's just one user (me) and I've fiddled with the cache (including > disabling it) and at least fs space and memory are good. OK, this points away from your proxy configuration then. I noticed you=20 mentioning that the problem is manifested with a different proxy applicatio= n,=20 points to a network problem, unless the cache fs set up is exactly the same= =2E =20 As long as you have enough disk space and enough inodes, plus enough RAM, t= hen=20 all points to a network problem. > > If all other causes are eliminated then a network related problem could > > be associated with TCP Window Scaling - but this would primarily show up > > on the transmission of larger files. This is why I initially asked if > > the problem shows up on video/audio downloads rather than small web > > pages. I have to come back to this. I tried the www.google.com/nexus/ you mention= ed=20 and noticed that the page eats up 1.3MB to load fully, before it starts=20 downloading a flash video. So seems to be a relatively large amount of dat= a=20 that brings up this problem and this could point to tcp window scaling. > I've tried all of these with no noticeable change: >=20 > echo 0 > /proc/sys/net/ipv4/tcp_ecn > echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc This should be *disabled* (double negative). PMTU discovery is necessary i= f=20 any nodes are using smaller than the default 1500 byte ethernet MTU value. = So=20 you better set it as: echo 0 > /proc/sys/net/ipv4/ip_no_pmtu_disc > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling This is typically enabled, but if you notice that a connection stalls and t= hen=20 later on it works fine again, it could be related to a firewall/router not= =20 responding as it should to tcp_window_scaling. In this case disabling this= =20 would fix the problem when traversing problematic nodes. If you saw no difference, this suggests that window scaling is not an issue. > Not that anyone here should bother to read it, but here's a link to my > thread on the squid list where I tried all kinds of stuff: >=20 > http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-the-= en > tire-system-td4660893.html I read it and if the squid experts say it is a network problem, then it cou= ld=20 well be - although the network problems can be more difficult to diagnose a= nd=20 resolve. > I think at this point I'm hoping that putting the server's > modem/router into bridged mode so it will respond to pings will clear > this up. =20 Well, we don't *know* that the router is the cause of the problem - yet. =20 Setting it up in fully bridged mode and exposing your desktop directly to t= he=20 Internet will definitely eliminate the router, because it will only be deal= ing=20 with ATM packet encapsulation. > I think that's conceivable if the modem/router is also > failing to return Fragmentation Needed since its MTU is 1492. Testing > the proxy from within the server's LAN as you suggested in my other > thread could also be informative. Please let me know if there's > anything else I should try. I would start with the simplest tests first, which involve isolating suspec= t=20 system components one at a time. Trying to use the same laptop-desktop=20 machines within the LAN, takes the router out the equation - full 1500 byte= =20 MTU will be used by both laptop and desktop. If that works as intended then setting the router into fully bridged mode w= ill=20 eliminate that node and any problems that it may have with tcp window=20 extensions. Troubleshooting public nodes becomes more difficult, unless you happen to=20 travel around and use networks that bypass the suspect nodes. For all we k= now=20 it could be the particular hotel firewall/router that is causing the proble= m. =20 ;-) =2D-=20 Regards, Mick --nextPart4182006.4bPgor3YRp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAABAgAGBQJSK0lHAAoJELAdA+zwE4YeTpAH/iH7zRTU5GVBbMkL1HmZvLJc Zr/kNoU45LYyTTHnFrRopv1LD3yOmN+RWObxQWid7tnNLsX4WPEg0VlrK6IwvoWO O7frAJcQ7jPmRKN5RzHqOwV9tSEFaj625NepagNNaktnozRGs3pJeLs+A1nAGDhT ujx09Y1ylIZBWI1t0PRY2KA3woCc2FLpNZPK3nJGSGL/5xgZk9W2UMDhGnFeW02c pTQAJ5H/mvwIMbhrMbjNS07Br7JSosFl0F+SAncsU2qHwGaNSS5LJzOTiHlRkUfa OBz3Ou7CD7e6GfAffVTupCzxoif5fRNrIurafU6FKDSiC2gVJXUndsRBrW4vC88= =NO8i -----END PGP SIGNATURE----- --nextPart4182006.4bPgor3YRp--