0

Using nodejs I can transmit udp packets with a payload of 50000 chars. But I fail to do so with socat (Linux ubuntu 20.04 on both the client and server).

For this test I've been using a vpn connecting my home host to my work host. I was kind of expecting some data loss with socat but not to that extent !

On the remote (work) host, a socat server waits for request to send back a bloated udp response > 50000 bytes.

cat <<EOF > sotest.sh 
#!/bin/bash
head -c 50000 < /dev/zero | tr '\0' 'q'
EOF
chmod +x sotest.sh
socat udp4-listen:13000,reuseaddr,fork EXEC:"./sotest.sh" # server
#client
printf "trigger" |socat -T 5 -,ignoreeof udp4:10.50.1.184:13000,sndbuf=64000,rcvbuf=64000 > t.t 

And checking the message size with wc -c t.t gives me about 8k chars instead of 50k.

If I use my nodejs udp client/server, the 50k chars message sent by the server are received in entirety by the nodejs client. client : https://jsfiddle.net/xtcpL63a/ server: https://jsfiddle.net/851fc7bp/

The only clue I have is the error message with socat that can be seen only in debug mode

022/12/03 22:37:40 socat[1051733] N forked off child process 1051734
2022/12/03 22:37:40 socat[1051733] N forked off child process 1051734
2022/12/03 22:37:40 socat[1051733] I close(7)
2022/12/03 22:37:40 socat[1051733] I resolved and opened all sock addresses
2022/12/03 22:37:40 socat[1051733] N starting data transfer loop with FDs [5,5] and [6,6]
2022/12/03 22:37:40 socat[1051733] I transferred 73 bytes from 5 to 6
2022/12/03 22:37:40 socat[1051734] I just born: child process 1051734
2022/12/03 22:37:40 socat[1051734] I close(4)
2022/12/03 22:37:40 socat[1051734] I close(3)
2022/12/03 22:37:40 socat[1051734] I close(6)
2022/12/03 22:37:40 socat[1051734] I dup2(7, 0) -> 0
2022/12/03 22:37:40 socat[1051734] I dup2(7, 1) -> 1
2022/12/03 22:37:40 socat[1051734] I close(7)
2022/12/03 22:37:40 socat[1051734] N execvp'ing "./sotest.sh"
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 8192 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] I transferred 848 bytes from 6 to 5
2022/12/03 22:37:40 socat[1051733] E read(5, 0x5566b4417150, 8192): Connection refused
2022/12/03 22:37:40 socat[1051733] N exit(1)
2022/12/03 22:37:40 socat[1051733] I shutdown(5, 2)
2022/12/03 22:37:40 socat[1051733] I shutdown(6, 2)

This problem can't be buffer related on Linux's side, it can't be mtu related neither. So what is happening with socat ?

Solution: Tero Kilkanen pointed out the problem. Forcing socat to use bigger buffers on the client's side allowed me to receive the message in its entirety; it solves but does not really explain this behavior...

#client
printf "${MSG}" |socat -b100000 -T 5 -,ignoreeof udp4:10.50.1.184:13000,sndbuf=64000,rcvbuf=64000 > t.t 

On the server's side, it ensured that one packet was sent; you can see the difference in behavior in the debug logs :

socat -b100000 -d -d -d udp4-listen:13000,reuseaddr,fork EXEC:"./sotest.sh"
3

1 Answer 1

0

socat default buffer size is 8k. You are only setting the buffer size on the client side. Therefore the server uses the default 8k buffer size. That is why the packets are sent in 8k UDP datagrams.

Then for some reason the client only reads the first UDP datagram sent by the server.

1
  • Indeed you're right. Thanks a lot !. The -b option did the trick. just doing it on the client's side allows me to get the message in its entirety :printf "${MSG}" |socat -b100000 -T 5 -,ignoreeof udp4:10.50.1.184:13000,sndbuf=64000,rcvbuf=64000 > t.t . I'll edit my message later Dec 5, 2022 at 8:03

You must log in to answer this question.

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