1 |
On 01/09/2013 20:50, Grant wrote: |
2 |
>>>>>>>>>> My laptop can't ping my remote system but it can ping others |
3 |
>>>>>>>>>> (google.com, yahoo.com, etc). I've tried disabling my firewall on |
4 |
>>>>>>>>>> both ends with '/etc/init.d/shorewall stop && shorewall clear'. Could |
5 |
>>>>>>>>>> my AT&T business ADSL connection on the remote system be blocking |
6 |
>>>>>>>>>> inbound pings? |
7 |
>>>>> |
8 |
>>>>> I did 'traceroute -w 30 -I ip-address' several times and the last IP |
9 |
>>>>> displayed is always the same. I looked it up and it's an AT&T IP |
10 |
>>>>> supposedly located about 1500 miles from my machine which is also on |
11 |
>>>>> an AT&T connection. Does this tell me anything? |
12 |
>>>> |
13 |
>>>> Yes, it tells you that all hops up to that point at least respond to |
14 |
>>>> the kinds of icmp packets traceroute uses. The first hop that fails to |
15 |
>>>> answer isn't answering. |
16 |
>>>> |
17 |
>>>> You are looking for possible reasons why icmp might not be working out |
18 |
>>>> properly - that router is your first suspect. Admittedly, it might be |
19 |
>>>> blocking traceroute pings and still allow the responses you seek, but |
20 |
>>>> you have to start somewhere :-) |
21 |
>>> |
22 |
>>> So the culprit is the first IP that should appear in the list but |
23 |
>>> doesn't? If so, how is that helpful since it's not displayed? |
24 |
>> |
25 |
>> This is where it gets tricky. You identify the last router in the list |
26 |
>> for which you have an address or name, and contact the NOC team for that |
27 |
>> organization. Ask them for the next hop in routing for the destination |
28 |
>> address you are trying to ping and hope that they will be kind enough to |
29 |
>> help you out. |
30 |
> |
31 |
> Oh man that's funny. Really? Let's say they do pass along the info. |
32 |
> Then I hunt down contact info for the culprit router based on its IP |
33 |
> and tell them their stuff isn't working and hope they fix it? |
34 |
> Actually, since the last IP displayed is from AT&T and my server's ISP |
35 |
> is AT&T, I suppose it's extremely likely that the culprit is either an |
36 |
> AT&T router somewhere or my own server and I could find out by calling |
37 |
> AT&T. |
38 |
|
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 |
-- |
49 |
Alan McKinnon |
50 |
alan.mckinnon@×××××.com |