Unpublish service

[r4v3n6101]

Hi! Great work, I really appreciate this crate because it's so simple and compact. But I've bumped into an error or at least unexpected behaviour: registered services don't send ServiceRemoved event and so they're continuously displaying in avahi-browser even they've done. Tested with dnssd C library and it sends such message as ServiceRemoved. Could you please add method for removing services manually or even impl Drop for purging all services which are being published at the moment.

[keepsimple1]

Thanks for your kind words!

But I've bumped into an error or at least unexpected behaviour: registered services don't send ServiceRemoved event and so they're continuously displaying in avahi-browser even they've done.

Have you tried unregister()? Would it work for your use case?

[r4v3n6101]

Yep, I've tried and still no ServiceRemoved events. avahi-browser also displays a service but it should be unpublished (remove/unregister and other words).

[keepsimple1]

Yep, I've tried and still no ServiceRemoved events. avahi-browser also displays a service but it should be unpublished (remove/unregister and other words).

To clarify, ServiceRemoved is an event name defined in mdns-sd, not a standard name that's used by other programs, such as avahi-browser.

I tried the following test:

• Run cargo run --example register with a modification: calls unregister after 2 seconds.

$ cargo run --example register _mdns-test._tcp.local. test1
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/examples/register _mdns-test._tcp.local. test1`
Registered service test1._mdns-test._tcp.local.
unregister event: OK

• Run avahi-browse on Linux to browse the same service type.

It seems that avahi-browse received the "unregister" event: Note that it show - at the beginning of the 2nd output:

$ avahi-browse _mdns-test._tcp
+  wlan0 IPv4 test1                                         _mdns-test._tcp      local
-  wlan0 IPv4 test1                                         _mdns-test._tcp      local

I also ran a client querying the same service type using our example code. It received the ServiceRemoved event as defined:

$ cargo run --example query _mdns-test._tcp
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/examples/query _mdns-test._tcp`
At 272.954µs : Received other event: SearchStarted("_mdns-test._tcp.local. on addrs [192.168.0.114]")
At 1.005069334s : Received other event: SearchStarted("_mdns-test._tcp.local. on addrs [192.168.0.114]")
At 3.018675038s : Received other event: SearchStarted("_mdns-test._tcp.local. on addrs [192.168.0.114]")
At 7.031544265s : Received other event: SearchStarted("_mdns-test._tcp.local. on addrs [192.168.0.114]")
At 7.850565179s : Received other event: ServiceFound("_mdns-test._tcp.local.", "test1._mdns-test._tcp.local.")
At 7.850808651s: Resolved a new service: test1._mdns-test._tcp.local. IP: {192.168.0.101} TXT properties: TxtProperties { properties: [TxtProperty {key: "PATH", val: Some("one")}] }
At 8.772215647s : Received other event: ServiceFound("_mdns-test._tcp.local.", "test1._mdns-test._tcp.local.")
At 9.796247673s : Received other event: ServiceRemoved("_mdns-test._tcp.local.", "test1._mdns-test._tcp.local.")
^C

(I will create a PR for supporting unregister in the example code)

[r4v3n6101]

That's odd, I don't see any differences in avahi-browse list (i.e. no minuses, only pluses)
And that's the reason I create this issue: I was thinking about incorrect work of unregister method, but it's fine
I've dive into local avahi configuration to get through this trouble

[keepsimple1]

I've merged in the unregister option for the example code into main branch, so you can try it easier. You can also add a logger in it to obtain debug logs if you want. (It does not use any logger by default yet.)

[r4v3n6101]

Well, I've tried running an example with my full name and started getting an error:
thread 'mDNS_daemon' panicked at 'index out of bounds: the len is 8966 but the index is 28109', src/dns_parser.rs:1005:26
Remark: both in query and register example, but unregister result: OK have been gotten

[keepsimple1]

thread 'mDNS_daemon' panicked at 'index out of bounds: the len is 8966 but the index is 28109', src/dns_parser.rs:1005:26

Do you have the stack trace by any chance?

[keepsimple1]

btw I've merged in an offset checking and error logging to help debugging if it can be reproduced.

[r4v3n6101]

 13:     0x555db94b25b2 - rust_begin_unwind
                               at /rustc/d0f204e4d750b62f9d6c2593405e828757126832/library/std/src/panicking.rs:578:5
 14:     0x555db93ed4b3 - core::panicking::panic_fmt::h99dcfcf83543bc7f
                               at /rustc/d0f204e4d750b62f9d6c2593405e828757126832/library/core/src/panicking.rs:67:14
 15:     0x555db93ed622 - core::panicking::panic_bounds_check::he1ed1b84b0ec5a27
                               at /rustc/d0f204e4d750b62f9d6c2593405e828757126832/library/core/src/panicking.rs:162:5
 16:     0x555db9481578 - mdns_sd::dns_parser::DnsIncoming::read_name::h3a176e87928129ca
                               at /home/ak/workspace/mdns-sd/src/dns_parser.rs:1005:26
 17:     0x555db947fb64 - mdns_sd::dns_parser::DnsIncoming::read_others::h0560a9571612936f
                               at /home/ak/workspace/mdns-sd/src/dns_parser.rs:894:24
 18:     0x555db947eb7b - mdns_sd::dns_parser::DnsIncoming::new::he3bfc76986cae733
                               at /home/ak/workspace/mdns-sd/src/dns_parser.rs:825:9
 19:     0x555db945e55e - mdns_sd::service_daemon::Zeroconf::handle_read::h2e42c45674418bad
                               at /home/ak/workspace/mdns-sd/src/service_daemon.rs:1045:15
 20:     0x555db9454ee0 - mdns_sd::service_daemon::ServiceDaemon::run::ha2c8601d3789414a
                               at /home/ak/workspace/mdns-sd/src/service_daemon.rs:309:31
 21:     0x555db94405c2 - mdns_sd::service_daemon::ServiceDaemon::new::{{closure}}::h82bab8a81e198715
                               at /home/ak/workspace/mdns-sd/src/service_daemon.rs:134:28

You could check it running such command:
cargo r --example register _mydns._tcp.local. A0DB0C69D36F@Test123._mydns._tcp.local. -- --unregister

[keepsimple1]

Thanks for the stack trace!

cargo r --example register _mydns._tcp.local. A0DB0C69D36F@Test123._mydns._tcp.local. -- --unregister

I wasn't able to reproduce the crash yet, but the instance name should not be the full name. i.e. should run this instead:

cargo r --example register _mydns._tcp.local. A0DB0C69D36F@Test123

[r4v3n6101]

Oh, I make the Service struct and Drop for unregistering, but didn't use a variable, so seems Rust deletes it. Added hint::black_box, so now it works.
Thanks for your help! Sorry for my bad

[keepsimple1]

Thanks! Btw, I was able to reproduce the crash issue today. I'm not sure what I did differently last time. But TL;DR is:

• The register example automatically appends the service type _mydns._tcp.local. to the end of the instance name A0DB0C69D36F@Test123._mydns._tcp.local.. Hence the full instance name becomes: A0DB0C69D36F@Test123._mydns._tcp.local.._mydns._tcp.local. . The problem is: there are two continous dots: .. in the name. That effectively truncates the full name by encoding a 0x0 in the middle.

• The PTR aliasread_name would read the full name only till the double dots. But the other bytes of the full name are still in the message body. Then the rest of the message body no longer decodes properly and then crashed.

I will look into a fix for such cases.