Red Hat Bugzilla – Bug 840601
dhcpd won't listen to alias: Failed to get HW address for eth0:1
Last modified: 2012-08-06 03:59:23 EDT
Description of problem: Even with a etc/sysconfig/dhcpd with these content: DHCPDARGS="eth0:1 eth0" ...dhcpd refuses to use the eth0:1 alias: dhcpd: Listening on LPF/eth0/00:50:56:ba:d4:cf/10.122.100.0/23 dhcpd: Sending on LPF/eth0/00:50:56:ba:d4:cf/10.122.100.0/23 dhcpd: Failed to get HW address for eth0:1 (dhcpd exits) This this intended? It seems to be a known RHEL6 issue: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sect-Configuring_a_Multihomed_DHCP_Server.html ... but does it have to be? Surely it shouldn't care. Version-Release number of selected component (if applicable): dhcp-4.2.4-2.fc17.x86_64
AFAIK these network aliases (in general) are a relic of linux-2.0 and one should generally avoid them, but yes, dhcpd shouldn't fail to start because of it.
Technical description of the problem (mainly for me to not forget): --- First we get (using getifaddrs(), AF_INET/AF_INET6 address family) the list of interfaces which have some network-layer (IPv4/IPv6) address configured. Either from the list the user provided (e.g. DHCPDARGS="eth0:1 eth0") or from all interfaces on the system. Then we try to get a link-layer (MAC) address for each of them. Again we use getifaddrs(), but this time we use only AF_PACKET address family. Problem is that there's no AF_PACKET for eth0:1, just for eth0 (try the example program from getifaddrs(3)).
I haven't any clean solution at the moment. Hopefully I'll get one in future. I just updated the lpf-ib.patch (which changes the way of getting ll address to getifaddrs() usage). When we haven't been able to get the ll address for some interface, we check whether it contains colon and if yes (so it's most likely an alias), we strip the part beginning with colon and try again for the rest (most likely the real interface name). This doesn't work when the alias name doesn't contain colon, but hopefully I'll figure out something cleaner one day.
Please try this build http://koji.fedoraproject.org/koji/taskinfo?taskID=4249326
Or better this one https://koji.fedoraproject.org/koji/taskinfo?taskID=4251262
dhcp-4.2.4-6.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dhcp-4.2.4-6.fc17
(In reply to comment #3) > When we haven't been able to get the ll address for some interface ... I changed the fix. I added the fall-back method (using ioctl(SIOCGIFHWADDR)) when getting of link-layer address with getifaddrs() fails. That seems to fix this bug and also bug #626514, comment #62.
Package dhcp-4.2.4-6.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dhcp-4.2.4-6.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-11020/dhcp-4.2.4-6.fc17 then log in and leave karma (feedback).
dhcp-4.2.4-7.P1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dhcp-4.2.4-7.P1.fc17
dhcp-4.2.4-9.P1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.