From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4841 Path: news.gmane.org!not-for-mail From: Natanael Copa Newsgroups: gmane.linux.lib.musl.general Subject: Re: if_nameindex/getifaddrs and dhcpcd issue Date: Tue, 8 Apr 2014 23:16:20 +0200 Message-ID: <20140408231620.64546259@ncopa-laptop> References: <20140408111147.5f79729f@ncopa-desktop.alpinelinux.org> <20140408134255.GE26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1396991807 15900 80.91.229.3 (8 Apr 2014 21:16:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Apr 2014 21:16:47 +0000 (UTC) Cc: dalias@aerifal.cx To: musl@lists.openwall.com Original-X-From: musl-return-4845-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 08 23:16:42 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WXdNp-0001Cd-Rz for gllmg-musl@plane.gmane.org; Tue, 08 Apr 2014 23:16:41 +0200 Original-Received: (qmail 5353 invoked by uid 550); 8 Apr 2014 21:16:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5341 invoked from network); 8 Apr 2014 21:16:37 -0000 In-Reply-To: <20140408134255.GE26358@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:4841 Archived-At: On Tue, 8 Apr 2014 09:42:55 -0400 Rich Felker 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