MaxCWhitehead
commented
1 month ago Have some changes to how lan discovery works in the pipe - will revisit this issue once those are complete. Thanks for the report!
Closed JeromeSchmied closed 1 month ago
MaxCWhitehead
commented
1 month ago Have some changes to how lan discovery works in the pipe - will revisit this issue once those are complete. Thanks for the report!
nelson137
commented
1 month ago 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 backtraceThe 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]:63908We discussed a few potential options to remediate this:
NetAddr individually (node ID, public key, direct addresses)
BTreeSet so finding the private address may require some brittle logicNetAddr
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).
nelson137
commented
1 month ago This problem originates from bones_framework, see tracking issue bones#485
nelson137
commented
1 month ago @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.
MaxCWhitehead
commented
1 month ago @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.
nelson137
commented
1 month ago lol you're so right, I can do that real quick
Description
when setting up a new LAN server, game panics soon something with
mDNSTo Reproduce
No response
Expected Behavior
No response
Additional Context
No response
Log Messages