No ICMP response

[Gerald Vogt]

It seems as one of my computers is very resistenly refusing to answer
ICMP echos/pings. I've already tried many things but in vain. My guess
is the ICMP protocol might not be bound to the ethernet card but I have
no idea where to look.

Setup: 2 Laptops A & B, XP SP2, connected via router Linksys WRT54G. For
tests I have turned off the firewalls in XP. No other PFW installed, no
filtering whatsoever setup on the router, i.e. both laptops should be
completely naked. (The settings of the firewall are in my opinion
correct, but just to be sure I turned it off)

(ping from X to Y means: on X enter "ping <IP address of Y>")

Pings from A to router, A to B work.
Pings from B to router work.
Pings from router to B work.
Local pings on A (ping <own IP>) work.

Pings from B or router to A do not work.

ARP resolution between A, B and router works (arp -a shows the MAC
addresses).

Both A and B have internet connectivity through router, ie IP works.

A is supposed to share a directory to be accessed by B which does not
work at the moment either, but I suppose it is somehow related with the
ICMP problem for a start...

Any pointers or hints are appreciated?

Thanks,

Gerald

 

[Hans-Georg Michna]

A is supposed to share a directory to be accessed by B which does not
work at the moment either, but I suppose it is somehow related with the
ICMP problem for a start...

Gerald,

I cannot pinpoint the cause, but I can propose some tests.

One is to check all firewall settings and compare them. The
firewall has separate functions that are not necessarily all
disabled when you disable the firewall. Please read
http://www.michna.com/kb/WxSP2.htm#The_Service_Pack_2_firewall
for details.

Another is to remove shares entirely, then recreate them,
particularly the one that's giving you problems, but doing that
with all shares can sometimes help. For good measure, add a
reboot.

Hans-Georg

 

[Gerald Vogt]

One is to check all firewall settings and compare them. The
firewall has separate functions that are not necessarily all
disabled when you disable the firewall. Please read
http://www.michna.com/kb/WxSP2.htm#The_Service_Pack_2_firewall
for details.

Good idea. But I cannot find any hints at that place stating which
firewall functions are not disabled when I deactivate the firewall. I
deactivated both firewalls (on the General tab). Despite of being
deactivated, the settings of the firewall on both laptops are identical:
Filesharing is enabled on the Exceptions tab and ICMP echo is enabled on
the advanced tab with ICMP button as well as in the per-network
connection setting ICMP tab. Ping from the router is still not working...

Another is to remove shares entirely, then recreate them,
particularly the one that's giving you problems, but doing that
with all shares can sometimes help. For good measure, add a
reboot.

They don't work at all. Nothing goes through. It does not find the
computer in the network nor the shares. They only work locally on the
laptop itself.

Gerald

 

[Hans-Georg Michna]

Hans-Georg Michna wrote:

They don't work at all. Nothing goes through. It does not find the
computer in the network nor the shares. They only work locally on the
laptop itself.

Gerald,

did you remove the shares entirely, then recreate them?

Hans-Georg

 

[Gerald Vogt]

did you remove the shares entirely, then recreate them?

No, I did not. The ICMP is not working. That is my main concern right
now. I guess, once the ICMP is working again, the shares will do to.

Anyay, I now did remove the shares. I even deinstalled file sharing. I
reinstalled file sharing. I recreated the shares. I rebooted each time
inbetween. At any time and any occasion the same result: nothing.

The laptop does not allow anything incoming: no incoming ICMP, no
incoming TCP (telnet tested on 139 and 445), no incoming shares etc.
Firewall is turned off.
--
Gerald
Die neue deutsche Money-FAQ http://money.gvogt.de/

Software-Fingerprint:
01 fa 8c 7a f3 24 d7 f1 54 7b be 16 2a cc b0 61 27 15 91 71

 

[Hans-Georg Michna]

Gerald,

did the problem computer work before and stopped working or was
it newly set up and never worked after that?

How about third party software, like network-scanning antivirus
programs? Anything else that touches the network, like third
party configuration programs? Anything called AOL or Norton?

If none, the next point would be to go through the points in
http://www.michna.com/kb/wxnet.htm, particularly the Winsock,
then the IP stack repair procedures. It may even be an idea to
remove all networking software components, reboot, then set them
up again from scratch. The web site may bring up some more
points after you fill in the form.

Hans-Georg

 

[Gerald Vogt]

