You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mfelsche opened this issue
Mar 31, 2022
· 0 comments
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.
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
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
The text was updated successfully, but these errors were encountered:
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.
I tried this code:
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 viasetsockopt
:It is reproducible for
TcpSocket
as well.Meta
rustc --version --verbose
:Backtrace
The text was updated successfully, but these errors were encountered: