From: Michael Buesch <mb@bu3sch.de>
To: Daniel Drake <dsd@gentoo.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
netdev@vger.kernel.org, Bcm43xx-dev@lists.berlios.de
Subject: Re: bcm43xx driver unstable behaviour (and linux wireless is junk btw)
Date: Sun, 24 Sep 2006 18:38:35 +0200 [thread overview]
Message-ID: <200609241838.35838.mb@bu3sch.de> (raw)
In-Reply-To: <4516A578.2030105@gentoo.org>
On Sunday 24 September 2006 17:34, Daniel Drake wrote:
> Michael Buesch wrote:
> > Well. Works For Me (tm).
> > If there is some bug for you in current mainline, it needs to
> > be fixed. But I can't fix something I am not able to reproduce and
> > don't know what happens.
>
> Take a look at the logs in Ben's original mail. I've seen this a lot
> myself and am fairly sure that the problem is softmac's handling of a
> SIWESSID *immediately* followed by a SIWAP call. This is what
> wpa_supplicant does, and the timing screws us over.
>
> You can see in the logs that the driver starts authenticating after the
> first ioctl comes in, but then starts scanning (in preparation for
> authentication, again) as soon as the 2nd call comes in immediately
> after. As the device is busy scanning other channels it misses the
> authentication response, and this goes round in circles.
>
> Now, Jose recently bolted on a few more lock-like flags onto the whole
> auth+assoc procedure, which has certainly helped, but the races do still
> exist, and I don't think that approach is practical: there are simply
> too many points in the sequence where softmac could be 'interrupted' by
> another ESSID/AP call.
>
> But, I'd be absolutely delighted if I'm missing something and you can
> fix it :)
Ok, thanks for the explaination. I will look into the issue.
I remember seeing racing wext calls, too.
--
Greetings Michael.
next prev parent reply other threads:[~2006-09-24 16:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 2:43 bcm43xx driver unstable behaviour (and linux wireless is junk btw) Benjamin Herrenschmidt
[not found] ` <1159065798.5924.8.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2006-09-24 3:45 ` Daniel Drake
[not found] ` <4515FF5D.4080602-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>
2006-09-24 6:18 ` Benjamin Herrenschmidt
[not found] ` <1159078683.5924.16.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2006-09-24 8:05 ` Michael Buesch
[not found] ` <200609241005.02024.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
2006-09-24 8:12 ` Benjamin Herrenschmidt
2006-09-24 8:43 ` Michael Buesch
2006-09-24 8:47 ` Benjamin Herrenschmidt
2006-09-24 15:34 ` Daniel Drake
2006-09-24 16:38 ` Michael Buesch [this message]
2006-09-25 9:02 ` Johannes Berg
2006-09-25 9:58 ` Benjamin Herrenschmidt
2006-09-25 10:00 ` Johannes Berg
2006-09-24 3:50 ` Dan Williams
[not found] ` <1159069857.2748.5.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2006-09-24 6:13 ` Benjamin Herrenschmidt
2006-09-24 16:02 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200609241838.35838.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=Bcm43xx-dev@lists.berlios.de \
--cc=benh@kernel.crashing.org \
--cc=dsd@gentoo.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).