Date: Tue, 8 Apr 2014 23:16:20 +0200 From: Natanael Copa <ncopa@...inelinux.org> To: musl@...ts.openwall.com Cc: dalias@...ifal.cx Subject: Re: if_nameindex/getifaddrs and dhcpcd issue On Tue, 8 Apr 2014 09:42:55 -0400 Rich Felker <dalias@...ifal.cx> wrote: > On Tue, Apr 08, 2014 at 11:07:47AM +0100, Justin Cormack wrote: > > However I can see no reason why dhcp on a specified interface needs to > > enumerate interfaces at all, > > Indeed. Regardless of how we address this topic in musl, I think we > should push for dhcpcd to be fixed. udhcpcd works perfectly fine with > no scanning of interfaces; you simply tell it the interface to use, > and it uses that. My understanding is that dhcpcd can do the same, but > it still insists on scanning all interfaces and refuses to run if the > interface you requested to use is not in the list. This is bad > behavior. It looks like the reason for this is that you can provide a wilcard, eg 'eth*' and it will monitor all interfaces that fnmatches that. > The other case, where no interface is specified on the command line > and dhcpcd tries all interfaces, is buggy usage by the caller. There > are all sorts of interfaces that might exist, unconfigured, and which > might not be appropriate to send dhcpc requests on. I assume dhcpcd > has some heuristics to avoid selecting things like unconfigured > tunnel, slip, etc. interfaces but if so that's just an ugly hack. The > operation of "try all instances of a given type of resource" is just > wrong by design. Yes you can configure a list of exact interfaces that you want dhcpcd to monitor or you can have a black list - with wilcards. See allowinterfaces and denyinterfaces (which also can be specified on command line) http://roy.marples.name/man/html5/dhcpcd.conf.html dhcpcd is more an ifplugd + dhcp client wit optional support for dbus. It can also get notifications from wpa_supplicant. You can even have dhcpcd to set static ip addresses. So its more an alternative to NetworkManager than to udhcpc. Other thing it can handle is currently unknown interfaces. For example the laptop I use right now does not have any ethernet port, only wifi. I do have an ethernet USB adapter. So eth0 is not there at bootup. I currently get error messages on screen due to udhcpc does not find the configured eth0 interface. To solve this, without needing install the full NetworkManager suite or systemds networkd, I can simply let dhcpcd run in manager mode, and it will run the show. There is even a dhcpcd-ui applet that gives me link status etc on my desktop. Note that I'm not really making any judgement if this is correct or wrong design, but I think it might explain why it works like it works. I can of course suggest for Roy Marples to redesign it but I suspect that the answer will be somethign like: if you want udhcpc, use udhcpc. > > and it only needs to read ipv4 addresses, > > unless it is implementing dhcp6 too, maybe it does now. Again dhcp6 > > needs netlink, the Musl ipv6 parts for getifaddrs already use /proc > > which is definitely unreliable for early boot config in a distro in my > > view. > > In what way does dhcp6 need netlink? What's made this discussion > difficult so far on IRC is assertions of that form (although not the > same one) without an explanation of why it's believed to be true, so > I'd like to keep rational discussion possible by making sure that such > claims are backed up by explanation rather than just stated as fact. I don't really have experience with ipv6 so I can not comment on that. But I know for sure that the current ioctl implementation cannot display multiple addresses on same interface. IIRC that was one of the reasons netlink exists in first place. You can actually easily see that with the current musl getifaddrs implementation. It will only show the primary address and nothing else. So you can currently not get all addresses with musl. > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.