mDNSResponder Issue with two network interfaces

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

I do have two network interfaces on my server ( one for "public" and one as "admin" network only ). The setup worked fine with net/mDNSResponder and net/netatalk3 . I configured the two networks in /usr/local/etc/afp.conf by restricting the netatalk to listen and response only to the public interface.

Then I upgraded to the current version of net/mDNSResponder and the trouble started: All services are bound to the first interface found - which is the admin interface.
While I can restrict net/netatalk to listen only to the public interface, net/mDNSResponder advertises only the first interface.

So all clients try to connect through the admin network ( which doesn't work as netatalk correctly listen only to the public interface ). My current workaround is, that netatalk also listen to the admin network and then all connections are working.

I think this is clearly a bug in net/mDNSResponder - and to my shame I have deleted the old working version. I have sent emails to the port owner , but nothing happens. Can I go to bugzilla and request this is a bug ? Any suggestions ?
 

obsigna

Daemon

Reaction score: 899
Messages: 1,295

I am using a modified net/mDNSResponder, since I wanted to force it to listen and respond only on one particular network interface, and at the time before I applied the respective patch, it utilized all interfaces on my machine.

Therefore, I cannot exactly verify your error report, because my mDNSResponder is listening to only one interface anyway, however, perhaps my patch would be also helpful in your case, namely by forcing mDNSResponder to listen/respond on your public network interface only:
Code:
--- mDNSPosix/Responder.c.orig    2011-12-01 22:39:45.000000000 -0200
+++ mDNSPosix/Responder.c    2014-08-21 13:36:58.000000000 -0300
@@ -209,7 +209,7 @@
 static void PrintUsage()
 {
     fprintf(stderr,
-            "Usage: %s [-v level ] [-r] [-n name] [-t type] [-d domain] [-p port] [-f file] [-b] [-P pidfile] [-x name=val ...]\n",
+            "Usage: %s [-v level ] [-r] [-n name] [-i iface] [-t type] [-d domain] [-p port] [-f file] [-b] [-P pidfile] [-x name=val ...]\n",
             gProgramName);
     fprintf(stderr, "          -v verbose mode, level is a number from 0 to 2\n");
     fprintf(stderr, "             0 = no debugging info (default)\n");
@@ -218,6 +218,7 @@
     fprintf(stderr, "             can be cycled kill -USR1\n");
     fprintf(stderr, "          -r also bind to port 53 (port 5353 is always bound)\n");
     fprintf(stderr, "          -n uses 'name' as the service name (required)\n");
+    fprintf(stderr, "          -i only binds to the interface 'iface'\n");
     fprintf(stderr, "          -t uses 'type' as the service type (default is '%s')\n", kDefaultServiceType);
     fprintf(stderr, "          -d uses 'domain' as the service domain (default is '%s')\n", kDefaultServiceDomain);
     fprintf(stderr, "          -p uses 'port' as the port number (default is '%d')\n",  kDefaultPortNumber);
@@ -231,6 +232,8 @@
     fprintf(stderr, "             all subsequent arguments after -x are treated as name=val pairs.\n");
 }

+extern const char *gInterfaceName;
+
 static mDNSBool gAvoidPort53      = mDNStrue;
 static const char *gServiceName      = "";
 static const char *gServiceType      = kDefaultServiceType;
@@ -260,7 +263,7 @@
     // Parse command line options using getopt.

     do {
-        ch = getopt(argc, argv, "v:rn:t:d:p:f:dP:bx");
+        ch = getopt(argc, argv, "v:rn:i:t:d:p:f:dP:bx");
         if (ch != -1) {
             switch (ch) {
             case 'v':
@@ -281,6 +284,9 @@
                     exit(1);
                 }
                 break;
+            case 'i':
+                gInterfaceName = strcpy(malloc(strlen(optarg)+1), optarg);
+                break;
             case 't':
                 gServiceType = optarg;
                 if ( !CheckThatServiceTypeIsUsable(gServiceType, mDNStrue) ) {
--- mDNSPosix/mDNSPosix.c.orig    2014-08-21 11:39:02.000000000 -0300
+++ mDNSPosix/mDNSPosix.c    2014-08-21 11:43:26.000000000 -0300
@@ -923,6 +923,8 @@
     return err;
 }

+const char *gInterfaceName = NULL;
+
 // Call get_ifi_info() to obtain a list of active interfaces and call SetupOneInterface() on each one.
 mDNSlocal int SetupInterfaceList(mDNS *const m)
 {
@@ -950,7 +952,8 @@
         struct ifi_info *i = intfList;
         while (i)
         {
-            if (     ((i->ifi_addr->sa_family == AF_INET)
+            if ((!gInterfaceName || !strcmp(i->ifi_name, gInterfaceName))
+                  && ((i->ifi_addr->sa_family == AF_INET)
 #if HAVE_IPV6
                       || (i->ifi_addr->sa_family == AF_INET6)
 #endif
--- mDNSCore/mDNS.c.orig    2014-08-21 19:32:41.000000000 -0300
+++ mDNSCore/mDNS.c    2014-08-21 19:33:07.000000000 -0300
@@ -12777,7 +12777,7 @@
     if (!set->InterfaceID)
     { LogMsg("mDNS_RegisterInterface: Error! Tried to register a NetworkInterfaceInfo %#a with zero InterfaceID", &set->ip); return(mStatus_Invalid); }

-    if (!mDNSAddressIsValidNonZero(&set->mask))
+    if (0 && !mDNSAddressIsValidNonZero(&set->mask))
     { LogMsg("mDNS_RegisterInterface: Error! Tried to register a NetworkInterfaceInfo %#a with invalid mask %#a", &set->ip, &set->mask); return(mStatus_Invalid); }

     mDNS_Lock(m);
This patch is now more than 2 years old, and perhaps the changes in mDNSCore/mDNS.c are no more necessary. If you want to try the patch above, save its content into a file at /usr/ports/net/mDNSResponder/files/patch-zz-bind.local, and then issue the following command: cd /usr/ports/net/mDNSResponder; make deinstall clean; make install clean

In my file /etc/rc.conf, I got:
Code:
...
mdnsresponderposix_enable="YES"
mdnsresponderposix_flags="-i bridge0 -f /root/config/mDNSServices.conf"
...
Another option would be to switch back to the version that worked for you. The previous version was 576.30.4, and you can re-install this by the way of the FreeBSD SVN-repository as follows:

mkdir -p ~/my_old_ports
cd ~/my_old_ports
svn checkout -r 398835 http://svn.freebsd.org/ports/head/net/mDNSResponder mDNSResponder-576.30.4
cd mDNSResponder-576.30.4
pkg delete mDNSResponder
make install clean
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

Hmm, the patch is something I would like to try tomorrow my daytime. I assume you also give the parameter via /etc/rc.conf with
Code:
mdnsresponderposix_flags = "... -i public ..."
, correct ?
 

obsigna

Daemon

Reaction score: 899
Messages: 1,295

Hmm, the patch is something I would like to try tomorrow my daytime. I assume you also give the parameter via /etc/rc.conf with
Code:
mdnsresponderposix_flags = "... -i public ..."
, correct ?
Yes, sorry, I forgot that tiny detail in my first response. I added, it meanwhile, and here it comes once again:

In my file /etc/rc.conf, I got:
Code:
...
mdnsresponderposix_enable="YES"
mdnsresponderposix_flags="-i bridge0 -f /root/config/mDNSServices.conf"
...
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

Thanks again . Are you using this with net/netatalk3 ? I just wonder, because normally everything is configured inside the afp.conf and so what should go inside a mDNSServices.conf , when Netatalk is the only service ?
 

obsigna

Daemon

Reaction score: 899
Messages: 1,295

Well, I started using mDNSResponder when net/netatalk v2 was still the latest version, and that one wasn't that smart about automatic service announcements. So, I configured everything with mDNSServices.conf, and I simply kept it this way:
Code:
Server
_afpovertcp._tcp
548
title='AFP Server'

Server
_ftp._tcp
21
title='FTP Server'

Server
_adisk._tcp
9
sys=waMa=0,adVF=0x100,adVU=88fcfd34-3092-11e4-aa48-7071bc633b8c
dk0=adVF=0xa1,adVN=Backups

Server
_device-info._tcp
548
model=Xserve
Recently, net/netatalk3 started complaining:
Code:
dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mdnsd Socket:5 Err:-1 Errno:2 No such file or directory
As a matter of fact I do not have running mdnsd. I still need to figure out how to silence Netatalk's complaints.
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

Ahh, here is the difference: I am using net/netatalk3 and do the zero-cont also inside of afp.conf. So I have no mDNSResponderPosix running, nor do I need a config file for it. Your setup is the opposite: you are running only mDNSResponderPosix and use that conf file.

If you compile net/netatalk3 without any zero-cont and then install mDNSResponder, you will not see the error. I assume that netatalk tries to connect to mdnsd to send the afp.conf parameters for an advertising.

So, I will need to apply your changes to mdnsd instead of mDNSResponder
 

obsigna

Daemon

Reaction score: 899
Messages: 1,295

I didn't look into the afp.conf(5) settings for quite a long time, and I cannot remember to have ever seen the following global setting:
Code:
       afp interfaces = name [name ...] (G)
           Specifies the network interfaces that the server should listens on.
           The default is advertise the first IP address of the system, but to
           listen for any incoming request.
Since in your case, you let Netatalk do the heavy zeroconf lifting, the default behaviour sounds pretty much being related to your problem. I suggest to add to the Global section of afp.conf the respective definition for your public interface.
Code:
[Global]
...
afp interfaces = <public interface>
...
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

You are right. I did this already in the last configuration and it has worked well. Today it is very strange: when I use a
Code:
afp interfaces = <hostname>
no connection will be able. That might be as this conf setup is wrong. when I use the interface name a connection is able , but it uses still the wrong interface.

I check on my macOS side with bonjour browser http://www.tildesoft.com and with netstat on FreeBSD system. I will try a bit around and also try to see if I can't patch
Code:
mdnsd

BTW: I also use
Code:
afp listen = <IP public network>:548
and also
Code:
cmid server
and
Code:
cmid listen
 

obsigna

Daemon

Reaction score: 899
Messages: 1,295

I don't think that patching mdnsd in a similar fashion like I did with mDNSResponderPosix would give a useful result. mdnsd is the service discovery daemon, and I have my doubts that it is listening for multicast DNS request on UDP port 5353. Please run the following command:
sockstat | grep 5353

In my case the result is:
Code:
root     mDNSRespon 1079  5  udp4   *:5353                *:*
root     mDNSRespon 1079  6  udp6   *:5353                *:*
On my system mDNSResponderPosix is the daemon listening/responding on the udp ports 5353, and therefore mDNSResponderPosix was the correct target of the patch.

You may want to start your troubleshooting with the daemon that is listening on udp:5353 on your system.

BTW, net/netatalk3 has been updated last night, and now mine is not complaining any more that it cannot connect to a not running mdnsd.
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

Code:
mDNSResponderPosix
is not running on my system ( when I do a ps -ajxd ) and sockstat | grep 5353 will result in
Code:
nobody   mdnsd      1454  5  udp4   *:5353                *:*
( I only use TCP4 )

I just tried with
Code:
log level = maxdebug
to identify what netatalk is advertising. ( At the moment I can only say , if you want to do a Barbecue with your MacBookPro, then enable this and let Timemaschine run :cool: )

Good point to check net/netatalk3. My concern is, that the bug was upcoming when I changed net/mDSNResponder pkg - so I doubt that netatalk will need to fix something, but you never know: They say within afp.conf, that for afp interface = name the default is the first interface found
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

I did the update to the new net/netatalk3 version 3.1.10_2,1 - not better :( I also looked in some source from files and have seen that netatalk maybe also ignores the afp interfaces = <public network card> )

So I could either do my own mDNSResponderPosix.conf setup or I need to select the shares under macOS with "Go to ...connect server"
 

obsigna

Daemon

Reaction score: 899
Messages: 1,295

I did the update to the new net/netatalk3 version 3.1.10_2,1 - not better :( I also looked in some source from files and have seen that netatalk maybe also ignores the afp interfaces = <public network card> )

In my setup, net/netatalk3 does obey my afp interfaces = definition. However, I do not confuse afpd by defining at the same time afp listen =.

In my file /usr/local/etc/afp.conf
Code:
[Global]
...
afp interfaces = bridge0
...
With this in place, Netatalk generates the following messages on starting up:
Code:
Oct 20 22:22:57 server netatalk[1204]: Netatalk AFP server starting
Oct 20 22:22:57 server cnid_metad[1206]: CNID Server listening on localhost:4700
Oct 20 22:22:57 server afpd[1205]: Netatalk AFP/TCP listening on interface bridge0 with address 192.168.0.1:548
Oct 20 22:22:57 server afpd[1205]: Netatalk AFP/TCP listening on interface bridge0 with address fd7d:ae04:94b7:b0a4::1:548

So I could either do my own mDNSResponderPosix.conf setup or I need to select the shares under macOS with "Go to ...connect server"

Why don't you simply reinstall the old version of net/mDNSResponder that worked for you? See my second suggestion in my first reply to your initial post.
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

Why don't you simply reinstall the old version of net/mDNSResponder that worked for you?

I tried it today - and thanks for the detailed steps - made it easy !

Now, here is the result. Today I know more and also where to look. So I can say also that old version has not worked either. It is a bit better as it advertises all networks, but it also ignores the restrictions on the admin network.

at least it now also advertises my public network, So a connection is faster made ... I give up and will open a bug report for mDNSResponder. BTW: the source has been removed from the Apple sites. Looks like they do heavy work on this package in the moment.

[Update]
Ok, of course I have not yet applied your patch to the net/mDNSResponder source. I think I will do this and stay with the mDNSresponder. It means that I need to maintain an extra configuration as net/netatalk3 then will not be used to advertise through afp.conf.
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

Why don't you simply reinstall the old version of net/mDNSResponder that worked for you? See my second suggestion in my first reply to your initial post.

So, I have now applied the patch to the old source and everything works "as expected"; means instead of mdnsd the mdnsreponderposix is the daemon and while I still have told /usr/local/etc/afp.conf to use
Code:
Zeroconf = yes
I also use /usr/local/etc/mdnsresponder.conf to configure the Bonjour advertising on my "public-net" only.

Thanks again for your support !

[Update]

Grrrrrr - after freebsd-install of p41 and two complied packages, the mdnsresponder always crashes. So I need to dig in again ....
 
OP
P

Peacekeeper2000

Active Member

Reaction score: 4
Messages: 110

Yeah, I also looked at that package already. From a description point of view , it looked more like a query tool than a responder. On my FreeBSD Server I don't need a query tool as my Macbook is acting as the query tool provider. On my server I use /etc/hosts or the building DNS Server from my Broadband router.

Reading the man pages, it looks like a possibility as it also could publish a record. Now saying that , it has no conf-file defined - so you will need a script to publish all the services you want to have on a specific interface published.

For me this is more like a last possibility to use that package ( at the current state ). net/netatalk3 is not prepared to use it instead of net/avahi or net/mDNSResponder and so I need to do all the setup by myself including to check each time two configurations. Hmm, not sure if I want to do it for now - I was still hoping, that the new mDNSResponder-625-60-4 will fix the problems. So I think I wait until that is released and if that will not work, I will switch over to openmdns.

Anyhow, thanks for taking the time for the hint !
 
Top