-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iperf server on debian squeeze #133
Comments
From wpmccormick on January 16, 2014 08:55:13 In trying a different port (I used 11111), nmap did show the port as open but a non local client still couldn't connect to it. |
From [email protected] on January 16, 2014 09:24:04 If you can connect to the iperf server locally but not from a different host, this sounds like a firewall problem. By default the iperf server doesn't bind to any particular port (it would if you use the -B option), so there's no particular reason for iperf to take connections via one interface versus another. When you say "cannot connect clients except from the same machine" what error message do you get from your client? Any way you can tell if you have a firewall configured on this host and if so what its ruleset is? (I wish I could give more specific guidance but I'm more of a FreeBSD person, most of my Linux experience is CentOS.) |
From wpmccormick on January 16, 2014 13:48:21 I agree it sounds like a firewall issue, but the fact that client and server are at the opposite ends of a VPN, and also that the the machine where the iperf server is running has NO iptables config (below), leaves me scratching my head. Even though I can connect locally, nmap still does not show the port as being open. Just to prove that this isn't a fire wall issues, I can connect to a server that I wrote that is listening on tcp/11111. I didn't do anything special to make this work. /* testing client connection to another server app ... it works */ Connection closed by foreign host. /* start iperf, the [3] is something I added so I could see what the sock fd was */ Linux SAM 2.6.33 #1 PREEMPT Wed Jun 30 11:35:16 EDT 2010 i586 GNU/LinuxServer listening on 5201 [3]/* from another console, see what iperf is doing / /* try to connect to the iperf server across and OpenVPN tunnel, server to client*/ /* see what ports are open on the remote side */ Starting Nmap 6.00 ( http://nmap.org ) at 2014-01-16 15:33 CST Nmap done: 1 IP address (1 host up) scanned in 11.82 seconds /* see what ports are open on the local side */ Starting Nmap 5.00 ( http://nmap.org ) at 2014-01-16 16:34 EST Nmap done: 1 IP address (1 host up) scanned in 0.83 seconds /* check iptables */ Chain FORWARD (policy ACCEPT) Chain OUTPUT (policy ACCEPT) |
From wpmccormick on January 16, 2014 13:51:27 oh yea ... and finally, iperf local client: [email protected]:/home/fiber# iperf3 -c 172.16.125.5 [ ID] Interval Transfer Bandwidth Retr iperf Done. [email protected]:/home/fiber# /usr/local/bin/iperf3 -s -4 -V Linux SAM 2.6.33 #1 PREEMPT Wed Jun 30 11:35:16 EDT 2010 i586 GNU/LinuxServer listening on 5201 [3]Time: Thu, 16 Jan 2014 21:49:53 GMT Test Complete. Summary Results: Linux SAM 2.6.33 #1 PREEMPT Wed Jun 30 11:35:16 EDT 2010 i586 GNU/LinuxServer listening on 5201 [3] |
From wpmccormick on January 16, 2014 13:54:25 Is it possible this all has something to do with OpenVPN? I'll see if can get to the iperf server over a LAN ... need to make iperf work on cygwin 1st! |
From wpmccormick on January 16, 2014 15:05:10 Debian linux systems on the OpenVPN client LAN can connect iperf client across the tunnel to the iperf server running on the same Ubuntu system that runs the OpenVPN server. Connecting a cygwin iperf client to a debian linux iperf server, not going through a VPN, and whether on the same LAN or to a VLAN, produces a similar but somewhat different result, detailed below: /* 1st start the server */ Linux SAM 2.6.33 #1 PREEMPT Wed Jun 30 11:35:16 EDT 2010 i586 GNU/LinuxServer listening on 5201/* then start a client */ /* nothing seems to happen until I ctrl-c the client, then I see this on the server ... */ Linux SAM 2.6.33 #1 PREEMPT Wed Jun 30 11:35:16 EDT 2010 i586 GNU/LinuxServer listening on 5201Time: Thu, 16 Jan 2014 23:00:21 GMT Linux SAM 2.6.33 #1 PREEMPT Wed Jun 30 11:35:16 EDT 2010 i586 GNU/LinuxServer listening on 5201 |
From [email protected] on February 03, 2014 14:17:39 Hrm. I'm reading the complete set of comments on this bug (admittedly a bit of time has passed since you wrote them), and I'm trying to sort this out. It looks like in Comment #6 you have things working (at least with the all Linux systems...we don't presently support building on CygWin)? In Comment #5 you asked whether this had to do with OpenVPN. That's certainly possible in that the OpenVPN endpoints could be doing some filtering). If there are some cases that aren't working, perhaps you could see if doing "telnet server 5201" (i.e. try to telnet to the iperf3 server on TCP port 5201) works or if you get a connection timeout. If you get a connection timeout from both the iperf3 client and the telnet client, the problem isn't in iperf3 (I suspect this will be the case). If you get a timeout from the iperf3 client, but a successful connection setup with telnet, then there's some more digging required. |
Closing, unlikely to be an iperf3 issue, and lack of feedback. Can be reopened if needed. |
From wpmccormick on January 16, 2014 05:37:06
What steps will reproduce the problem? 1. fresh compile on debian squeeze
2. iperf3 -s or iperf3 -s -D
3. netstat -a; tcp/5201 is listening What is the expected output? What do you see instead? nmap 172.16.125.5 shows no port open
cannot connect clients except from the same machine What version of the product are you using? On what operating system? [email protected]:/home/fiber# iperf3 -v
iperf version 3.0.1 (10 January 2014)
Linux SAM 2.6.33 #1 PREEMPT Wed Jun 30 11:35:16 EDT 2010 i586 GNU/Linux Please provide any additional information below. I thought that perhaps iperf might be binding to eth0, an unused dhcp port, but I think I ruled that out by swapping eth0 & eth1.
Client seems to work ok.
Original issue: http://code.google.com/p/iperf/issues/detail?id=133
The text was updated successfully, but these errors were encountered: