[gutsy] Unable to associate with already associated network on ipw3945 hardware

[Scott Robinson]

Binary package hint: wpasupplicant

As detailed in bugs #121439, #119563 and probably more - the ipw3945 driver does not send an association event in the case of a requested association to the already associated AP.

wpasupplicant expects this but won't request a disassociation due to the bssid never being filled in its internal view of the wireless interface.

The attached patch can be placed in the debian/patches directory for wpasupplicant and will fill in the data structures and request a disassociation, thereby solving the problem.

[Reinhard Tartler (siretart)]

how did you come to this dpatch? have you already discussed this with upstream?

How likely is this to break non ipw3945 hardware or drivers?

[Scott Robinson (scott-ubuntu)]

I have tested it on two other laptops using bcm43xx and ndiswrapper driver sets.

I haven't discussed it with upstream - feel free to push it there. I'm not emotionally invested in this patch.

It basically works around the fact that the core wpasupplicant code has grown very organically and expects very particular behavior from WE. ipw3945 doesn't provide that behavior, but _most_ other drivers do. (Some ndiswrapper drivers don't, but handling those is a headache anyway.)

Is that a bug from ipw or a bug on wpasupplicant's part? It's debatable and definitely not one I feel like getting into on a mailing list.

[Reinhard Tartler (siretart)]

Forwarded to upstream here:
http://comments.gmane.org/gmane.linux.drivers.hostap/16345

currently waiting for comments.

[Reinhard Tartler (siretart)]

From: Dan Williams <email address hidden>
Subject: Re: [patch] Unable to associate with already associated network on
        ipw3945 hardware
Date: Tue, 04 Sep 2007 08:10:03 -0400

I'd say, fix the driver. I had to fix this in libertas too, because
that's the correct place to do it.

If a userspace process calls SIOCSIWESSID or SIOCSIWAP, then the driver
is expected to return the association event no matter what, even if the
card is already associated to the AP.

Dan

[Reinhard Tartler (siretart)]

I know that Alexander has been hacking on the ipw3945 a lot. Perhaps he can comment on this issue better than me?

[Alexander Sack (asac)]

we have a patch for the ipw3945 driver now that should make this fix obsolete. The fixed module source is available at https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac ... would be great if you could verify that this resolves your issues as well.

[Alexander Sack (asac)]

one more thing why this patch probably just works partially: the ipw3945 driver currently does not obey the associate module parameter and does auto association in any case. So unsetting the essid from userspace will just make the driver reassociate ... if that happens quick enough, the association event you want to trigger by this will still not be send. The bzr branch above is ment to fix all these issues.

[Reinhard Tartler (siretart)]

Hey Scott. This is about
https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/135442,
where you filed a patch against wpasupplicant. The upstream author has
further questions about this, could you please answer them yourself?

regards,
        Reinhard

On Tue, Sep 04, 2007 at 12:29:27PM +0200, Reinhard Tartler wrote:

> This is a forward for a bug filed by Scott Robinson against the
> wpasupplicant package in ubuntu. You can see the bug report here:
>
> https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/135442

> > the ipw3945 driver does not send an association event in the case of a
> > requested association to the already associated AP.

Does the driver actually re-associate at this point or just ignore the
request? If it re-associates, I would certainly expect it to report the
association. If not, I would have expected it to reassociate and
consequently, report the association.. ;-)

> > wpasupplicant expects this but won't request a disassociation due to
> > the bssid never being filled in its internal view of the wireless
> > interface.
> >
> > The attached patch can be placed in the debian/patches directory for
> > wpasupplicant and will fill in the data structures and request a
> > disassociation, thereby solving the problem.

I'm not that keen on forcing the disassociation at this point
unconditionally, but I do have to admit that I ended up doing exactly
the same with driver_ndis.c. Then again, with Linux, I would expect us
to be more likely to be able to make drivers behave more sanely than in
the NDIS case..

> --- wpa_supplicant/wpa_supplicant.c.orig 2007-05-28 10:26:55.000000000 -0700
> +++ wpa_supplicant/wpa_supplicant.c 2007-08-24 19:08:22.000000000 -0700
> @@ -2107,6 +2107,11 @@
> wpa_printf(MSG_DEBUG, "RSN: flushing PMKID list in the driver");
> wpa_drv_flush_pmkid(wpa_s);
>
> + /* Disassociate the interface on startup, as WPAS has presumptions
> + * about the whole mess. */
> + wpa_supplicant_get_bssid(wpa_s, wpa_s->bssid);
> + wpa_supplicant_disassociate(wpa_s, WLAN_REASON_UNSPECIFIED);

What is the get_bssid used for here if the next operation is to request
disassociation immediately? The wording of that comment is not that
helpful here..

Using get_bssid to figure out whether the driver is associated and then
do something differently could be one option. However, with WPA it is
often best to just force the driver to re-associate. I would just expect
the driver to do this (and report new association) when we ask it to
associate; even if this is for the same BSS that was used before.

--
Jouni Malinen PGP id EFC895FA

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Scott Robinson (scott-ubuntu)]

> > > the ipw3945 driver does not send an association event in the case of a
> > > requested association to the already associated AP.
>
> Does the driver actually re-associate at this point or just ignore the
> request? If it re-associates, I would certainly expect it to report the
> association. If not, I would have expected it to reassociate and
> consequently, report the association.. ;-)
>

As noted in the launchpad bug, and in the associated ipw3945 patch:

  https://code.launchpad.net/~asac/intellinuxwireless/ipw3945.asac

The driver was not reporting the association.

> I'm not that keen on forcing the disassociation at this point
> unconditionally, but I do have to admit that I ended up doing exactly
> the same with driver_ndis.c. Then again, with Linux, I would expect us
> to be more likely to be able to make drivers behave more sanely than in
> the NDIS case..
>

I agree. Though, on that note, the wext is used with ndiswrapper now, so
oddities like this still occur.

> What is the get_bssid used for here if the next operation is to request
> disassociation immediately? The wording of that comment is not that
> helpful here..
>

Because wpa_supplicant_disassociate ignores the request if the BSSID
isn't valid.

> Using get_bssid to figure out whether the driver is associated and then
> do something differently could be one option. However, with WPA it is
> often best to just force the driver to re-associate. I would just expect
> the driver to do this (and report new association) when we ask it to
> associate; even if this is for the same BSS that was used before.
>

I agree. Fortunately, it seems the patch to ipw3945 mentioned earlier
nullifies this patch.

--
Scott Robinson | http://quadhome.com/

Q: Why is this reply five sentences or less?
A: http://five.sentenc.es/

[Daniel Holbach (dholbach)]

Unsubscribing ubuntu-main-sponsors for now until there is more agreement about the patch.

[Alexander Sack (asac)]

this should be fixed in ipw3945 module now:

$ modinfo ipw3945 | grep version
version: 1.2.2mp.ubuntu1