Packets that are returned when TTL expires are not recieved

[Killeroo]

It seems nothing is recieved when we call RecvFrom:

PowerPing/src/PowerPing/Ping.cs

Line 301 in 615f78e

bytesRead = sock.ReceiveFrom(receiveBuffer, ref responseEP);

I tried changing responseEP to be IPAddress.Any and tried remove the guards around the socket but at the socket level it doesn't seem to be recieving the returned packet.

The returned packet seems to be in the correct format, could be a problem with the source address of the packet being different from what we expect (but I doudt this because Destination unreachable packets normally come from hosts that we don't expect and they are normally recieved. Needs more investigation, also returned packet contains a copy of the original packet, might be interesting to see how that should be handled. Listen function doesn't seem to see the returned packet either...

This fix is required to make traceroute work (#1).

[Meister1977]

I tried a lot of implementations, and can not get back the source address. What is interesting, if I use Windows tracert command, I see the TtlExpired messages in LIsten function. I don't know what is the difference.

[Killeroo]

Yeah I don't under stand why all other ping commands ttlexpired packets show up in the listen command and PowerPing's don't. I am starting to think the source address isn't the problem, it's something about the way PowerPing recieves the packets that is going wrong, but I am pretty stumped to be honest.

[Meister1977]

I think, it should be reported to the .net team. To be honest, I backported the ping from the current source code (5.0), the Unix version, because it uses raw socket, but those implementation does not work too.
I checked with Message Analyzer (same as wireshark), and I can see the same TTLExpired response, but it is not come up to the .net, I don't know why.

[Meister1977]

You won't believe it!
If I add a new firewall rule to Windows to allow all ICMP packets (inbound) it works immediately.

Seems to me, ping.exe and traceroute.exe has own rules for inbound ICMP package. So we cab see it in Wireshark, but the firewall drop the answer if it would go to a not-well-known program which is on the exception list of the firewall.

[Killeroo]

Wow @Meister1977 really good find! That does sound like a very likely cause. I will try and add some cursory code to request inbound ICMP access through the firewall (can be done as we are already running as administrator). Thanks alot for really looking into this, this issue has been bugging me a really long time.
(can hopefully get a traceroute function working as well if this works)

[Killeroo]

@Meister1977 Your solution does seem to work, annoyingly I can't seem to restrict the rule to just PowerPing, it only works when ICMPv4 packets for any program is specified. I think this might have something to do the way the .NET programs are actually run, I actually tried to only allow different .NET dlls but that didn't work either.

I am a bit torn about what to do, adding a blanket inbound rule to allow all ICMPv4 traffic through the firewall is possible and does work but it might be kind of rude to do this without user consent and limiting the inbound rule to just PowerPing doesn't seem possible.

I will add these changes in a seperate branch and might implement a yes no option to ask users if they want to open firewall access when a user tries to use traceroute or ttl commands.