On Sunday 16 November 2008, Dave wrote:
> John W. Linville wrote:
> > On Sat, Nov 15, 2008 at 11:15:47AM +0300, Andrey Borzenkov wrote:
> >
> >> - we should not be doing it in ->open. It is technically legal to set
> >> wireless parameters before "icfonfig up" and we lose all of them. I will
> >> try next week with similar patch in orinoco_stop().
> >
> > That seems wrong...
> >
> >> - I am still not even sure we should do it at all. What is sematic of
> >> ifconfig up/down w.r.t. wireless parameters? I.e. is "ifconfig down"
> >> expected to clean all device state and start from scratch?
> >
> > No. Unfortunately, it is mostly a matter of opinion as to what
> > wireless extensions expects.
>
> Agreed with all the above. I'll discard the driver patch.
>
> There are two other things I can think of:
>
> 1. make sure wpa_supplicant is shut down before ifconfig ethX down, and
> restart it on resume.
>
That is exactly what happens currently.
> From the data you've provided it looks like your distribution brings the
> device down, but may leave wpa_supplicant running.
No, wpa_supplicant is started as part of ifup and stopped as part of ifdown.
Which are called on network start/stop.
> I've noticed that
> every time wpa_supplicant shuts down it removes most configuration
> settings. Or has that changed?
>
As far as I can tell - it should. I am not sure how to check for it; I do
not see any difference in output of either iwconfig or iwlist scan either
before or after "network stop".
We really need some more debugging code in orinoco.
Returning to the original problem. The only difference visible currently is
when association happens.
Good case:
[16992.355418] eth1: Lucent/Agere firmware doesn't support manual roaming
[16992.636475] eth1: New link status: Connected (0001)
As already mentioned, "error" message comes from SIOCSIWAP which is not
supported by Agere firmware. wpa_supplicant calls it as part of association
resuest in wpa_driver_wext_associate().
Bad case is always:
[ 7669.871273] eth1: New link status: Connected (0001)
[ 7670.046171] eth1: Lucent/Agere firmware doesn't support manual roaming
[ 7670.495779] eth1: Lucent/Agere firmware doesn't support manual roaming
[ 7675.774280] eth1: Lucent/Agere firmware doesn't support manual roaming
...
i.e. it /looks/ like first card is connected to AP and then wpa_supplicant
request association. BTW, I just realized that I am not sure what "connected"
means exactly. Does it mean card is associated?
That is what let me believe that old parameters somehow are retained.
Looking at wpa_supplicant log intersting part is
Wireless event: cmd=0x8c07 len=32
AssocReq IE wireless event - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'eth1' added
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:60:b3:ca:91:b0
Association info event
req_ies - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
WPA: set own WPA/RSN IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02
State: ASSOCIATING -> ASSOCIATED
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
Associated to a new BSS: BSSID=44:44:44:44:44:44
Which corresponds to this code:
static void wpa_supplicant_event_assoc(struct wpa_supplicant *wpa_s,
union wpa_event_data *data)
{
u8 bssid[ETH_ALEN];
int ft_completed = wpa_ft_is_completed(wpa_s->wpa);
if (data)
wpa_supplicant_event_associnfo(wpa_s, data);
wpa_supplicant_set_state(wpa_s, WPA_ASSOCIATED);
if (wpa_s->use_client_mlme)
os_memcpy(bssid, wpa_s->bssid, ETH_ALEN);
if (wpa_s->use_client_mlme ||
(wpa_drv_get_bssid(wpa_s, bssid) >= 0 &&
os_memcmp(bssid, wpa_s->bssid, ETH_ALEN) != 0)) {
wpa_msg(wpa_s, MSG_DEBUG, "Associated to a new BSS: BSSID="
MACSTR, MAC2STR(bssid));
in other words, wpa_drv_get_bssid() returns 44:... BSSID. I could not find
any place in kernel or wpa_supplicant that would set it, so I can only assume
that firmware returns it for watever reason.
We really need more debugging in driver ...
Attachment:
signature.asc
Description: This is a digitally signed message part.
