Project

General

Profile

Bug #24942

Register mDNS on all interfaces

Added by Siegfried Leonard over 1 year ago. Updated 2 months ago.

Status:
Resolved
Priority:
Blocks Until Resolved
Assignee:
John Hixson
Category:
Middleware
Target version:
Seen in:
Sprint:
Severity:
Backlog Priority:
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Intel i5 CPU with Q87 chipset and all Intel network cards (PCIe/onboard)

ChangeLog Required:
No

Description

Going to e.g. AFP or SMB service setting and selecting a particular interface to listen to will not stop mdns from advertising on the same interfaces as before. It looks like mdns is "fixed" to advertise on the "first" interface of the system regardless.

For Mac clients this makes the server show in the network but cannot connect because it's advertising the wrong IP. All .local DNS queries go to the wrong IP and I get complains and tell people to connect by the IP address instead (or hostname without .local - but that's dangerous because some add .local by habit anyway)

This could be fixed with my feature request here: Feature #24941

Adding an option to order interfaces by priority (or a "default" interface option) might be a good idea. It could apply to mdns to start, and progress to allow other services when they have to choose a default interface for something.

Thanks


Related issues

Related to FreeNAS - Feature #24941: Allow mdns to exclude certain interface from advertising (e.g. management port) OR introduce ordering interface prioritiesClosed: Duplicate2017-06-30

Associated revisions

Revision 7350fc2a (diff)
Added by William Grzybowski about 1 year ago

fix(src): register mdns on all interfaces

In the future we will want to make that an option in the UI.

Ticket: #24942

Revision dd693aef (diff)
Added by William Grzybowski about 1 year ago

fix(src): register mdns on all interfaces

In the future we will want to make that an option in the UI.

Ticket: #24942

Revision b95cead2 (diff)
Added by John Hixson 11 months ago

mDNS fixes for Samba (work in progress).

Ticket: #24942

Revision 3e7d2a93 (diff)
Added by John Hixson 11 months ago

Fork mDNSResponder

Ticket: #24942

Revision d780ac24 (diff)
Added by John Hixson 11 months ago

Fork mDNSResponder

Ticket: #24942

Revision d4257a63 (diff)
Added by John Hixson 11 months ago

Fork mDNSResponder

Ticket: #24942
(cherry picked from commit 3e7d2a935ec6d5420d37d302c1b2562af99b25c0)

Revision 5bad06ec (diff)
Added by John Hixson 11 months ago

Fork mDNSResponder

Ticket: #24942
(cherry picked from commit 3e7d2a935ec6d5420d37d302c1b2562af99b25c0)

Revision 8bc66dd6 (diff)
Added by John Hixson 11 months ago

mDNS fixes for Samba (work in progress).

Ticket: #24942
(cherry picked from commit b95cead2b13bc1b51ac057e629ba813fb7c320f8)

Revision 43fc0435 (diff)
Added by John Hixson 11 months ago

Fork mDNSResponder

Ticket: #24942
(cherry picked from commit d780ac24f59435e1894d137be8e77e522c54d23e)

Revision 640088ce (diff)
Added by John Hixson 11 months ago

Freenas/11.1 stable netatalk fork (#12)

  • Build with forked netatalk

(cherry picked from commit 696ea2c4a42c83c649230bb1cda812b4d534ba8c)

  • Fork mDNSResponder

Ticket: #24942
(cherry picked from commit 3e7d2a935ec6d5420d37d302c1b2562af99b25c0)

  • Use freenas/11.1-stable branch

Revision caf6e210
Added by John Hixson 11 months ago

Freenas/11.1 stable mdnsresponder fork (#13)

  • Fork mDNSResponder

Ticket: #24942
(cherry picked from commit 3e7d2a935ec6d5420d37d302c1b2562af99b25c0)

  • Use freenas/11.1-stable branch

Revision 923bc7a1 (diff)
Added by John Hixson 10 months ago

Freenas/master mdns fixes (#22)

  • mDNS fixes for Samba (work in progress).

Ticket: #24942

  • Fix mDNS - Can advertise on individual interfaces
  • Fix mDNS browsing in smbclient

Revision f3973ea4 (diff)
Added by John Hixson 10 months ago

Freenas/11.1 stable mdns fixes (#23)

  • mDNS fixes for Samba (work in progress).

Ticket: #24942
(cherry picked from commit b95cead2b13bc1b51ac057e629ba813fb7c320f8)

  • Fix mDNS - Can advertise on individual interfaces

(cherry picked from commit fe0738122fd86bb17be9c46ac74d0c3c9ead8007)

  • Fix mDNS browsing in smbclient

(cherry picked from commit 3144a6518d686350c50a85442a3d57748d812a97)

Revision 576dc49e (diff)
Added by John Hixson 6 months ago

Fork mDNSResponder

Ticket: #24942

Revision ef42d8fe (diff)
Added by John Hixson 6 months ago

Freenas/master mdns fixes (#22)

  • mDNS fixes for Samba (work in progress).

Ticket: #24942

  • Fix mDNS - Can advertise on individual interfaces
  • Fix mDNS browsing in smbclient

(cherry picked from commit 923bc7a1afeb0b920e60e14846987ae1d2d7dca4)

Revision 708bcb3d (diff)
Added by John Hixson 6 months ago

Fork mDNSResponder

Ticket: #24942

Revision 8c52f63d (diff)
Added by John Hixson 6 months ago

Fork mDNSResponder

Ticket: #24942

Revision f57decf5 (diff)
Added by John Hixson 2 months ago

Freenas/master mdns fixes (#22)

  • mDNS fixes for Samba (work in progress).

Ticket: #24942

  • Fix mDNS - Can advertise on individual interfaces
  • Fix mDNS browsing in smbclient

(cherry picked from commit 923bc7a1afeb0b920e60e14846987ae1d2d7dca4)

Revision 73872f5d (diff)
Added by John Hixson 26 days ago

Fork mDNSResponder

Ticket: #24942

Revision 15674195 (diff)
Added by John Hixson 25 days ago

Fork mDNSResponder

Ticket: #24942

Revision 0a03a5a6 (diff)
Added by John Hixson 25 days ago

Fork mDNSResponder

Ticket: #24942

Revision 961d3917 (diff)
Added by John Hixson 22 days ago

Fork mDNSResponder

Ticket: #24942

History

#1 Updated by Siegfried Leonard over 1 year ago

I realize that the service settings go by IP address, and mdns goes by interface. To really solve this, there would be have to be a way to configure mdns on the IP level.

In the interim we could allow mdns configurable on the interface level and mention in the documentation that mdns would have to be configured in addition to the "Bind IP Addresses" option, but that it only supports interfaces for now.

#2 Updated by William Grzybowski over 1 year ago

  • Status changed from Unscreened to Screened
  • Priority changed from No priority to Nice to have
  • Target version set to 11.2-BETA1

#3 Updated by Siegfried Leonard over 1 year ago

Just a more clear idea: Shouldn't mdns send broadcasts on each network the ip address of that network?

Say:
  • em0 = 10.10.10.1
  • lagg0 = 192.168.1.1
  • hostname = fserve

Shouldn't 10.10.10.0/24 (or whatever mask is) broadcast advertise fserve.local to be 10.10.10.1 and broadcasts on 192.168.1.1 interface resolve to 192.168.1.1? Because they might be completely different networks. It makes sense to advertise different IPs on different interfaces in general, doesn't it? And don't get mad, but does anyone know how OS X does this? I haven't had issues with Mac's and multiple interfaces like this, even working on Xserve's a lot. Thanks!

#4 Updated by Ash Gokhale about 1 year ago

  • File bind_trace.dtrace added
  • File recvmsg_snoop.dtrace added

Trivially easy to reproduce and is now a concern for TrueNAS customers as well. I'm not sure mdnsd is in the wrong yet. The afpd setting for port bindings are working however they have no effect on mdns.

mdnsd binds to 0.0.0.0:5353 but only ever recvmsg's from one interface. Frames destined for the alternate interface:5353 never get delivered to userland.

Dtrace scripts that verify the binding and snoop the application recvmsg are attached. I'm suspicious of an OS or routing configuration bug.

#5 Updated by Ash Gokhale about 1 year ago

os is off the hook for this behaviour;

If we listen on all interfaces on a port
via:
nc -u -k -l 5354

dig badger.local @192.168.1.249 p 5354 <-- this one hits
dig badger.local @192.168.254.1 p 5354 < - this one hits too

#6 Updated by an odos about 1 year ago

Ash Gokhale wrote:

Trivially easy to reproduce and is now a concern for TrueNAS customers as well. I'm not sure mdnsd is in the wrong yet. The afpd setting for port bindings are working however they have no effect on mdns.

mdnsd binds to 0.0.0.0:5353 but only ever recvmsg's from one interface. Frames destined for the alternate interface:5353 never get delivered to userland.

Dtrace scripts that verify the binding and snoop the application recvmsg are attached. I'm suspicious of an OS or routing configuration bug.

Perhaps register_mdns.py needs to pass along "interfaceIndex = 0" to pybonjour. (I believe "0" means "all interfaces") i.e.:

def register(name, regtype, port):
    sdRef = pybonjour.DNSServiceRegister(name=name,
                                         interfaceIndex=0,
                                         regtype=regtype,
                                         port=port,
                                         callBack=None)

It defaults to "interfaceIndex = kDNSServiceInterfaceIndexAny", which should work, but ¯\_(ツ)_/¯

Big picture, I think interfaceIndex should perhaps be configurable in the FreeNAS UI.

#7 Updated by William Grzybowski about 1 year ago

  • Status changed from Screened to Ready For Release
  • Target version changed from 11.2-BETA1 to 11.1

an odos wrote:

Ash Gokhale wrote:

Trivially easy to reproduce and is now a concern for TrueNAS customers as well. I'm not sure mdnsd is in the wrong yet. The afpd setting for port bindings are working however they have no effect on mdns.

mdnsd binds to 0.0.0.0:5353 but only ever recvmsg's from one interface. Frames destined for the alternate interface:5353 never get delivered to userland.

Dtrace scripts that verify the binding and snoop the application recvmsg are attached. I'm suspicious of an OS or routing configuration bug.

Perhaps register_mdns.py needs to pass along "interfaceIndex = 0" to pybonjour. (I believe "0" means "all interfaces") i.e.:

[...]

It defaults to "interfaceIndex = kDNSServiceInterfaceIndexAny", which should work, but ¯\_(ツ)_/¯

Big picture, I think interfaceIndex should perhaps be configurable in the FreeNAS UI.

Thanks for that! I have committed that fix. We will eventually have it as an option in the UI (#24941), but for now this will do.

#8 Updated by William Grzybowski about 1 year ago

  • Related to Feature #24941: Allow mdns to exclude certain interface from advertising (e.g. management port) OR introduce ordering interface priorities added

#9 Updated by an odos about 1 year ago

William Grzybowski wrote:

an odos wrote:

Ash Gokhale wrote:

Trivially easy to reproduce and is now a concern for TrueNAS customers as well. I'm not sure mdnsd is in the wrong yet. The afpd setting for port bindings are working however they have no effect on mdns.

mdnsd binds to 0.0.0.0:5353 but only ever recvmsg's from one interface. Frames destined for the alternate interface:5353 never get delivered to userland.

Dtrace scripts that verify the binding and snoop the application recvmsg are attached. I'm suspicious of an OS or routing configuration bug.

Perhaps register_mdns.py needs to pass along "interfaceIndex = 0" to pybonjour. (I believe "0" means "all interfaces") i.e.:

[...]

It defaults to "interfaceIndex = kDNSServiceInterfaceIndexAny", which should work, but ¯\_(ツ)_/¯

Big picture, I think interfaceIndex should perhaps be configurable in the FreeNAS UI.

Thanks for that! I have committed that fix. We will eventually have it as an option in the UI (#24941), but for now this will do.

Did this actually fix the problem? I forgot that I wrote this, and now looking back on it don't see how it could have fixed anything. :-)

#10 Updated by William Grzybowski about 1 year ago

  • Status changed from Ready For Release to Screened

Hah, you're right, it doesn't. Somehow I thought it did, but testing again I see it does not. Thanks!

#11 Updated by Joshua Sirrine about 1 year ago

Any update on when this will be fixed? A TrueNAS customer is waiting on this to be fixed. Is this really planned for 11.1?

Thanks.

#12 Updated by William Grzybowski about 1 year ago

Joshua Sirrine wrote:

Any update on when this will be fixed? A TrueNAS customer is waiting on this to be fixed. Is this really planned for 11.1?

Thanks.

Yes, it is targeted for 11.1. Unless you can clarify why it is important, because it seems this issues exists for quite some time and no flags had been raised until now.

#14 Updated by Dru Lavigne about 1 year ago

  • Status changed from Screened to Ready For Release
  • Target version changed from 11.1 to 11.1-BETA1

#15 Updated by Dru Lavigne about 1 year ago

  • File deleted (bind_trace.dtrace)

#16 Updated by Dru Lavigne about 1 year ago

  • File deleted (recvmsg_snoop.dtrace)

#18 Updated by Dru Lavigne about 1 year ago

  • Subject changed from mdns advertises on wrong interface despite service settings to Register mdns on all interfaces

#19 Updated by William Grzybowski about 1 year ago

  • Status changed from Ready For Release to Screened
  • Target version changed from 11.1-BETA1 to 11.1

Dru, why did you change the status of this ticket?

#21 Updated by William Grzybowski 12 months ago

  • Assignee changed from William Grzybowski to John Hixson

John agreed to take care of this since he is owning mdns in middleware.

#22 Avatar?id=14398&size=24x24 Updated by Kris Moore 12 months ago

  • Target version changed from 11.1 to 11.1-U1

#24 Avatar?id=14398&size=24x24 Updated by Kris Moore 11 months ago

  • Priority changed from Nice to have to Blocks Until Resolved
  • Target version changed from 11.1-U1 to 11.1

John - Bumping this one up, we really need to get it into 11.1 for several customers. Thanks!

#25 Updated by Dru Lavigne 11 months ago

  • Private changed from No to Yes

#26 Updated by John Hixson 11 months ago

So there are multiple issues here ;-) Just blindly "registering mdns on all interfaces" is not the solution. mDNSResponder isn't even the problem here, it just does what it's told. In the case of SMB, samba is very dumb here, if you enable mdns it will just blindly register on all interfaces even if only listening on one. I haven't checked AFP yet but I suspect the same. There are multiple ways to fix this. For Samba and Netatalk, we can fix the code to do things correctly when bound to certain IP addresses or interfaces, but this gets difficult because mDNSResponder only deals with interfaces, not IP addresses. The alternative is just to register services manually. This gives us the flexibility to register per interface and we can handle all the IP->interface logic external to the application. I'm still digging into this and will post more as I come up with a better solution than what we currently have. The topic for this ticket is misleading ;-)

#27 Updated by John Hixson 11 months ago

This just continues to get better. I had working Netatalk code that mysteriously stopped working as intended (I found it to stop working as intended when working on similar code for Samba). I banged my head into the wall for quite a while until I figured out whatever version of mDNSResponder I previously had , had been upgraded.. and in turn, behaved differently. I still don't know what version I was working with, but I do know that the version in FreeNAS 11.0-stable only advertises services on interface 0 while the version in 11.1-stable advertises on all interfaces. Both do this regardless of how you register with DNSServiceRegister(). This is so ridiculous it's amusing. So now I need to dig into mDNSResponder and sort out what has changed, what should change, what shouldn't change and how it should behave. I think I have working SMB mDNS code but can't be sure until mDNSResponder behaves correctly ;-) The plot thickens...

#28 Updated by John Hixson 11 months ago

Just to clarify, the DNSServiceRegister() function, should do exactly what it is told. If you want to advertise _smb._tcp or _afpovertcp._tcp on all interfaces, you specify the interfaceIndex as 0. If you want to advertise on a specific interface, you specify that interfaces index. Currently, in FreeNAS 11.1-stable, ALL interfaces are advertised on regardless of what index is specified. On FreeNAS 11.0-stable, only interface 0 is advertised on, no matter what interfaceIndex you specify. Neither of these are the correct behavior ;-) We must whip mDNSResponder into shape or nuke it from orbit. I'm beginning to learn towards the latter.

#29 Updated by John Hixson 11 months ago

After reviewing the mDNSResponder code (in the latest version), it mostly works. While it doesn't do exactly what you want, it does work. If you register a service on a single interface, or multiple interfaces, but not on others, it will prioritize the specified interfaces before all others. IMO, if you register a service to only be on a single interface of a multi-homed, box, mDNS should only resolve to that interface. I'm okay with this behavior however. I have committed code that fixes Samba and Netatalk to do the right thing here. Here are the pull requests:

freenas/build:
https://github.com/freenas/build/pull/11

freenas/samba:
https://github.com/freenas/samba/pull/22

freenas/netatalk:
https://github.com/freenas/Netatalk/pull/1

freenas/ports:
https://github.com/freenas/ports/pull/50
https://github.com/freenas/ports/pull/51
https://github.com/freenas/ports/pull/52

I will wait for all of these to be merged into master before I begin the convoluted process of bringing all these changes into stable ;-)

#30 Updated by John Hixson 11 months ago

  • Status changed from Screened to Needs Developer Review
  • Assignee changed from John Hixson to Release Council

#31 Updated by Dru Lavigne 11 months ago

  • Subject changed from Register mdns on all interfaces to Register mDNS on all interfaces

#32 Updated by Dru Lavigne 11 months ago

  • Private changed from Yes to No

#33 Updated by Dru Lavigne 11 months ago

  • Assignee changed from Release Council to Timur Bakeyev

Timur: can you review this?

#35 Avatar?id=14398&size=24x24 Updated by Kris Moore 11 months ago

  • Status changed from Needs Developer Review to Reviewed by Developer
  • Assignee changed from Timur Bakeyev to John Hixson

All merged in

#36 Updated by Dru Lavigne 11 months ago

  • Status changed from Reviewed by Developer to 47

#37 Updated by Joe Maloney 10 months ago

  • Needs QA changed from Yes to No
  • QA Status Test Passes FreeNAS added
  • QA Status deleted (Not Tested)

#38 Updated by Joe Maloney 10 months ago

  • Status changed from 47 to Ready For Release

#39 Updated by Dru Lavigne 10 months ago

  • Status changed from Ready For Release to Resolved

Also available in: Atom PDF