Skip to content

Tcp/UdpSocket.set_ttl fails on macOS for ipv6 sockets #95541

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

Open
mfelsche opened this issue Mar 31, 2022 · 0 comments
Open

Tcp/UdpSocket.set_ttl fails on macOS for ipv6 sockets #95541

mfelsche opened this issue Mar 31, 2022 · 0 comments
Labels
A-io Area: `std::io`, `std::fs`, `std::net` and `std::path` C-bug Category: This is a bug. O-macos Operating system: macOS T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@mfelsche
Copy link

I tried this code:

use std::net::{Ipv6Addr, SocketAddrV6, UdpSocket};

fn main() {
    let laddr = SocketAddrV6::new(Ipv6Addr::new(0,0,0,0,0,0,0,1), 50000, 0, 0);
    let destination = SocketAddrV6::new(Ipv6Addr::new(0,0,0,0,0,0,0,1), 50000, 0, 0);

    let socket = UdpSocket::bind(laddr).unwrap();
    socket.connect(destination).unwrap();
    socket.set_ttl(10).unwrap();
    println!("{:?}", socket.ttl().unwrap());

    let payload = [1,2,3,4,5,6,7,8];
    socket.send(&payload).unwrap();
}

I expected to see this happen:

As reported in #47727 using set_ttl on a IPv6 based socket does not have any effect and does not set the hop limit correctly. I was able to reproduce this on linux. But on macOS Big Sur (11.6.5) this actually fails.

I expected this snippet above to print 10 and issue the pakets with the default hop limit. I mean, I actually expected this call to set the hoplimit correctly, but given i knew about #47727 i lowered my expectations a bit.

I would have loved to have the documentation of set_ttl to tell me that it is intended to only work on ipv4 (given, i don't know both protocol and packet fields by heart) or to work for both ipv4 and ipv6.

Instead, this happened:

The snippet above fails with the following output when trying to set the IP_TTL field via setsockopt:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', src/main.rs:9:24

It is reproducible for TcpSocket as well.

Meta

rustc --version --verbose:

rustc 1.59.0 (9d1b2106e 2022-02-23)
binary: rustc
commit-hash: 9d1b2106e23b1abd32fce1f17267604a5102f57a
commit-date: 2022-02-23
host: x86_64-apple-darwin
release: 1.59.0
LLVM version: 13.0.0

Backtrace

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', src/main.rs:9:24
stack backtrace:
   0: rust_begin_unwind
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:116:14
   2: core::result::unwrap_failed
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/result.rs:1690:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/result.rs:1018:23
   4: ttl_fun::main
             at ./src/main.rs:9:5
   5: core::ops::function::FnOnce::call_once
             at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/ops/function.rs:227:5

@mfelsche mfelsche added the C-bug Category: This is a bug. label Mar 31, 2022
@Enselic Enselic added O-macos Operating system: macOS A-io Area: `std::io`, `std::fs`, `std::net` and `std::path` labels Jul 30, 2024
@jieyouxu jieyouxu added T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed needs-triage-legacy labels Nov 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-io Area: `std::io`, `std::fs`, `std::net` and `std::path` C-bug Category: This is a bug. O-macos Operating system: macOS T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants