Date: Tue, 27 Dec 2011 10:39:07 +0400 From: Eygene Ryabinkin <rea@FreeBSD.ORG> To: Doug Barton <dougb@FreeBSD.org> Cc: Pyun Yong-Hyeon <pyunyh@gmail.com>, Brooks Davis <brooks@freebsd.org>, freebsd-rc@FreeBSD.ORG, Gleb Smirnoff <glebius@FreeBSD.org>, Dag-Erling Smorgrav <des@des.no>, d@delphij.net, Xin LI <delphij@delphij.net> Subject: Re: Annoying ERROR: 'wlan0' is not a DHCP-enabled interface Message-ID: <KQLeXs1YdEQxk4IGqrNuq/Y6CrA@g5jH1yj%2BTnAiSdLOy3xs5Jutvhc> In-Reply-To: <4EF93429.4020404@FreeBSD.org> References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ubBGeysJ7fFOU9Y9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Doug, good day.
Mon, Dec 26, 2011 at 06:57:45PM -0800, Doug Barton wrote:
> My proposed solution:
>=20
> Make devd.conf smarter about how it tries to bring the interface up.
> This is accomplished rather easily in the attached patch, which uses
> netif instead of dhclient. The virtue of this solution is that it will
> use whatever configuration exists for the interface, and will not call
> rc.d/dhclient spuriously.
This solution will also do the work, but I am slightly concerned that it
will
- call all netif machinery for interfaces with static IPs: it will be
useless for already-configured interfaces;
- in the case of vlan interfaces, ifconfig dance will be done twice
for each of them: once from the netif for the parent interface and
once for each vlan in turn.
This will just do the work that is useless in all-static configuration.
Worse, this solution will ruin host's connectivity in the following
scenario:
- one runs his remote server with all static configuration and strict,
default-to-deny firewall configuration (call this person "Eygene
Ryabinkin");
- his upstream provider tells him: listen, we're rearranging our IP
space and you should change IP1 to IP2;
- administrator is busy changing the configuration of his host; his
plan is to substitute IP1 to IP2 everywhere and to reboot his
machine to cleanly acquire IP2 and continue operations;
- he already substituted IP1 -> IP2 in rc.conf and starts poking
the firewall configuration, but here comes the link down event
due to the $PROVIDER who reconfigures his $CISCO or whatever;
- the system ends up in an unusable state, because link up event
will change interface's IP, but firewall isn't ready for this
and isn't allowing connections to IP2, but allows them only for
IP1 that is already gone from the interface due to devd and netif
script.
Here's the demo that changes in rc.conf will unconditionally change
interface's IP regardless of the current setting:
{{{
$ grep ifconfig_sk0 /etc/rc.conf
ifconfig_sk0=3D"inet 10.0.0.1/24"
$ service netif quietstart sk0
Starting Network: sk0.
sk0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3D80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:22:15:6e:9d:a9
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet autoselect (none)
status: no carrier
$ grep ifconfig_sk0 /etc/rc.conf
ifconfig_sk0=3D"inet 10.0.0.2/24"
$ service netif quietstart sk0
Starting Network: sk0.
sk0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3D80009<RXCSUM,VLAN_MTU,LINKSTATE>
ether 00:22:15:6e:9d:a9
inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
}}}
People may tell me that
- Eygene Ryabinkin should run firewall configuration whose knowledge
of IP for the interface is based on the automagic like ipfw's "me"
verb;
- Eygene Ryabinkin should not work with the remote host without access
to its physical console via remote KVM or alike;
- Eygene Ryabinkin should not run remote servers at all (just kidding).
I am aware of these fine points, however my meat is that static IP
configuration is the _static_ one (cool assertion, isn't it?). But it
has at least one consequence: people view their static IP
configurations as a really static ones and tend to think that only their
direct actions will change them. So, any non-atomic changes in
configuration won't be regarded as a problem: only direct actions that
will initiate the reconfiguration of the network interfaces must
change the stuff and changes in configuration files that aren't
supplemented with such actions must not change anything.
Your way to fix the problem adds the possibility of the
linkdown/linkup event combo to alter the configuration that is in the
process of being changed. That's unexpected and one can't be ready
for it in all situations (though remote console will save some brain
cells): it depends on the external factor one can't fully control.
Linkup/linkdown events aren't that rare and generally they are not
viewed as something unusual that will ruin people's connectivity: as
long as L3 layer and above will stay alive, link flaps on L2 shouldn't
change its operations apart from outages for the flap duration.
So, my motto here is "Static is static, leave it alone and don't make
it to depend on the dynamic events; DHCP is the dynamic protocol by
its nature, so it can depend on the dynamic events".
--=20
Eygene Ryabinkin ,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
--ubBGeysJ7fFOU9Y9
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iF4EAREIAAYFAk75aAsACgkQFq+eroFS7PvnPAEAiRhMcXufLdgZwaGH5cPjMpSl
rg2pLNG2LR36EUbCbIcA/iWOph3i8hzqZKPAcrSMH1oxkRfs9S/GKWDrnu1LOV53
=He07
-----END PGP SIGNATURE-----
--ubBGeysJ7fFOU9Y9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?KQLeXs1YdEQxk4IGqrNuq/Y6CrA>