Project

General

Profile

Feature #24941

Allow mdns to exclude certain interface from advertising (e.g. management port) OR introduce ordering interface priorities

Added by Siegfried Leonard over 3 years ago. Updated about 3 years ago.

Status:
Closed: Duplicate
Priority:
Expected
Assignee:
John Hixson
Category:
Middleware
Target version:
N/A
Estimated time:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Intel i5 on Q87 chipset with Intel network cards.

Description

With multiple interfaces configured, it appears the first one (?) is used to advertise services on mdns.

If you use Link Aggregation like me, then you have a problem if you want that to be your main interface for clients that use mdns, e.g. Mac clients.

I use em0 as my "management port" but I want all clients to go through lagg0. I keep the "management port" on the same network because I like using it sometimes for certain things, file transfers, etc, without disrupting the normal lagg0 traffic. But even if you put it onto another network entirely, the problem won't go away as it'll still keep advertising the same IPs as long as the interface is configured.

Going to Services and changing the settings to only listen to lagg0 IPs does nothing. It looks like mdns is set to advertise whatever interface is "first".

If there was a way to reorder interfaces to the priority you want (like you can on OS X), or if there was a way to disable interfaces for mdns such that it uses the next available interface instead, that would fix this.

That's why avahi had the 'deny-interfaces' and 'allow-interfaces' options, which were REALLY handy. We need something like this for the current mdns implementation.

Thanks!

Related issues

Related to FreeNAS - Bug #24942: Register mDNS on all interfacesResolved

History

#1 Updated by William Grzybowski over 3 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 11.2-BETA1

#2 Updated by T F over 3 years ago

Seconding this. I've been trying to track down this exact issue and finally found your forum thread @ https://forums.freenas.org/index.php?threads/disable-mdns-on-management-interface.55766/ which led me to this & https://bugs.freenas.org/issues/24942

Currently my FreeNAS systems are broadcasting out a management vlan interface so none of my mac clients on other vlans can see them in Finder.app

EDIT: Actually, my issue might be a bit different than yours or maybe you hacked something ... my mac clients on vlanX don't even see the advertisements FreeNAS is sending on vlanY. You seem to be implying your mac clients on vlanX do see the advertisement, but it's to an IP address that is bound to vlanY on the FreeNAS side therefore they cannot connect?

#3 Updated by Ash Gokhale over 3 years ago

This is odd - we are seeing it in the field as well I'm not sure if where this bug is yet.
mdns respondr is binding to 0.0.0.0:5353; the mcast frame arrives at the (alternate) interface, but it's never getting the frames at recvmsg.

I will be working this from the bug side; I'm inclined to make the feature req a dup.

#4 Updated by Siegfried Leonard over 3 years ago

Thanks so much for looking into this guys so quickly. It's great to see such non-critical bugs are still dealt with a serious manner. Way to go! :)

Sorry if this message is distracting. Just want to thank you for your work and if there is a way I can help with testing or something, let me know. Thanks!

#5 Updated by Ash Gokhale over 3 years ago

Breaking time machine for any nontrivial network is pretty serious .

#6 Updated by William Grzybowski over 3 years ago

  • Related to Bug #24942: Register mDNS on all interfaces added

#7 Updated by William Grzybowski over 3 years ago

  • Status changed from Screened to Unscreened
  • Assignee changed from William Grzybowski to John Hixson

John, since you have the other mdns ticket can you look at this as well?

#8 Updated by John Hixson over 3 years ago

  • Status changed from Unscreened to Screened

#9 Updated by Kevin Fleming over 3 years ago

I've run into this as well; my ideal configuration would be to allow each service (at least the Web GUI, AFP, and SMB) to only be broadcast on the interfaces they are bound to, and only on the addresses they are bound to as well.

#10 Avatar?id=13649&size=24x24 Updated by Ben Gadd about 3 years ago

  • Status changed from Screened to Resolved

#12 Updated by Dru Lavigne about 3 years ago

  • Status changed from Resolved to Closed: Duplicate
  • Target version changed from 11.2-BETA1 to N/A

Also available in: Atom PDF