Re: [brooks_at_FreeBSD.ORG: [src] cvs commit: src/etc pccard_ether]

On Wed, Sep 28, 2005 at 09:52:55PM -0600, M. Warner Losh wrote:
> In message: <20050928235033.GA13616_at_odin.ac.hmc.edu>
>             Brooks Davis <brooks_at_one-eyed-alien.net> writes:
> : On Wed, Sep 28, 2005 at 05:14:17PM -0600, Warner Losh wrote:
> : > > I've just committed the following change to /etc/pccard_ether.  I think
> : > > it's the right solution, but I'm concerned it may cause problems with
> : > > drivers that incorrectly frob the IFF_UP flag themselves.  If so it may
> : > > be nessicary to revert this change temporarily or at least not MFC it.
> : > 
> : > This change converts the "I already have an address" check to be a
> : > "I'm up" which are two different things.  dhclient leaves the
> : > interface up when it exits, even if it can't get an address.  I think
> : > that might cause a lot of problems for people.  I originally had this
> : > test in pccard_ether, but changed it to checking for netmask because
> : > roving from network to network didn't work without it on my laptop
> : > with multiple network interfaces.
> : 
> : I don't think dhclient's behavior will have any effect in the normal
> : case. "pccard_ether <ifn> start" is only called on attach.  It is not
> : involved in any with the link state transitions caused by roving since
> : those should not happen until after attach.  The one POLA violation I
> : can see is that you probably can't manually run pccard_ether's start
> : mode twice without performing a stop first.
> 
> notify 0 {
> 	match "system"		"IFNET";
> 	match "type"		"LINK_UP";
> 	media-type		"802.11";
> 	action "/etc/rc.d/dhclient start $subsystem";
> };
> 
> was the case I was worried about, but I think that since it calls
> dhclient directly, we should be OK.
> 
> The original check was supposed to be there as a short-circuit.  We
> called pccard_ether for *ALL* devices in the system when devd
> started.  We didn't want it to do anything if the link had already
> been configured earlier in the boot process.  Hence the check for a
> netmask.  There were many scripts around that put wireless devices
> (esp ndis) into the 'up' state before calling pccard_ether so that it
> would associate with the AP.  It would then be in the 'UP' state, but
> have no address.
> 
> Eg, you've broken:
> 
> 	ifconfig ndis0 ssid fred up
> 	/etc/pccard_ether ndis0 start

This change does break that case.  Wacking the interface into the up
state before running pccard_either should now be unnecessicary because
I always to it as part of he invocation of /etc/rc.d/netif (there might
be an issue with IPv6 only systems, but its easily fixed).  Scripts
that try various ssids should be obsoleted by wpa_supplicant.conf so
I think that while this does change behavior it only removes certain
uses that can be handled other ways.  If people find this change truly
objectionable I will back it out, but I'd really rather not without
evidence of problems that can't be easily worked around.  Our interface
setup process needs to continue to evolve if we're going to adapt to
modern hardware and networks.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4