Linux – Why does tcpdump see a reply, but not netcat

linuxnetcatopenvpntcpdumpvpn

I'm debugging a OpenVPN site-to-site connection using UDP in netcat.

I can get packets to flow in one direction (host A->host B), but not the reverse one.

root@hosta:~# nc 10.0.3.2 1234 -u

root@hostb:~# nc -l 1234 -u

The strange thing is that, when running tcpdump in host A, I actually see the UDP packet arriving from host B:

root@hosta:~# tcpdump port 1234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:36:04.695423 IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
17:36:06.484233 IP 10.0.3.2.1234 > hosta.46603: UDP, length 4

However, netcat doesn't output anything at all. I've tried strace on the nc, and nothing is even received from the socket.

What else can I do to diagnose this?

Best Answer

With only the commands given, this would have been easy! Netcat defaults to TCP without -u for UDP. While nc -lp 1234 -u listens to UDP connections on port 1234, nc 10.0.3.2 1234 tries to open a TCP connection instead.

I suggest adding -v -v to your Netcat on both ends as it will give you sent/rcvd statistics in the end. Please add this information and also correct the commands you were using so that we could know you had your debugging condition right.

Also use tcpdump port 1234 -XX to see what's inside these packets in HEX and ASCII.

However, based on the output of tcpdump port 1234 you probably still had the commands right, but let's play with this mistake a little to see how we can know that:

Since you got UDP packets

IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
IP 10.0.3.2.1234 > hosta.46603: UDP, length 4

instead of TCP packets like

IP hosta.46603 > 10.0.3.2.1234: Flags [S], seq 1384271454, win 14600, options [mss 1460,sackOK,TS val 1969077197 ecr 0,nop,wscale 3], length 0
IP 10.0.3.2.1234 > hosta.46603: Flags [R.], seq 0, ack 1384271455, win 0, length 0

lets assume you had it vice versa:

root@hosta:~# nc 10.0.3.2 1234 -u
root@hostb:~# nc -lp 1234

But in this case you would only have seen the first

IP hosta.46603 > 10.0.3.2.1234: UDP, length 4

and there would not have been any UDP packets to the other direction!

Then, if you accidentally used same nc <IP> 1234 -u on both ends, you would have both lines, but the ports wouldn't have been the same, but something like:

IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
IP 10.0.3.2.73644 > hosta.1234: UDP, length 4
Related Topic