1 |
On Tuesday 03 Sep 2013 07:12:05 Alan McKinnon wrote: |
2 |
> On 01/09/2013 20:50, Grant wrote: |
3 |
> >>>>>>>>>> My laptop can't ping my remote system but it can ping others |
4 |
> >>>>>>>>>> (google.com, yahoo.com, etc). I've tried disabling my firewall |
5 |
> >>>>>>>>>> on both ends with '/etc/init.d/shorewall stop && shorewall |
6 |
> >>>>>>>>>> clear'. Could my AT&T business ADSL connection on the remote |
7 |
> >>>>>>>>>> system be blocking inbound pings? |
8 |
> >>>>> |
9 |
> >>>>> I did 'traceroute -w 30 -I ip-address' several times and the last IP |
10 |
> >>>>> displayed is always the same. I looked it up and it's an AT&T IP |
11 |
> >>>>> supposedly located about 1500 miles from my machine which is also on |
12 |
> >>>>> an AT&T connection. Does this tell me anything? |
13 |
> >>>> |
14 |
> >>>> Yes, it tells you that all hops up to that point at least respond to |
15 |
> >>>> the kinds of icmp packets traceroute uses. The first hop that fails to |
16 |
> >>>> answer isn't answering. |
17 |
> >>>> |
18 |
> >>>> You are looking for possible reasons why icmp might not be working out |
19 |
> >>>> properly - that router is your first suspect. Admittedly, it might be |
20 |
> >>>> blocking traceroute pings and still allow the responses you seek, but |
21 |
> >>>> you have to start somewhere :-) |
22 |
> >>> |
23 |
> >>> So the culprit is the first IP that should appear in the list but |
24 |
> >>> doesn't? If so, how is that helpful since it's not displayed? |
25 |
> >> |
26 |
> >> This is where it gets tricky. You identify the last router in the list |
27 |
> >> for which you have an address or name, and contact the NOC team for that |
28 |
> >> organization. Ask them for the next hop in routing for the destination |
29 |
> >> address you are trying to ping and hope that they will be kind enough to |
30 |
> >> help you out. |
31 |
> > |
32 |
> > Oh man that's funny. Really? Let's say they do pass along the info. |
33 |
> > Then I hunt down contact info for the culprit router based on its IP |
34 |
> > and tell them their stuff isn't working and hope they fix it? |
35 |
> > Actually, since the last IP displayed is from AT&T and my server's ISP |
36 |
> > is AT&T, I suppose it's extremely likely that the culprit is either an |
37 |
> > AT&T router somewhere or my own server and I could find out by calling |
38 |
> > AT&T. |
39 |
> |
40 |
> Well, I did try to convey a sense of what it sometimes takes to deal |
41 |
> with such things. Usually your ISP deals with it for you and you'd be |
42 |
> amazed how often they pick up the phone to do exactly what I described. |
43 |
> |
44 |
> But I think this is getting OT to your actual problem. AT&T's routers |
45 |
> are probably not the cause, it only came up because of issues with |
46 |
> pinging things, and that is not what you are trying to solve. |
47 |
|
48 |
+1 on Alan's hunch. I have not used Squid to comment on the specifics and |
49 |
also Grant stated that another proxy gave him similar symptoms. From my |
50 |
limited knowledge a proxy could be stalling because of cache configuration |
51 |
problems, like running out fs space, or inodes and also running out of memory |
52 |
if it has to process simultaneous requests from too many clients at a time. |
53 |
If the problem also manifests when the clients are within the same subnet, |
54 |
then this is unlikely to be a network issue. |
55 |
|
56 |
If all other causes are eliminated then a network related problem could be |
57 |
associated with TCP Window Scaling - but this would primarily show up on the |
58 |
transmission of larger files. This is why I initially asked if the problem |
59 |
shows up on video/audio downloads rather than small web pages. |
60 |
|
61 |
It's probably OT describing this problem here (Google can do it much better) |
62 |
but a quick test would show if this solves the problem: |
63 |
|
64 |
echo 0 > /proc.sys/net/ipv4/tcp_default_window_scaling |
65 |
|
66 |
Please check the man page because this key may have changed over time and |
67 |
indeed it may not be a problem in later kernels who may have been coded so as |
68 |
to compensate for dodgy routers. This will slow down the connection because a |
69 |
smaller window size will be used, but there shouldn't be a problem of |
70 |
oversized packets being dropped by a misconfigured router on the way. Shout |
71 |
if you need more detail. |
72 |
-- |
73 |
Regards, |
74 |
Mick |