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 07BAC1381F3 for ; Thu, 5 Sep 2013 13:17:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4E4BE0F0D; Thu, 5 Sep 2013 13:17:16 +0000 (UTC) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9EDFCE0EE3 for ; Thu, 5 Sep 2013 13:17:15 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id u57so640647wes.39 for ; Thu, 05 Sep 2013 06:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eY8lY3p2tKQccFtvcpveuOQRdX3eE88EJFjLHAb4Y20=; b=n4l5pF/Yv/cKlJVLOTcRg3Uad0aq4NC6r80yEcO/PsOKo1hUUkHqF48lrR4S2/63SW wIAz3Kg+6KvKQUqlN+sr7dyc/5XJKhUlQCJO9TWfsQV+mqXHVvUbpIBq9Jl7yYc22I9W Kwh2KB5OTqeGo9gbH5QkO79hDZvDfRuUD78/n1z8jshFv8hXZRO151TFS0oD02mubJ4q TfvddUqe5dHN3HCd+1Sod+a67KowTM8A/m9KAKT+FmXIBpXA/k9YvxwtbaLO+5HMSh3K mt1nK2HS8aKWVZZqJYN7Io1v8AztV59ogVdIpdSoqcvaO2EkpDLyOxcL4yBzeZazRhzl BUug== 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 X-Received: by 10.180.20.42 with SMTP id k10mr6416396wie.0.1378387034309; Thu, 05 Sep 2013 06:17:14 -0700 (PDT) Received: by 10.194.93.199 with HTTP; Thu, 5 Sep 2013 06:17:14 -0700 (PDT) In-Reply-To: <201309031635.11591.michaelkintzios@gmail.com> References: <52257DB5.3090607@gmail.com> <201309031635.11591.michaelkintzios@gmail.com> Date: Thu, 5 Sep 2013 06:17:14 -0700 Message-ID: Subject: Re: [gentoo-user] Can't ping remote system From: Grant To: Gentoo mailing list Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: e922b11e-a435-40d4-b876-b37e36ef26f5 X-Archives-Hash: 4fa85d4789fc90dc4a32220c1311b876 > +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. 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. Which hunch was that? I snipped a lot above but I couldn't find it in there. 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. > 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. > > It's probably OT describing this problem here (Google can do it much better) > but a quick test would show if this solves the problem: > > echo 0 > /proc.sys/net/ipv4/tcp_default_window_scaling > > Please check the man page because this key may have changed over time and > indeed it may not be a problem in later kernels who may have been coded so as > to compensate for dodgy routers. This will slow down the connection because a > smaller window size will be used, but there shouldn't be a problem of > oversized packets being dropped by a misconfigured router on the way. Shout > if you need more detail. I've tried all of these with no noticeable change: echo 0 > /proc/sys/net/ipv4/tcp_ecn echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc echo 0 > /proc/sys/net/ipv4/tcp_window_scaling 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: http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-3-3-5-hangs-the-entire-system-td4660893.html 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. 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. - Grant