esnet
`iperf3: error - unable to receive cookie at server: Bad file descriptor`
With 3.18 I see the errors below, which I hadn’t seen with 3.15 (edit: the second part is wrong: It’s there with 3.15.):
$ iperf3 --version
iperf 3.18 (cJSON 1.7.15)
Linux platsch.molgen.mpg.de 5.15.131.mx64.457 #1 SMP Tue Sep 12 12:55:20 CEST 2023 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing, authentication, bind to device, support IPv4 don't fragment, POSIX threads
$ iperf3 --server --port 5201 --bind iperf3.molgen.mpg.de --timestamps
Wed May 14 10:43:57 2025 -----------------------------------------------------------
Wed May 14 10:43:57 2025 Server listening on 5201 (test #1)
Wed May 14 10:43:57 2025 -----------------------------------------------------------
Wed May 14 10:53:28 2025 iperf3: error - unable to receive cookie at server: Bad file descriptor
Wed May 14 10:53:28 2025 -----------------------------------------------------------
Wed May 14 10:53:28 2025 Server listening on 5201 (test #2)
Wed May 14 10:53:28 2025 -----------------------------------------------------------
warning: JSON data length overflow
Wed May 14 10:53:29 2025 iperf3: error - unable to receive parameters from client: Bad file descriptor
Wed May 14 10:53:29 2025 -----------------------------------------------------------
Wed May 14 10:53:29 2025 Server listening on 5201 (test #3)
Wed May 14 10:53:29 2025 -----------------------------------------------------------
warning: JSON data length overflow
Wed May 14 10:53:29 2025 iperf3: error - unable to receive parameters from client: Bad file descriptor
Wed May 14 10:53:29 2025 -----------------------------------------------------------
Wed May 14 10:53:29 2025 Server listening on 5201 (test #4)
Wed May 14 10:53:29 2025 -----------------------------------------------------------
Can you run the server using -V -d options (verbose+debug) and send the output?
Also, what is the client version you are using for these tests?
Can you run the server using -V -d options (verbose+debug) and send the output?
Also, what is the client version you are using for these tests?
Can you run the server using
-V -doptions (verbose+debug) and send the output?
Sure. I’ll report back.
Also, what is the client version you are using for these tests?
No idea, these were not my tests. That’s why I assume these are port scanners.
No idea, these were not my tests. That’s why I assume these are port scanners.
OK. I thought that you were running the clients. Now I also understand your question about the scanners. In this case, I assume that there are successful tests, so the -d may generate too much output. Therefore, try using --debug=3 instead of -d. Another option is to use only -V.
Here is an example with verbose and debug log:
$ iperf3 --server --port 5201 --bind iperf3.molgen.mpg.de --timestamps -V -d
Thu May 15 09:26:58 2025 iperf 3.18
Thu May 15 09:26:58 2025 Thu May 15 09:26:58 2025 Linux platsch.molgen.mpg.de 5.15.131.mx64.457 #1 SMP Tue Sep 12 12:55:20 CEST 2023 x86_64
Thu May 15 09:26:58 2025 -----------------------------------------------------------
Thu May 15 09:26:58 2025 Server listening on 5201 (test #1)
Thu May 15 09:26:58 2025 -----------------------------------------------------------
Thu May 15 09:26:58 2025 State change: State set to 15-IPERF_START - waiting for a new test (from 0-Test reset)
Thu May 15 15:33:35 2025 State change: State set to 9-PARAM_EXCHANGE - Client to Server Parameters Exchange (from 15-IPERF_START - waiting for a new test)
warning: JSON data length overflow
Thu May 15 15:33:35 2025 All threads stopped
Thu May 15 15:33:35 2025 iperf3: error - unable to receive parameters from client: Bad file descriptor
Thu May 15 15:33:35 2025 iperf 3.18
Thu May 15 15:33:35 2025 Thu May 15 15:33:35 2025 Linux platsch.molgen.mpg.de 5.15.131.mx64.457 #1 SMP Tue Sep 12 12:55:20 CEST 2023 x86_64
Thu May 15 15:33:35 2025 -----------------------------------------------------------
Thu May 15 15:33:35 2025 Server listening on 5201 (test #2)
Thu May 15 15:33:35 2025 -----------------------------------------------------------
Thu May 15 15:33:35 2025 State change: State set to 15-IPERF_START - waiting for a new test (from 0-Test reset)
Thu May 15 21:06:09 2025 All threads stopped
Thu May 15 21:06:09 2025 iperf3: error - unable to receive cookie at server: Bad file descriptor
Thu May 15 21:06:09 2025 iperf 3.18
Thu May 15 21:06:09 2025 Thu May 15 21:06:09 2025 Linux platsch.molgen.mpg.de 5.15.131.mx64.457 #1 SMP Tue Sep 12 12:55:20 CEST 2023 x86_64
Thu May 15 21:06:09 2025 -----------------------------------------------------------
Thu May 15 21:06:09 2025 Server listening on 5201 (test #3)
Thu May 15 21:06:09 2025 -----------------------------------------------------------
Thu May 15 21:06:09 2025 State change: State set to 15-IPERF_START - waiting for a new test (from 0-Test reset)
Thu May 15 21:06:10 2025 State change: State set to 9-PARAM_EXCHANGE - Client to Server Parameters Exchange (from 15-IPERF_START - waiting for a new test)
warning: JSON data length overflow
Thu May 15 21:06:10 2025 All threads stopped
Thu May 15 21:06:10 2025 iperf3: error - unable to receive parameters from client: Bad file descriptor
I did some tests, and that these errors happens when an application tries to connect and send data to TCP port 5201 on the server side. I assume that these can be port scanners, but probably may be any other app. E.g. speedguide.net say that port 5201 is being used by "TARGUS GetData 1".
The "unable to receive cookie" error happens when the "client" sends less than cookie size (37) bytes, and the "unable to receive parameters" is when more than 37 bytes are sent.
I needed to correct my report. I found logs from 3.15, and the errors show up there already. Sorry about the incorrect report.
I did some tests, and that these errors happens when an application tries to connect and send data to TCP port 5201 on the server side. I assume that these can be port scanners, but probably may be any other app. E.g. speedguide.net say that port 5201 is being used by "TARGUS GetData 1".
So operators should just ignore it then?
The "unable to receive cookie" error happens when the "client" sends less than cookie size (37) bytes, and the "unable to receive parameters" is when more than 37 bytes are sent.
Understood.
https://github.com/esnet/iperf/blob/204421d895ef7b7a6546c3b8f42aae24ffa99950/src/iperf_tcp.c#L155C1-L159C6
So operators should just ignore it then?
Probably yes, but maybe someone else can answer as I don't have related operator experience.
I assume that to better understand who is connecting, tools like Wireshark should be used to see were these connections are coming from and view the actual data received (the contents may help to understand is source).
Yes, I am going to start tcpdump. I wonder if in debug logging mode, the IP address and invalid data should be logged or dumped.
I wonder if in debug logging mode, the IP address and invalid data should be logged or dumped.
No such data is logged by iperf3 in debug mode. Currently, the "client" IP address is logged only after successful parameters exchange.
I wonder if in debug logging mode, the IP address and invalid data should be logged or dumped.
No such data is logged by iperf3 in debug mode. Currently, the "client" IP address is logged only after successful parameters exchange.
Yes. My comment was meant as a feature suggestion.
My comment was meant as a feature suggestion.
Submitter PR #1885 that shows more information and that hopefully can help. Any comments or suggestions about the messages contents are welcome.
From the PR's description: Added information that may help understanding the source of receiving non-iperf3 connection requests to the iperf3 port:
- Verbose message about receiving new test connection, showing IP and Port.
- Debug messages (DEBUG_LEVEL_INFO) about the received cookie when its size is too short or when the Parameters JSON size is illegal.