@shrodi 

Have you run the troubleshooting and checked if there is anything wrong?

What are the results of each step in the guide?

From the screenshots, it looks like you simply did not configure the protocols but simply "enabled" them and expect it to work.

The mDNS is not plug-and-play. For other protocols not included, you gotta manually config.

  @Clive_A Yes, I saw and have read this guide before posting and, to the contrary, we can see from my screenshots that the desired protocols have been configured, the mere proof being that the desired mDNS broadcasts *are* repeated and forwarded by the gateway between VLANs, but the screenshots also show that those broadcasts seem to be somehow broken by the router. I have no firewall ACLs and VLANs can ping each other.

  @shrodi 

shrodi wrote

  @Clive_A Yes, I saw and have read this guide before posting and, to the contrary, we can see from my screenshots that the desired protocols have been configured, the mere proof being that the desired mDNS broadcasts *are* repeated and forwarded by the gateway between VLANs, but the screenshots also show that those broadcasts seem to be somehow broken by the router. I have no firewall ACLs and VLANs can ping each other.

A diagram with IP specified.

Protocols have been set for the mDNS.

Is that possible for a remote desktop or your backup, so we can import and investigate? Might need your assistance to reproduce this issue.

  @Clive_A I would be pleased to help in anyway I can.

I've tried to send you a link in private to an online folder containing a controller .cfg backup file and some screenshots with a Readme.md file with some explanations, but the system told me you needed to follow me first for me to be able to message you.

  @Clive_A Here's an update. I wanted to create a live demo of what happens to the packets from source vlan to destination vlan, and what I observed is that sometimes they are forwarded correctly, without being malformed, and are then picked up by the client. However, strangely, I have two printers and 1) only one of them gets its packets malformed and 2) the second one seems to always have good packets forwarded, but is not discovered. I will continue to investigate and update.

  @Clive_A I've disabled mDNS on the ER8411 and have setup Avahi an old pfSense box that was still lying around, and I get the same result (do you use Avahi internally on the ER8411?), which is exactly the problem described here.

  @shrodi 

shrodi wrote

  @Clive_A I would be pleased to help in anyway I can.

 

I've tried to send you a link in private to an online folder containing a controller .cfg backup file and some screenshots with a Readme.md file with some explanations, but the system told me you needed to follow me first for me to be able to message you.

You can send it now. 

  @shrodi 

shrodi wrote

  @Clive_A I've disabled mDNS on the ER8411 and have setup Avahi an old pfSense box that was still lying around, and I get the same result (do you use Avahi internally on the ER8411?), which is exactly the problem described here.

I do not have this information. And if I have, I am not able to share any information regarding the system components.

  @shrodi 

shrodi wrote

  @Clive_A OK, so I managed to patch avahi-app-0.8 on my pfSense (v2.8.0) with this workaround suggested here and it worked: now my printers are correctly seen on all my VLANs! 

 

After a ton of tcpdump/iperf/nc investigations, it is well apparent to me that the ER8411 is using avahi 0.8 (or earlier) for mDNS forwarding because I could see the exact same NSEC record packet malformations using either the ER8411 with firmware v1.3.1 or pfSense with avahi-app-0.8. It is important to mention that tose malformations occur only for NSEC records, so yes mDNS forwarding on the ER8411 with firmware v1.3.1 will work for mDNS-published services that don't use NSEC.

 

So TP-Link could probably fix this specific problem by using the same patch as me, but I guess the reasonable choice for them would rather be to wait for the official avahi 0.9.1 milestone (the one scheduled to include a fix), which has no due date yet...

 

I don't know all the exact repercussions of disabling NSEC forwarding with the patch, but from what I gather they seem quite mild. We can see from this commit from another project that an option for disabling this workaround is possible, so that could be another way to go for TP-Link (i.e., patching with the workaround but include an option in the mDNS settings for enabling or disabling this workaround).

Wonderful to know. 

As the dev has noticed your reply and information. We will look into it.