librespot-org / libmdns Goto Github PK

Shouldn't QueryType::All return all records possible for our hostname?
We lump A,AAAA and All together queries together - which seems somewhat incorrect to me.
Came across this when implementing matter - the client was expecting a bunch of records from us us but we only return hostname.
Does the spec say anything about this? I couldn't find much in the RFCs, if anyone has a link with a correction/reason would be appreciated.

Per the suggestion in PR #13 this issue is to address the potential to infinitely retry sending a packet if it repeatedly fails.

per-Responder or per-Service ?

Inspired by #3

Hello,

when running the register example on boot as user service, it usually panics with the error messaage:

Result::unwrap()' on an 'Err' value: DnsSdError(Os { code: 19, kind: Uncategorized, message: "No such device" })

It was discovered as used in spotifyd and is reproducable. I have the error on RpasberryPi OS Bookworm 64bit.

Here you can find more information:

Spotifyd/spotifyd#1227
Spotifyd/spotifyd#1244

If you need any more information please let me know.

Best regards
Matthias

I'm using spotifyd which uses librespot, and my journal is full (>25k log entires a day) with these warnings:

Apr 25 20:26:59 ro… spotifyd[5020]: couldn't parse packet from V4(X.X.X.182:47258): type 10240 is invalid
Apr 25 20:26:59 ro… spotifyd[5020]: couldn't parse packet from V4(X.X.X.182:47258): type 10240 is invalid

See also Spotifyd/spotifyd#578 for the regarding spotifyd issue.

The host the packets come from is not my laptop which runs spotifyd but a different device in the local network.

Please (add an option to) reduce the logging since it literally spams my journal in bulk.

Extensible options without changing .register fn signature.

Creating bug at request of: librespot-org/librespot#545

running librespot separately like:

/usr/bin/librespot --name Snapcast --bitrate 320 --backend pipe --initial-volume 100 --verbose

Yields:

[2020-12-03T21:05:57Z INFO  librespot] librespot 89cafd7 (2020-11-27). Built on 2020-12-03. Build ID: tnGD7Qeu
[2020-12-03T21:05:57Z DEBUG librespot_connect::discovery] Zeroconf server listening on 0.0.0.0:44899
[2020-12-03T21:06:02Z WARN  libmdns::fsm] couldn't parse packet from 10.10.1.1:5353: type 47 is invalid
[2020-12-03T21:06:02Z WARN  libmdns::fsm] couldn't parse packet from [fe80::dcde:59ff:fe7e:71e5]:5353: type 47 is invalid
[2020-12-03T21:06:03Z WARN  libmdns::fsm] couldn't parse packet from 10.10.1.1:5353: type 47 is invalid
[2020-12-03T21:06:06Z WARN  libmdns::fsm] couldn't parse packet from 10.10.1.1:5353: type 47 is invalid
[2020-12-03T21:06:06Z WARN  libmdns::fsm] couldn't parse packet from [fe80::dcde:59ff:fe7e:71e5]:5353: type 47 is invalid
[2020-12-03T21:06:11Z WARN  libmdns::fsm] couldn't parse packet from 10.10.1.1:5353: type 47 is invalid
[2020-12-03T21:06:14Z WARN  libmdns::fsm] couldn't parse packet from 10.10.1.1:5353: type 47 is invalid
[2020-12-03T21:06:15Z WARN  libmdns::fsm] couldn't parse packet from 10.10.1.1:5353: type 47 is invalid
[2020-12-03T21:06:15Z WARN  libmdns::fsm] couldn't parse packet from [fe80::dcde:59ff:fe7e:71e5]:5353: type 47 is invalid
[2020-12-03T21:06:16Z WARN  libmdns::fsm] couldn't parse packet from 10.10.1.1:5353: type 47 is invalid

this currently breaks librespot and should be addressed. From @ashthespy:

Type 47 should map to Next Secure record from rfc4034
Would you open up an issue in libmdns for this?

Either way @willstott101 something to consider?

On a multihomed environment calling join_multicast_v4 or join_multicast_v6 with Ipv4Addr::UNSPECIFIED(0.0.0.0) or Ipv6Addr::UNSPECIFIED(::) does not have the intended effect of accepting queries on all interfaces. According to the man pages, calling bind with INADDR_ANY means the socket is bound to all local interfaces, however when calling setsockopt with INADDR_ANY, it means that the OS will pick an appropriate interface, NOT ALL interfaces as it was intended.

It seems like libmdns does not probe on startup according to the mdns specification

When a service is registrered, the 'send_unsollicited' function is triggered but this sends out a Query Response out to the multicast group

Shouldn't we first send a few rounds of DNS Queries questioning whether anyone has records for the service we wish to occupy and then after some time and nobody answered we announce the service?

https://www.rfc-editor.org/rfc/rfc6762#section-8

As discussed here librespot-org/librespot#676 (comment) we don't seem to get "goodbye" mDNS messages when stopping the librespot process which leaves the service lingering in clients. I think it's due to this TODO:

I had a bash at a fix, it is not pretty...

Hi.