did the problem computer work before and stopped working or was
it newly set up and never worked after that?

It did work before and now it doesn't. It could coincide with SP2 but I
cannot say definitively as I have't tried it for a while...

How about third party software, like network-scanning antivirus
programs? Anything else that touches the network, like third
party configuration programs? Anything called AOL or Norton?

No. Nothing except Windows. No.

If none, the next point would be to go through the points in
http://www.michna.com/kb/wxnet.htm, particularly the Winsock,
then the IP stack repair procedures. It may even be an idea to
remove all networking software components, reboot, then set them
up again from scratch. The web site may bring up some more
points after you fill in the form.

Well, I will see. I don't really want to do brute force methods. I
really want to know how to figure out where the problem is.

Gerald

 

[Hans-Georg Michna]

Hans-Georg Michna wrote:

Well, I will see. I don't really want to do brute force methods. I
really want to know how to figure out where the problem is.

Gerald,

that web page also contains some purely diagnostic methods, for
example how to find out whether the Winsock is corrupted and
needs repair. It is usually simpler though to run the repair
anyway, as it takes only seconds.

Hans-Georg

 

[Gerald Vogt]

that web page also contains some purely diagnostic methods, for
example how to find out whether the Winsock is corrupted and
needs repair. It is usually simpler though to run the repair
anyway, as it takes only seconds.

Yes, and reconfigures the IP-stack in a way that the Palm HotSync
Manager does not work anymore and complains with an error message until
you reinstall the complete suite with all conduits.

Anyway, the problem was an installation of Cisco VPN Client which either
did not fully work (although the client and the system showed no
problems despite of this one here) as there were error messages in the
event log that TrueVector service could not be started (no I never had
ZoneAlarm) and second there was the "Deterministic Network Enhancer"
installed with the client. Deinstallation of the client did remove the
TrueVector files, solved the error messages in the log during startup
and removed the DNE. So either one or both must have been the problem
but for today I have enough as I roughly spent hours analyzing till
now... I'll see if I get it properly installed as it works on an other
laptop...
--
Gerald
Die neue deutsche Money-FAQ http://money.gvogt.de/

Software-Fingerprint:
01 fa 8c 7a f3 24 d7 f1 54 7b be 16 2a cc b0 61 27 15 91 71

 

[Hans-Georg Michna]

Hans-Georg Michna wrote:

Yes, and reconfigures the IP-stack in a way that the Palm HotSync
Manager does not work anymore and complains with an error message until
you reinstall the complete suite with all conduits.

Gerald,

sorry, at least the web site warns clearly of that and offers
the diagnosis. Or are you talking about the IP stack repair
procedure? I'd like to know because I constantly amend the web
site and will add your information for the benefit of future
solution seekers. -)

Anyway, the problem was an installation of Cisco VPN Client which either
did not fully work (although the client and the system showed no
problems despite of this one here) as there were error messages in the
event log that TrueVector service could not be started (no I never had
ZoneAlarm) and second there was the "Deterministic Network Enhancer"
installed with the client. Deinstallation of the client did remove the
TrueVector files, solved the error messages in the log during startup
and removed the DNE. So either one or both must have been the problem
but for today I have enough as I roughly spent hours analyzing till
now... I'll see if I get it properly installed as it works on an other
laptop...

Thanks for this information as well! I'll add this too, as I've
heard of it before.

Hans-Georg

 

[Gerald Vogt]

On Thu, 28 Oct 2004 17:23:03 +0900, Gerald Vogt
sorry, at least the web site warns clearly of that and offers
the diagnosis. Or are you talking about the IP stack repair
procedure? I'd like to know because I constantly amend the web
site and will add your information for the benefit of future
solution seekers. -)

I preferred not to download a program which I don't know but went after
the links to some Microsoft support pages, specifically to

http://support.microsoft.com/?kbid=811259

and deleted the registry keys and reinstalled the IP-stack. After that,
HotSync was gone...

Gerald

 

[Hans-Georg Michna]

I preferred not to download a program which I don't know but went after
the links to some Microsoft support pages, specifically to

http://support.microsoft.com/?kbid=811259

and deleted the registry keys and reinstalled the IP-stack. After that,
HotSync was gone...

Gerald,

ah, thanks a lot. I'll add this to the web site.

Hans-Georg

 

[zigi]

Gerald,

ah, thanks a lot. I'll add this to the web site.

Hans-Georg

