0

I've got three servers, "a", "b" and "c", all in same /24 subnet mask.

On all of the servers, to any of the two other servers, nc to TCP port 9999 consistently takes 0.01 seconds, while UDP to port 9694 consistently takes 2.01 seconds.

This is on RHEL 8.6 with ncat 7.70.

Is there some configuration parameter which slows down UDP responses?

$ hostname
FISPCCPGS302c

$ nc -zvu FISPCCPGS302a 9694
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 10.109.160.16:9694.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.

$ nc -zv FISPCCPGS302a 9999
Ncat: Version 7.70 ( https://nmap.org/ncat )
Ncat: Connected to 10.109.160.16:9999.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

1 Answer 1

3

UDP contrary to TCP is not a connection oriented protocol.

Here nc just sends one packet containing a one byte payload, and waits for a message back, either a UDP packet or a ICMP packet saying the port is not available or the destination not routeable, etc like for TCP.

In general, there's no reason whatever is listening on that UDP port should send a UDP message back to the sender. For instance, if that's a DNS server, that incoming one byte message will just be seen as garbage and ignored. To be able to get an answer, you'd need to send a proper DNS query like nmap does for its UDP scan¹.

So when not receiving a response within a timeout (which seems to be 2 seconds with your netcat), netcat assumes the UDP port is open since it didn't receive any ICMP message either.

So all you see is:

  • for TCP, the system on the other end (not even the server software running there) replying with SYN+ACK upon the SYN sent by the client to establish the connection. That happens straight away.
  • for UDP, netcat timing out after 2 seconds, assuming the port is open because it didn't receive any ICMP packet indicating it's not.

To estimate the response time of the server software, you'd need to issue proper requests in the protocol of those servers. That's for both TCP and UDP.

For instance, if those were DNS servers, you'd need to send DNS queries (maybe some that don't involve querying upstreams servers like a SOA query for the domain the DNS server is authoritative on, or a NS query on the root domain like with dig . NS @"$address" -p "$port"¹), which for TCP would imply sending connection request, data, and termination packets and waiting for their response, and for UDP would involve sending the data packet with the query and waiting for the response.


¹ for example, on UDP port 53 (the standard port for DNS), according to network traces on a test run here, nmap -sU sends a Server Status Request DNS query.

3
  • Something's definitely listening on the three nodes' 0 0.0.0.0:9694.
    – RonJohn
    Mar 13, 2023 at 17:44
  • 1
    @RonJohn, but unless they're echo servers, there's no reason they'd be replying to those 1 byte packets sent by netcat Mar 13, 2023 at 18:58
  • It’s a heartbeat server. I’m going to have to ask them what they’re doing.
    – RonJohn
    Mar 13, 2023 at 20:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .