avahi-autoipd hangs in probing state on MAC address 00:01:00:00:00:00

I am pretty sure this is unrelated to avahi-autoipd, because we don't really care about the MAC addresses, we just take whatever the operating system gives us.

I would assume you have some hardware/driver issue here, where transmission or reception fails and the unusual MAC address is just another side effect of the issue.

Please check with wireshark if proper arp packets are generated and received. Also check with strace where avahi-autoipd freezes.

The bug might be in the is_ll_address() function.
~# ifconfig eth0 | grep HW && avahi-autoipd --debug eth0
eth0      Link encap:Ethernet  HWaddr 00:01:00:00:00:00
Found user 'avahi-autoipd' (UID 42) and group 'avahi-autoipd' (GID 64002).
Successfully called chroot().
Successfully dropped root privileges.
State transition START-0 -> START-0
Starting with address 169.254.0.2
State transition START-0 -> WAITING_PROBE-0
sleeping 284ms
State transition WAITING_PROBE-0 -> PROBING-0
sending...
sleeping 1708ms
State iteration PROBING-1
sending...
sleeping 1593ms
State transition PROBING-1 -> WAITING_ANNOUNCE-0
sending...
sleeping 1998ms
State transition WAITING_ANNOUNCE-0 -> ANNOUNCING-0
Callout BIND, address 169.254.0.2 on interface eth0
sending...
sleeping 1994ms
A routable address has been configured.
Callout UNBIND, address 169.254.0.2 on interface eth0
State transition ANNOUNCING-0 -> SLEEPING-0

==============

~# ifconfig eth0 | grep HW && avahi-autoipd --debug -S 169.254.0.1 eth0
eth0      Link encap:Ethernet  HWaddr 00:07:F5:01:38:BA
Found user 'avahi-autoipd' (UID 42) and group 'avahi-autoipd' (GID 64002).
Successfully called chroot().
Successfully dropped root privileges.
Requested address 169.254.0.1 is not from IPv4LL range 169.254/16 or a reserved address, ignoring.
State transition START-0 -> START-0
Starting with address 169.254.6.119
State transition START-0 -> WAITING_PROBE-0
sleeping 144ms
State transition WAITING_PROBE-0 -> PROBING-0
sending...
sleeping 1595ms
State iteration PROBING-1

===========

the function
int is_ll_address(uint32_t addr) {
    return
        ((ntohl(addr) & IPV4LL_NETMASK) == IPV4LL_NETWORK) &&
        ((ntohl(addr) & 0x0000FF00) != 0x0000) &&
        ((ntohl(addr) & 0x0000FF00) != 0xFF00);
} 
should be changed to:
int is_ll_address(uint32_t addr) {
    return
        ((ntohl(addr) & IPV4LL_NETMASK) == IPV4LL_NETWORK) &&
        ((ntohl(addr) & 0x000000FF) != 0x00FF) &&
        ((ntohl(addr) & 0x0000FF00) != 0xFF00);
}

but I'm not sure what 169.xxxx reserved addresses are. Might be, that you have to change the algorithm which generates IP numbers out of the MAC if there are reserved values.

Marcel

I fail to see how the test in is_ll_address() is in any way relevant for your problem?

The function is completely correct as far as I can see. See 2.1 of RFC 3927: http://files.zeroconf.org/rfc3927.txt:

"When a host wishes to configure an IPv4 Link-Local address, it selects an address using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255 inclusive."

"The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism."

HAve you figured out where exactly avahi-autoipd freezes? In a send() call? If so, then you have a device/driver problem.

The problem is, that the MAC 00:01:00:00:00:00 leads with the current AVAHI autoipd to the IP address 169.254.0.2 which is recognised as NON link local by the is_ll_address() function. The daemon gives the interface this IP, then the netlink interface notifies the daemon about a new IP on the interface. The daemon thinks the interface has a routable address because the function is_ll_address() gives this result, removes the just assigned IP from the interface and then the game starts again.

marcel

Yes! You are right!

Could you please check if this patch fixes your problem?

http://git.0pointer.de/?p=avahi.git;a=commit;h=d6ce91c0b5258c2e107415704413f42edfab2c30

Thanks!

The patch works for me. As the result I've got an ethernet interface configured with an an valid IPv4LL address by avahi-autoipd, see below:

~$ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:01:00:00:00:00

inet addr:169.254.1.2 Bcast:169.254.255.255 ...

Thanks Lennart!

Closing then.