Have any of you seen situations where the id in a ping reply does not match the id in the request? We've seen 4 occurrences this year. This is likely a Windows 7 bug but if it was ever seen I think it would be by this audience. The only web hit I found was one item about Windows 2000 back in 2003, and it didn't apply to our systems. 199 19.483937 10.234.10.113 10.234.10.25 ICMP 74 Echo (ping) request id=0x0001, seq=242/61952, ttl=128 200 19.484187 10.234.10.25 10.234.10.113 ICMP 74 Echo (ping) reply id=0x0100, seq=242/61952, ttl=128 When it occurs, it persists, but only between those two computers and only in one direction. The pinger can ping other systems fine, and the pingee can be pinged by other systems fine. The pingee can ping the pinger fine. Changing cabling, even eliminating routers and going direct, makes no difference. Nor does changing IP addresses. Nor does rebooting. It's been seen with different Ethernet hardware. The only solution we've found is to reload from the OS up. Capture on both sides simultaneously shows that it is the pingee changing the id at some level outside of wireshark. It causes our software to think that the pingee is unreachable. The .NET Ping class must be comparing ids, which seems correct to me. It has happened with both 32-bit and 64-bit pingees. A capture and my notes which points squarely at Internet Connection Sharing as the culprit. https://www.cloudshark.org/captures/4fadc0835230 Any Microsofties around who can look at the code? asked 14 Sep '15, 08:56  lordbah edited 30 Sep '15, 08:28 |
One Answer:
Notice that the reply ID, 0x0100, is exactly what you'd get if you reversed the two bytes of the request ID, 0x0001. I'd check the whole trace to see if that's always true: Whenever the IDs don't match, the bytes are reversed. If so, then it appears that there is some sort of bug on the reply system relating to network byte order. Wireshark will show you the ICMP Identifier field both ways in the Packet Details pane. In any case, this shouldn't be happening, so if these packets are correctly identified and the packet with ID 0x0100 really is a response to the ping with ID 0x0001, then there's probably nothing you can do unless the OS vendor already knows about this and has come up with a patch. answered 14 Sep '15, 12:51  Jim Aragon |
I did notice that. Initially I thought maybe it only occurred when 32-bit was pinging 64-bit, but later it happened with 32-to-32. When it is mismatched, it is always swapped like that in every reply to requests from that one requester, but the value is always 0001 from Win7 so there's not a wide range of examples. The really strange part is that when it gets this way, it'll only do it for replies to one pinger - other pingers get a non-swapped (i.e. correct) id in reply.
Based on sequence number matching and timing I believe it really is the matching reply.
Found a similar question at https://ask.wireshark.org/questions/3965/ping-packets-sent-received-yet-host-unreachable
In my case the NAT is being done by Windows Internet Connection Sharing. If the issue is the size of a table which maps ICMP ids, does anyone know how to change that size in ICS?