8

On computer 1 (192.168.1.3):
I made a route to be sure that my communication pass through my wireless card

sudo route add -net 239.0.0.0 netmask 255.255.255.0 dev wlan2

I launch iperf with the following command :

iperf -c 239.0.0.1 -u -l 1316

On computer 2 (192.168.1.6):
I acknowledge the fact that I am receiveing the traffic on the wireless card with tcpdump.
I launch iperf with the following command:

iperf -s -u -l 1316 -B 239.0.0.1

But nothing comes out from computer 2, do I have to bind it on another address ?

Improve this question
5
  • MOAR DETAILS. Seriously. what distro ? how is the destination configured ? (does it happen to not have a route to Computer 1 and having reverse path filtering enabled ?)
    – BatchyX
    Jun 12, 2013 at 12:35
  • This should work just fine. Could you try to repeat the test with wired connection, just to exclude WLAN wonkiness (I know that some WLANs kill IPv6, because they don't forward multicast)
    – ytti
    Jun 12, 2013 at 12:53
  • And additionally, what wireless cards are you using ?
    – BatchyX
    Jun 12, 2013 at 12:58
  • I just tried on my mac mini (osx) and laptop (linux), both on wlan (AX411+SRX210), and above test worked after adding 'broadcast-multicast-rate-limit rate-limit 50' and 'broadcast-multicast-rate-limit rate-limit-bursts 75', prior to that I could just send to WLAN->wire, not WLAN->WLAN (so I send to radio, but could not receive from radio)
    – ytti
    Jun 12, 2013 at 13:08
  • Which version of iperf are you using? I've had success with iperf 2.0.5+. (Note, I do run an IGMP querier so any intermediate switches will perform IGMP snooping.) I think the bind device is based from the route table entries, at least for Linux.
    – rjmcmahon
    Jul 15, 2016 at 18:22

1 Answer 1

Reset to default
8

I had this problem using multicast with iperf myself - in my case it was due to the fact that iperf does not let you bind to a multicast source on a specific interface and instead just hardcodes itself to the first interface of the system, meaning that, if the response isn't being received on what is typically eth0, it's useless. From what you say, it sounds like you have this problem too.

So, I wrote a patch that allows you to specify the interface to bind to - you can grab the source from my github repo.

To use it, enter either -O eth123 or --interface eth123 where eth123 is your actual interface name.

I did submit my patch to the project, but, given the inactivity, I suspect the author has either abandoned iperf or is just too busy.

Improve this answer
1
  • Great ! It work Perfectly !
    – Vladimir Leiv
    Jun 12, 2013 at 14:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.