From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-150338-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 8510A1381F3
for <garchives@archives.gentoo.org>; 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 <gentoo-user@lists.gentoo.org>; Tue, 3 Sep 2013 15:35:16 +0000 (UTC)
Received: by mail-we0-f178.google.com with SMTP id p58so970156wes.37
for <gentoo-user@lists.gentoo.org>; 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 <michaelkintzios@gmail.com>
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: <CAN0CFw3RRsYA2CF2qVaAN7hxcP-jqTqwYbTNDDSUc_BcqOWKLw@mail.gmail.com> <CAN0CFw0ffS=5bd1NQtfPfU3beF1=A0dOooZBdPmZmR1RPgeCFw@mail.gmail.com> <52257DB5.3090607@gmail.com>
In-Reply-To: <52257DB5.3090607@gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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--