Linux compatibility

[ygina]

I am trying to run the examples on a Linux distro:

$ uname -a
Linux [HOSTNAME] 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Setup starting from c80301a:

$ sudo apt-get install libavahi-compat-libdnssd-dev libavahi-compat-libdnssd1  # apt search libavahi-compat

Output:

$ cargo r --example browse
[2020-09-07T17:16:28Z INFO  browse] Starting browser...
*** WARNING *** The program 'browse' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/proje
cts/avahi-compat.html>
<END>

$ cargo r --example register
Registering service...
*** WARNING *** The program 'register' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
<END>

$ avahi-browse -a | grep MyRustService
+ enp7s0 IPv4 MyRustService                                 Web Site             local
+     lo IPv4 MyRustService                                 Web Site             local

The warning seems harmless, and I can confirm the service was actually registered using avahi-browse. But I expect log output from the callbacks like I get on MacOS. Otherwise the browse binary is unable to interact with the discovered hosts. See MacOS output from browse:

macos$ cargo r --bin browse
[2020-09-07T17:19:49Z INFO  browse] Starting browser...
[2020-09-07T17:19:51Z INFO  browse] Added: if: 8 name: MyRustService type: _http._tcp. domain: local.
[2020-09-07T17:19:51Z TRACE astro_dnssd::browser] Got TXT: TXTHash { data: [11, 115, 116, 97, 116, 117, 115, 61, 111, 112, 101, 110] }
[2020-09-07T17:19:51Z TRACE astro_dnssd::browser] MyRustService._http._tcp.local. - [HOSTNAME].local. service resolved
[2020-09-07T17:19:51Z INFO  browse] Addr: 10.128.162.203:2048
[2020-09-07T17:19:51Z INFO  browse] Addr: [fe80::f2:3585:957:c9b3]:2048
[2020-09-07T17:19:51Z INFO  browse] Resolved service: ResolvedService { full_name: "MyRustService._http._tcp.local.", hostname: "[HOSTNAME].local.", port: 2048, txt_record: Some(TXTHash { data: [11, 115, 116, 97, 116, 117, 115, 61, 111, 112, 101, 110] }), interface_index: 8 } status: Ok(Some([111, 112, 101, 110]))

[jfro]

yeah haven't had time to poke at it more, but my initial thoughts are maybe trying to process results in a separate thread, just seems like on linux it would block and never get any replies from the mdns daemon

[ygina]

It reaches the callback when I uncomment the browser.has_data() part around process_result(), for both binaries. I think resolve() needs to do something similar to not be blocking.

[jfro]

interesting, thanks for checking. Odd since other platforms don't require to check first, can just block and it'll return when there's data.

Also wonder if it might be worth using the proper avahi API instead of the compat but that might be a lot more work of course, but is recommended by them.

[clemens-msupply]

I am getting a timeout during registration (on Ubuntu):

$ cargo r --example register
Registering service...
*** WARNING *** The program 'register' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
[2023-04-30T23:32:18Z TRACE astro_dnssd::os::apple::register] Processing...
[2023-04-30T23:32:18Z TRACE astro_dnssd::os::apple::register] Processing...
[2023-04-30T23:32:18Z TRACE astro_dnssd::os::apple::register] Processing...
[2023-04-30T23:32:28Z ERROR astro_dnssd::os::apple::register] Error waiting for callback: Timeout
[2023-04-30T23:32:28Z TRACE astro_dnssd::os::apple::register] Closing socket to signal service cleanup...
Error registering: ServiceError(0)
[2023-04-30T23:32:28Z INFO  register] Drop should have happened

Is this related to the previous comments? Or should I create a new issue?

[jfro]

it might be related, thinking the best way forward might be just to use the avahi APIs instead of the compatbility APIs which might work out better in the end. Just haven't had time to spend much on linux to make progress myself.