Skip to content

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

Open
@mfelsche

Description

@mfelsche

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`C-bugCategory: This is a bug.O-macosOperating system: macOST-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions