# Mdns on ZZ units does not return ipv4

**URL:** <https://forum.bondhome.io/t/mdns-on-zz-units-does-not-return-ipv4/861>\
**Category:** BETA\
**Created:** [September 19, 2019, 4:05am UTC](https://forum.bondhome.io/t/mdns-on-zz-units-does-not-return-ipv4/861 "2019-09-19T04:05:39Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![alanchow](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.bondhome.io/alanchow/32/182_2.png) [@alanchow](https://forum.bondhome.io/u/alanchow)\
**Post date:** [September 19, 2019, 4:05am UTC](https://forum.bondhome.io/t/mdns-on-zz-units-does-not-return-ipv4/861/1 "2019-09-19T04:05:39Z")

</div>

Noticed that the ZZ models are not returning ipv4 and only providing hostname.

port: 80  
service: \_bond.\_tcp.local  
name: ZZCC67474  
hostname: ZZCC67474

---

<div class="post-metadata">

**Author:** ![merck](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.bondhome.io/merck/32/1238_2.png) [@merck](https://forum.bondhome.io/u/merck)\
**Post date:** [September 19, 2019, 2:44pm UTC](https://forum.bondhome.io/t/mdns-on-zz-units-does-not-return-ipv4/861/2 "2019-09-19T14:44:05Z")

</div>

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.

 ![30](https://us1.discourse-cdn.com/flex019/uploads/bond1/original/1X/6404ed0cac95dc428d3f0b9ad79ae602e3269720.png)

Can you advise how you are resolving from mDNS to IPv4 address? Or provide some other detail?

---

<div class="post-metadata">

**Author:** ![alanchow](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.bondhome.io/alanchow/32/182_2.png) [@alanchow](https://forum.bondhome.io/u/alanchow)\
**Post date:** [September 20, 2019, 1:39am UTC](https://forum.bondhome.io/t/mdns-on-zz-units-does-not-return-ipv4/861/3 "2019-09-20T01:39:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![merck](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.bondhome.io/merck/32/1238_2.png) [@merck](https://forum.bondhome.io/u/merck)\
**Post date:** [September 20, 2019, 8:19pm UTC](https://forum.bondhome.io/t/mdns-on-zz-units-does-not-return-ipv4/861/4 "2019-09-20T20:19:36Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![alanchow](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.bondhome.io/alanchow/32/182_2.png) [@alanchow](https://forum.bondhome.io/u/alanchow)\
**Post date:** [September 20, 2019, 9:20pm UTC](https://forum.bondhome.io/t/mdns-on-zz-units-does-not-return-ipv4/861/5 "2019-09-20T21:20:22Z")

</div>

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.