On Thu, Feb 20, 2025 at 11:08:28AM -0500, Jon Maloy wrote:On 2025-02-19 22:47, David Gibson wrote:I think that makes sense for now.On Wed, Feb 19, 2025 at 02:30:05PM -0500, Jon Maloy wrote:[...]Reconstruct incoming ICMP headers for failed UDP connect and forward back to local peer. v2: - Added patch breaking out udp header creation from function tap_udp4_send(). - Updated the ICMP creation by using the new function. - Added logics to find correct flow, depending on origin. - All done after feedback from David Gibson. v3: - More changes after feedback from David Gibson."listening" socket. The only way I can see to fix this would be to create connect()ed sockets for both ends of a flow when we establish it. I _think_ we can have the listening and connected socket concurrently (at least with REUSEADDR) with the connect()ed socket taking priority when it matches. However, it does have a complication: there's a brief time window between bind() and connect() on the new socket, when it might pick up packets that should go to the original listening socket. We'd need to decide what to do with that case. In any case, it kind of looks like there's not much point trying to handle error events on the listening socket (beyond a debug() message), since I'm not sure such events are ever delivered.I eliminated the handling of listener sockets ICMPs in my latest version.I can create a separate connected socket in a separate patch, if you agree that is the way to go.That's reasonable. Fwiw someone momentarily popped up on the IRC and suggested trying to read MSG_ERRQUEUE for the listening sockets on EPOLLIN events. I don't know if that will do anything useful, but you could try. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson