From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 06:42:05 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99A71065672; Tue, 27 Dec 2011 06:42:05 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E90778FC1B; Tue, 27 Dec 2011 06:39:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=uWwWS1keGWdYEc3dxfcyRMeH9uxoR/utJPADQmvdPGs=; b=AjVwvBsWV3AG+uwHZlX+qZFtLBKw7kXQBlb9MMSZPmTrT1+oZk1+2ypXzqqlhD8C98DmxmjHJLFdr7cyNqiqOok0tF2/FDy7pVM+/IiSSDxcCjCy3T5CQDAlCIn4NLGB+IO6U0x0J2/MRkXhSkRUV9C5yDW94MCa+TdLmcTUDLGxHSrmkyx/IO6qoUPS/q/p6FBWE9qtEKaqm+4xFq3mt+pQ61Nk6TvtaTTOVaQVUfk4uHDrKJSY5U8E4CuXxawr4/YZc5a4K1rvpz29zXvnluqdiUpg6K0Wyy5SOChqWTzHZuE9DogfmvUN6h0tEvbJCjMDVATvRAFMNziTJnonHQ==; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1RfQgp-000LJb-00; Tue, 27 Dec 2011 09:39:11 +0300 Date: Tue, 27 Dec 2011 10:39:07 +0400 From: Eygene Ryabinkin To: Doug Barton Message-ID: References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ubBGeysJ7fFOU9Y9" Content-Disposition: inline In-Reply-To: <4EF93429.4020404@FreeBSD.org> Sender: rea@codelabs.ru Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.ORG, Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI Subject: Re: Annoying ERROR: 'wlan0' is not a DHCP-enabled interface X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 06:42:05 -0000 --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 metric 0 mtu 1500 options=3D80009 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 metric 0 mtu 1500 options=3D80009 ether 00:22:15:6e:9d:a9 inet 10.0.0.2 netmask 0xffffff00 broadcast 10.0.0.255 media: Ethernet autoselect (1000baseT ) 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--