are there any changes to mDNS in the 388 code base

[jata]

Hi all - I'm a very happy user of asus routers and merlin firmware... So thanks for all the great work and this community!

I have issues (over many years) with some homekit devices (and hubs/homepods) where they occasionally go offline saying 'no response'. I've done lots of testing/researching etc and i think the underlying issue is related to the mDNS implementation on asus routers - and many other routers too!

I have tried switching off advanced wifi settings. using fixed ip's, reservations etc. nothing works.

In my testing I have seen that sometimes a homekit device (e.g. camera) stops advertising it's mDNS name. this is 100% correlated to the issue occurring

Is this (mdns) an area that is being actively developed by asus?

Is this an area that could be further developed/improved through a script / entware package etc?

any help appreciated folks...

 

[ColinTaylor]

Asuswrt uses the standand Linux avahi daemon so there's nothing for them to develop. RMerlin updated avahi to the most recent version (0.8) in January 2022.

 

[sfx2000]

The main issues I've found with Bonjour/Avahi on any distro is default LAN domains being .local (which causes problems) and Multicast issues with IGMP snooping/proxy settings, esp in the Wireless settings side.

.local as the LAN domain is known to cause issues - .lan is fine here... OpenWRT and IIRC, pfSense, they default to .lan if the local domain isn't specified...

If one has an Apple TV or HomePod Mini in the house, it can anchor the mDNS side, avahi isn't actually needed on AsusWRT as a package, but it's nice to have..

 

[jata]

Asuswrt uses the standand Linux avahi daemon so there's nothing for them to develop. RMerlin updated avahi to the most recent version (0.8) in January 2022.

thanks Colin.

It is strange that some routers/platforms are better than others. Reddit 'experts' that have had issues say eero is particularly good with homekit.

It's so frustrating that I can't get to the bottom of this as I love my asus setup

 

[ColinTaylor]

You don't even need avahi to be running on the router (I don't) for mDNS to work. That's the whole point of mDNS.

 

[Frank Monroe]

thanks Colin.

It is strange that some routers/platforms are better than others. Reddit 'experts' that have had issues say eero is particularly good with homekit.

It's so frustrating that I can't get to the bottom of this as I love my asus setup

I started having HomeKit issues on my RT-AC5300 after the January Merlin update. I reverted back to version 386.3_2 and haven't had a problem since.

 

[drinkingbird]

thanks Colin.

It is strange that some routers/platforms are better than others. Reddit 'experts' that have had issues say eero is particularly good with homekit.

It's so frustrating that I can't get to the bottom of this as I love my asus setup

There seem to be various people complaining of issues with homekit discovery/MDNS. Apparently it has gone through phases of getting better then getting worse.

If your homekit stops advertising/responding, I don't think the Asus would be causing that. If it advertises but other devices don't see it, that would be an issue with multicast forwarding via the switch and/or wifi in the Asus, and not the MDNS implementation/version (I would think). The MDNS on the Asus is probably only there to make it compatible with apple devices doing time machine backups to the Asus USB port and similar stuff.

Maybe eero or some brands default to wifi multicast settings that work better, or their IGMP snooping is better implemented (or disabled, which seems to be more compatible with MDNS).

Multicast on a home router is never going to be a home run. It is somewhat uncommon and not the primary thing they're focused on making sure works right. When you add wifi into the mix it gets even more troublesome. Multicast relies on a good, stable, consistent connection and one device with poor signal quality can throw the whole thing off.

 

[drinkingbird]

I started having HomeKit issues on my RT-AC5300 after the January Merlin update. I reverted back to version 386.3_2 and haven't had a problem since.

Do you happen to know what the homekit interacts with the router for? Looking for printers and network storage I'm assuming? Or does it just want every device to announce its name and capabilities?

Hard to tell if your issues (or anyone's for that matter) are related to MDNS on the Asus, or its handling of multicast/broadcast/udp packets. Either one can change with a firmware update.

 

[Frank Monroe]

Do you happen to know what the homekit interacts with the router for? Looking for printers and network storage I'm assuming? Or does it just want every device to announce its name and capabilities?

Hard to tell if your issues (or anyone's for that matter) are related to MDNS on the Asus, or its handling of multicast/broadcast/udp packets. Either one can change with a firmware update.

The problem is bigger than HomeKit. HomeKit was just one of the symptoms. The issue I was having was traffic between wired devices and wifi devices. It mostly involved icmp traffic. But it wasn't limited to icmp. The biggest problem was with IPv6 traffic and losing RA's from the router. The problem wasn't just limited to that though. I had to reboot the router several times a week to fix the problem. The problem occurs with every single release in the 387 branch. On 386, it never happens. There are several other threads in this forum with others reporting similar issues with the AC5300 and the 387 branch.

 

[SomeWhereOverTheRainBow]

The main issues I've found with Bonjour/Avahi on any distro is default LAN domains being .local (which causes problems) and Multicast issues with IGMP snooping/proxy settings, esp in the Wireless settings side.

.local as the LAN domain is known to cause issues - .lan is fine here... OpenWRT and IIRC, pfSense, they default to .lan if the local domain isn't specified...

If one has an Apple TV or HomePod Mini in the house, it can anchor the mDNS side, avahi isn't actually needed on AsusWRT as a package, but it's nice to have..

Do you happen to know what the homekit interacts with the router for? Looking for printers and network storage I'm assuming? Or does it just want every device to announce its name and capabilities?

Hard to tell if your issues (or anyone's for that matter) are related to MDNS on the Asus, or its handling of multicast/broadcast/udp packets. Either one can change with a firmware update.

should avahi be using .local?

here is an example of some of the lines I see, let us say the normal lan domain name is .lan .


Avahi tacks .local to the end of that in my tcp dump inspections.

22:21:40.594144 IP (tos 0x0, ttl 1, id 22235, offset 0, flags [DF], proto UDP (17), length 90)
    192.168.1.81.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 1/0/0 amazon-067db4faf-lan.local. (Cache flush) A 192.168.1.81 (62)
22:21:40.594144 IP (tos 0x0, ttl 1, id 22236, offset 0, flags [DF], proto UDP (17), length 90)
    192.168.1.81.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 1/0/0 amazon-067db4faf-lan.local. (Cache flush) A 192.168.1.81 (62)

is this a normal behavior? typically for the LAN domain, it would be amazon-067db4faf.lan; however for MDNS, it changes it to amazon-067db4faf-lan.local .

 

[SomeWhereOverTheRainBow]

Ironically, from clients i can ping

ping amazon-067db4faf-lan.local

Pinging amazon-067db4faf-lan.local [192.168.1.81] with 32 bytes of data:

Reply from 192.168.1.81: bytes=32 time=131ms TTL=64
Reply from 192.168.1.81: bytes=32 time=4ms TTL=64
Reply from 192.168.1.81: bytes=32 time=175ms TTL=64
Reply from 192.168.1.81: bytes=32 time=94ms TTL=64

Ping statistics for 192.168.1.81:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 175ms, Average = 101ms

From the router himself I get:

ping: amazon-067db4faf-lan.local: Name does not resolve

 

[jata]

Thanks everyone.

I have my LAN domain set to .lan

mdns uses .local

I can see some devices across my network report/use:

1. client.local for mDNS name only
2. client.lan for DNS name only
3. both 1 and 2 above together (this would be perfect if all devices did this all of the time)

I see that sometimes the mDNS name stops advertising for some clients when i scan the network. No idea why and I think this is a big part of the issue.

I sometimes have one of my apple homepods say 'no response' but these always look fine when i scan the network - always show both mDNS and NDS names correctly. they are on the 5ghz network. But i get the issue if i fors=ce them to use the 2.4ghz

It's so weird and soooooo annoying.

I have put so much time (and money) into getting this right. I have 3x AX routers in a mesh setup that is rock solid but still have the issue.

Even if i join all devices to the main router (no mesh nodes) I still have the issue.

 

[drinkingbird]

The problem is bigger than HomeKit. HomeKit was just one of the symptoms. The issue I was having was traffic between wired devices and wifi devices. It mostly involved icmp traffic. But it wasn't limited to icmp. The biggest problem was with IPv6 traffic and losing RA's from the router. The problem wasn't just limited to that though. I had to reboot the router several times a week to fix the problem. The problem occurs with every single release in the 387 branch. On 386, it never happens. There are several other threads in this forum with others reporting similar issues with the AC5300 and the 387 branch.

Ok so just a general issue and not related to MDNS at all then.

 

[drinkingbird]

should avahi be using .local?

here is an example of some of the lines I see, let us say the normal lan domain name is .lan .


Avahi tacks .local to the end of that in my tcp dump inspections.

22:21:40.594144 IP (tos 0x0, ttl 1, id 22235, offset 0, flags [DF], proto UDP (17), length 90)
    192.168.1.81.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 1/0/0 amazon-067db4faf-lan.local. (Cache flush) A 192.168.1.81 (62)
22:21:40.594144 IP (tos 0x0, ttl 1, id 22236, offset 0, flags [DF], proto UDP (17), length 90)
    192.168.1.81.5353 > 224.0.0.251.5353: [udp sum ok] 0*- [0q] 1/0/0 amazon-067db4faf-lan.local. (Cache flush) A 192.168.1.81 (62)

is this a normal behavior? typically for the LAN domain, it would be amazon-067db4faf.lan; however for MDNS, it changes it to amazon-067db4faf-lan.local .

That's expected, the whole point of MDNS is client based name resolution with no DNS server, every client maintains a list of other clients. That's why it uses .local. You will be able to ping the host from an MDNS enabled device but won't be able to do an nslookup for it (unless the OS has built that table into their nslookup implementation).

Its basically a dynamic hosts file on each machine.

 

[Frank Monroe]

Ok so just a general issue and not related to MDNS at all then.

I didn't comment because of mDNS. I commented because the issue showed up with me due to my Home Hub being an Apple TV connected to the ASUS through ethernet. My HomeKit devices are wifi. The problem breaks HomeKit in two ways: 1). When ICMP breaks between ethernet and wifi and 2). When IPv6 breaks. Home Kit is using both.

 

[drinkingbird]

Thanks everyone.

I have my LAN domain set to .lan

mdns uses .local

I can see some devices across my network report/use:

1. client.local for mDNS name only
2. client.lan for DNS name only
3. both 1 and 2 above together (this would be perfect if all devices did this all of the time)

I see that sometimes the mDNS name stops advertising for some clients when i scan the network. No idea why and I think this is a big part of the issue.

I sometimes have one of my apple homepods say 'no response' but these always look fine when i scan the network - always show both mDNS and NDS names correctly. they are on the 5ghz network. But i get the issue if i fors=ce them to use the 2.4ghz

It's so weird and soooooo annoying.

I have put so much time (and money) into getting this right. I have 3x AX routers in a mesh setup that is rock solid but still have the issue.

Even if i join all devices to the main router (no mesh nodes) I still have the issue.

MDNS and DNS are completely unrelated. The router has nothing to do with MDNS for the most part other than forwarding the packets for it and possibly responding with its own capabilities when queried.

If the router has issues passing multicast traffic especially over wifi that can certainly interfere with MDNS, but that isn't related to the version of MDNS on the router.

If you are seeing client.lan.local in MDNS that's because the client reported its name to MDNS in that format. Some clients probably use the domain and some don't, depends how MDNS was designed/written for that particular vendor/OS. There are several different standards and of course Apple will always be different than everything else.

 

[SomeWhereOverTheRainBow]

That's expected, the whole point of MDNS is client based name resolution with no DNS server, every client maintains a list of other clients. That's why it uses .local. You will be able to ping the host from an MDNS enabled device but won't be able to do an nslookup for it (unless the OS has built that table into their nslookup implementation).

Its basically a dynamic hosts file on each machine.

Thanks for that explanation. I wish I had you around for when I face my toughest issues! But for now I give you the likes!

 

[drinkingbird]

Thanks for that explanation. I wish I had you around for when I face my toughest issues! But for now I give you the likes!

Not sure if you're being sarcastic or not. I'm far from an expert on MDNS other than knowing it is annoying and inconsistent. I do know multicast though. Actually that's annoying and inconsistent too but at least in the enterprise it is pretty solid for the past 15-20ish years. Over wireless, even on good enterprise stuff, still not great.

Multicast (and thus MDNS) is called an "unreliable" protocol since it uses UDP with no acknowledgements or guaranteed delivery. If you think dealing with MDNS even if a couple hundred messages per second is bad, we have a feed that is close to 40 gigs now and a bit over 3 million packets per second. True "reliable" multicast requires a separate TCP mechanism to request a retransmission of a missed packet and MDNS has nothing like that implemented, it basically sees no response from a device and just keeps trying and trying and trying and never getting the hint.

I blame apple for popularizing it. And naming it something French. (I'm French so allowed to make that joke).

 

[SomeWhereOverTheRainBow]

Not sure if you're being sarcastic or not. I'm far from an expert on MDNS other than knowing it is annoying and inconsistent. I do know multicast though. Actually that's annoying and inconsistent too but at least in the enterprise it is pretty solid for the past 15-20ish years. Over wireless, even on good enterprise stuff, still not great.

Multicast (and thus MDNS) is called an "unreliable" protocol since it uses UDP with no acknowledgements or guaranteed delivery. If you think dealing with MDNS even if a couple hundred messages per second is bad, we have a feed that is close to 40 gigs now and a bit over 3 million packets per second. True "reliable" multicast requires a separate TCP mechanism to request a retransmission of a missed packet and MDNS has nothing like that implemented, it basically sees no response from a device and just keeps trying and trying and trying and never getting the hint.

I blame apple for popularizing it. And naming it something French. (I'm French so allowed to make that joke).

No sarcasm intended. It was meant as an enthusiastic gesture (or jester) of kindness. Basically my way of saying thank you and you are pretty spot on around here.

 

[drinkingbird]

No sarcasm intended. It was meant as an enthusiastic gesture (or jester) of kindness. Basically my way of saying thank you and you are pretty spot on around here.

Ok, there are several here (or one at least) who feel differently so it can be hard to tell (not that I'd be offended either way)