Setting TOS/DSCP when using Reverse Mode (--tos with -R)

[brandon-shannon]

Context

• Version of iperf3: 3.0.11

• Hardware: Macbook Pro

Bug Report

• ACTUAL Behavior
  When doing a Reverse test (-R), the --tos value isn't used to tag traffic from the server to the client, making the TOS setting irrelevant. Only traffic from the client to the server is tagged, but on a reverse test that's not the important bit.

• EXPECTED Behavior
  Packets sent from server to client would be tagged correctly.

• Steps to Reproduce

1. iperf3 -c 104.131.128.139 -p 2222 --tos 72 -R
2. Look at the packets in WireShark

[brandon-shannon]

For what it's worth, I can see that the client tells the server the ToS/DSCP value to use. It looks like the server just doesn't do it. Here's a capture using UDP via WireShark.

{"udp":true,"omit":0,"time":10,"parallel":1,"reverse":true,"len":1448,"bandwidth":1048576,"pacing_timer":1000,"TOS":184,"client_version":"3.2"}

[gwbrown]

This is an odd bug. If an iperf server is started in its default dual IPv6/IPv4 mode, the server will fail to set the appropriate DSCP value on outgoing packets in IPv4 streams. A workaround is to set the -4 flag on the server to force IPv4-only mode if you are running IPv4 tests.

In detail, the socket on the server is opened in IPv6 mode in order to be able to accept both IPv6 and IPv4 connections per this comment in iperf_tcp.c. When the server goes to set the DSCP option on the socket for a specific test here in iperf_api.c, it detects that the socket is an IPv6 socket and sets the appropriate IPv6 option even when a test is using IPv4. I've done some testing, and if iperf_api.c is modified to attempt to set both the IPv6 and IPv4 DSCP options when the socket is detected as IPv6, the behavior will be correct (although if the connection is really an IPv6 connection, the call to set the appropriate IPv4 option will fail).

I'm going to do some more testing and intend to submit a pull request with this fix.

[bmah888]

Thanks @brandon-shannon and @gwbrown for reporting and looking into this!

I haven't had a chance to try reproducing the problem yet, but this sounds reasonable. Just to confirm, this but was originally reported against iperf-3.0.11 but it's also occurring on 3.2, correct?

[brandon-shannon]

That is correct. We upgraded and tried a second time to see if it had been addressed. It is still an issue in 3.2.

[bmah888]

OK, thanks for verifying. I tested this behavior on a couple of (dual-stack) VMs and I've been able to reproduce the problem. Along the way I discovered issue #639, which I would encourage you to watch out for when testing any solutions for this bug. I think the solution for #639 is pretty straightforward but I won't be able to look at this for a little while.

[O-ring]

this bug is also present in 3.6 version running on Linux kernel 64bit

[FireballDWF]

In #889 I added a comment showing where this scenario works as expected when --udp is specified, but not when default of TCP packets used.

[SirAchmed]

Hi, it's 2020 and I'm still facing this issue on iperf3 3.7 on macOS even with the -4 flag. Anyone managed to find a solution or a workaround?

[disprosium8]

I looked into this briefly and the issue does indeed seem to stem from allowing v4 connections on v6 sockets and IPV6_TCLASS setsockopt not applying to v4 connections on a v6 socket domain. If we check for mapped IPv4 addresses as per RFC4291 and then use IP_TOS setsockopt the TOS/DSCP get set on the reverse connection as expected. I have an ugly way to do this in 4995680 that works but needs a more elegant approach. I have not found a clean solution yet other than forcing v4 with -4 flag.

[bmah888]

@disprosium8 : Agreed this is kinda ugly, but there might not be any better way. There does not appear to be any kind of pre-defined predicate that you can use to look for a mapped IPv4 address. If you have a fixed version of the test (like you implied in the comment) I'd be happy to just have you roll with that.