Great to hear. Do you have a pointers to any sample code that handles BSD socket connections that are able to process both the UDP datagrams and potential returned ICMP packets? Are you suggesting we could achieve the same for TCP connections at the BSD socket level as an interim solution until they are addressed in the Network Framework?

Great appreciate the team's consideration. How can we stay in the loop of any progress on the UDP / ICMP support as if this is likely to drop sooner we could look at this as an interim step?

Thanks for your follow up Quinn and happy to hear our timing on this issue is spot on. Just to clarify our use case is related to the original post in our lack of ability to be notified / process ICMP messages but it does differ in the fact we are currently using a TCP connection and wanting to process any potential TTL exceeded ICMP packets that are returned in transit to our target host. Currently our only way to know this situation has occurred is the receipt of the following error state which is not very deterministic: error: The operation couldn’t be completed. (Network.NWError error 0.) Ideally we need to be notified on the receipt of (and type of) the ICMP packet along with the details of the source host to responded with the TTL exceeded in our case. I have included more detail in the suggested bug ticket I just raised. (FB12118366). Thanks!

Hey @Zona wondering if you ever found a resolution to this as we can chasing a similar solution. It appears the current APIs offered by NWConnection don't allow you to monitor for returned ICMP messages potentially returned on a TCP connection.

Was this enhancement to the NWConnection framework ever considered? We also have the requirement to understand when a connection fails and the target emits an ICMP error message to be able to parse this message and failure state. Does this otherwise force us back to implementing the same using BSD sockets so both a TCP connection and the potential resulting ICMP messages can be processed?