This is our old Q&A Site. Please post any new questions and answers at

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 ICMP 74 Echo (ping) request id=0x0001, seq=242/61952, ttl=128 200 19.484187 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.

Any Microsofties around who can look at the code?

asked 14 Sep '15, 08:56

lordbah's gravatar image

accept rate: 0%

edited 30 Sep '15, 08:28

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.

permanent link

answered 14 Sep '15, 12:51

Jim%20Aragon's gravatar image

Jim Aragon
accept rate: 24%

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.

(14 Sep '15, 13:08) lordbah

Found a similar question at

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?

(29 Sep '15, 08:18) lordbah
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 14 Sep '15, 08:56

question was seen: 3,235 times

last updated: 30 Sep '15, 08:28

p​o​w​e​r​e​d by O​S​Q​A