When working with UDP (User Datagram Protocol) connections using netcat, you'll quickly notice a fundamental difference from TCP behavior. Unlike TCP where connections are persistent, UDP operates in a connectionless manner. This becomes particularly evident when trying to capture server responses.

The common approach:

echo "request" | nc -u 1.1.1.1 9999 > response.txt

fails to capture responses because netcat terminates immediately after sending the UDP packet, before any response can be received.

Method 1: Using Netcat with Timeout

The most straightforward solution is to force netcat to wait for a response:

echo "request" | nc -u -w 2 1.1.1.1 9999 > response.txt

Key parameters:

• -u: UDP mode
• -w 2: Wait 2 seconds before timeout

Method 2: Persistent Netcat Listener

For more reliable response capture, use two terminals:

Terminal 1 (listener):

nc -ul 9999 > response.txt

Terminal 2 (sender):

echo "request" | nc -u localhost 9999

Method 3: Using Netcat with Ncat's Enhanced Features

If you have ncat (from nmap) installed, it offers better UDP handling:

echo "request" | ncat -u --recv-only 1.1.1.1 9999 > response.txt

Packet Analysis with Tcpdump

When debugging UDP communications, always verify packets are actually being sent/received:

sudo tcpdump -i any port 9999 -vv -X

Automated Response Handling

For scripts requiring UDP communication, consider this bash function:

udp_query() {
    local host=$1 port=$2 request=$3 timeout=${4:-2}
    (echo "$request" | nc -u -w $timeout $host $port) 2>/dev/null
}

# Usage:
response=$(udp_query 1.1.1.1 9999 "status_request")

• Firewalls blocking UDP responses (check iptables/ufw)
• Server not actually sending responses (verify with tcpdump)
• Netcat version differences (GNU netcat vs BSD variants)

---

When working with UDP connections in Linux, many developers encounter situations where netcat (nc) appears to receive responses (visible in packet captures), but fails to write them to the output file. This typically happens because of UDP's connectionless nature and netcat's default behavior.

The basic command:

echo "request" | nc -u 1.1.1.1 9999 > response.txt

Has these limitations:

• Netcat exits immediately after sending the UDP packet
• No built-in timeout for waiting responses
• Output redirection may close before response arrives

Method 1: Using Timeout Flags

echo "request" | nc -u -w 3 1.1.1.1 9999 > response.txt

Key parameters:

• -w 3: Wait 3 seconds for response
• Works with traditional netcat implementations

Method 2: Ncat (Improved Version)

echo "request" | ncat -u --recv-only 1.1.1.1 9999 > response.txt

Advantages:

• Better handling of UDP responses
• --recv-only ensures proper output capture

Method 3: Persistent Listening

For servers that might delay responses:

(echo "request"; sleep 5) | nc -u 1.1.1.1 9999 > response.txt

Always verify with:

tcpdump -i any udp port 9999 -vv -X

And check if packets actually reach your interface.

For interactive UDP sessions:

nc -u 1.1.1.1 9999

Then type requests and see immediate responses in terminal.

• Verify firewall rules (both directions)
• Check server actually sends responses to your IP
• Test with different timeout values
• Try alternative tools like socat if issues persist