fishfolk
LAN hosting panics
Description
when setting up a new LAN server, game panics soon
something with mDNS
To Reproduce
No response
Expected Behavior
No response
Additional Context
No response
Log Messages
jumpy
2024-09-14T16:28:50.037096Z INFO bevy_winit::system: Creating new window "App" (0v0)
2024-09-14T16:28:50.150076Z INFO bevy_render::renderer: AdapterInfo { name: "Intel(R) UHD Graphics (TGL GT2)", vendor: 32902, device: 39544, device_type: IntegratedGpu, driver: "Intel open-source Mesa driver", driver_info: "Mesa 24.2.2-arch1.1", backend: Vulkan }
2024-09-14T16:28:50.201354Z INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "Linux Arch Linux", kernel: "6.10.9-arch1-2", cpu: "11th Gen Intel(R) Core(TM) i3-1125G4 @ 2.00GHz", core_count: "4", memory: "7.5 GiB" }
2024-09-14T16:28:55.109119Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:28:55.434324Z INFO magic_ep{me=7hds5wvnqfxhqqye}:magicsock{me=7hds5wvnqfxhqqye}:actor: iroh_net::magicsock: home is now relay https://euw1-1.relay.iroh.network./, was None
2024-09-14T16:28:55.434440Z INFO pkarr_publish{me=7hds5wvnqfxhqqye}: iroh_net::discovery::pkarr: Publish node info to pkarr relay_url=Some("https://euw1-1.relay.iroh.network./")
2024-09-14T16:28:55.434440Z INFO magic_ep{me=7hds5wvnqfxhqqye}:magicsock{me=7hds5wvnqfxhqqye}:relay-actor: iroh_net::magicsock::relay_actor: adding connection to relay: https://euw1-1.relay.iroh.network./ for home-keep-alive
2024-09-14T16:28:57.907471Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:28:59.574415Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:28:59.674373Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:28:59.974195Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:00.074511Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:00.241239Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:00.508176Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:00.807917Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:00.874336Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:01.008975Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:01.908309Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:02.274684Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:02.741631Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:02.840988Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:02.941305Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:03.008532Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:03.174699Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:03.441307Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:04.174489Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:04.740876Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:04.808451Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:04.908788Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:05.040888Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:05.441531Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:05.874678Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:06.404314Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:06.508867Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:06.940799Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:07.574784Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:10.140988Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:10.374237Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:10.741545Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:10.807447Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:10.974008Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:12.841415Z INFO bones_framework::networking::lan: Starting LAN server
2024-09-14T16:29:12.841429Z ERROR bones_framework::logging: A panic occurred panic.payload="called `Result::unwrap()` on an `Err` value: TryFromIntError(())" panic.location="/build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/mdns-sd-0.10.5/src/service_info.rs:633:39" panic.backtrace=disabled backtrace panic.note="run with RUST_BACKTRACE=1 environment variable to display a backtrace"
thread 'mDNS_daemon' panicked at /build/.cargo/registry/src/index.crates.io-6f17d22bba15001f/mdns-sd-0.10.5/src/service_info.rs:633:39:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2024-09-14T16:29:14.273832Z WARN bones_framework::networking::lan: Lan: failed to stop server: Error unregistering MDNS service: flume::channel::send failed: sending on a closed channel
2024-09-14T16:29:17.573863Z INFO bones_framework::networking::lan: New service hosting
2024-09-14T16:29:22.641325Z ERROR bones_framework::logging: A panic occurred panic.payload="Could not register MDNS service.: Msg(\"flume::channel::send failed: sending on a closed channel\")" panic.location="/build/.cargo/git/checkouts/bones-b608aa0d074178a4/bf745aa/framework_crates/bones_framework/src/networking/lan.rs:78:10" panic.backtrace=disabled backtrace panic.note="run with RUST_BACKTRACE=1 environment variable to display a backtrace"
thread 'main' panicked at /build/.cargo/git/checkouts/bones-b608aa0d074178a4/bf745aa/framework_crates/bones_framework/src/networking/lan.rs:78:10:
Could not register MDNS service.: Msg("flume::channel::send failed: sending on a closed channel")
Encountered a panic in exclusive system `bones_bevy_renderer::step_bones_game`!
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!
2024-09-14T16:29:22.650881Z WARN bones_framework::logging: LogFileGuard dropped - flushing buffered tracing to file, no further tracing will be written to file. If unexpected, make sure bones logging init is done in root scope of app.
Have some changes to how lan discovery works in the pipe - will revisit this issue once those are complete. Thanks for the report!
I recently ran into this issue with similar logs:
2024-10-21T01:04:35.770888Z ERROR bones_framework::logging: A panic occurred panic.payload="called `Result::unwrap()` on an `Err` value: TryFromIntError(())" panic.location="/Users/nelson/.cargo/registry/src/index.crates.io-6f17d22bba15001f/mdns-sd-0.10.5/src/service_info.rs:633:39" panic.backtrace=disabled backtrace panic.note="run with RUST_BACKTRACE=1 environment variable to display a backtrace"
thread 'mDNS_daemon' panicked at /Users/nelson/.cargo/registry/src/index.crates.io-6f17d22bba15001f/mdns-sd-0.10.5/src/service_info.rs:633:39:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The panic happens where mdns-sd tries to serialize custom data set by bones to a DNS TXT record:
Arbitrary data can be set on the DNS record which is serialized as <length><key>=<value> where <length> is the length in bytes of the <key>=<value> string. To encode this format the mdns-sd crate takes the usize length and downcasts it to a u8 to push it to the buffer. In this case the key-value pair has a length of 308 bytes which exceeds u8::MAX causing the panic.
The DNS-SD spec doesn't specify that an entry must be <=256 bytes (relevant section of the spec) but this is a hard limit of the mdns-sd crate due to its implementation.
This data comes from bones, it's an iroh_net::NetAddr (my_addr) we are encoding to facilitate peer discovery:
The encoded NetAddr is only >256 bytes for some users due to the direct addresses. Mine are the following:
192.168.1.66:63907
x.x.9.121:62105
x.x.9.121:63907
[xxx:9e27::44]:63908
[xxx:9e27:189f:d808:609e:adcd]:63908
[xxx:9e27:8c35:9dab:aa0:6421]:63908
We discussed a few potential options to remediate this:
- :x: Send the fields of the
NetAddrindividually (node ID, public key, direct addresses)- The addresses on their own account for 170 bytes of the hex-encoded data, so as long as there are not more than 4 IPv4 and 4 IPv6 addresses this should be fine
- This requires the most code changes; not apparent if there are any benefits to this over other options
- :x: Do the first option but send only the 1 private IPv4 address
- The IPv6 addresses aren't needed as this is an issue with LAN lobbies
- The addresses are stored in a
BTreeSetso finding the private address may require some brittle logic
- :white_check_mark: Remove all of the IPv6 addresses before encoding the
NetAddr- IPv6 isn't needed, see above
- Simplest code change:
my_addr.info.direct_addresses.retain(std::net::SocketAddr::is_ipv4);
Going with option 3 as it is the easiest and mdns-sd will hopefully be removed from bones soon, pending some upcoming features that will provide a way of doing more precise peer discovery (it is currently difficult for clients looking to join a lobby to find only those hosting and ignore other nodes that are also looking to join).
@MaxCWhitehead I think this can be closed, the logs look almost identical to mine. If there ends up being another issue here we can re-investigate.
@nelson137 I think we might need to bump bones version in lock file before we actually have the fix here - maybe can PR that in before closing this.
Yeah definitely agree this looks like should be fixed with that change.