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.

I gave this a test.  The outbound "connection" version works nicely:

$ ./pasta --config-net socat STDIO UDP4:<gw address>:9999
Multiple default IPv4 routes, picked first
Multiple default IPv6 routes, picked first
qwer
2025/02/20 14:39:08 socat[1] E read(5, 0x55c12494f000, 8192): Connection refused

I also tried with an inbound "connection" to test the handling of
errors on listening sockets.  There I,

	1. Start a server in pasta
	2. Connect and write with a client on the host
	3. Kill the client
	4. Attempt to more data from the server

Without pasta in the way, this gives a similar Connection refused
error on the server socat.  With pasta in the way, it doesn't, even
with this patch.

Looking at an strace I suspect the problem is that the kernel doesn't
deliver EPOLLERR events to non-connect()ed sockets for ICMPs, so pasta
never knows to look for an error.  It think it works for plain socat,
because it - even in server mode - connect()s its socket.  pasta
doesn't however, and just sends the outbound packets via the original
"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.

-- 
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