That is motivated by debugging SCUM game which could not connect to MP servers most of the time (while the game currently has some other blocking issue before that I believe this is generally useful). The game uses iphlpapi.IcmpSendEcho() for hundreds of servers. When the game fails to connect to (official) server that happens on network level, there are ICMP errors for TCP connection attempts (as seen through Wireshark). Those state that a packet was administratively filtered (while at another moment ping to that address from command line works). That doesn't happen (or doesn't happen that easily) on Windows or when allowing raw sockets for Wine with setcap(). Those errors come from some remote host (possibly intermediate). That seems to be triggered by a big amount of ICMP requests sent through IcmpSendEcho. The only solid difference I could find between ICMP over dgram vs Windows / Wine raw sockets is that ICMP packet id is constant on Windows (that is always 0001) and on Wine / raw sockets (nsiproxy process id). While with Linux ping sockets that id is set by the kernel to the UDP port number kernel assigned to the ping socket. Currently we create a separate socket for each ping request resulting in ever-changing id. Reusing the socket (s o it is bound to the same address and id is constant) seems to largely help the issue and it is possible to connect to servers (while refreshing server list a couple of times can trigger the issue again, while I could also reproduce that on Windows). While I don't know for sure, maybe that is some anti-DDOS filter which is sensitive to packet details and starts rejecting packets based on unusual contents. So the first 5 patches end up redesigning ICMP requests in nsiproxy.sys so that the socket is reused when possible. I believe that is overall beneficial: * besides more compatible ICMP packets, reusing sockets avoids allocating of UDP ports for each request which may result in hundreds of ports used concurrently; * removes extra unneeded threads, all the Unix side socket polling is done through one now and PE-side requests work with RegisterWaitForSingleObject; * Probably simplifies the thing a bit: remove 3 of 5 Unix calls related to ICMP, makes PE side code and IRP cancelling more straightforward. Then, currently ping sockets only work for echo replies while icmp error packets are not delivered for such sockets through normal recvmsg(). However, that can be retrieved using IP_RECVERR / IPV6_RECVERR msg. Ping sockets have special behaviour when MSG_ERRQUEUE is used and error packet is available: it will return original echo packet as the data received from recvmsg (that is needed to match the error packet to request and similar to what is available in raw icmp reply like that, just without reply IP packet header) and ICMP error type and code in 'struct sock_extended_err'. The last patch implements proper ICMP error reporting on ping sockets. Unfortunately I could not find anywhere reliable way to test that, whether these packets ever arrive depends on a lot of things in source and destination network configuration. I tested that locally by rejecting ICMP packets on [localhost](http://localhost) through ip\[6\]tables and verified how that works in game which receives those ICMP errors on various occasions (and it seems that delivering those insteading of timing out helps a bit additionally). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10954#note_140723