Server debug information for non-iperf3 connection to the server #1885
Conversation
|
Thank you for the patch. Unfortunately, the IPv4 address looks printed as an IPv6 address: |
If you will get the other error type, parameters error, it may help, as the first 37 bytes of the message received will be printed. In any case, note that hex 35323031are characters "5201" - the port number. That may suggest that the connection may be coming from a tool inside your network (the ipv6 addrr itself is not riutable). Maybe, as you suggested, this is an internal tool in you network that scans open ports. |
How do I get that error type? I merged your changes, built iperf3 and ran it. What do I need to do? |
#1882 shoeed two issues. One is "unable to receive cookie" that is what you got here, and the other is "unable to receive parameters". If that issue will happen than in addition to the ip addr, the 37 bytes received as the cookie will also be printed, which may help to inderstand which tool is connecting. |
Sorry, I still do not fully understand. My excerpt contains: So nothing seems to have been sent. Now with having been running for a while, there is also: So, some server tries to talk HTTP. |
Sorry to bring this up again, but shouldn’t the logging be able to differentiate between IP address and port number, and log it accordingly? |
Yes, "GET / HTTP/1.1 Host: 141.14.27.109:5" was sent (I assume the full port is 5201). However it does not add information about the sending app. (There seem to be an issue with the hex print which I will try to fix next week).
I was referring ro the IPv6 source addr "::3532:3031:0". Note the the "3532:3031" is the hex coding of the chars "5201", which probably means that this is a fake addr generated by internal network app (the addr is not routable to ouside network). Maybr IT can help to identify what is this app. |
|
Here you go: PS: The tcpdump output shows also a lot of servers try to connect to port 80 and 443. |
|
The tcpdump output is interesting as it shows IPv4 source adress 91.238.181.96. I will check if there is a bug in the IP addr print I added .... In any case, searching this IP shows that is is provided by ISP "AS49434 FBW NETWORKS SAS". I now suspect that the connections are from a web crawler. The first "0 length cookie" connection is from port scanning that looks for open ports but does not send any data. When a port is open then it reconnects and sends HTTP GET (this is when the params error happens). PS: Port 80 (http) and port 443 (https) are the ports for connecting to web servers, so it may be that the tool (web crawler?) also try to find if there is aweb server active in the site and get its data. |
davidBar-On
force-pushed
the
issue-1882-add-server-debug-information
branch
from
9e3b408 to
2cf3d30
Compare
|
@paulmenzel, I have improved the verbose/debug messages, including the display of the source IP address. If you still receive these connection reports, can you try running using this version to see if the verbose and debug messages show the right information? The problem that IPv6 addr was displayed instead of IPv4 addr did not happen in my environment, so I am not sure if the issue is fixed now. (I assume this will not give additional information, but it will help to make sure this PR is correct.) |
|
Awesome. Thank you for your work. It seems to work now: No idea, what is different in our setup. For the record, that server is an IPv4 server only, and has IPv6 disabled/no IPv6 address. |
Great. Thanks for testing. Unfortunately, I still had one issue with printing the cookie which I fixed now (using
I also don't understand, but but that may be because the server only supports IPv4. While in your server "address family 2" ( |
2 participants
Version of iperf3 (or development branch, such as
masteror3.1-STABLE) to which this pull request applies:master
Issues fixed (if any):
iperf3: error - unable to receive cookie at server: Bad file descriptor#1882Brief description of code changes (suitable for use as a commit message):
(Updated on May 25, 2025 to show example of the Verbose and debug messages)
Added information that may help understanding the source of receiving non-iperf3 connection requests to the iperf3 port:
For example (from the logs in the following discussion):
New test connection accepted from 167.94.145.107, port 40362 (address family 2).For example (from the logs in the following discussion):
Cookie received=GET / HTTP/1.1\x0D\x0AHost: 141.14.27.109:5.