From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4847 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: Wed, 9 Apr 2014 09:55:56 +0200 Message-ID: <20140409095556.701e0363@ncopa-desktop.alpinelinux.org> References: <20140408111147.5f79729f@ncopa-desktop.alpinelinux.org> <20140408152559.124030b1@vostro> <20140408154537.GG26358@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 1397030181 18275 80.91.229.3 (9 Apr 2014 07:56:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Apr 2014 07:56:21 +0000 (UTC) Cc: dalias@aerifal.cx, justin@specialbusservice.com To: musl@lists.openwall.com Original-X-From: musl-return-4851-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 09 09:56:15 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 1WXnMj-0005Tt-Ds for gllmg-musl@plane.gmane.org; Wed, 09 Apr 2014 09:56:13 +0200 Original-Received: (qmail 3551 invoked by uid 550); 9 Apr 2014 07:56:12 -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 3542 invoked from network); 9 Apr 2014 07:56:12 -0000 In-Reply-To: <20140408154537.GG26358@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-alpine-linux-uclibc) Xref: news.gmane.org gmane.linux.lib.musl.general:4847 Archived-At: On Tue, 8 Apr 2014 11:45:37 -0400 Rich Felker wrote: > > We should not be looking at dhcpd. It's the APIs musl implements: > > getifaddrs() and if_nameindex() - they are not currently exposing all > > the information they should. > > One can argue about what if_nameindex should expose; Yes. This is the real issue at hand. What dhcpcd does is not that relevant here. > for instance, > should it expose all possible interface names the kernel could > support, even with modules that haven't been loaded yet? IMHO, no. I think it should only expose what you normally find as /sys/class/net/* (you find same list in /proc/net/dev) A use case if_nameindex() that I think would be valid is a network config ui. Which interface do you want to configure? Presents a list of currently available network interfaces. (from if_nameindex) It has a button 'Add virtual interface', which lets user configure bonding/bridges/vlans etc. (yes, no application should assume that the listed interface actually works. I could select my USB ethernet dongle and before press 'ok' I could pull out the USB ethernet...) > The only > thing a strictly conforming application can _DO_ with interface > names/numbers is use them for link-local ipv6 scope ids (this is > presumably why these functions were added to POSIX in the first > place). So, from a conformance standpoint, only exposing ids that > could actually appear on a link-local address (i.e. configured > interfaces that have ipv6 link-local addresses) would be sufficient. Then, from a conformance standpoint, the current musl if_nameindex implementation is broken. It only lists interfaces with configured ipv4 addresses. To test yourself: modprobe dummy ip link set up dev dummy0 ip addr #verify that dummy has ipv6 link-local Then run the following testcase: #include #include #include #include int main(int argc, char *argv[]) { struct if_nameindex *if_ni, *i; if_ni = if_nameindex(); if (if_ni == NULL) { perror("if_nameindex"); exit(EXIT_FAILURE); } for (i = if_ni; ! (i->if_index == 0 && i->if_name == NULL); i++) printf("%u: %s\n", i->if_index, i->if_name); if_freenameindex(if_ni); exit(EXIT_SUCCESS); } The ipv6 link-local configured dummy0 interface will not be listed. -nc