multicast-example
multicast-example copied to clipboard
bluejekyll
IPv6 tests fail
IPv6 tests are not passing in the code as-is under Ubuntu 18.04 ( at least in my LXC rust development container).
I'd imagine the issue is deeper in one of the libraries since your example code is straightforward but I thought you'd like to know in case it is something you have insight into
IPv6 tests fail
ubuntu@rust-development-environment:~/multicast-example$ RUST_BACKTRACE=1 cargo test ipv6 -- --nocapture
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running target/debug/deps/multicast_example-393ddd9ab30d415c
running 1 test
thread 'ipv6:server' panicked at 'failed to create listener: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', libcore/result.rs:945:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:475
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:390
6: rust_begin_unwind
at libstd/panicking.rs:325
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::result::unwrap_failed
at /checkout/src/libcore/macros.rs:26
9: <core::result::Result<T, E>>::expect
at /checkout/src/libcore/result.rs:809
10: multicast_example::multicast_listener::{{closure}}
at src/lib.rs:99
IPv4 tests pass
ubuntu@rust-development-environment:~/multicast-example$ cargo test ipv4 -- --nocapture
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running target/debug/deps/multicast_example-393ddd9ab30d415c
running 1 test
ipv4:server: joined: 224.0.0.123:7645
ipv4:client: running
ipv4:server: is ready
ipv4:server: got data: Hello from client! from: 10.212.58.77:50330
ipv4:client: got data: ipv4
ipv4:server: sent response to: 10.212.58.77:50330
test test_ipv4_multicast ... ipv4:server: client is done
ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out
Doc-tests multicast-example
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
Ah. Yes, ipv6 is a bit problematic. I think I have better work arounds in my trust-dns repo, but even that is not perfect.
Specifically, we need to come up with some better solutions around picking interfaces, etc. This example was done on macOS, and I think is fully functional, except with a gap around ipv6 interface selection.
Is the issue in the socket2 code? I’m a rust beginner but it looks to me like your code should use any IPv6 interface?
On Sep 26, 2018, at 11:07 AM, Benjamin Fry [email protected] wrote:
Ah. Yes, ipv6 is a bit problematic. I think I have better work arounds in my trust-dns repo, but even that is not perfect.
Specifically, we need to come up with some better solutions around picking interfaces, etc. This example was done on macOS, and I think is fully functional, except with a gap around ipv6 interface selection.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
It's definitely possible. I think I added that code to the libc library and the socket2 library. It's been a little bit since I've looked at this. Not sure how you came across this code, but I posted it as an example associated with this blog post: http://bluejekyll.github.io/blog/rust/2018/03/18/multicasting-in-rust.html "IPv6 leaves me dissatisfied, so I’ll be continuing to look for solutions here. I’d love feedback from others who might know what, if anything, I’m doing wrong there."
The issue that I see is that while the route for a given ipv4 interface is determined properly, ipv6 seems to work differently, even though the documentation that I've found on the matter implies otherwise. It's entirely possible that there's a bug somewhere in the Rust bindings lower-level, but I haven't gotten much feedback around this specific subject. The other thing I noticed is that Linux, macOS, and Windows all require different parameters set. As part of this example and the exploration in the blog post I never got into the details around Linux. We should probably set up a travis job for this, and see if we can get the Linux side working properly.
That article is indeed how I came across the code, as I was looking for examples of cross-platform, multi-threaded sending/receiving of UDP packets over IPv4 and v6 for a utility I wanted to implement (both because it would be useful to me and as an exercise in learning Rust)
I wish I could be of more assistance in debugging the issue but I'm just getting started with Rust. If you can think of a way I can help I will be happy to try.
On Thu, Sep 27, 2018 at 6:18 PM Benjamin Fry [email protected] wrote:
It's definitely possible. I think I added that code to the libc library and the socket2 library. It's been a little bit since I've looked at this. Not sure how you came across this code, but I posted it as an example associated with this blog post: http://bluejekyll.github.io/blog/rust/2018/03/18/multicasting-in-rust.html "IPv6 leaves me dissatisfied, so I’ll be continuing to look for solutions here. I’d love feedback from others who might know what, if anything, I’m doing wrong there."
The issue that I see is that while the route for a given ipv4 interface is determined properly, ipv6 seems to work differently, even though the documentation that I've found on the matter implies otherwise. It's entirely possible that there's a bug somewhere in the Rust bindings lower-level, but I haven't gotten much feedback around this specific subject. The other thing I noticed is that Linux, macOS, and Windows all require different parameters set. As part of this example and the exploration in the blog post I never got into the details around Linux. We should probably set up a travis job for this, and see if we can get the Linux side working properly.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bluejekyll/multicast-example/issues/1#issuecomment-425193309, or mute the thread https://github.com/notifications/unsubscribe-auth/ADSE3n3yU8R18vUWKLhxu6ur2crxn6F9ks5ufRZugaJpZM4W6n4F .
Just to double check, I don't think I ever came up with a solution to this, where I actually use it: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/multicast/mdns_stream.rs#L441
You can see I have the ipv6 test disabled there as well. All the ipv4 tests are functional across platforms, i.e. being tested on Linux, macOS, and Windows. Beyond that, I am aware of some multicast issues in my mDNS implementations, at some point I plan to put in some research to try and figure that out.
