Fix multicast_ttl_v4 on non-Linux

[jtojnar]

On Windows, set_multicast_ttl_v4 fails with:

Os { code: 10022, kind: InvalidInput, message: "An invalid argument was supplied." }

On MacOS and FreeBSD, multicast_ttl_v4 fails with:

Os { code: 22, kind: InvalidInput, message: "Invalid argument" }

According to FreeBSD’s ip(4), it is supposed to be u8:

u_char ttl;     /* range: 0 to 255, default = 1 */
setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));

I do not understand why it fail on Windows, where it should be DWORD (i.e. u32).

[jtojnar]

Actually, set_multicast_ttl_v4 fails on Linux as well:

Os { code: 22, kind: InvalidInput, message: "Invalid argument" }

Even though it succeeds in tokio, which uses essentially the same code internally:
https://github.com/rust-lang/rust/blob/4f834264ab8d0cb95ac7972532661c84a154667e/library/std/src/sys/net/connection/socket.rs#L639

Edit: Never mind, that was because the tests default to SOCK_STREAM.

[Darksonn]

This claims to change how multicast_ttl_v4 works, but actually just changes the tests?

[jtojnar]

Right.

I had a theory that the tests were failing on Darwin because of wrong size of the value passed to setsockopt but it looks like it actually passes even with u32 hardcoded (reverted the fix in second commit to verify). I just used wrong socket type (TCP instead of UDP) in the test initially.

And it also turned out that tokio’s UdpSocket does not even use socket2 for this option – it uses std, which properly uses u8 on non-Linux UNIXes. And Windows was correct all along in both stacks.

So I am even more confused why the tests in tokio were failing on Windows and non-Linux UNIXes with the same errors like here initially:
tokio-rs/tokio#7781 (comment)

[Thomasdezeeuw]

If everything (in socket2) works, then what is the plan for this pr?

[jtojnar]

I can just keep the test if you think it is helpful. Otherwise, it can be closed.

[Thomasdezeeuw]

Then I'm going to close this.