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 8510A1381F3 for ; Tue, 3 Sep 2013 15:35:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4AAFEE0F19; Tue, 3 Sep 2013 15:35:18 +0000 (UTC) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F2FAFE0E60 for ; Tue, 3 Sep 2013 15:35:16 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id p58so970156wes.37 for ; Tue, 03 Sep 2013 08:35:15 -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=oYwRb4NNO6oaCv4lepI4XDmIljYTNmiALsjAKlwgxTk=; b=eG5BifQ7w02iQfIzLn2bQ/F90EPzbi5mxQMdfVKw0Ef0SOh8G8rbZtebz7GkvsAniI EzPLnR1ff+thiDLkf9/w2lIPBV0Jt4j5L5BZZOcXuotX/Ppxaoms4flx873UkuY+k83j ZhGG4D5zOtpPOAg+Ce/N9lKOXX3Fqagayvn8xniYrM4hI9lw/8n1qE3KZcknHNUg0QmX oE4x9crls3PH2c5FzE2yX/K0Nti/1+gypb9speX67rXlG8PaCB/59vKYQecyhsPHcxSV NQ5PAbICumB2NTOaKYz4SATPyzoXIfpIX+jw5ou5yKqnsDPZELRgNQC4fjM9V/BBIphJ e5QQ== X-Received: by 10.180.20.42 with SMTP id k10mr20441649wie.0.1378222515636; Tue, 03 Sep 2013 08:35:15 -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 dr11sm26575472wid.3.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 08:35:14 -0700 (PDT) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Can't ping remote system Date: Tue, 3 Sep 2013 16:35:01 +0100 User-Agent: KMail/1.13.7 (Linux/3.10.7-gentoo; KDE/4.10.5; x86_64; ; ) References: <52257DB5.3090607@gmail.com> In-Reply-To: <52257DB5.3090607@gmail.com> 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="nextPart4324968.etiFMKbqcP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201309031635.11591.michaelkintzios@gmail.com> X-Archives-Salt: 27688295-d552-484e-a68d-2177d4b208ed X-Archives-Hash: b62c99b8f9b5d9bba621689687165000 --nextPart4324968.etiFMKbqcP Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday 03 Sep 2013 07:12:05 Alan McKinnon wrote: > On 01/09/2013 20:50, Grant wrote: > >>>>>>>>>> My laptop can't ping my remote system but it can ping others > >>>>>>>>>> (google.com, yahoo.com, etc). I've tried disabling my firewall > >>>>>>>>>> on both ends with '/etc/init.d/shorewall stop && shorewall > >>>>>>>>>> clear'. Could my AT&T business ADSL connection on the remote > >>>>>>>>>> system be blocking inbound pings? > >>>>>=20 > >>>>> I did 'traceroute -w 30 -I ip-address' several times and the last IP > >>>>> displayed is always the same. I looked it up and it's an AT&T IP > >>>>> supposedly located about 1500 miles from my machine which is also on > >>>>> an AT&T connection. Does this tell me anything? > >>>>=20 > >>>> Yes, it tells you that all hops up to that point at least respond to > >>>> the kinds of icmp packets traceroute uses. The first hop that fails = to > >>>> answer isn't answering. > >>>>=20 > >>>> You are looking for possible reasons why icmp might not be working o= ut > >>>> properly - that router is your first suspect. Admittedly, it might be > >>>> blocking traceroute pings and still allow the responses you seek, but > >>>> you have to start somewhere :-) > >>>=20 > >>> So the culprit is the first IP that should appear in the list but > >>> doesn't? If so, how is that helpful since it's not displayed? > >>=20 > >> This is where it gets tricky. You identify the last router in the list > >> for which you have an address or name, and contact the NOC team for th= at > >> organization. Ask them for the next hop in routing for the destination > >> address you are trying to ping and hope that they will be kind enough = to > >> help you out. > >=20 > > Oh man that's funny. Really? Let's say they do pass along the info. > > Then I hunt down contact info for the culprit router based on its IP > > and tell them their stuff isn't working and hope they fix it? > > Actually, since the last IP displayed is from AT&T and my server's ISP > > is AT&T, I suppose it's extremely likely that the culprit is either an > > AT&T router somewhere or my own server and I could find out by calling > > AT&T. >=20 > Well, I did try to convey a sense of what it sometimes takes to deal > with such things. Usually your ISP deals with it for you and you'd be > amazed how often they pick up the phone to do exactly what I described. >=20 > But I think this is getting OT to your actual problem. AT&T's routers > are probably not the cause, it only came up because of issues with > pinging things, and that is not what you are trying to solve. +1 on Alan's hunch. I have not used Squid to comment on the specifics and= =20 also Grant stated that another proxy gave him similar symptoms. From my=20 limited knowledge a proxy could be stalling because of cache configuration= =20 problems, like running out fs space, or inodes and also running out of memo= ry=20 if it has to process simultaneous requests from too many clients at a time.= =20 If the problem also manifests when the clients are within the same subnet,= =20 then this is unlikely to be a network issue. If all other causes are eliminated then a network related problem could be= =20 associated with TCP Window Scaling - but this would primarily show up on th= e=20 transmission of larger files. This is why I initially asked if the problem= =20 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= )=20 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=20 indeed it may not be a problem in later kernels who may have been coded so = as=20 to compensate for dodgy routers. This will slow down the connection becaus= e a=20 smaller window size will be used, but there shouldn't be a problem of=20 oversized packets being dropped by a misconfigured router on the way. Shou= t=20 if you need more detail. =2D-=20 Regards, Mick --nextPart4324968.etiFMKbqcP 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) iQEcBAABAgAGBQJSJgGvAAoJELAdA+zwE4YegsoH/2itN9dlIjHJSehy0sDMmuPX XAkpLMmB8Dni+i0zxW/xW5f4kgiN0ijuu36axLwNmSUfYea0BfkcFfgoSm0jX1lH N2bECLDxBP6HSNfb87LHWsKJ8WHjoLaDPpD4AAWupsT6rskwnjeRac7iIwoNXzkf MRZ0XCjKBG4HXclcG/2ssJHGMdCrf9mnaXfH9xczxf8Jzg7bmtOJHZWccA9QYA1T jNjcSv/w39vsHWwnRzijBHPTe7F/VfAQMKegOsDYn075WVFGA1w2fqwZeWVZb8Ic REYhVJ+cz7tEL8oOt5Xnee40JDgVPzigVKDp5anGpUrYC1qX9QF9GiNrILnPzok= =2YiM -----END PGP SIGNATURE----- --nextPart4324968.etiFMKbqcP--