From owner-freebsd-current@FreeBSD.ORG Wed Nov 16 07:51:45 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C29C106564A; Wed, 16 Nov 2011 07:51:45 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 252328FC13; Wed, 16 Nov 2011 07:51:45 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A07A2CB5C8; Wed, 16 Nov 2011 08:51:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Wed, 16 Nov 2011 08:51:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: GR X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-current Current , "freebsd-stable@freebsd.org List" Subject: Re: SIOCGIFADDR broken on 9.0-RC1? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 07:51:45 -0000 Am 15.11.2011 um 23:35 schrieb GR: > So, I switched to static assignement and it changes the behaviour (and = "fixes" the "bug"). > My guess is that during the time waiting for the DHCP offer, all = aliases are already configured on the network interface, and the IP = address given by DHCP is added at the end of the tail. >=20 > Is that a wanted behaviour? I find it dangerous (i.e. not exactly what = a user is expecting). A bit of background, as best I understand it and remember from Stevens: Interfaces in BSD do not have a notion of "primary" and "additional" = addresses; interfaces just have any number of addresses associated with = them. There's no inherent ordering in this list (except for how the = current implementation seems to keep them in the order they were = configured). To be able to associate proper routes with interface addresses, the = recommendation for multiple IPv4 addresses on an Ethernet interface is = to have one of them have the proper netmask for the network, and = configure the remainder with a netmask of 255.255.255.255. But that's = solely for the benefit of the routing table; the interface itself = doesn't really care. Reading the rc.conf man page could give you the impression that there = are primary and alias addresses, but the networking code doesn't really = work like that. The new ipv4_addrs_ syntax exposes the = actual behavior in a more direct way. Jeremy gave you a hint on how to fix your immediate problem, but the = real answer is that the program needs to be fixed that makes assumptions = about meaning attached to the first configured IPv4 address. HTH, Stefan --=20 Stefan Bethke Fon +49 151 14070811