Bug 1956299 - UDP listen/recv functionality of socat does not work since Fedora 34
Summary: UDP listen/recv functionality of socat does not work since Fedora 34
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: socat
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Paul Wouters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-03 12:18 UTC by Daniel Rusek
Modified: 2021-05-11 13:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-11 13:53:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Daniel Rusek 2021-05-03 12:18:42 UTC
Description of problem:
Trying to listen for some UDP stream data using socat does not work anymore since Fedora 34. It worked fine on Fedora 33.

Version-Release number of selected component (if applicable):
socat-1.7.4.1-2.fc34.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. Set up some application that streams data over UDP port.
2. Verify that there is actually some data stream using: nc -l -u 1234 #replace "1234" with the actual port number
3. Run: socat stdout udp-listen:1234 #replace "1234" with the actual port number
4. Try running the previous command again, but replace udp-listen with udp-recv.

Actual results:
No data are printed on stdout.

Comment 1 Ondrej Moriš 2021-05-05 11:07:54 UTC
Daniel, I have a problem reproducing this issue, here's what I am doing:

0. # rpm -q socat
   socat-1.7.4.1-2.fc34.x86_64

1. <terminal_1># socat stdout udp-listen:1234

2. <terminal_2># echo "hello" | netcat -u 127.0.0.1 1234

3. <terminal_1>
   hello

The same with udp-recv. Can you be more specific what to do to see the problem? Can you perhaps share socat output with -dddd option? I suspect that something else might actually be playing some role there.

Comment 2 Daniel Rusek 2021-05-05 14:30:04 UTC
Hmm, that's strange. I have this issue when trying to use an UDP stream functionality of Gqrx software defined radio receiver. It worked fine on F33. And it works on F34 when using "nc -l -u 1234" instead of socat.

Comment 3 Ondrej Moriš 2021-05-06 13:08:00 UTC
Unfortunately I cannot use gqrx myself but I tried again with vlc streaming a video to UDP 127.0.0.1:1234, here's what I see:

$ cat /etc/fedora-release 
Fedora release 33 (Thirty Three)

$ netstat -putna | grep 1234
udp        0      0 127.0.0.1:38353         127.0.0.1:1234          ESTABLISHED 272412/vlc     

I updated socat and glibc to F34 version.

$ rpm -q socat
socat-1.7.4.1-2.fc34.x86_64

Now I capture UDP stream for 1 seconds using all three methods.

$ timeout 1 nc -u -l 127.0.0.1 1234 >out; wc -c out
93436 out

$ timeout 1 socat stdio udp-recv:1234 >out; wc -c out
332948 out

$ timeout 1 socat stdio udp-listen:1234 >out; wc -c out
106596 out

So all three capture data just fine. Can you run socat in your scenario with -dddd and share the output?

Comment 4 Daniel Rusek 2021-05-06 15:22:50 UTC
$ socat -dddd stdout udp-listen:7355
2021/05/06 17:18:54 socat[24015] D getpid()
2021/05/06 17:18:54 socat[24015] D getpid() -> 24015
2021/05/06 17:18:54 socat[24015] D setenv("SOCAT_PID", "24015", 1)
2021/05/06 17:18:54 socat[24015] D setenv() -> 0
2021/05/06 17:18:54 socat[24015] D setenv("SOCAT_PPID", "24015", 1)
2021/05/06 17:18:54 socat[24015] D setenv() -> 0
2021/05/06 17:18:54 socat[24015] I socat by Gerhard Rieger and contributors - see www.dest-unreach.org
2021/05/06 17:18:54 socat[24015] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2021/05/06 17:18:54 socat[24015] I This product includes software written by Tim Hudson (tjh)
2021/05/06 17:18:54 socat[24015] D socat version 1.7.4.1 on Jan 27 2021 00:00:00
2021/05/06 17:18:54 socat[24015] D setenv("SOCAT_VERSION", "1.7.4.1", 1)
2021/05/06 17:18:54 socat[24015] D setenv() -> 0
2021/05/06 17:18:54 socat[24015] D running on Linux version #1 SMP Wed Apr 28 14:21:28 UTC 2021, release 5.11.17-300.fc34.x86_64, machine x86_64

