Add ControlMessage::Ipv6MulticastHopLimit

[sgasse]

When sending IPv6 multicast packets with sendmsg, Linux does not use the hop limit set on the socket. Instead, the hop limit has to be specified for each individual message with ancillary data in a cmsg.

This commit adds the enum variant
ControlMessage::Ipv6MulticastHopLimit to specify the limit.

[asomers]

The PR looks good but for a few things:

• Why limit it to Linux? libc defines IPV6_HOPLIMIT for several operating systems.
• It needs a CHANGELOG entry.
• Ideally there would be a test, though that can be hard for some cmsg types.

[asomers]

Oh, and most of the CI failures should be fixed if you rebase on master.

[sgasse]

Thanks for the feedback @asomers !

• Seeing with which hop limit a packet actually leaves the network interface is hard to test - if you have a suggestion for a test or an existing test to orient myself along, I am happy to write one.
• Because I can only manually test this so far, I only added linux because I could not verify that it works on other systems myself. If I should add another group of devices (android or something) please let me know.
• I added a changelog entry.

Unfortunately, there are still a bunch of CI failures which I think are not related to my patch despite rebasing on latest upstream/master 🤔

[asomers]

No, I don't have a good suggestion for how to write a test. It isn't always possible for weird network options. But I did fix the CI failures on master, so that should work if you rebase. And I suggest you go ahead and define this on every platform where libc defines IPV6_HOPLIMIT. That looks like haiku, Linux, Android, FreeBSD, DragonflyBSD, macos, and ios.

[sgasse]

OK thanks 🙂 I updated the patch to include all the target_oses you mentioned. Where would I find the info for which target_os we have IPV6_HOPLIMIT defined? I tried to check in the libc crate but did not find cfg flags with the set that you mention 🤔

Patch is rebased (and tested after the rebase locally), fingers crossed that it gets through CI this time.

[asomers]

Yes, the libc crate is the correct place to check. This is what I see, with an up to date checkout:

> rg -N IPV6_HOPLIMIT ../libc/src/
../libc/src/unix/haiku/mod.rs
pub const IPV6_HOPLIMIT: ::c_int = 33;

../libc/src/unix/linux_like/mod.rs
pub const IPV6_HOPLIMIT: ::c_int = 52;

../libc/src/unix/bsd/apple/mod.rs
pub const IPV6_HOPLIMIT: ::c_int = 47;

../libc/src/unix/bsd/freebsdlike/mod.rs
pub const IPV6_HOPLIMIT: ::c_int = 47;

../libc/src/unix/nto/mod.rs
pub const IPV6_HOPLIMIT: ::c_int = 47;

../libc/src/unix/aix/mod.rs
pub const IPV6_HOPLIMIT: ::c_int = 40;

[sgasse]

Ah using grep to find the mentions make sense, thanks 🙏

I guess I was too slow in resolving the merge conflict - there seem to be new CI issues with a transitive dependency on some runners:

error: failed to compile `cross v0.2.1`, intermediate artifacts can be found at `/tmp/cargo-installrZI4R6`

Caused by:
  package `addr2line v0.21.0` cannot be built because it requires rustc 1.65 or newer, while the currently active rustc version is 1.63.0

Is the right course of action to bump the MSRV here, or pinning some transitive dependency?

[asomers]

Yeah, I raised MSRV. And it's fixed now, so you can rebase.

[sgasse]

Thanks, should be ready now after the rebase 🙂

[asomers]

@sgasse there was a merge conflict.

[sgasse]

Hm OK during a local rebase, I was not required to resolve anything manually. However seeing that you released version 0.27.0, I moved my addition to the changelog into a new Unreleased block.

[sgasse]

@asomers maybe now everything is ready for a merge? 🙂

[sgasse]

@asomers would you be fine with merging this? It would be really useful for me; right now, I have to include this version with a git tag to be able to use the functionality. I think I resolved all issues that you raised, the changelog is up to date and CI is also happy.

[asomers]

@sgasse the changelog is out of date again, unfortunately. We really need to switch to recording it in a less merge-conflict-prone way.

[sgasse]

Ah OK 🙃 I have not tried it out, but maybe there are less merge conflicts if we always had the complete structure

## [Unreleased] - ReleaseDate

### Fixed

### Changed

### Added

above the release changes? I would hope that git can then figure out where to place changes even if other releases are done before. But not sure, how do other crates to that? 🤔

Nevertheless, updated the patch.