Re: [regression] iwi0 with WPA on 8.0 - FIXED, pilot error

Ulrich Spörlein wrote:
> On Fri, 21.08.2009 at 10:31:39 +0200, Vladimir Botka wrote:
>> It seems that there is no problem with WPA. The wpa_supplicant
>> associates. You can see the message.
>>
>> wpa_supplicant[481]: Associated with 00:21:27:f3:37:37
>>
>> Run the wpa_supplicant with more debug info to get more information why
>> the wpa_supplicant disconnects later.
>>
>> wpa_supplicant[481]: CTRL-EVENT-DISCONNECTED - Disconnect
> 
> It is a combination of setting the MAC address that makes wpa_supplicant
> barf. These settings in rc.conf result in broken wpa_supplicant during
> boot:
> 
> ifconfig_bfe0="up"
> ifconfig_iwi0="up"
> wlans_iwi0="wlan0"
> ifconfig_wlan0="WPA ether 00:0f:1f:1d:a3:76 ssid COYOTE"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="DHCP up laggproto failover laggport bfe0 laggport wlan0"
> 
> Result
> 
> iwi0: timeout waiting for (null) firmware initialization to complete
> iwi0: could not load boot firmware (null)
> iwi0: timeout waiting for (null) firmware initialization to complete
> iwi0: could not load boot firmware (null)
> wlan0: Ethernet address: 00:15:00:22:26:61
> iwi0: need multicast update callback
> iwi0: need multicast update callback
> iwi0: need multicast update callback
> wlan0: link state changed to DOWN
> wlan0: link state changed to UP
> wlan0: link state changed to DOWN
> wlan0: link state changed to UP
> wlan0: link state changed to DOWN
> wlan0: link state changed to UP
> wlan0: link state changed to DOWN
> 
> As you can see, wlan0 is created with the wrong MAC address and
> wpa_supplicant does not like different MACs on the wlanX dev and the
> real hardware.
> 
> These settings now work. Everything is well
> 
> ifconfig_bfe0="up"
> ifconfig_iwi0="ether 00:0f:1f:1d:a3:76 up"
> wlans_iwi0="wlan0"
> ifconfig_wlan0="WPA ssid COYOTE"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="DHCP up laggproto failover laggport bfe0 laggport wlan0"

It so happens I've been discussing this issue with someone else.  The 
lagg setup is documented in the EXAMPLES section of lagg(4) and doing 
things this way will be necessary for 8.0.

Changing the mac address of a vap after it is created does not work 
right and may never work for certain devices.  There are issues in how 
the ifnet layer handles this operation and when there are multiple vap's 
present it is unclear how to handle this operation (if it's possible at 
all).  Devices like iwn that do not support multi-bssid can handle 
dynamically changing the mac address but not w/o some changes to the 
infrastructure.  For now you need to force the mac address of the 
underlying device so cloned ifnet's inherit the new address.

	Sam