Just a note...Issuing a ping from A to B, and having it suceed at A,
means that B is able to reply back to A, and the reply uses IP. So you
do have IP connectivity from B to A. I know some firewall s/w does
block incoming pings as a means to make a computer look
invisible..perhaps some remnant of a previous install. Try a different
interface (change wireless to wireline or wireline to wireless) and
see what happens..maybe the remnante is tied to a particular
interface.

 

[Gerald Vogt]

Just a note...Issuing a ping from A to B, and having it suceed at A,
means that B is able to reply back to A, and the reply uses IP. So you
do have IP connectivity from B to A. I know some firewall s/w does

This is incorrect depending what your understanding of IP is. A "ping a"
sends an ICMP packet and the reply is also an ICMP packet. Neither of
them technically uses IP which would make ICMP as "internet control
message protocol" useless because it would depend on the protocol it is
supposed to control and maintain.

Thus, being able to Ping B from A does show that you have connectivity
between A and B. This includes "B to A". The ping shows that packets are
able to go from A to B and from B to A.

Failure in either direction does again mean nothing in regard to
connectivity. You can have a proper connection and still it fails as at
either end or somewhere in between certain packets are dropped -
intentionally or unintentionally...

block incoming pings as a means to make a computer look
invisible..perhaps some remnant of a previous install. Try a different
interface (change wireless to wireline or wireline to wireless) and
see what happens..maybe the remnante is tied to a particular
interface.

Sometimes it does, sometimes not. In my case it did not.

Gerald

 

[zigi]

This is incorrect depending what your understanding of IP is. A "ping a"
sends an ICMP packet and the reply is also an ICMP packet. Neither of
them technically uses IP which would make ICMP as "internet control
message protocol" useless because it would depend on the protocol it is
supposed to control and maintain.

Thus, being able to Ping B from A does show that you have connectivity
between A and B. This includes "B to A". The ping shows that packets are
able to go from A to B and from B to A.

Failure in either direction does again mean nothing in regard to
connectivity. You can have a proper connection and still it fails as at
either end or somewhere in between certain packets are dropped -
intentionally or unintentionally...


Sometimes it does, sometimes not. In my case it did not.

Gerald

ICMP does use IP as the transport protocol. The IP header layout is
the same as for icmp, email, ftp etc. In the case of B pinging A, B
creates an IP packet with source IP address = B, destination IP
address = A, protocol type = ICMP, and the IP payload is the ICMP
message which indicates its a ping. IP is used to route the packet to
A. A's IP stack sees its an ICMP message, acts on the ping request and
returns the packet using IP, with source IP address = A, destination
IP address = B, protocol type = ICMP, and uses IP to route the packet
back to B. Google RFC 792 for more ifo.

 

[Gerald Vogt]

ICMP does use IP as the transport protocol. The IP header layout is

Again, this is incorrect. Let me quote the RFC:

"ICMP, uses the basic support of IP as if it were a higher
level protocol, however, ICMP is actually an integral part of IP, and
must be implemented by every IP module."

ICMP is part of IP. It is on the same level as IP. Nothing else is
possible if it is to manage IP. It cannot manage IP if it would depend
on the protocol it is supposed to manage. ICMP are IP packets with
special protocol number 1. It is a common misconception that ICMP is
built upon IP.

the same as for icmp, email, ftp etc. In the case of B pinging A, B
creates an IP packet with source IP address = B, destination IP
address = A, protocol type = ICMP, and the IP payload is the ICMP

email, ftp etc. are something completely different from ICMP or IP.
email, i.e. SMTP and all the other protocols are actually two layers
above IP. SMTP for example uses TCP connection that are implemented on
IP packets, i.e. SMTP is the payload of TCP packets and the TCP packets
are the payload of IP. ICMP is nothing like that. ICMP is a different
kind of IP packet for a specific purpose. Its payload (control
information) is not payload of an IP packet.

message which indicates its a ping. IP is used to route the packet to
A. A's IP stack sees its an ICMP message, acts on the ping request and

There exactly lies the diffence: "Normal" IP packets are routed to the
destination and are not checked for any other information than the
destination. ICMP packets however are different and do not work like
that. Just think about traceroute packets for a moment: they indicate
how many hops the packets should do and after the number of hops return
from the router wherever you are.

For the same reasons ICMP may usually be routed the same way as all the
other IP packets but even that is not necessarily so and can be handled
differently if required.

Gerald