I'm trying to use the libmdns to responde mdns and dns-sd messages to an IEEE 2030.5 client.
It turns out that IEEE 2030.5 standard has several subtypes:
For example,
tm._sub._smartenergy._tcp.local

If I send a request for this subtypes, the answer must be something like:

tm-00000000._smartenergy._tcp.local

However, there is no subtype parameter in the register function of libmdns. So, if i declare the type as tm._sub._smartenergy._tcp.local, the server returns:
tm-00000000.tm._sub._smartenergy._tcp.local

that's not the right answer.

Is there any way to implement subtypes in libmdns? If not, could you consider implementing this support?

When building and running the register example, using libmdns version 0.7.3 through 0.7.5, I encounter an "Address already in use" error at this line:

let responder = libmdns::Responder::new().unwrap();

The full output is as follows:

myname@myhost:~/play/rust-hello$ cargo run
   Compiling rust-hello v0.1.0 (/home/myname/play/rust-hello)
    Finished dev [unoptimized + debuginfo] target(s) in 0.60s
     Running `target/debug/rust-hello`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 98, kind: AddrInUse, message: "Address already in use" }', src/main.rs:6:47
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

However, if I change the dependency to libmdns = "=0.7.2" or libmdns = "0.6", the error disappears.

Please let me know if there is any further information I can provide to help resolve this issue.

Using the embeded call of rust if_addrs::get_if_addrs() doesn't list link-local ipv6 addresses on win32.
The implementation proposed by the crate local-ip-address resolve this.

Proposing to replace rust if_addrs::get_if_addrs() call with rust local-ip-address::list_afinet_netifas()

Example:

let if_addrs: Vec<std::net::IpAddr> = local-ip-address::list_afinet_netifas()
    .expect("Cannot get local IP addresses")
    .into_iter()
    .map(|(_, ip)| ip)
    .collect::<Vec<std::net::IpAddr>>();

Hi, maybe I'm using this wrong, I can't seem to get the examples to advertise on ipv6 at all?
It seems to register something but it never shows up in my mdns scan tools.
I've tried running the register and register_with_ip_list with a single item in the vector of my ipv6 addr - it always shows up on the ipv4 interface, showing a v4 IP. The register example shows up either my proper v4 IP or my docker IP.

I see that the enabled/disable ipv6 PRs are closed and from looking at the code, IPv6 should work out of the box?
The use case I'm looking at is matter: https://github.com/project-chip/matter-rs
It currently works great on IPv4 but the end user clients only query over ipv6. I'd love to open a PR with IPv6 life imrpovements but I'm not sure where I should be looking?

Opening this issue to show a client is in-scope for this project, but not yet implemented. This follows a mention in #4 (comment)

Questions to resolve:

• Can we provide any meaningful improvement over the mDNS resolution in https://crates.io/crates/trust-dns-resolver ? #37
• Would a client need to be hidden behind a feature flag? No probing is a core part of the spec.

I was testing this crate on a development board I am using for work and it killed my home network. Wireshark showed ~32k MDNS responses per second! Taking out this crate fixed the issue.

Is the problem related to overflowing UDP multicasts from the same ifs with multiple adresses?
Send using the first link-local address encountered then, but publish and answer AAAA questions with all IPV6 adresses attached to an iface.

• fe80::dead:bee/64%eth0 should use ff02::fb%eth0 multicast
• 2003::dead:bee/64%eth0 should be in AAAA record published by fe80::dead:bee/64%eth0

Other mDNS-sd implementations are including link-local / ULA / GUA adresses, see umdns OpenWrt implementation: https://git.openwrt.org/project/mdnsd.git

This issue has also been discussed in avahi-daemon but not implemented : avahi/avahi#243 (comment)

RFC6762 for mDNS seems to require publishing dynamicly all IPs related to the interface responding to a question in the multicast subnet.

Interesting reading using link-local mDNS advertising : https://github.com/becarpenter/misc/tree/main/zelect#linux-a-tale-of-woe

https://docs.rs/libmdns is a little bare

I am just getting into mDNS, so this might be a silly question: I tried running the example on windows and used bonjour browser to discover the service. This works great when I run the browser on the same PC I run the example on. Bonjour browser on another PC in the network however doesn't pick the service up. There are a few printers and servers on the network which get discovered by both PCs.

Not sure if I am doing something wrong here. I went as far as disabling the windows firewall completely.

edit: it works when I run the example on a Linux machine. Then I can discover the service even on my phone.

When registering a service, the service won't respond to mDNS on packets from the Mobile Hotspot / Wi-Fi Direct network adapter.
I assume this is because it only listenes on the "main" interface.

Furthermore, I noticed, packets from an Android emulator (in my case Genymotion, using Virtual-Box under the hood) won't come through either.

My device has a number of IP addresses associated with various if's.
Of course libmDNS chooses the wrong one when it reponds to mDNS requests :(

For discussion - what is the best approach? Specify IP addresses for the service at responder.register() time ?
Or specify the IF device so the responder can work out both ipv4/6 addresses?

Thanks,
Gerd.