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? > >>>>> > >>>>> 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? > >>>> > >>>> 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. > >>>> > >>>> You are looking for possible reasons why icmp might not be working out > >>>> 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 :-) > >>> > >>> 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? > >> > >> 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 that > >> 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. > > > > 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. > > 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. > > 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 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. 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. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
