Date: Mon, 26 Dec 2011 23:21:08 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Eygene Ryabinkin <rea@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: <4EF971E4.4050905@FreeBSD.org> In-Reply-To: <KQLeXs1YdEQxk4IGqrNuq/Y6CrA@g5jH1yj%2BTnAiSdLOy3xs5Jutvhc> References: <4EB6693F.2020102@delphij.net> <4EF93429.4020404@FreeBSD.org> <KQLeXs1YdEQxk4IGqrNuq/Y6CrA@g5jH1yj%2BTnAiSdLOy3xs5Jutvhc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/26/2011 22:39, Eygene Ryabinkin wrote: > Doug, good day. > > Mon, Dec 26, 2011 at 06:57:45PM -0800, Doug Barton wrote: >> My proposed solution: >> >> 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: The machinery is not that big/complex. > it will be useless for already-configured interfaces; It also won't harm anything. > - 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. Are you certain that the devd.conf trigger will fire when a vlan is up'ed? > This will just do the work that is useless in all-static configuration. I'm not sure I agree that it's useless. I can actually see this as quite handy. Personally I try to be in the habit of adding the configuration to rc.conf first, and using netif to start the interface so that I know for sure what will happen when that host reboots. > 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. First, I think what you're describing is a pretty small edge case. [snip demo] > 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; Second, these are both valid points. :) > 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. I agree that this change will require user education. However 'ifconfig down' and 'ifconfig up' are actually direct actions. Users who don't want this can simply comment out the entry in rc.conf, or the entry in devd.conf. > 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. In very rare edge cases, yes. > 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. But it's the combination of "unexpected L2 flap" AND "being in the process of making an rc.conf change" that will trigger the problem you describe. And once again, if the user doesn't want the change to take effect immediately they can comment it out. If no config exists for the interface, nothing bad will happen. > 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". While I don't agree that the problems you're describing are enough of a possibility to be concerned about, the other alternative that I considered is for devd.conf to call a wrapper script that first determines whether or not it's a DHCP interface, and then calls rc.d/dhclient if it is. However, there are a couple of downsides to that. First, it's more work. :) But seriously, one advantage of using netif is that it will also work with interfaces that are dynamically configured with IPv6. If we were to move to a wrapper script idea I'd like to see it support that as well as IPv4 DHCP. Doug -- [^L] Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF971E4.4050905>