Update README.md with info that Avahi daemon and Chrome on Linux should be stopped

[ivmarkov]

Follow-up on #66

[cheat-sc]

FYI: Probably, you need to change MulticastDNS=yes to MulticastDNS=no in /etc/systemd/resolved.conf if you're using systemd-resolved.

$ sudo ss --listen --all --processes --num|grep 5353
udp   UNCONN    0      0                                                                     0.0.0.0:5353                      0.0.0.0:*        users:(("systemd-resolve",pid=660,fd=11))                                                                                                                                                                                                                                                                                                                                                                      
udp   UNCONN    0      0                                                                        [::]:5353                         [::]:*        users:(("systemd-resolve",pid=660,fd=12))                                                                                                                                                                                                                                                                          

[ssnover]

I came to this after running into issues with avahi-daemon.service and avahi-daemon.socket. I think printing a log::info statement in the std environment would be helpful as right now there's no level of logging that actually reveals the root issue (since StdIoError is kind of opaque).

Additionally, stopping avahi is not as trivial as sudo systemctl stop|disable <service> as it will retrigger itself. I had to do sudo systemctl mask <service> for each of them to completely stop them.

[ivmarkov]

I came to this after running into issues with avahi-daemon.service and avahi-daemon.socket. I think printing a log::info statement in the std environment would be helpful as right now there's no level of logging that actually reveals the root issue (since StdIoError is kind of opaque).

Which is why we also have #67

Additionally, stopping avahi is not as trivial as sudo systemctl stop|disable <service> as it will retrigger itself. I had to do sudo systemctl mask <service> for each of them to completely stop them.

Yes, this can go into the readme.

[ssnover]

@ivmarkov what are your thoughts on adding a zeroconf feature for hosted systems in order to support using mDNS with Avahi rather than adding directions on how to disable?

[ivmarkov]

@ivmarkov what are your thoughts on adding a zeroconf feature for hosted systems in order to support using mDNS with Avahi rather than adding directions on how to disable?

If somebody (you?) want to spend time on making it work - by all means do. I was unable to find a Rust crate that can talk to Avahi. astro-dnssd (the one we use for MacOSX) claims to do so, but fails at runtime.

IMO, for real (embedded) use cases, this does not bring much value, as you want a tightly controlled, minimal Linux stack, possibly created with buildroot underneath your embedded software. I don't think Avahi has a place there.

[ssnover]

Of course, in my case I'm looking at implementing a Matter bridge on my home server for a non-Matter set of devices so I'm not really resource constrained but I also don't want to prevent other processes from making use of mDNS at the same time.

