Testing UDP port connectivity
Solution 1:
To test if udp port is responding, use netcat.
An example from the man page:
nc -v -u -z -w 3 example.host 20-30
Send UDP packets to ports 20-30 of example.host, and report which ones
did not respond with an ICMP packet after three seconds.
Of course, if a firewall is DROPing, which is normally the case when dealing with internet-faced gateways, you won't receive an ICMP response.
Solution 2:
There is no such thing as an "open" UDP port, at least not in the sense most people are used to think (which is answering something like "OK, I've accepted your connection"). UDP is session-less, so "a port" (read: the UDP protocol in the operating system IP stack) will never respond "success" on its own.
UDP ports only have two states: listening or not. That usually translates to "having a socket open on it by a process" or "not having any socket open". The latter case should be easy to detect since the system should respond with an ICMP Destination Unreachable packet with code=3 (Port unreachable). Unfortunately many firewalls could drop those packets so if you don't get anything back you don't know for sure if the port is in this state or not. And let's not forget that ICMP is session-less too and doesn't do retransmissions: the Port Unreachable packet could very well be lost somewhere on the net.
A UDP port in the "listening" state may not respond at all (the process listening on it just receives the packet and doesn't transmit anything) or it could send something back (if the process does act upon reception and if it acts by responding via UDP to the original sender IP:port). So again, you never know for sure what's the state if you don't get anything back.
You say you can have control of the receiving host: that makes you able to construct your own protocol to check UDP port reachability: just put a process on the receiving host that'll listen on the given UDP port and respond back (or send you an email, or just freak out and unlink() everything on the host file system... anything that'll trigger your attention will do).
Solution 3:
- both on client ans server install nc:
yum install nc(for centos) - on server listen UDP port:
nc -ul 6111 - on client
nc -u <server> 6111 - type anything on client and hit enter - you should see this text on server
Note: When you run the nc -ul command on the server, it will only connect for the first connection coming to it. You can't, as I found out, switch between servers pinging it without stopping and restarting nc -ul. In fact, if you ^C stop the client (nc -u ...), you also cannot restart the client without first restarting the server listener.
Solution 4:
I was having a similar issue and found a good solution using netcat here: http://en.wikipedia.org/wiki/Netcat#Test_if_UDP_port_is_open:_simple_UDP_server_and_client
nc -vzu <host> <port>
I was able to confirm my UDP port was open and then could proceed to testing my actual code.
Solution 5:
Testing open UDP ports with nmap is fraught with perils -- there's no three-way handshake to indicate openness. Unless the listening process responds to whatever nmap sends, there's no way for nmap to differentiate between an open port that isn't responding and a filtered port.
Much easier is just to listen on one end with netcat and use netcat at the other end to send packets, and see they arrive at the other end. Do it both ways just be sure. You can also tcpdump to see the packets getting to where they need to go.