I’m reopening this issue just to report a similar head-scratching issue for the community:
I have encountered a scenario in which a network configuration that has literally worked for years all of a sudden failed in the strangest way: A ping to my FreeRTOS based unit would fail - UNTIL I opened wireshark and captured that interface! Both ICMP requests and responses were clearly visible AND the ping utility reported successful ICMP transactions. I closed wireshark - at that instance the ping requests would again fail.
As it turned out, this must have been a combination of two things: First, the PC submitting the ICMP requests and the unit answering were not in the same subnet, so I should have widened the subnet mask on the unit (the default gateway would not route correctly). I knew about that anyways, but the configuration gets changed infrequently, so at that time it had just slipped my mind. Thus, the expected behavior would have been for the unit not to respond at all until I would have remembered that.
But what about this really obnoxious wireshark issue? That’s the second issue: In the meantime I had enabled Microsoft’s virtualization engine (Hypervisor) and allowed it to virtualize the network adapter, so running ipconfig now yielded two network adapters, one of them being called V-Ethernet or something the like. There must be some kind of interference between this virtual driver and wireshark’s pcap driver that fed back on the routing. After disabling the Hypervisor, everything worked as expected.
That’s just to remind everybody (including myself) that it’s all software, and thus everything is prone to bugs and/or unexpected behavior if one little thing changes. It’s tempting to look for a problem like that in the target (because that’s the one we’re focussing on), but in truth it can be anywhere in the control flow.