2

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?

user410784
  • 21
  • 1
  • 3

3 Answers3

3

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
Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • 1
    Well spotted, I copied a previous version of the command accidentally. I was originally trying with TCP, but the handshake doesn't succeed, so switched to UDP on both sides (edited on the original question). I do have hostb using -l, so I have no idea what's wrong :( – user410784 Apr 15 '17 at 19:54
0

The reply maybe similar to the response of this question: Forwarded packets are visible by tcpdump but not received by application

Is hostA in a different network than hostB? Does hostB return to hostA (Does it have a route to hostA? If not, is net.ipv4.conf.*.rp_filter disabled?

The solution if hostB hasn't route to hostA is to add a route or disabling rp_filter (reverse path filter).

Humberto Castellon
  • 879
  • 1
  • 7
  • 17
i5513
  • 1
0

Also, in my hardcoded IPv4 header I got the checksum wrong so that on the receiving end netcat ignored the UDP packet even though tpcdump and wireshark reported it. tcpdump flagged the wrong checksum, wireshark ignored it

whennig
  • 1