Bug 840601
| Summary: | dhcpd won't listen to alias: Failed to get HW address for eth0:1 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | joshua |
| Component: | dhcp | Assignee: | Jiri Popelka <jpopelka> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | jpopelka, thozza |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-06 07:59:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
joshua
2012-07-16 16:53:27 UTC
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. |