ICMP echo requests are not sent while receiving "Destination Unreachable" packets
I am working on a network management application that manages hosts using ICMP over BSD ( sendto
) sockets .
My question is not how to do this, it actually works very well. It seems that I am only running into an issue where the target host is sending unreachable Destination messages to the management server while I am trying to send an ICMP echo request to that host.
When a host is added to the management application, it will be tested using the specified ICMP ping, and at the same time it will start to "open", testing various ports on the host such as SNMP (161), etc., using the appropriate protocols.
Now I know that it doesn't make sense to perform this "discovery" on a host where I don't know if it exists or is responding (i.e. it sent an ICMP echo reply), but for this question it is key. Let's also assume that the hosts in question are indeed reachable and respond to ICMP signals, for example. via the command line ping
.
"Opening" eventually causes some ICMP "Destination unreachable: Port unreachable" packets to be sent back to the management server, for example. when there is no SNMP agent on the target host and port 161 is essentially unavailable.
This is fine, but for some reason it prevents the ICMP socket from sending an ICMP echo request to that host, which is required for ICMP ping. Since this request is never sent, my application does not receive a response and the host will be considered "unreachable" after some time (timeout).
I have analyzed the network traffic using Wireshark so I can tell that no ICMP echo request is sent to the target host. The application I am working in also has a "poll status" feature that can be used to "manually" execute another ICMP request on that host. If this is used after the host has been added (i.e. no more destination packets are available), the echo request is sent without any problem.
I am puzzled that the ICMP echo request is not being sent in the situation described above. I have another ICMP socket that accepts all incoming ICMP packets (in order to react to responses), but it shouldn't affect the sending socket, right? There is no reaction in my code defined for unreachable Destination messages, they are simply ignored, so I am very confident that this is not my own code that disables sending the request.
In fact, the function sendto
responsible for sending the request gets executed (after making sure of this by debugging) and even returns success (the number of bytes sent), but the packet is not actually sent. I can reproduce this on both Windows and Linux systems, so I don't believe this is an operating system issue.
Disabling "discovery" which causes messages to be sent out of the reach of the recipients makes everything fine again, so I'm pretty sure these are the messages that interfere with the ICMP echo request. The big question that I cannot find an answer to is: Why is this?
I can provide additional information if needed, however, I am afraid that I am not allowed to post any code here because it is a commercial product. However, the code is nothing special, just sending and receiving ICMP (IPv4) packets with TOS=0
and TTL=64
using raw ICMP sockets.
source to share
Dest unreachable is generated by the router, or if you are pinging on the local network it will be generated by the local host.
I assume your observation is due to the fact that you pinged on the local network. The fact that ICMP-3 is generated means that the ARP lookup failed, without the ARP lookup you actually cannot send the packet because you do not know the target MAC address. That explained everything.
So, anyway, you just have to wait for a fixed amount of time, like a second, and declare that the host doesn't exist, it doesn't matter if the packet is sent.