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

From: M. Warner Losh <imp_at_bsdimp.com>
Date: Wed, 28 Sep 2005 22:45:04 -0600 (MDT)
In message: <20050929043828.GA27416_at_odin.ac.hmc.edu>
            Brooks Davis <brooks_at_one-eyed-alien.net> writes:
: 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).

Whacking it into the up state is necessary to set the ssid parameter
for ndis (or at least used to be).  So the fact that it is placed in
the up state in netif isn't relevant.

: 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.

Agreed.  I was just trying to give perspective on when this change
would break things.

Warner
Received on Thu Sep 29 2005 - 02:44:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC