Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avahi registering new address on wrong interface when using ip aliasing #103

Closed
deb0ch opened this issue Feb 27, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@deb0ch
Copy link

commented Feb 27, 2017

Having the following hardware interface, Avahi registers 192.168.42.1 on eth0, which is what I want:

eth0      Link encap:Ethernet  HWaddr A0:14:3D:C5:B3:6F  
          inet addr:192.168.42.1  Bcast:192.168.42.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:126 errors:0 dropped:3 overruns:0 frame:3013
          TX packets:362 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:19377 (18.9 KiB)  TX bytes:41751 (40.7 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

The problem is when I add an ip address using ip aliasing with ifconfig eth0:0 192.168.42.2 (see #99 for details on why I need to do that):

ifconfig:

...
eth0:0    Link encap:Ethernet  HWaddr A0:14:3D:C5:B3:6F  
          inet addr:192.168.42.2  Bcast:192.168.42.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

Avahi:

<system startup>
...
Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.42.1.
New relevant interface eth0.IPv4 for mDNS.
...
Registering new address record for 192.168.42.1 on eth0.*.
...
<somewhere here I add the interface>
...
Registering new address record for 192.168.42.2 on eth0.*.
...

Avahi registers the new address on eth0 instead of eth0:0, which makes it answer discovery requests with the wrong ip (192.168.42.2) and is the cause of all of my problems 😕

As I also noted, I didn't see any trace of a new relevant interface eth0:0 being added.

I also know that eth0:0, as a virtual interface, will have the same index as eth0 but a different label and its own message in the netlink response to a RTM_GETADDR query.

I am currently investigating the code to find a workaround or a proper fix to this issue, as I strongly need this setup to be working.

If you had any advice, help, or heads start to give me that could help with this issue it would be strongly needed and gladly welcomed 😸

EDIT Forgot to mention, I had that in avahi-daemon.conf:

allow-interfaces=eth0
deny-interfaces=eth0:0
@lathiat

This comment has been minimized.

Copy link
Owner

commented Mar 5, 2017

Hi deb0ch,

The kind of interface you are referring to (eth0:0) is an "alias" interface, it's not a real interface but instead is a bit of a hack around the old kernel interface (which ifconfig used) which did not support more than 1 IP address per interface.

Modern APIs including those used by "ip addr" and similar support multiple IPs per interface so these aliases are not needed - however the aliases are just that - an alias. The true interface is really eth0 and the alias is not relevant for the mDNS protocol.

The root of your problem is that sometimes the "wrong" IP address is returned to your applications which it can't use. This is really a problem partly with nss-mdns and partly with applications that won't try more than 1 IP address per hostname (though I think sometimes that happens due to nss-mdns). nss-mdns should probably prioritise the IP addresses to return "local" addresses first and we should try to support applications retrying multiple addresses.

Long story long: This is not a bug with avahi-daemon, but there are application level improvements that could assist in this situation. I would suggest we move this bug over to the nss-mdns project and see if we can find a good solution there.

@lathiat lathiat closed this Mar 5, 2017

@letshack

This comment has been minimized.

Copy link

commented Mar 6, 2017

@deb0ch

This comment has been minimized.

Copy link
Author

commented Apr 19, 2017

I just submitted a PR with the solution that we used to make our setup work :)

I am aware that alias interfaces are an old mechanism from the times when the kernel didn't handle multiple IP addresses per interface, and that the alias interfaces are underneath the same hardware interface with the same index.

Having that alias interface mechanism was the only way for us of distinguishing the two IPs that we had on our interface: one of these IPs is used for a NAT/Masquerade trick to bring a device from another network into our wifi network, so it belongs to this other device and shouldn't be used for mDNS.

Yes, this setup is very particular, it does not run on regular computers but on embedded drone products.

Moreover, the way I solved this issue in my PR is very generic and brings avahi-daemon's behaviour closer to what the user would expect when configuring avahi-daemon.conf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.