2021/05/06 17:18:54 socat[24015] D argv[0]: "socat"
2021/05/06 17:18:54 socat[24015] D argv[1]: "-dddd"
2021/05/06 17:18:54 socat[24015] D argv[2]: "stdout"
2021/05/06 17:18:54 socat[24015] D argv[3]: "udp-listen:7355"
2021/05/06 17:18:54 socat[24015] D sigaction(1, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(2, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(3, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(4, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(6, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(7, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(8, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(11, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D sigaction(15, 0x7ffc0e740690, 0x0)
2021/05/06 17:18:54 socat[24015] D sigaction() -> 0
2021/05/06 17:18:54 socat[24015] D signal(13, 0x1)
2021/05/06 17:18:54 socat[24015] D signal() -> 0x0
2021/05/06 17:18:54 socat[24015] D atexit(0x55ff1ac1e110)
2021/05/06 17:18:54 socat[24015] D atexit() -> 0
2021/05/06 17:18:54 socat[24015] D xioopen("stdout")
2021/05/06 17:18:54 socat[24015] D calloc(1, 824)
2021/05/06 17:18:54 socat[24015] D calloc() -> 0x55ff1c4d2950
2021/05/06 17:18:54 socat[24015] D malloc(1024)
2021/05/06 17:18:54 socat[24015] D malloc() -> 0x55ff1c4d2cb0
2021/05/06 17:18:54 socat[24015] N using stdout for reading and writing
2021/05/06 17:18:54 socat[24015] D isatty(1)
2021/05/06 17:18:54 socat[24015] D isatty() -> 1
2021/05/06 17:18:54 socat[24015] D tcgetattr(1, 0x55ff1c4d2aac)
2021/05/06 17:18:54 socat[24015] D tcgetattr(, {00006506,00000005,000000bf,00008a3b, 15,15, 03,1c,7f,15,04,00,01,00,11,13,1a,00,12,0f,17,16,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00}) -> 0
2021/05/06 17:18:54 socat[24015] D xioopen("udp-listen:7355")
2021/05/06 17:18:54 socat[24015] D calloc(1, 824)
2021/05/06 17:18:54 socat[24015] D calloc() -> 0x55ff1c4d30c0
2021/05/06 17:18:54 socat[24015] D malloc(1024)
2021/05/06 17:18:54 socat[24015] D malloc() -> 0x55ff1c4d3a60
2021/05/06 17:18:54 socat[24015] D socket(2, 2, 17)
2021/05/06 17:18:54 socat[24015] I socket(2, 2, 17) -> 5
2021/05/06 17:18:54 socat[24015] D fcntl(5, 2, 1)
2021/05/06 17:18:54 socat[24015] D fcntl() -> 0
2021/05/06 17:18:54 socat[24015] D bind(5, AF=2 0.0.0.0:7355, 16)
2021/05/06 17:18:54 socat[24015] D bind() -> 0
2021/05/06 17:18:54 socat[24015] D getsockname(5, 0x7ffc0e7404e0, 0x7ffc0e7400dc{16})
2021/05/06 17:18:54 socat[24015] D getsockname(, {AF=2 0.0.0.0:7355}, {16}) -> 0
2021/05/06 17:18:54 socat[24015] N listening on UDP AF=2 0.0.0.0:7355
2021/05/06 17:18:54 socat[24015] D select(6, &0x20, &0x0, &0x0, NULL/0.000000)

Here is the log.

Comment 5 Ondrej Moriš 2021-05-06 16:22:47 UTC
Hm, all good there, nothing suspicious. I suppose you see it hanging like that silently even though you are already streaming to 127.0.0.1:7355. Isn't it possible that something is capturing traffic before it got to socat (tcpdump for instance)? Also, can you try with F33 socat? It should be possible to install it on F34 just fine from Koji [1].

And finally, I am wondering what else is using that port, what can you see in 'netstat -putna | grep 7355'?

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1667707

Comment 6 Daniel Rusek 2021-05-06 20:08:11 UTC
Hmm, "netstat -putna | grep 7355" shows nothing. That's weird. Socat does hang silently, but "nc -l -u 7355" correctly prints the data stream. I wonder what's going on...

Comment 7 Daniel Rusek 2021-05-06 20:12:18 UTC
I have tried the F33 socat and there is exactly the same issue. So the problem seems to be somewhere else.

Comment 8 Ondrej Moriš 2021-05-11 13:53:09 UTC
Thanks Daniel, in that case I am going to close this bug. Feel free to reopen it in the future if needed.


Note You need to log in before you can comment on or make changes to this bug.