Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Nov 2011 08:51:42 +0100
From:      Stefan Bethke <stb@lassitu.de>
To:        GR <freebsd@gomor.org>
Cc:        freebsd-current Current <freebsd-current@freebsd.org>, "freebsd-stable@freebsd.org List" <freebsd-stable@freebsd.org>
Subject:   Re: SIOCGIFADDR broken on 9.0-RC1?
Message-ID:  <AEC7F2C7-3B34-4861-8D8C-4AB8C5212518@lassitu.de>
In-Reply-To: <ee86fcc8-de74-4506-bad8-a6a35209b5cf@ubuntu64>
References:  <ee86fcc8-de74-4506-bad8-a6a35209b5cf@ubuntu64>

next in thread | previous in thread | raw e-mail | index | archive | help
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_<interface> 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 <stb@lassitu.de>   Fon +49 151 14070811






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AEC7F2C7-3B34-4861-8D8C-4AB8C5212518>