Ok, I think at least I got something with socat
- namely, the option fork
needs to be appended to the server line:
$ socat - udp4-listen:5000,reuseaddr,fork
... and then, in another terminal, we can call echo
piping into socat
client line multiple times on command line, as it will exit immediately (well, after half a second :)):
$ echo "hello" | socat - udp-sendto:127.0.0.1:5000
$ echo "hello" | socat - udp-sendto:127.0.0.1:5000
$ echo "hello" | socat - udp-sendto:127.0.0.1:5000
... and going back to the first terminal, we can see that the server has successfully shown all three hello
s:
$ socat - udp4-listen:5000,reuseaddr,fork
hello
hello
hello
^C
Note that even with a fork
-ed socat
server, the line echo "hello" | nc -u 127.0.0.1 5000
will still 'lock' as if waiting for user input; however, now after Ctrl-C and re-running the command, i.e.
$ echo "hello" | nc -u 127.0.0.1 5000
^C
$ echo "hello" | nc -u 127.0.0.1 5000
^C
$ echo "hello" | nc -u 127.0.0.1 5000
^C
... the fork
-ed socat
server will show three hello
s without the need to be restarted..
Seemingly, this openBSD netcat
doesn't have a fork
option - but I'm not sure if it has one that is corresponding to it..
Anyways, hope this helps someone,
Cheers!
Only if the source port of the original outgoing datagram was also port N, and if the NAT didn't choose to float the source port.
That is, the first UDP datagram from Machine A looks like this on your LAN:
Source IP: MachineAPrivate
Source Port: PortA <-- note this is typically different than the destination port
Destination IP: MachineBPublic
Destination Port: PortN
Then, after it is translated by the NAT in the outbound direction, it looks like this:
Source IP: NATPublic
Source Port: PortC <-- note this may or may not be the same as "PortA" above
Destination IP: MachineBPublic
Destination Port: PortN
Now, when Machine B replies, the reply typically looks like this:
Source IP: MachineBPublic
Source Port: PortN
Destination IP: NATPublic
Destination Port: PortC
Then, after it goes through the inbound NAT translation process:
Source IP: MachineBPublic
Source Port: PortN
Destination IP: MachineAPrivate
Destination Port: PortA
So, IF Machine A sends the frame from the same source port as the destination port ("Port N"), and IF the NAT is able to preserve that source port (i.e. it's configured to preserve source ports when possible, and that source port is not in use), THEN you can expect a reply to "Port N" to get back to Machine A.
Here's the authoritative reference on proper NAT UDP behavior:
RFC 4787 / BCP 127: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
Best Answer
So there are multiple things called netcat; ubuntu even has /etc/alternatives symbolic-link-hackery for it.
I think part of your problem is that UDP doesn't do sessions; I've copied in part of the file /usr/share/doc/netcat-traditional/README.gz below which does a pretty good job of explaining.
OK so maybe that's not all that great of an explanation but it's what I could find.
If you haven't yet, you might want to experiment with any netcat options you can find that would have to do with waiting... have you experimented with:
using -l as well as -u to ensure you're in "listening" mode
-vv to see exactly what's happening
-q -1 ...which should "wait forever" even after receiving EOF (hopefully, listening again?)