The zeroconf library claims to support avahi and depends on avahi-sys (it also supports Bonjour, but I don't have a Mac system to test on).

[newcomertv]

Maybe I misunderstood this PR but as far as I can tell this didn't fix the issue for me.

Still panics without disabling the demon on Ubuntu 22.04:

[2023-10-06T20:04:44Z INFO rs_matter::transport::core] Transport: waiting for incoming packets
Error: Error::StdIoError: Address already in use (os error 98) {
0: rs_matter::error::Error::new_with_details
at ./rs-matter/src/error.rs:111:24
1: <rs_matter::error::Error as core::convert::Fromstd::io::error::Error>::from
at ./rs-matter/src/error.rs:165:9
2: <core::result::Result<T,F> as core::ops::try_trait::FromResidual<core::result::Resultcore::convert::Infallible,E>>::from_residual
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/core/src/result.rs:1962:27
3: rs_matter::transport::udp::async_io::UdpListener::new::{{closure}}
at ./rs-matter/src/transport/udp.rs:58:40
4: rs_matter::mdns::builtin::MdnsService::run::{{closure}}
at ./rs-matter/src/mdns/builtin.rs:141:10
5: <core::pin::Pin

as core::future::future::Future>::poll
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/core/src/future/future.rs:125:9
6: <&mut F as core::future::future::Future>::poll
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/core/src/future/future.rs:113:9
7: <embassy_futures::select::Select3<A,B,C> as core::future::future::Future>::poll
at /home/nikolas/.cargo/registry/src/index.crates.io-6f17d22bba15001f/embassy-futures-0.1.0/src/select.rs:111:33
8: async_io::driver::block_on
at /home/nikolas/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-io-1.12.0/src/driver.rs:146:33
9: dimmable_light::run
at ./rs-matter/../examples/dimmable_light/src/main.rs:165:5
10: core::ops::function::FnOnce::call_once
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/core/src/ops/function.rs:250:5
11: std::sys_common::backtrace::rust_begin_short_backtrace
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/std/src/sys_common/backtrace.rs:154:18
12: std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/std/src/thread/mod.rs:529:17
13: <core::panic::unwind_safe::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/core/src/panic/unwind_safe.rs:271:9
14: std::panicking::try::do_call
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/std/src/panicking.rs:526:40
15: std::panicking::try
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/std/src/panicking.rs:490:19
16: std::panic::catch_unwind
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/std/src/panic.rs:142:14
17: std::thread::Builder::spawn_unchecked::{{closure}}
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/std/src/thread/mod.rs:528:30
18: core::ops::function::FnOnce::call_once{{vtable.shim}}
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/core/src/ops/function.rs:250:5
19: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/alloc/src/boxed.rs:2007:9
20: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce>::call_once
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/alloc/src/boxed.rs:2007:9
21: std::sys::unix::thread::Thread::new::thread_start
at /rustc/9f5fc1bd443f59583e7af0d94d289f95fe1e20c4/library/std/src/sys/unix/thread.rs:108:17
22: start_thread
at ./nptl/pthread_create.c:442:8
23: clone3
at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
}

Steps to reproduce:
Boot Ubuntu 22.04
Open Browser to clone rs-matter repository
Build and run OnOff_Light example

[ssnover]

I would recommend copying the example code into an application and then initializing with the zeroconf feature.

Sidenote: @kedars what do you think about splitting the examples on a per platform basis? There's a lot of extra noise in the example in making the same source file support esp32 and Linux.

[inevity]

I just on the master commit 3d8fc59, also met this issue. On arch linux.

[2024-03-21T08:15:21Z INFO  onoff_light] Will use network interface ens18 with 172.16.10.109/fe80::10bd:11ff:fef8:35d5 for mDNS
Error: Error::StdIoError: Address already in use (os error 98) {
disabled backtrace}

[ivmarkov]

I just on the master commit 3d8fc59, also met this issue. On arch linux.

This issue is no longer relevant because the current main branch now does support Avahi. You just need to compile with cargo build --features async-io,zeroconf --examples

[inevity]

This issue is no longer relevant because the current main branch now does support Avahi. You just need to compile with cargo build --features async-io,zeroconf --example

On mine node,

sudo lsof -i -P -n | grep 5353
systemd-r     457 systemd-resolve  15u  IPv4     18562      0t0  UDP *:5353
systemd-r     457 systemd-resolve  16u  IPv6     18563      0t0  UDP *:5353


cargo build --features async-io,zeroconf --examples
And the error log is that:
2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key D val 250
[2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key CM val 1
[2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key DN val OnOff Light
[2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key VP val 65521+32768
[2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key SII val 5000
[2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key SAI val 300
[2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key PH val 33
[2024-03-21T08:28:35Z INFO  rs_matter::mdns::builtin] mDNS TXT key PI val
[2024-03-21T08:28:35Z DEBUG zeroconf::linux::service] Registering service: AvahiMdnsService { client: None, poll: None, context: AvahiServiceContext { name: Some("135098307ADC8921"), kind: "_matterc._udp", port: 5540, group: None } }
[2024-03-21T08:28:35Z ERROR rs_matter::mdns::builtin] Encountered error registering mDNS service: could not initialize AvahiClient

[inevity]

Should i also need disable it with MulticastDNS=no?
look like We should also zeroconf for mdns in systemd-resolved.
Because systemd-resoloved and avahi conflict on the mdns.

Now I just disable mdns in systemd-resolved, and build without zeroconf, now example run ok.

[ivmarkov]

On mine node,

sudo lsof -i -P -n | grep 5353
systemd-r     457 systemd-resolve  15u  IPv4     18562      0t0  UDP *:5353
systemd-r     457 systemd-resolve  16u  IPv6     18563      0t0  UDP *:5353

What you have running on your node is not Avahi, but systemd-resolve - which - to my understanding - is a "very minimal" mDNS-like client which we cannot / do not yet integrate with.

So it is normal that the app outputs:

[2024-03-21T08:28:35Z DEBUG zeroconf::linux::service] Registering service: AvahiMdnsService { client: None, poll: None, context: AvahiServiceContext { name: Some("135098307ADC8921"), kind: "_matterc._udp", port: 5540, group: None } }
[2024-03-21T08:28:35Z ERROR rs_matter::mdns::builtin] Encountered error registering mDNS service: could not initialize AvahiClient

... because what you have is not Avahi in the first place.

I think what you should do is
(a) stop this systemd-resolve
(b) Build and run the rs-matter stack without Avahi/zeroconf support, as you started originally. I.e. cargo build --features async-io --examples

[ivmarkov]

Should i also need disable it with MulticastDNS=no? look like We should also zeroconf for mdns in systemd-resolved. Because systemd-resoloved and avahi conflict on the mdns.

Now I just disable mdns in systemd-resolved, and build without zeroconf, now example run ok.

Exactly. Until (if ever) we also have an integration with systemd-resolved, you need to disable it, and then run rs-matter with its own built-in mDNS responder.