* Re: [PATCH] compat-2.6: Makefile: fixed test expressions for target install
From: Luis R. Rodriguez @ 2009-08-05 18:32 UTC (permalink / raw)
To: Joerg Albert; +Cc: Pavel Roskin, linux-wireless@vger.kernel.org
In-Reply-To: <4A741B7B.7070200@gmx.de>
On Sat, Aug 1, 2009 at 3:39 AM, Joerg Albert<jal2@gmx.de> wrote:
> On 08/01/2009 01:22 AM, Luis R. Rodriguez wrote:
>>
>> Actually please do keep relying on /bin/bash, all the scripts on
>> compat-wireless do depend on /bin/bash, I don't expect users of
>> dash/etc to use compat-wireless.
>>
>> If we want to make compat-wireless be shell agnostic we'd need to
>> address all the other scripts. I rather not deal with that now unless
>> we really think that is also a good idea and someone is up for the
>> task.
>
> IMHO we could make bug fixes to the Makefile/scripts shell agnostic if it's
> not much effort and
> doesn't break readability, which is neither the case here.
Applied, thanks.
Luis
^ permalink raw reply
* Re: [PATCH] wireless-regdb: TH gets 5 GHz enabled as of new regulatory rules
From: John W. Linville @ 2009-08-05 18:17 UTC (permalink / raw)
To: Phattanon Duangdara; +Cc: linux-wireless
In-Reply-To: <f7de31c0907292246h6002e9bdod9691c2f24456017@mail.gmail.com>
On Thu, Jul 30, 2009 at 12:46:29PM +0700, Phattanon Duangdara wrote:
> On Wed, Jul 29, 2009 at 10:18 PM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
> > Note: this e-mail is in a public mailing list.
> >
> > Adding Michael and David. Michael, I'd appreciate your review on this,
> > if possible.
> >
> > Phattanon, thanks for your review of the TH document and sharing it
> > with us. Please see my reply inline below.
> >
> > On Wed, Jul 29, 2009 at 3:13 AM, Phattanon Duangdara<sfalpha@gmail.com> wrote:
> >> I corrected redgb from my knowledge.
> >
> > Did you see my patch? I corrected TH to be:
> >
> > country TH:
> > (2402 - 2482 @ 20), (N/A, 20)
> > (5170 - 5250 @ 20), (3, 17)
> > (5250 - 5330 @ 20), (3, 20), DFS
> > (5490 - 5710 @ 20), (3, 20), DFS
> > (5735 - 5835 @ 20), (3, 30)
> >
> >> For 5150-5350 is for Indoor Use Only.
> >> Most of the regulartory
> >
> > What do you mean by that? Do you mean that the document refers to FCC
> > and ETSI/ITU standard for regulatory purposes for some items?
> >
> >> refer _either_ FCC or ETSI/ITU standard, so I
> >> guess that from the document 40MHz can also be used (same as US)
> >> because TH regulatory mostly cover all bandwidth on 40MHz.
> >
> > Are you saying the Thailand document refers to FCC for max allowed
> > bandwidth spacing and therefore US max bandwidth spacing should be
> > used (ie allow 40 MHz width channels)?
>
> I am not sure about this. But if equipment that comply with FCC
> standard allow to use 40MHz, I think we can because, for example
> Translated rule for 2.4GHz says
<snip>
So, is the patch from Luis wrong? If so, what is the correct patch?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: wireless-regdb entry for DE wrong
From: John W. Linville @ 2009-08-05 18:20 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: linux-wireless
In-Reply-To: <4A71A6BE.20304@domdv.de>
On Thu, Jul 30, 2009 at 03:57:18PM +0200, Andreas Steinmetz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [please CC me as I'm not subscribed]
>
> Error in regulatory database for country DE:
>
> The document
>
> http://www.bundesnetzagentur.de/media/archive/5009.pdf
>
> states that the frequency range from 5470 GHz to 5725 GHz can be used
> indoor and outdoor, thus the NO-OUTDOOR flag for this range is wrong.
>
> Quick and dirty translation of the relevant text from this document
> including the note:
>
> Usage indoor and outdoor. Transmission between within a plane and a
> location outside of a plane prohibited.
Post a patch?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: Status of 802.11s in wireless-testing?
From: Johannes Berg @ 2009-08-05 18:23 UTC (permalink / raw)
To: Javier Cardona; +Cc: John W. Linville, xxiao, linux-wireless
In-Reply-To: <445f43ac0908051049wb32ea49r3e8894fd99f4ae60@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
Hi Javier,
> I agree that there is a bug in that would cause a synchronize_rcu() in
> an atomic section when the mpath table grows beyond a certain size.
> The bug was there since the first submission of the mesh code, yes.
>
> However, the "bunch of bugs that appear to have been in the code
> forever" are, I believe, regressions. In particular we've identified:
> - Airtime Link Metric broken (fix in progress)
> - Forwarding path broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124698982910794&w=2)
> - mpath pending queue broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124717648406661&w=2)
> - PREQ notification broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124752948320455&w=2)
>
> We've been busy with those but the synchronize_rcu fix is next in our list.
I was really only referring to the issue with synchronize_rcu(), and the
two related things where there's GFP_KERNEL that should be GFP_ATOMIC,
although that might have been fixed? It just felt like multiple
issues/places to me that could run into this.
> I also agree with your assessment of the severity of the bug.
> Hopefully we'll get to fix it really soon so we can re-enable mesh
> again.
Yes, that would be great, thanks. I've been meaning to look into this
(if only to understand the mesh code better), but I have little time and
a lot of other things to fix that are still regressions (currently
looking at assoc vs. reassoc for instance).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [ath5k-devel] a possible regression in managed mode ?
From: Andrea Rossato @ 2009-08-05 17:31 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: ath5k-devel@venema.h4ckr.net, linux-wireless
In-Reply-To: <20090805171523.GE4727@mosca>
On Wed, Aug 05, 2009 at 10:15:23AM -0700, Luis R. Rodriguez wrote:
> > When I use 2.6.29.4 everything works smoothly and association and
> > authentication always happen at the first try. The "authentication
> > timeout" issue only happens with the wireless-testing kernel from git.
>
> This is when using wpa_supplicant 0.6.9? Or when using both 0.6.9
> and git version of the supplicant?
That happens with both versions.
> You know you can just have wpa_supplicant try to reassoc for you
> upon disconnection automatically, right? I use something like this:
yes, but in my setup I need to force a reassociation in order to run
the dhclient and the correct configuration script - but not at boot
time.
Thanks
Andrea
^ permalink raw reply
* Re: Status of 802.11s in wireless-testing?
From: Javier Cardona @ 2009-08-05 17:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, xxiao, linux-wireless
In-Reply-To: <1249491866.6902.23.camel@johannes.local>
Hi Johannes,
On Wed, Aug 5, 2009 at 10:04 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> Right now, except from the stuff Luis had broken and fixed, the real
> problem is that there are a bunch of bugs that appear to have been in
> the code forever, just never noticed -- for instance the code can end up
> calling synchronize_rcu() in an atomic section.
I agree that there is a bug in that would cause a synchronize_rcu() in
an atomic section when the mpath table grows beyond a certain size.
The bug was there since the first submission of the mesh code, yes.
However, the "bunch of bugs that appear to have been in the code
forever" are, I believe, regressions. In particular we've identified:
- Airtime Link Metric broken (fix in progress)
- Forwarding path broken (fixed here:
http://marc.info/?l=linux-wireless&m=124698982910794&w=2)
- mpath pending queue broken (fixed here:
http://marc.info/?l=linux-wireless&m=124717648406661&w=2)
- PREQ notification broken (fixed here:
http://marc.info/?l=linux-wireless&m=124752948320455&w=2)
We've been busy with those but the synchronize_rcu fix is next in our list.
> This is the reason for disabling it -- it can splatter all over the
> scheduler if that happens, and it's not clear to me that it cannot
> happen. It seems not to happen in _most_ scenarios, but I've certainly
> caused it to happen by not beaconing, for instance.
I also agree with your assessment of the severity of the bug.
Hopefully we'll get to fix it really soon so we can re-enable mesh
again.
Thanks,
^ permalink raw reply
* Re: [ath5k-devel] a possible regression in managed mode ?
From: Luis R. Rodriguez @ 2009-08-05 17:15 UTC (permalink / raw)
To: Andrea Rossato
Cc: Luis Rodriguez, ath5k-devel@venema.h4ckr.net, linux-wireless
In-Reply-To: <20090805165227.GA18394@eeepc.nowhere.net>
Please include linux-wireless, addint it back again.
On Wed, Aug 05, 2009 at 09:52:27AM -0700, Andrea Rossato wrote:
> On Wed, Aug 05, 2009 at 05:10:18PM +0200, Luis R. Rodriguez wrote:
> > Can you try with -D nl80211 and see if that fixes your issue?
>
> I'll be able to try that in a couple of days... I'm now in the
> situation when I run my eee pc in Master mode.
>
> >
> > Also from your description of the issue below it is unclear to me if
> > you do not see these issues with an older kernel or if this is only
> > happening with newer kernels or wireless-testing. Can you please
> > clarify.
>
> When I use 2.6.29.4 everything works smoothly and association and
> authentication always happen at the first try. The "authentication
> timeout" issue only happens with the wireless-testing kernel from git.
This is when using wpa_supplicant 0.6.9? Or when using both 0.6.9
and git version of the supplicant?
> Since my scripts always call "wpa_cli reassociate" I was not aware of
> the fact that the first time wpa_supplicant was succeeding in
> associating the first time (hence the Access Point log that show the
> first successful association and nothing more).
You know you can just have wpa_supplicant try to reassoc for you
upon disconnection automatically, right? I use something like this:
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="mosca"
scan_ssid=1
key_mgmt=NONE
}
> On Wed, Aug 05, 2009 at 05:53:31PM +0200, Luis R. Rodriguez wrote:
> >
> > Also please install iw, and provide 'iw event -t' log.
>
> Already installed here. I'll provide the output as soon as I'll be
> able to test the nl80211 driver.
May want to update from git, iw has been updated recently so you could
decode more messages specially if using wireless-testing.
Luis
^ permalink raw reply
* Re: Status of 802.11s in wireless-testing?
From: Johannes Berg @ 2009-08-05 17:04 UTC (permalink / raw)
To: John W. Linville; +Cc: xxiao, linux-wireless
In-Reply-To: <20090805165021.GA20338@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
On Wed, 2009-08-05 at 12:50 -0400, John W. Linville wrote:
> On Wed, Aug 05, 2009 at 09:08:54AM -0700, xxiao wrote:
> > I didn't see patches from open80211s project for a while, which
> > means it will break as the rest mac80211/drivers are evolving quickly.
>
> You may be right, but it _should_not_ mean that -- at least not
> necessarily. Yes, there will be accidental breakage from time to time.
> But developers ought to keep mesh in mind when making changes and
> they should be "on the hook" to fix whatever breaks.
Right now, except from the stuff Luis had broken and fixed, the real
problem is that there are a bunch of bugs that appear to have been in
the code forever, just never noticed -- for instance the code can end up
calling synchronize_rcu() in an atomic section.
This is the reason for disabling it -- it can splatter all over the
scheduler if that happens, and it's not clear to me that it cannot
happen. It seems not to happen in _most_ scenarios, but I've certainly
caused it to happen by not beaconing, for instance.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Status of 802.11s in wireless-testing?
From: John W. Linville @ 2009-08-05 16:50 UTC (permalink / raw)
To: xxiao; +Cc: devel, linux-wireless
In-Reply-To: <175701.5780.qm@web55308.mail.re4.yahoo.com>
On Wed, Aug 05, 2009 at 09:08:54AM -0700, xxiao wrote:
> I didn't see patches from open80211s project for a while, which
> means it will break as the rest mac80211/drivers are evolving quickly.
You may be right, but it _should_not_ mean that -- at least not
necessarily. Yes, there will be accidental breakage from time to time.
But developers ought to keep mesh in mind when making changes and
they should be "on the hook" to fix whatever breaks.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: Status of 802.11s in wireless-testing?
From: xxiao @ 2009-08-05 16:08 UTC (permalink / raw)
To: devel; +Cc: linux-wireless
In-Reply-To: <2f1373ed0908042145pc83adc5qd968e3bf8d0ce3c7@mail.gmail.com>
I didn't see patches from open80211s project for a while, which means it will break as the rest mac80211/drivers are evolving quickly.
to get mesh working I now spend more time to use the ibss/ad-hoc mode in mac80211 instead.
xxiao
--- On Tue, 8/4/09, Steve Glass <stevie.glass@gmail.com> wrote:
> From: Steve Glass <stevie.glass@gmail.com>
> Subject: Status of 802.11s in wireless-testing?
> To: devel@lists.open80211s.org
> Date: Tuesday, August 4, 2009, 11:45 PM
> Hi,
>
> I noticed today that 802.11s has been disabled when running
> "make xconfig". Apparently its been marked as
> broken although Luis Rodriguez has posted a patch to at
> least have it compile successfully.
>
>
> I missed all this because I usually run "make
> oldconfig" so it came as a surprise . It did, however,
> explain why iw was telling me that my ath5k device supported
> mesh point mode but would fail when I tried to create one.
>
>
> What can we do to help? Its a huge step backwards to be
> marked as broken so I've applied Luis' compilation
> patch and want to know where to look to find out what
> functionality is broken. Is anyone working on it? What can
> we do to help?
>
>
> Stevie
>
> --
> The highest human happiness is not the exploitation of the
> present but the preparation of the future.
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Devel mailing list
> Devel@lists.open80211s.org
> http://open80211s.com/mailman/listinfo/devel
>
^ permalink raw reply
* Re: [ath5k-devel] a possible regression in managed mode ?
From: Luis R. Rodriguez @ 2009-08-05 15:53 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: andrea rossato, Johannes Berg, linux-wireless,
ath5k-devel@venema.h4ckr.net
In-Reply-To: <43e72e890908050810h29c28945o4732f8606caab9fb@mail.gmail.com>
On Wed, Aug 05, 2009 at 08:10:18AM -0700, Luis R. Rodriguez wrote:
> On Wed, Aug 5, 2009 at 6:41 AM, andrea rossato<andrea.rossato@unitn.it> wrote:
> > On Tue, Aug 04, 2009 at 08:36:43AM -0700, Luis R. Rodriguez wrote:
> >> Also, can you try wpa_supplicant from git, to see if that makes a
> >> difference?
> > ...
> >>
> >> I should note that new kernel stuff should not bust with old
> >> userspace. If upgrading to a newer supplicant fixes your issue
> >> we may have a regression somewhere in wireless-testing, which
> >> I have been suspicious about, but haven't had time to look at it.
> >
> >
> > On Tue, Aug 04, 2009 at 08:36:43AM -0700, Luis R. Rodriguez wrote:
> >> Also, can you try wpa_supplicant from git, to see if that makes a
> >> difference?
> > ...
> >>
> >> I should note that new kernel stuff should not bust with old
> >> userspace. If upgrading to a newer supplicant fixes your issue
> >> we may have a regression somewhere in wireless-testing, which
> >> I have been suspicious about, but haven't had time to look at it.
> >
> >
> > Well, I need to correct myself a bit: after trying wpa_supplicant from
> > git and noticing it worked fine I wanted to investigate a bit further
> > and went back to the 0.6.9 release. And it worked too, sort of...
> >
> > Basically both versions work with the first association and
> > authentication. The problem comes when I ask them or they need to
> > reassociate.
>
> Can you try with -D nl80211 and see if that fixes your issue?
>
> Also from your description of the issue below it is unclear to me if
> you do not see these issues with an older kernel or if this is only
> happening with newer kernels or wireless-testing. Can you please
> clarify.
>
> Luis
>
> > Now, since I do not use NetworkManager, and I need to connect to
> > different wireless networks with different configurations (dhcp,
> > proxies, etc.), in my scripts I use something like:
> >
> > wpa_cli -a/usr/local/sbin/wpa_action -B
> >
> > followed by a:
> > wpa_cli rea
> >
> > And whenever wpa_supplicat tries to associate for a second time I keep
> > getting an authentication timeout error.
> >
> > For instance:
> >
> > [13:38:02]$ wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf
> > CTRL-EVENT-SCAN-RESULTS
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > CTRL-EVENT-SCAN-RESULTS
> > Associated with 00:22:b0:70:1f:67
> > WPA: Key negotiation completed with 00:22:b0:70:1f:67 [PTK=CCMP GTK=TKIP]
> > CTRL-EVENT-CONNECTED - Connection to 00:22:b0:70:1f:67 completed (auth) [id=1 id_str=]
> >
> > The first run is ok. But I cannot reassociate. Below you'll see the
> > output of wpa_supplicant and iwevent when I run `wpa_cli reas`.
> >
> > Now, if I run the adapter in Master mode (as an access point) and then
> > go back to Managed mode with wpa_supplicant, the first association and
> > authentication will work most of the time (not always).
> >
> > I'm puzzled but that could be a useful piece of information,
> > hopefully. Take into account that my other Eee pc connects always
> > perfectly with the very same AP (as mine does when running
> > wpa_supplicant for the first time).
> >
> > Right now I have some troubles in providing some better debugging
> > output (I cannot reboot right now, due to some unfinished work that
> > must have the precedence), but please let me know what might be useful
> > and I'll try to come up with something in the next few days.
> >
> > Andrea
> >
> > The wpa_supplicant output:
> >
> > CTRL-EVENT-SCAN-RESULTS
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > Authentication with 00:22:b0:70:1f:67 timed out.
> > CTRL-EVENT-SCAN-RESULTS
> > WPS-AP-AVAILABLE
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > Authentication with 00:22:b0:70:1f:67 timed out.
> > CTRL-EVENT-SCAN-RESULTS
> > WPS-AP-AVAILABLE
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > Authentication with 00:22:b0:70:1f:67 timed out.
> > CTRL-EVENT-SCAN-RESULTS
> > WPS-AP-AVAILABLE
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > Authentication with 00:22:b0:70:1f:67 timed out.
> > CTRL-EVENT-SCAN-RESULTS
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > Authentication with 00:22:b0:70:1f:67 timed out.
> > CTRL-EVENT-SCAN-RESULTS
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > Authentication with 00:22:b0:70:1f:67 timed out.
> > CTRL-EVENT-SCAN-RESULTS
> > WPS-AP-AVAILABLE
> > Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> > Authentication with 00:22:b0:70:1f:67 timed out.
> >
> > The iwevent session:
Also please install iw, and provide 'iw event -t' log.
http://wireless.kernel.org/en/users/Documentation/iw
Luis
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Marcel Holtmann @ 2009-08-05 15:45 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, linville, Reinette Chatre, Johannes Berg
In-Reply-To: <1249450153.6083.4.camel@maxim-laptop>
Hi Maxim,
> > > From: Maxim Levitsky <maximlevitsky@gmail.com>
> > > Date: Fri, 31 Jul 2009 18:54:12 +0300
> > > Subject: [PATCH] [MAC80211] Retry probe request few times
> > >
> > > Retry 5 times (chosen arbitary ), before assuming
> > > that station is out of range.
> >
> > so today I got the disconnect :(
> >
> > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
> > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
> > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
> >
> > Should we increase the value to 8 or something? Or just accept that
> > sometimes we get a disconnect?
> >
> I think a disconnect or two aren't a problem, they are always handled
> automatically, and can be caused by natural events.
>
> Even without these patches (I have WPA2, and disconnects were every 4
> five seconds), and still it was possible to use network.
this assumption only works if you are not using NetworkManager or alike
where every new connect triggers DHCP again. If we wanna survive them,
then we have to teach them to handle the lease time more intelligent
which is kinda tricky. Might be worth doing anyway. I have to play with
it a little bit.
> One disconnect in a day is really nothing to worry about (I have seen
> such here as well)
>
> You can increase try count, probably won't hurt much (each try is 0.5
> seconds, so even 10 tries gives total of 5 seconds, before disconnect on
> a really unaccessible AP, anyway)
Or just increase the try to 1 second. I still think there is something
odd going on with the iwlwifi driver here, but so far nobody saw
anything that is obviously wrong.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] nl80211: fix attrtype and value for NL80211_ATTR_SUPPORTED_COMMANDS
From: Johannes Berg @ 2009-08-05 15:41 UTC (permalink / raw)
To: Zhu Yi; +Cc: linville, linux-wireless
In-Reply-To: <1249464510-21539-1-git-send-email-yi.zhu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Wed, 2009-08-05 at 17:28 +0800, Zhu Yi wrote:
> The patch fixes the misuse between attrtype and value for the
> CMD list nested in NL80211_ATTR_SUPPORTED_COMMANDS attribute.
No? It was this way intentionally.
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -520,7 +520,7 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
> do { \
> if (dev->ops->op) { \
> i++; \
> - NLA_PUT_U32(msg, i, NL80211_CMD_ ## n); \
> + NLA_PUT_U32(msg, NL80211_CMD_ ## n, i); \
This is an array, the index doesn't matter, and the value is the
supported command. You parse it with nla_for_each_nested()
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [ath5k-devel] a possible regression in managed mode ?
From: Luis R. Rodriguez @ 2009-08-05 15:10 UTC (permalink / raw)
To: andrea rossato; +Cc: ath5k-devel, linux-wireless, Johannes Berg
On Wed, Aug 5, 2009 at 6:41 AM, andrea rossato<andrea.rossato@unitn.it> wrote:
> On Tue, Aug 04, 2009 at 08:36:43AM -0700, Luis R. Rodriguez wrote:
>> Also, can you try wpa_supplicant from git, to see if that makes a
>> difference?
> ...
>>
>> I should note that new kernel stuff should not bust with old
>> userspace. If upgrading to a newer supplicant fixes your issue
>> we may have a regression somewhere in wireless-testing, which
>> I have been suspicious about, but haven't had time to look at it.
>
>
> On Tue, Aug 04, 2009 at 08:36:43AM -0700, Luis R. Rodriguez wrote:
>> Also, can you try wpa_supplicant from git, to see if that makes a
>> difference?
> ...
>>
>> I should note that new kernel stuff should not bust with old
>> userspace. If upgrading to a newer supplicant fixes your issue
>> we may have a regression somewhere in wireless-testing, which
>> I have been suspicious about, but haven't had time to look at it.
>
>
> Well, I need to correct myself a bit: after trying wpa_supplicant from
> git and noticing it worked fine I wanted to investigate a bit further
> and went back to the 0.6.9 release. And it worked too, sort of...
>
> Basically both versions work with the first association and
> authentication. The problem comes when I ask them or they need to
> reassociate.
Can you try with -D nl80211 and see if that fixes your issue?
Also from your description of the issue below it is unclear to me if
you do not see these issues with an older kernel or if this is only
happening with newer kernels or wireless-testing. Can you please
clarify.
Luis
> Now, since I do not use NetworkManager, and I need to connect to
> different wireless networks with different configurations (dhcp,
> proxies, etc.), in my scripts I use something like:
>
> wpa_cli -a/usr/local/sbin/wpa_action -B
>
> followed by a:
> wpa_cli rea
>
> And whenever wpa_supplicat tries to associate for a second time I keep
> getting an authentication timeout error.
>
> For instance:
>
> [13:38:02]$ wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf
> CTRL-EVENT-SCAN-RESULTS
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> CTRL-EVENT-SCAN-RESULTS
> Associated with 00:22:b0:70:1f:67
> WPA: Key negotiation completed with 00:22:b0:70:1f:67 [PTK=CCMP GTK=TKIP]
> CTRL-EVENT-CONNECTED - Connection to 00:22:b0:70:1f:67 completed (auth) [id=1 id_str=]
>
> The first run is ok. But I cannot reassociate. Below you'll see the
> output of wpa_supplicant and iwevent when I run `wpa_cli reas`.
>
> Now, if I run the adapter in Master mode (as an access point) and then
> go back to Managed mode with wpa_supplicant, the first association and
> authentication will work most of the time (not always).
>
> I'm puzzled but that could be a useful piece of information,
> hopefully. Take into account that my other Eee pc connects always
> perfectly with the very same AP (as mine does when running
> wpa_supplicant for the first time).
>
> Right now I have some troubles in providing some better debugging
> output (I cannot reboot right now, due to some unfinished work that
> must have the precedence), but please let me know what might be useful
> and I'll try to come up with something in the next few days.
>
> Andrea
>
> The wpa_supplicant output:
>
> CTRL-EVENT-SCAN-RESULTS
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Authentication with 00:22:b0:70:1f:67 timed out.
> CTRL-EVENT-SCAN-RESULTS
> WPS-AP-AVAILABLE
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Authentication with 00:22:b0:70:1f:67 timed out.
> CTRL-EVENT-SCAN-RESULTS
> WPS-AP-AVAILABLE
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Authentication with 00:22:b0:70:1f:67 timed out.
> CTRL-EVENT-SCAN-RESULTS
> WPS-AP-AVAILABLE
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Authentication with 00:22:b0:70:1f:67 timed out.
> CTRL-EVENT-SCAN-RESULTS
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Authentication with 00:22:b0:70:1f:67 timed out.
> CTRL-EVENT-SCAN-RESULTS
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Authentication with 00:22:b0:70:1f:67 timed out.
> CTRL-EVENT-SCAN-RESULTS
> WPS-AP-AVAILABLE
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Authentication with 00:22:b0:70:1f:67 timed out.
>
> The iwevent session:
> Waiting for Wireless Events from interfaces...
> 13:38:18.981673 wlan0 Set Mode:Managed
> 13:38:20.627136 wlan0 Scan request completed
> 13:38:20.652664 wlan0 Set Mode:Managed
> 13:38:20.652715 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:38:20.809462 wlan0 Scan request completed
> 13:38:20.817356 wlan0 Association Response IEs:010882848B960C12182432043048606C
> 13:38:20.817430 wlan0 New Access Point/Cell address:00:22:B0:70:1F:67
> 13:39:01.101861 wlan0 Scan request completed
> 13:39:01.103037 wlan0 Set Mode:Managed
> 13:39:01.103086 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:39:16.814358 wlan0 Scan request completed
> 13:39:16.814860 wlan0 Set Mode:Managed
> 13:39:16.814895 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:39:32.553004 wlan0 Scan request completed
> 13:39:32.553482 wlan0 Set Mode:Managed
> 13:39:32.553518 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:39:48.264804 wlan0 Scan request completed
> 13:39:48.265324 wlan0 Set Mode:Managed
> 13:39:48.265360 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:40:03.964434 wlan0 Scan request completed
> 13:40:03.964875 wlan0 Set Mode:Managed
> 13:40:03.964912 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:40:19.668543 wlan0 Scan request completed
> 13:40:19.668963 wlan0 Set Mode:Managed
> 13:40:19.668998 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:40:35.368787 wlan0 Scan request completed
> 13:40:35.369267 wlan0 Set Mode:Managed
> 13:40:35.369307 wlan0 Set Frequency:2.427 GHz (Channel 4)
> 13:40:51.067925 wlan0 Scan request completed
> 13:40:51.068308 wlan0 Set Mode:Managed
> 13:40:51.068338 wlan0 Set Frequency:2.427 GHz (Channel 4)
>
>
> /var/log/messages when turning on the adapter:
> Aug 5 13:35:45 eeepc kernel: cfg80211: Using static regulatory domain info
> Aug 5 13:35:45 eeepc kernel: cfg80211: Regulatory domain: US
> Aug 5 13:35:45 eeepc kernel: ^I(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> Aug 5 13:35:45 eeepc kernel: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> Aug 5 13:35:45 eeepc kernel: ^I(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> Aug 5 13:35:45 eeepc kernel: ^I(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> Aug 5 13:35:45 eeepc kernel: ^I(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> Aug 5 13:35:45 eeepc kernel: ^I(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> Aug 5 13:35:45 eeepc kernel: ^I(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> Aug 5 13:35:45 eeepc kernel: cfg80211: Calling CRDA for country: US
> Aug 5 13:35:46 eeepc kernel: cfg80211: Regulatory domain changed to country: US
> Aug 5 13:35:46 eeepc kernel: ^I(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> Aug 5 13:35:46 eeepc kernel: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> Aug 5 13:35:46 eeepc kernel: ^I(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Aug 5 13:35:46 eeepc kernel: ^I(5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Aug 5 13:35:46 eeepc kernel: ^I(5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Aug 5 13:35:46 eeepc kernel: ^I(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Aug 5 13:35:46 eeepc kernel: ath5k 0000:01:00.0: enabling device (0000 -> 0002)
> Aug 5 13:35:46 eeepc kernel: ath5k 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
> Aug 5 13:35:46 eeepc kernel: ath5k 0000:01:00.0: registered as 'phy0'
> Aug 5 13:35:46 eeepc kernel: Registered led device: ath5k-phy0::rx
> Aug 5 13:35:46 eeepc kernel: Registered led device: ath5k-phy0::tx
> Aug 5 13:35:46 eeepc kernel: ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
>
>
> some output from running wpa_supplicant -d:
>
> Authentication with 00:22:b0:70:1f:67 timed out.
> Added BSSID 00:22:b0:70:1f:67 into blacklist
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: SUPP_PAE entering state DISCONNECTED
> EAPOL: SUPP_BE entering state INITIALIZE
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (specific SSID)
> Scan SSID - hexdump_ascii(len=14):
> 49 73 74 69 74 75 74 6f 20 43 6f 6c 6c 69 Istituto Colli
> Scan requested (ret=0) - scan timeout 30 seconds
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 820 bytes of scan results (2 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> WPS-AP-AVAILABLE
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> Authentication with 00:22:b0:70:1f:67 timed out.
> BSSID 00:22:b0:70:1f:67 blacklist count incremented to 2
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (broadcast SSID)
> Scan requested (ret=0) - scan timeout 30 seconds
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 327 bytes of scan results (1 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> Try to find non-WPA AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> No APs found - clear blacklist and try again
> Removed BSSID 00:22:b0:70:1f:67 from blacklist (clear)
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> Authentication with 00:22:b0:70:1f:67 timed out.
> Added BSSID 00:22:b0:70:1f:67 into blacklist
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (specific SSID)
> Scan SSID - hexdump_ascii(len=7):
> 75 6e 69 74 6e 2d 78 unitn-x
> Scan requested (ret=0) - scan timeout 30 seconds
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 327 bytes of scan results (1 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> RX ctrl_iface - hexdump_ascii(len=6):
> 53 54 41 54 55 53 STATUS
> Authentication with 00:22:b0:70:1f:67 timed out.
> BSSID 00:22:b0:70:1f:67 blacklist count incremented to 2
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (specific SSID)
> Scan SSID - hexdump_ascii(len=14):
> 49 73 74 69 74 75 74 6f 20 43 6f 6c 6c 69 Istituto Colli
> Scan requested (ret=0) - scan timeout 30 seconds
> RX ctrl_iface - hexdump_ascii(len=6):
> 53 54 41 54 55 53 STATUS
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 820 bytes of scan results (2 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> WPS-AP-AVAILABLE
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> 1: 00:1c:f0:f3:b0:ee ssid='ISITWIFI_SEG' wpa_ie_len=26 rsn_ie_len=24 caps=0x11
> skip - SSID mismatch
> skip - SSID mismatch
> skip - SSID mismatch
> Try to find non-WPA AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> 1: 00:1c:f0:f3:b0:ee ssid='ISITWIFI_SEG' wpa_ie_len=26 rsn_ie_len=24 caps=0x11
> skip - SSID mismatch
> skip - SSID mismatch
> skip - privacy mismatch
> No APs found - clear blacklist and try again
> Removed BSSID 00:22:b0:70:1f:67 from blacklist (clear)
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> Authentication with 00:22:b0:70:1f:67 timed out.
> Added BSSID 00:22:b0:70:1f:67 into blacklist
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (broadcast SSID)
> Scan requested (ret=0) - scan timeout 30 seconds
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 327 bytes of scan results (1 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> Authentication with 00:22:b0:70:1f:67 timed out.
> BSSID 00:22:b0:70:1f:67 blacklist count incremented to 2
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (specific SSID)
> Scan SSID - hexdump_ascii(len=7):
> 75 6e 69 74 6e 2d 78 unitn-x
> Scan requested (ret=0) - scan timeout 30 seconds
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 820 bytes of scan results (2 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> WPS-AP-AVAILABLE
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> 1: 00:1c:f0:f3:b0:ee ssid='ISITWIFI_SEG' wpa_ie_len=26 rsn_ie_len=24 caps=0x11
> skip - SSID mismatch
> skip - SSID mismatch
> skip - SSID mismatch
> Try to find non-WPA AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> 1: 00:1c:f0:f3:b0:ee ssid='ISITWIFI_SEG' wpa_ie_len=26 rsn_ie_len=24 caps=0x11
> skip - SSID mismatch
> skip - SSID mismatch
> skip - privacy mismatch
> No APs found - clear blacklist and try again
> Removed BSSID 00:22:b0:70:1f:67 from blacklist (clear)
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> Authentication with 00:22:b0:70:1f:67 timed out.
> Added BSSID 00:22:b0:70:1f:67 into blacklist
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (specific SSID)
> Scan SSID - hexdump_ascii(len=14):
> 49 73 74 69 74 75 74 6f 20 43 6f 6c 6c 69 Istituto Colli
> Scan requested (ret=0) - scan timeout 30 seconds
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 327 bytes of scan results (1 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> Authentication with 00:22:b0:70:1f:67 timed out.
> BSSID 00:22:b0:70:1f:67 blacklist count incremented to 2
> No keys have been configured - skip key clearing
> State: ASSOCIATING -> DISCONNECTED
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> EAPOL: External notification - portEnabled=0
> EAPOL: External notification - portValid=0
> EAPOL: External notification - EAP success=0
> Setting scan request: 0 sec 0 usec
> State: DISCONNECTED -> SCANNING
> Starting AP scan (broadcast SSID)
> Scan requested (ret=0) - scan timeout 30 seconds
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b19 len=8
> Received 327 bytes of scan results (1 BSSes)
> CTRL-EVENT-SCAN-RESULTS
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> Try to find non-WPA AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - blacklisted
> No APs found - clear blacklist and try again
> Removed BSSID 00:22:b0:70:1f:67 from blacklist (clear)
> Selecting BSS from priority group 0
> Try to find WPA-enabled AP
> 0: 00:22:b0:70:1f:67 ssid='Istituto Colli' wpa_ie_len=26 rsn_ie_len=0 caps=0x11
> skip - SSID mismatch
> selected based on WPA IE
> selected WPA AP 00:22:b0:70:1f:67 ssid='Istituto Colli'
> Trying to associate with 00:22:b0:70:1f:67 (SSID='Istituto Colli' freq=2427 MHz)
> Cancelling scan request
> WPA: clearing own WPA/RSN IE
> Automatic auth_alg selection: 0x1
> WPA: using IEEE 802.11i/D3.0
> WPA: Selected cipher suites: group 8 pairwise 24 key_mgmt 2 proto 1
> WPA: set AP WPA IE - hexdump(len=28): dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 04 00 50 f2 02 01 00 00 50 f2 02
> WPA: clearing AP RSN IE
> WPA: using GTK TKIP
> WPA: using PTK CCMP
> WPA: using KEY_MGMT WPA-PSK
> WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 04 01 00 00 50 f2 02
> No keys have been configured - skip key clearing
> wpa_driver_wext_set_drop_unencrypted
> State: SCANNING -> ASSOCIATING
> wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> WEXT: Operstate: linkmode=-1, operstate=5
> wpa_driver_wext_associate
> wpa_driver_wext_set_psk
> Setting authentication timeout: 10 sec 0 usec
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b06 len=8
> RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP])
> RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
> Wireless event: cmd=0x8b04 len=12
> Authentication with 00:22:b0:70:1f:67 timed out.
> _______________________________________________
> ath5k-devel mailing list
> ath5k-devel@lists.ath5k.org
> https://lists.ath5k.org/mailman/listinfo/ath5k-devel
>
^ permalink raw reply
* [PATCH] wl12xx: make irq handling interface specific
From: Bob Copeland @ 2009-08-05 13:56 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <877hxionnt.fsf@litku.valot.fi>
In SDIO, the host driver requests the IRQ and invokes a callback to the
card driver. This differs from SPI, so the relevant code needs to be
interface-specific. This patch pushes the irq code down into _spi.c
and _sdio.c, and adds enable/disable callbacks.
This fixes the following warning:
[ 566.343887] ------------[ cut here ]------------
[ 566.349105] WARNING: at kernel/irq/manage.c:222 __enable_irq+0x3c/0x6c()
[ 566.356735] Unbalanced enable for IRQ 0
[ 566.361099] Modules linked in: msm_wifi wl12xx_sdio wl12xx mac80211 cfg80211 rfkill_backport lib80211_crypt_ccmp lib80211_crypt_wep lib80211_crypt_tkip lib80211
[ 566.381240] [<c025acec>] (dump_stack+0x0/0x14) from [<c004b610>] (warn_slowpath+0x70/0x8c)
[ 566.391860] [<c004b5a0>] (warn_slowpath+0x0/0x8c) from [<c0077c10>] (__enable_irq+0x3c/0x6c)
[ 566.402572] r3:00000000 r2:c02cad13
[ 566.407516] r7:00001002 r6:00000000 r5:c0310be4 r4:c0310be4
[ 566.415786] [<c0077bd4>] (__enable_irq+0x0/0x6c) from [<c0077fd0>] (enable_irq+0x38/0x64)
[ 566.425826] r5:c0310be4 r4:a0000013
[ 566.430709] [<c0077f98>] (enable_irq+0x0/0x64) from [<bf0dfa78>] (wl12xx_boot_run_firmware+0xfc/0x170 [wl12xx])
[ 566.442947] r7:00001002 r6:c440a9fc r5:00000072 r4:c440a9e0
[ 566.450851] [<bf0df97c>] (wl12xx_boot_run_firmware+0x0/0x170 [wl12xx]) from [<bf0e05f0>] (wl1251_boot+0xd4/0x108 [wl12xx])
[ 566.464492] r5:00000000 r4:c440a9e0
[ 566.469466] [<bf0e051c>] (wl1251_boot+0x0/0x108 [wl12xx]) from [<bf0dd27c>] (wl12xx_op_start+0x54/0xb8 [wl12xx])
[ 566.482162] r5:00000000 r4:c440a9e0
[ 566.487472] [<bf0dd228>] (wl12xx_op_start+0x0/0xb8 [wl12xx]) from [<bf0b96dc>] (ieee80211_open+0x2dc/0x720 [mac80211])
[ 566.500594] r7:00001002 r6:c4950800 r5:c440a220 r4:00000000
[ 566.508865] [<bf0b9400>] (ieee80211_open+0x0/0x720 [mac80211]) from [<c01f1edc>] (dev_open+0x9c/0xfc)
[ 566.520705] [<c01f1e40>] (dev_open+0x0/0xfc) from [<c01f17dc>] (dev_change_flags+0x98/0x170)
[ 566.531417] r5:00000041 r4:c4950800
[ 566.536330] [<c01f1744>] (dev_change_flags+0x0/0x170) from [<c023041c>] (devinet_ioctl+0x3a8/0x784)
[ 566.547683] r7:c128e380 r6:00000001 r5:00008914 r4:00000000
[ 566.555587] [<c0230074>] (devinet_ioctl+0x0/0x784) from [<c02318cc>] (inet_ioctl+0xdc/0x114)
[ 566.566299] [<c02317f0>] (inet_ioctl+0x0/0x114) from [<c01e1a60>] (sock_ioctl+0x1f0/0x248)
[ 566.576827] r5:00008914 r4:c572c1a0
[ 566.581771] [<c01e1870>] (sock_ioctl+0x0/0x248) from [<c00b23a0>] (vfs_ioctl+0x34/0x94)
[ 566.592086] r7:c572c1a0 r6:bee497e8 r5:00008914 r4:c572c1a0
[ 566.599990] [<c00b236c>] (vfs_ioctl+0x0/0x94) from [<c00b2a28>] (do_vfs_ioctl+0x52c/0x584)
[ 566.610549] r7:c572c1a0 r6:00008914 r5:c572c1a0 r4:c3201228
[ 566.618453] [<c00b24fc>] (do_vfs_ioctl+0x0/0x584) from [<c00b2ac0>] (sys_ioctl+0x40/0x64)
[ 566.628890] [<c00b2a80>] (sys_ioctl+0x0/0x64) from [<c0021da0>] (ret_fast_syscall+0x0/0x2c)
[ 566.639541] r7:00000036 r6:00000000 r5:00000004 r4:001a11f3
[ 566.647445] ---[ end trace 15c26ef7dd5e7b03 ]---
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
v2: make sdio irq functions void to match wl1251.h
drivers/net/wireless/wl12xx/wl1251.h | 5 +++-
drivers/net/wireless/wl12xx/wl1251_boot.c | 7 +-----
drivers/net/wireless/wl12xx/wl1251_main.c | 24 +++++-------------
drivers/net/wireless/wl12xx/wl1251_sdio.c | 36 +++++++++++++++++++++-------
drivers/net/wireless/wl12xx/wl1251_spi.c | 26 +++++++++++++++++++++
5 files changed, 65 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1251.h b/drivers/net/wireless/wl12xx/wl1251.h
index ebe2c70..13f0589 100644
--- a/drivers/net/wireless/wl12xx/wl1251.h
+++ b/drivers/net/wireless/wl12xx/wl1251.h
@@ -285,6 +285,8 @@ struct wl1251_if_operations {
void (*read)(struct wl1251 *wl, int addr, void *buf, size_t len);
void (*write)(struct wl1251 *wl, int addr, void *buf, size_t len);
void (*reset)(struct wl1251 *wl);
+ void (*enable_irq)(struct wl1251 *wl);
+ void (*disable_irq)(struct wl1251 *wl);
};
struct wl1251 {
@@ -404,10 +406,11 @@ struct wl1251 {
int wl1251_plt_start(struct wl1251 *wl);
int wl1251_plt_stop(struct wl1251 *wl);
-irqreturn_t wl1251_irq(int irq, void *cookie);
struct ieee80211_hw *wl1251_alloc_hw(void);
int wl1251_free_hw(struct wl1251 *wl);
int wl1251_init_ieee80211(struct wl1251 *wl);
+void wl1251_enable_interrupts(struct wl1251 *wl);
+void wl1251_disable_interrupts(struct wl1251 *wl);
#define DEFAULT_HW_GEN_MODULATION_TYPE CCK_LONG /* Long Preamble */
#define DEFAULT_HW_GEN_TX_RATE RATE_2MBPS
diff --git a/drivers/net/wireless/wl12xx/wl1251_boot.c b/drivers/net/wireless/wl12xx/wl1251_boot.c
index 5c6f327..8b50d44 100644
--- a/drivers/net/wireless/wl12xx/wl1251_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1251_boot.c
@@ -29,11 +29,6 @@
#include "wl1251_spi.h"
#include "wl1251_event.h"
-static void wl1251_boot_enable_interrupts(struct wl1251 *wl)
-{
- enable_irq(wl->irq);
-}
-
void wl1251_boot_target_enable_interrupts(struct wl1251 *wl)
{
wl1251_reg_write32(wl, ACX_REG_INTERRUPT_MASK, ~(wl->intr_mask));
@@ -278,7 +273,7 @@ int wl1251_boot_run_firmware(struct wl1251 *wl)
*/
/* enable gpio interrupts */
- wl1251_boot_enable_interrupts(wl);
+ wl1251_enable_interrupts(wl);
wl->chip.op_target_enable_interrupts(wl);
diff --git a/drivers/net/wireless/wl12xx/wl1251_main.c b/drivers/net/wireless/wl12xx/wl1251_main.c
index abe157a..4c1aad3 100644
--- a/drivers/net/wireless/wl12xx/wl1251_main.c
+++ b/drivers/net/wireless/wl12xx/wl1251_main.c
@@ -42,9 +42,14 @@
#include "wl1251_init.h"
#include "wl1251_debugfs.h"
-static void wl1251_disable_interrupts(struct wl1251 *wl)
+void wl1251_enable_interrupts(struct wl1251 *wl)
{
- disable_irq(wl->irq);
+ wl->if_ops->enable_irq(wl);
+}
+
+void wl1251_disable_interrupts(struct wl1251 *wl)
+{
+ wl->if_ops->disable_irq(wl);
}
static void wl1251_power_off(struct wl1251 *wl)
@@ -57,20 +62,6 @@ static void wl1251_power_on(struct wl1251 *wl)
wl->set_power(true);
}
-irqreturn_t wl1251_irq(int irq, void *cookie)
-{
- struct wl1251 *wl;
-
- wl1251_debug(DEBUG_IRQ, "IRQ");
-
- wl = cookie;
-
- schedule_work(&wl->irq_work);
-
- return IRQ_HANDLED;
-}
-EXPORT_SYMBOL_GPL(wl1251_irq);
-
static int wl1251_fetch_firmware(struct wl1251 *wl)
{
const struct firmware *fw;
@@ -1280,7 +1271,6 @@ int wl1251_free_hw(struct wl1251 *wl)
wl1251_debugfs_exit(wl);
- free_irq(wl->irq, wl);
kfree(wl->target_mem_map);
kfree(wl->data_path);
kfree(wl->fw);
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index f1d9e76..f7e451f 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -50,7 +50,12 @@ static struct sdio_func *wl_to_func(struct wl1251 *wl)
static void wl1251_sdio_interrupt(struct sdio_func *func)
{
- wl1251_irq(0, sdio_get_drvdata(func));
+ struct wl1251 *wl = sdio_get_drvdata(func);
+
+ wl1251_debug(DEBUG_IRQ, "IRQ");
+
+ /* FIXME should be synchronous for sdio */
+ schedule_work(&wl->irq_work);
}
static const struct sdio_device_id wl1251_devices[] = {
@@ -88,6 +93,24 @@ void wl1251_sdio_reset(struct wl1251 *wl)
{
}
+static void wl1251_sdio_enable_irq(struct wl1251 *wl)
+{
+ struct sdio_func *func = wl_to_func(wl);
+
+ sdio_claim_host(func);
+ sdio_claim_irq(func, wl1251_sdio_interrupt);
+ sdio_release_host(func);
+}
+
+static void wl1251_sdio_disable_irq(struct wl1251 *wl)
+{
+ struct sdio_func *func = wl_to_func(wl);
+
+ sdio_claim_host(func);
+ sdio_release_irq(func);
+ sdio_release_host(func);
+}
+
void wl1251_sdio_set_power(bool enable)
{
}
@@ -96,6 +119,8 @@ struct wl1251_if_operations wl1251_sdio_ops = {
.read = wl1251_sdio_read,
.write = wl1251_sdio_write,
.reset = wl1251_sdio_reset,
+ .enable_irq = wl1251_sdio_enable_irq,
+ .disable_irq = wl1251_sdio_disable_irq,
};
int wl1251_sdio_probe(struct sdio_func *func, const struct sdio_device_id *id)
@@ -124,21 +149,14 @@ int wl1251_sdio_probe(struct sdio_func *func, const struct sdio_device_id *id)
sdio_release_host(func);
ret = wl1251_init_ieee80211(wl);
- sdio_claim_host(func);
if (ret)
goto disable;
- ret = sdio_claim_irq(func, wl1251_sdio_interrupt);
- if (ret)
- goto no_irq;
-
- sdio_release_host(func);
sdio_set_drvdata(func, wl);
return ret;
-no_irq:
- wl1251_free_hw(wl);
disable:
+ sdio_claim_host(func);
sdio_disable_func(func);
release:
sdio_release_host(func);
diff --git a/drivers/net/wireless/wl12xx/wl1251_spi.c b/drivers/net/wireless/wl12xx/wl1251_spi.c
index 464b802..fffa970 100644
--- a/drivers/net/wireless/wl12xx/wl1251_spi.c
+++ b/drivers/net/wireless/wl12xx/wl1251_spi.c
@@ -31,6 +31,19 @@
#include "reg.h"
#include "wl1251_spi.h"
+static irqreturn_t wl1251_irq(int irq, void *cookie)
+{
+ struct wl1251 *wl;
+
+ wl1251_debug(DEBUG_IRQ, "IRQ");
+
+ wl = cookie;
+
+ schedule_work(&wl->irq_work);
+
+ return IRQ_HANDLED;
+}
+
static struct spi_device *wl_to_spi(struct wl1251 *wl)
{
return wl->if_priv;
@@ -193,10 +206,22 @@ static void wl1251_spi_write(struct wl1251 *wl, int addr, void *buf,
wl1251_dump(DEBUG_SPI, "spi_write buf -> ", buf, len);
}
+static void wl1251_spi_enable_irq(struct wl1251 *wl)
+{
+ return enable_irq(wl->irq);
+}
+
+static void wl1251_spi_disable_irq(struct wl1251 *wl)
+{
+ return disable_irq(wl->irq);
+}
+
const struct wl1251_if_operations wl1251_spi_ops = {
.read = wl1251_spi_read,
.write = wl1251_spi_write,
.reset = wl1251_spi_reset_wake,
+ .enable_irq = wl1251_spi_enable_irq,
+ .disable_irq = wl1251_spi_disable_irq,
};
static int __devinit wl1251_spi_probe(struct spi_device *spi)
@@ -274,6 +299,7 @@ static int __devexit wl1251_spi_remove(struct spi_device *spi)
{
struct wl1251 *wl = dev_get_drvdata(&spi->dev);
+ free_irq(wl->irq, wl);
wl1251_free_hw(wl);
return 0;
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] wl12xx: make irq handling interface specific
From: Bob Copeland @ 2009-08-05 13:39 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87hbwoniog.fsf@litku.valot.fi>
On Tue, Aug 4, 2009 at 3:26 AM, Kalle Valo<kalle.valo@iki.fi> wrote:
> Thanks, this looks good and I'll take it.
Actually let me send a v2 in a just a minute or two. There's a
prototype mismatch compiler warning to fix.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] nl80211: fix attrtype and value for NL80211_ATTR_SUPPORTED_COMMANDS
From: Zhu Yi @ 2009-08-05 9:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
The patch fixes the misuse between attrtype and value for the
CMD list nested in NL80211_ATTR_SUPPORTED_COMMANDS attribute.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
net/wireless/nl80211.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 0cd5482..086d3fb 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -520,7 +520,7 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
do { \
if (dev->ops->op) { \
i++; \
- NLA_PUT_U32(msg, i, NL80211_CMD_ ## n); \
+ NLA_PUT_U32(msg, NL80211_CMD_ ## n, i); \
} \
} while (0)
@@ -539,19 +539,19 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
CMD(join_ibss, JOIN_IBSS);
if (dev->wiphy.netnsok) {
i++;
- NLA_PUT_U32(msg, i, NL80211_CMD_SET_WIPHY_NETNS);
+ NLA_PUT_U32(msg, NL80211_CMD_SET_WIPHY_NETNS, i);
}
#undef CMD
if (dev->ops->connect || dev->ops->auth) {
i++;
- NLA_PUT_U32(msg, i, NL80211_CMD_CONNECT);
+ NLA_PUT_U32(msg, NL80211_CMD_CONNECT, i);
}
if (dev->ops->disconnect || dev->ops->deauth) {
i++;
- NLA_PUT_U32(msg, i, NL80211_CMD_DISCONNECT);
+ NLA_PUT_U32(msg, NL80211_CMD_DISCONNECT, i);
}
nla_nest_end(msg, nl_cmds);
--
1.6.0.4
^ permalink raw reply related
* [PATCH V2] wireless: display wext SSID when connected by cfg80211
From: Zhu Yi @ 2009-08-05 7:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi, Johannes Berg
cfg80211 displays correct link info when connected by wext. But if
the connection is setup by cfg80211, wext cannot display the SSID.
This patch fixed this issue.
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
V2: use wdev->current_bss instead of wdev->ssid
net/wireless/wext-sme.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index 7bacbd1..e4a054a 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -206,7 +206,15 @@ int cfg80211_mgd_wext_giwessid(struct net_device *dev,
data->flags = 0;
wdev_lock(wdev);
- if (wdev->wext.connect.ssid && wdev->wext.connect.ssid_len) {
+ if (wdev->current_bss) {
+ const u8 *ie = ieee80211_bss_get_ie(&wdev->current_bss->pub,
+ WLAN_EID_SSID);
+ if (ie) {
+ data->flags = 1;
+ data->length = ie[1];
+ memcpy(ssid, ie + 2, data->length);
+ }
+ } else if (wdev->wext.connect.ssid && wdev->wext.connect.ssid_len) {
data->flags = 1;
data->length = wdev->wext.connect.ssid_len;
memcpy(ssid, wdev->wext.connect.ssid, data->length);
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Johannes Berg @ 2009-08-05 5:58 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Maxim Levitsky, Marcel Holtmann, linux-wireless, linville,
Reinette Chatre
In-Reply-To: <69e28c910908042253t67e5aa93j1db74dfe187a9bd1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
On Wed, 2009-08-05 at 07:53 +0200, Gábor Stefanik wrote:
> It just feels illogical to me that the AP essentially has to respond
> to probes twice (it sends an ACK, then a probe response) - but if that
> is what the 802.11 spec calls for, then its fine.
You're just confused then. Think about it again, it's perfectly logical.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Gábor Stefanik @ 2009-08-05 5:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Maxim Levitsky, Marcel Holtmann, linux-wireless, linville,
Reinette Chatre
In-Reply-To: <1249451506.6902.2.camel@johannes.local>
2009/8/5 Johannes Berg <johannes@sipsolutions.net>:
> On Wed, 2009-08-05 at 07:50 +0200, Gábor Stefanik wrote:
>
>> My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?
>
> Of course not. What makes you think so?
>
> johannes
>
>
It just feels illogical to me that the AP essentially has to respond
to probes twice (it sends an ACK, then a probe response) - but if that
is what the 802.11 spec calls for, then its fine.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Johannes Berg @ 2009-08-05 5:51 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Maxim Levitsky, Marcel Holtmann, linux-wireless, linville,
Reinette Chatre
In-Reply-To: <69e28c910908042250n1e0bf9c6v20b6301db9e3286b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
On Wed, 2009-08-05 at 07:50 +0200, Gábor Stefanik wrote:
> My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?
Of course not. What makes you think so?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Gábor Stefanik @ 2009-08-05 5:50 UTC (permalink / raw)
To: Johannes Berg
Cc: Maxim Levitsky, Marcel Holtmann, linux-wireless, linville,
Reinette Chatre
In-Reply-To: <1249450416.4168.22.camel@johannes.local>
On Wed, Aug 5, 2009 at 7:33 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Wed, 2009-08-05 at 08:29 +0300, Maxim Levitsky wrote:
>
>> > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
>> > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
>> > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
>> > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
>> > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
>> > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
>> > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
>> > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
>> >
>> > Should we increase the value to 8 or something? Or just accept that
>> > sometimes we get a disconnect?
>> >
>> I think a disconnect or two aren't a problem, they are always handled
>> automatically, and can be caused by natural events.
>>
>> Even without these patches (I have WPA2, and disconnects were every 4
>> five seconds), and still it was possible to use network.
>>
>> One disconnect in a day is really nothing to worry about (I have seen
>> such here as well)
>>
>> You can increase try count, probably won't hurt much (each try is 0.5
>> seconds, so even 10 tries gives total of 5 seconds, before disconnect on
>> a really unaccessible AP, anyway)
>
> Mind you, each try will end up sending a LOT of probe request frames,
> iwlwifi sends like 12 frames for every try and never gets a response for
> some reason, so I wouldn't really increase it much further since you'd
> be spamming around a lot.
>
> johannes
>
My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH V3] b43: implement baseband init for LP-PHY <= rev1
From: Gábor Stefanik @ 2009-08-05 5:48 UTC (permalink / raw)
To: John Linville, Larry Finger
Cc: Michael Buesch, Broadcom Wireless, linux-wireless
In-Reply-To: <4A78F0DC.4070104@lwfinger.net>
2009/8/5 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor Stefanik wrote:
>> Implement baseband init for rev.0 and rev.1 LP PHYs. Convert
>> boardflags_hi values to defines.
>> Implement b43_phy_copy for easier copying between registers, as needed
>> by LP-PHY init.
>>
>> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
>> Cc: Michael Buesch <mb@bu3sch.de>
>> Cc: Larry Finger <larry.finger@lwfinger.net>
>> ---
>> V3:
>> -Added FIXME to the b43_hf_write call.
>> -The b43_hf_write call now uses a #defined value, rather than a magic
>> number.
>
> It looks to me that V2 was put into wireless-testing. You will need to
> prepare a separate patch to make the V2 => V3 changes.
>
> Larry
OK, I will be sending one today.
Note to John: Please apply the "Fix fallout" patch, but not the
"Cleanups" one. The second part of "Cleanups" will be resubmitted,
combined with other V2->V3 changes.
Larry, my next target is
http://bcm-v4.sipsolutions.net/802.11/PHY/LP/SYNCHSTX - however, what
is the definition of struct lpphy_extstxdata_t? Where does the stx
array get its values (or what are its initial values, if it needs to
be initialized here)?
Also, with Sync-STX, >=rev2 radio init is essentially complete, except
for "with interrupts disabled, do something with backplane (TODO)" -
when can we expect documentation on this step?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] wireless: display wext SSID when connected by cfg80211
From: Zhu Yi @ 2009-08-05 5:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1249450543.6902.1.camel@johannes.local>
On Wed, 2009-08-05 at 13:35 +0800, Johannes Berg wrote:
> On Wed, 2009-08-05 at 13:27 +0800, Zhu Yi wrote:
>
> > Yeah, I'm lazy to parse the current_bss.pub->information_elements for
> > SSID in the first instance. Should we implement some beacon parsing in
> > cfg80211 or move ieee802_11_parse_elems from mac80211?
>
> There's ieee80211_bss_get_ie() in cfg80211, which doesn't give you the
> length/data in two separate values, but otherwise behaves pretty
> similarly. IOW, something like
>
> const u8 *ssid = ieee80211_bss_get_ie(bss /* or &bss->pub */, WLAN_EID_SSID);
> if (ssid) {
> ssid_len = ssid[1];
> ssid_data = ssid + 2;
> }
Ah, I missed that. Will send out a patch.
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH] wireless: display wext SSID when connected by cfg80211
From: Johannes Berg @ 2009-08-05 5:35 UTC (permalink / raw)
To: Zhu Yi; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1249450026.4069.111.camel@debian>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Wed, 2009-08-05 at 13:27 +0800, Zhu Yi wrote:
> Yeah, I'm lazy to parse the current_bss.pub->information_elements for
> SSID in the first instance. Should we implement some beacon parsing in
> cfg80211 or move ieee802_11_parse_elems from mac80211?
There's ieee80211_bss_get_ie() in cfg80211, which doesn't give you the
length/data in two separate values, but otherwise behaves pretty
similarly. IOW, something like
const u8 *ssid = ieee80211_bss_get_ie(bss /* or &bss->pub */, WLAN_EID_SSID);
if (ssid) {
ssid_len = ssid[1];
ssid_data = ssid + 2;
}
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox