# mDNSResponder Issue with two network interfaces



## Peacekeeper2000 (Oct 18, 2016)

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 (Oct 18, 2016)

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:

```
--- 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:

```
...
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`


----------



## Peacekeeper2000 (Oct 18, 2016)

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 
	
	



```
mdnsresponderposix_flags = "... -i public ..."
```
 , correct ?


----------



## obsigna (Oct 18, 2016)

Peacekeeper2000 said:


> 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
> 
> 
> 
> ...


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:

```
...
mdnsresponderposix_enable="YES"
mdnsresponderposix_flags="-i bridge0 -f /root/config/mDNSServices.conf"
...
```


----------



## Peacekeeper2000 (Oct 18, 2016)

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 (Oct 18, 2016)

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:

```
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:

```
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.


----------



## Peacekeeper2000 (Oct 18, 2016)

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 (Oct 19, 2016)

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:

```
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.

```
[Global]
...
afp interfaces = <public interface>
...
```


----------



## Peacekeeper2000 (Oct 19, 2016)

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 
	
	



```
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 
	
	



```
mdnsd
```

BTW: I also use 
	
	



```
afp listen = <IP public network>:548
```
 and also 
	
	



```
cmid server
```
 and 
	
	



```
cmid listen
```


----------



## obsigna (Oct 19, 2016)

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:

```
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.


----------



## Peacekeeper2000 (Oct 19, 2016)

```
mDNSResponderPosix
```
 is not running on my system ( when I do a `ps -ajxd` )  and sockstat | grep 5353 will result in 

```
nobody   mdnsd      1454  5  udp4   *:5353                *:*
```
 ( I only use TCP4 ) 

I just tried with 
	
	



```
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  )

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


----------



## Peacekeeper2000 (Oct 20, 2016)

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 (Oct 21, 2016)

Peacekeeper2000 said:


> 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

```
[Global]
...
afp interfaces = bridge0
...
```
With this in place, Netatalk generates the following messages on starting up:

```
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
```



Peacekeeper2000 said:


> 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.


----------



## Peacekeeper2000 (Oct 23, 2016)

obsigna said:


> 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.


----------



## Peacekeeper2000 (Oct 26, 2016)

obsigna said:


> 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 
	
	



```
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 ....


----------



## dch (Nov 5, 2016)

I have had similar issues and will be giving https://www.freshports.org/dns/openmdns/ http://www.haesbaert.org/openmdns/ a try.


----------



## Peacekeeper2000 (Nov 5, 2016)

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 !


----------

