Avahi demon removed in 23.05

mauriziomeucci

I would like to know the "genius" who decided to remove the avahi demon from latest release. We upload our custom firmware using a 32 port switch to 32 Omega devices at a time, using a script where simply I compile a field (for each device) with the mac address. When starting a production, generally we have to program hundreds of devices at a time...
Now this proceduce won't work anymore! The "genius" tell me to connect to each device with a serial cable (but our board hasn't the connector...) or using wifi (and how automate the process?). Very easy a quick!

MM

crispyoz

@mauriziomeucci While I have no idea of the decision making process, perhaps some clarity can be found in the heading of the release announcement: "Major Beta Firmware Update: OpenWRT 23.05 ......"

The term "Beta" indicating that it is a test release inviting feedback, which would include which packages users may prefer to be included. Personally I don't include avahi in my custom builds.

luz

hi @mauriziomeucci, I understand the necessity for efficient factory programming via Ethernet, but I am genuinely curious to learn what you need avahi for in this scenario.

I am factory programming omega2s via ethernet for many years now, but my script is using IPv6 neighbour discovery, which automatically provides the full MAC address of the omegas, as the MAC is part of the IPv6 link local address. Of course that requires IPv6 to be initially enabled, which was the case so far with omega2 in factory state. @Lazar-Demin77 I hope this will remain the case also for future factory firmware…

Lazar Demin

hi @mauriziomeucci, sorry to hear about the frustration caused by not having the avahi daemon.

To quote @crispyoz:

The term "Beta" indicating that it is a test release inviting feedback, which would include which packages users may prefer to be included.

The 23.05 firmware is still in beta and not yet our stable firmware. We want to give users a chance to try it out before rolling it out as the default firmware in the factory.

If you have specific improvement suggestions (or bugs to report), you can create an Issue in the OnionIoT/OpenWRT-Packages GitHub Repo. There are issue templates you can use for Improvement Suggestions/Feature Requests and Bug Reports.

You can also try building your own version of the 23.05 firmware that includes the avahi daemon. This is now very easy and takes minutes instead of hours. See the How to Build Custom Firmware article in the new documentation for the procedure.

Let me know how it goes!

@luz what's a quick way to test if IPv6 and link local is enabled in the new fw? I'm not too familiar with IPv6 - I need to study

crispyoz

@Lazar-Demin If you have ipv6 installed it will default a link local address on each interface. Same as 169.254.x.x ipv4 addresses. An easy test is to use ping 6 command:

ping6 -c 2 -i 4 -I wlp0s20f3 ff02::1

Where "wlp0s20f3" is the name of my notebook's interface and the ff02::1 is the link local "all nodes" address, like broadcast address (but that term upsets the ipv6 professors). It will respond with the ipv6 address of all nodes on link local. Here 's what's on my development network:

ping6 -c 2 -i 4 -I wlp0s20f3 ff02::1 
ping6: Warning: source address might be selected on device other than: wlp0s20f3
PING ff02::1 (ff02::1) from :: wlp0s20f3: 56 data bytes
64 bytes from fe80::b06d:1d07:966:4c65%wlp0s20f3: icmp_seq=1 ttl=64 time=0.160 ms
64 bytes from fe80::feec:daff:fe31:e1c6%wlp0s20f3: icmp_seq=1 ttl=64 time=2.94 ms
64 bytes from fe80::8bb4:297b:abb:7968%wlp0s20f3: icmp_seq=1 ttl=64 time=3.27 ms
64 bytes from fe80::46d9:e7ff:feb8:53a7%wlp0s20f3: icmp_seq=1 ttl=64 time=3.54 ms
64 bytes from fe80::6ad7:9aff:fe02:b2b8%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::c251:7eff:fe5d:7c73%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::76ac:b9ff:fe4e:29db%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::b6a3:82ff:fe4b:20b6%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::f64d:30ff:fe6b:8b4a%wlp0s20f3: icmp_seq=1 ttl=64 time=3.59 ms
64 bytes from fe80::188a:822d:9b56:843c%wlp0s20f3: icmp_seq=1 ttl=64 time=3.93 ms
64 bytes from fe80::42a3:6bff:fec4:1d8e%wlp0s20f3: icmp_seq=1 ttl=64 time=4.24 ms
64 bytes from fe80::d8f4:6b58:8b5e:cd9f%wlp0s20f3: icmp_seq=1 ttl=64 time=73.7 ms
64 bytes from fe80::a2dc:4ff:fe2a:8411%wlp0s20f3: icmp_seq=1 ttl=64 time=181 ms
64 bytes from fe80::a91:15ff:fefe:8897%wlp0s20f3: icmp_seq=1 ttl=64 time=304 ms
64 bytes from fe80::10b7:9243:cdf4:873e%wlp0s20f3: icmp_seq=1 ttl=64 time=304 ms
64 bytes from fe80::b6fb:e4ff:fec9:3b8%wlp0s20f3: icmp_seq=1 ttl=64 time=308 ms
64 bytes from fe80::f29f:c2ff:fec5:9ab2%wlp0s20f3: icmp_seq=1 ttl=64 time=356 ms
64 bytes from fe80::f29f:c2ff:fe09:fe1%wlp0s20f3: icmp_seq=1 ttl=64 time=878 ms
64 bytes from fe80::b06d:1d07:966:4c65%wlp0s20f3: icmp_seq=2 ttl=64 time=0.081 ms

--- ff02::1 ping statistics ---
2 packets transmitted, 2 received, +17 duplicates, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 0.081/128.421/877.572/217.804 ms

You can see they all start with "fe80" which indicates these addresses are created by the Stateless Auto Address Configuration function of ipv6 (SLACC). So even if you set an ipv6 address on an interface ipv6 will still create the link local address.

There is a lot to ipv6, but this is one of the nice little features.