Can't discover a IPv4 link-local address when having an static IP configured

Question

I have link-local addresses working out-of-the-box when coupled with DHCP, since when there's no DHCP, the device doesn't get an IP, only a link-local one. Still, I need to have link-local addresses working even if I'm setting up interfaces statically. I'm not sure how I should proceed. This is what I've done:

auto eth0
allow-hotplug eth0
        iface eth0 inet static
        gateway 192.168.0.1
        address 192.168.0.25
        netmask 255.255.255.0
        post-up /usr/sbin/avahi-autoipd --force-bind --daemonize --wait $IFACE 2> /dev/null
        pre-down /usr/sbin/avahi-autoipd --kill $IFACE 2> /dev/null

And this is the result:

$ ifconfig
eth0      Link encap:Ethernet  HWaddr d0:63:b4:00:88:1f
          inet addr:192.168.0.25  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::d263:b4ff:fe00:881f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:243 errors:0 dropped:0 overruns:0 frame:0
          TX packets:554 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:33114 (33.1 KB)  TX bytes:56243 (56.2 KB)

eth0:avahi Link encap:Ethernet  HWaddr d0:63:b4:00:88:1f
          inet addr:169.254.5.135  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

All nice, my target got 2 local IP's. Now, I want to access it by connecting a network cable directly. I can't browse it with avahi-browse, "avahi-browse -alr" only returns the 192.168.0.25 static address or the IPv6 link-local, never the IPv4 link-local one. I'm able to ssh the target using the 169.254.5.135 link-local address! and I can't do it with the static address avahi-browse reports, because there's no route for it, it's just a cable connection. I just dunno how I can discover this link-local IP... It's the last piece in this puzzle since the link-local IP is working. It's like the static configuration is taking precedence over discovering.

Notice that all machines are reporting the avahi workstation service.

EDIT

Ah, I've forgot to set the publish workstation service on the target avahi-daemon.conf. So, after setting this, behavior has changed. avahi-browse -ar, even when executed from inside the target, is not listing its own link-local address, only its IPv6 and the static IPv4. So, if the target itself can't browse this link-local address anymore, how could the connected machine do it in the first place. I dunno how to make avahi-browse list this address that is valid.

~ ❯❯❯ ssh francisco@169.254.5.135                                                                                                                  archlinux ✱
francisco@169.254.5.135's password:
  ____      _                 _ ____     __  __
 / ___|   _| |__   _____  __ (_)___ \ ___\ \/ /
| |  | | | | '_ \ / _ \ \/ / | | __) / _ \\  /
| |__| |_| | |_) | (_) >  <  | |/ __/  __//  \
 \____\__,_|_.__/ \___/_/\_\ |_|_____\___/_/\_\


Welcome to ARMBIAN Ubuntu 14.04.4 LTS 3.14.60-cubox

System load:   0.00             Up time:       35 min
Memory usage:  5 % of 3788Mb    IP:            192.168.0.25
CPU temp:      47°C
Usage of /:    4% of 29G

Last login: Wed Feb 24 04:19:27 2016 from 169.254.4.29
francisco@cubox-i:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d0:63:b4:00:88:1f brd ff:ff:ff:ff:ff:ff
    inet 169.254.5.135/16 brd 169.254.255.255 scope link eth0:avahi
       valid_lft forever preferred_lft forever
    inet 192.168.0.25/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::d263:b4ff:fe00:881f/64 scope link
       valid_lft forever preferred_lft forever
3: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default
    link/ether f6:4b:80:39:3e:0b brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 6c:ad:f8:1d:4b:87 brd ff:ff:ff:ff:ff:ff
francisco@cubox-i:~$ avahi-browse -ar
+   eth0 IPv6 cubox-i [d0:63:b4:00:88:1f]                   Workstation          local
+   eth0 IPv4 cubox-i [d0:63:b4:00:88:1f]                   Workstation          local
=   eth0 IPv6 cubox-i [d0:63:b4:00:88:1f]                   Workstation          local
   hostname = [cubox-i.local]
   address = [fe80::d263:b4ff:fe00:881f]
   port = [9]
   txt = []
=   eth0 IPv4 cubox-i [d0:63:b4:00:88:1f]                   Workstation          local
   hostname = [cubox-i.local]
   address = [192.168.0.25]
   port = [9]
   txt = []

score 1 · Answer 1 · answered Feb 24 '16 at 06:21

The truth is that I can access the static IP 192.168.0.25! The issue was that I was trying to communicate using direct cable while my notebook was connected to WiFi, inside a 192.168.0.0/24 network. When turning off WiFi I'm able to access 192.168.0.25.

score 1 · Answer 2 · answered Apr 11 '19 at 09:44

I had the same problem, and I see why your statement

It's like the static configuration is taking precedence over discovering.

is partly correct. At least the behavior is explainable.

Avahi only publishes link-local addresses, if they are the only ones on the link, see [https://github.com/lathiat/avahi/blob/1cc2b8e8d62e939b8bd683f795794878863931af/avahi-core/iface.c#L707][1]. You can also observe this behavior when running avahi-daemon on your interface configuration, the output states which addresses are published. As there are two IPv4 addresses (static and link-local), the local one is not published. For IPv6 you only have a link-local one, which you accordingly see on your avahi-browse.

As Wikipedia states

RFC 3927 warns against the simultaneous use of IPv4 addresses of different scope,[6] such as configuring link-local addresses as well as globally routable addresses on the same interface. Therefore, hosts search for a DHCP server on the network before assigning link-local addresses.

So I think this behavior is intended, and forcing a link-local address for static configurations is discouraged.

Can't discover a IPv4 link-local address when having an static IP configured

EDIT

2 Answers2