Noticed that the ZZ models are not returning ipv4 and only providing hostname.
port: 80
service: _bond._tcp.local
name: ZZCC67474
hostname: ZZCC67474
The ZZ models do use a different mDNS stack. However, IPv4 resolution hasn’t been an issue for us thus far. See screenshot from OSX terminal.
Can you advise how you are resolving from mDNS to IPv4 address? Or provide some other detail?
We are using a mdns lua library which when we decypher the mdns packet provides port, service, name, hostname, ipv4 (if available) & ipv6 (if available). The non ZZ units provide ipv4 in the packet but the ZZ units do not.
We patched the mdns library so that if the mdns packet does not supply ipv4 then we utilise the address that sent the mdns packet.
This works fine.
Aha, glad you got a fix that quick.
Your solution seems maximally reliable as it will always use a valid address on the subnet you are talking.
DETAIL:
Actually, it’s possibly an issue with the A/B (Snowbird) units that they do specify an IPv4 address! There’s potentially two addresses: one for the WiFi in Access Point mode, and one for the Station mode. I’m not sure how the network stack would determine which address to specify at the mDNS layer. I’m also thinking ahead here to a product variation with Ethernet, where we will definitely be participating on multiple subnets.
1 Like
Yeah the hack works and should in theory work forever. Just thought i’d notify you guys about the differences between hardware as discovery was intermittently working and couldn’t figure out why until i dug a bit deeper.
1 Like