linux - Netcat stops listening for UDP traffic

08
2013-08
  • heavyd

    I am using netcat on some Linux machines (see this other question), but seeing some unexpected behavior.

    Unlike the guide in the accepted answer, I am not using UDP tunneling to do DNS queries. I have a remote server that I can log into, but not install software on, and I'm trying to tunnel UDP traffic from my computer to the server, and then setup a separate tunnel to send UDP responses back from the server to my machine.

    The tunnel going from my machine to the server is working perfectly, however on the server side, the instance of netcat that is listening for the response from the UDP server will close the listener after receiving the first response. So I can send a request and get 1 response back, but any subsequent requests make it to the server okay but responses are not received. Using netstat I can see that before the response is received netcat is listening, but the port is then closed after the response is received.

    The netcat instance on my machine seems to handle everything just fine. Both machines are running netcat v1.10-38. Any ideas what is going on?

    • Answers
  • pbr

    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.

    UDP connections are opened instead of TCP when -u is specified. These aren't really "connections" per se since UDP is a connectionless protocol, although netcat does internally use the "connected UDP socket" mechanism that most kernels support. Although netcat claims that an outgoing UDP connection is "open" immediately, no data is sent until something is read from standard input. Only thereafter is it possible to determine whether there really is a UDP server on the other end, and often you just can't tell. Most UDP protocols use timeouts and retries to do their thing and in many cases won't bother answering at all, so you should specify a timeout and hope for the best. You will get more out of UDP connections if standard input is fed from a source of data that looks like various kinds of server requests.

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


    • Related Question

    linux - Sending file via netcat
  • Phil

    I'm using something like this to send file from one computer to another:

    To serve file (on computer A):

    cat something.zip | nc -l -p 1234

    To receive file (on computer B):

    netcat server.ip.here. 1234 > something.zip

    My question is... can I do the opposite? Let's say I have file on computer B and I want to send it to A but not the way I wrote above, but by making computer that's supposed to receive file (A) be 'listening' server and connect computer that's 'sending' file (B) to server and send the file? Is it possible? I think it might be but I'm not sure how to do this.

    In case my above explanation is messed up: How do I send file TO 'server' instead of serving the file on server and then taking it FROM it (like I did above)?


    • Related Answers
  • martinwguy

    On your server (A): 

    nc -l -p 1234 -q 1 > something.zip < /dev/null
    On your "sender client" (B): 
    cat something.zip | netcat server.ip.here 1234

  • DaveParillo

    Start another instance of netcat on computer B. Just do what you did on computer A, but serve it from B. Give the new server a new port.