since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
connect to a hidden wireless access point using the iwlwifi driver. i
can connect to open ones though (the ones that broadcast their name).
2.6.34 worked without any problems. any ideas?
this is with the driver in the standard linux kernel (2.6.35-rc6 is the
latest one i tried).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> On Fri, 2010-07-23 at 13:38 -0700, Guy, Wey-Yi wrote:
>> Hi Johannes,
>>
>> On Fri, 2010-07-23 at 13:14 -0700, Alex Romosan wrote:
>> > since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
>> > connect to a hidden wireless access point using the iwlwifi driver. i
>> > can connect to open ones though (the ones that broadcast their name).
>> > 2.6.34 worked without any problems. any ideas?
>> >
>> > this is with the driver in the standard linux kernel (2.6.35-rc6 is the
>> > latest one i tried).
>>
>> Do you aware any changes?
>
> Nope, and it works fine here on wireless-testing.
any ideas on how i can debug this? i tried to do a git-bisect but i
didn't get anywhere. i have the driver compiled in the kernel if that
makes any difference. as i played with the later kernels (after 2.6.34)
i discovered that if kept bringing the interface down and then up again
eventually i would get "cfg80211: Calling CRDA to update world
regulatory domain" the antenna light on the laptop (i have a thinkpad
t61) would go off and then at the next ifup the driver connected. looks
like some kind of reset/initialization problem to me.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Mon, 2010-07-26 at 21:59 -0700, Alex Romosan wrote:
> any ideas on how i can debug this? i tried to do a git-bisect but i
> didn't get anywhere. i have the driver compiled in the kernel if that
> makes any difference. as i played with the later kernels (after 2.6.34)
> i discovered that if kept bringing the interface down and then up again
> eventually i would get "cfg80211: Calling CRDA to update world
> regulatory domain" the antenna light on the laptop (i have a thinkpad
> t61) would go off and then at the next ifup the driver connected. looks
> like some kind of reset/initialization problem to me.
So is the issue maybe the channel the AP is no, not the fact that it's
hidden? or something like that?
johannes
Hi Johannes,
On Fri, 2010-07-23 at 13:14 -0700, Alex Romosan wrote:
> since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
> connect to a hidden wireless access point using the iwlwifi driver. i
> can connect to open ones though (the ones that broadcast their name).
> 2.6.34 worked without any problems. any ideas?
>
> this is with the driver in the standard linux kernel (2.6.35-rc6 is the
> latest one i tried).
Do you aware any changes?
Thanks
Wey
>
On Fri, 2010-07-23 at 13:38 -0700, Guy, Wey-Yi wrote:
> Hi Johannes,
>
> On Fri, 2010-07-23 at 13:14 -0700, Alex Romosan wrote:
> > since kernel 2.6.35-rc3 (i didn't try 1 or 2) i haven't been able to
> > connect to a hidden wireless access point using the iwlwifi driver. i
> > can connect to open ones though (the ones that broadcast their name).
> > 2.6.34 worked without any problems. any ideas?
> >
> > this is with the driver in the standard linux kernel (2.6.35-rc6 is the
> > latest one i tried).
>
> Do you aware any changes?
Nope, and it works fine here on wireless-testing.
johannes
Johannes Berg <[email protected]> writes:
> Yes, thank you, but it's very strange. But it's probably ok, let's
> remove the call then, it wasn't there before. Want to post a patch
> yourself?
btw, the old code had this comment
/* We avoid iwl_commit_rxon here to commit the new filter flags
* since mac80211 will call ieee80211_hw_config immediately.
* (mc_list is not supported at this time). Otherwise, we need to
* queue a background iwl_commit_rxon work.
*/
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
>
>> > Thanks. The down/up is fine, I'll be able to identify that in the
>> > traces. Except the "working" trace looks like it only starts after you
>> > connected already?
>>
>> the driver connects automatically on boot, so, yes, it was after i was
>> connected. i can bring down the interface and try again if you want.
>
> Yes, please do that.
http://caliban.lbl.gov/iwlwifi/trace.dat-working.before.ifup.gz
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Tue, 2010-08-03 at 05:43 -0700, Alex Romosan wrote:
> Johannes Berg <[email protected]> writes:
>
> > Yes, thank you, but it's very strange. But it's probably ok, let's
> > remove the call then, it wasn't there before. Want to post a patch
> > yourself?
>
> btw, the old code had this comment
>
> /* We avoid iwl_commit_rxon here to commit the new filter flags
> * since mac80211 will call ieee80211_hw_config immediately.
> * (mc_list is not supported at this time). Otherwise, we need to
> * queue a background iwl_commit_rxon work.
> */
Yes, but that predates this callback being able to sleep, which
according to the comment is the reason for not committing here. Now that
the callback could sleep, I figured we could safely commit there, I have
no idea why that caused issues with your AP.
I realised though that mac80211 will sometimes call the filter config
w/o calling hw_config() immediately, so I'd prefer actually figuring out
what the issue with your AP is. Could you rebuild your kernel with
CONFIG_MAC80211_DRIVER_API_TRACER and CONFIG_IWLWIFI_DEVICE_TRACING, get
trace-cmd from
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git and
record traces for me? I'd like to have
trace-cmd record -e iwlwifi -e mac80211
for both the working and non-working case, preferably the same kernel
with that single line of code changed. Please compress the output.
johannes
On Wed, 2010-08-04 at 08:12 -0700, Alex Romosan wrote:
> Johannes Berg <[email protected]> writes:
>
> > On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
> >
> >> > Thanks. The down/up is fine, I'll be able to identify that in the
> >> > traces. Except the "working" trace looks like it only starts after you
> >> > connected already?
> >>
> >> the driver connects automatically on boot, so, yes, it was after i was
> >> connected. i can bring down the interface and try again if you want.
> >
> > Yes, please do that.
>
> http://caliban.lbl.gov/iwlwifi/trace.dat-working.before.ifup.gz
Thank you. I need to adjust my analysis tools because you're using 3945,
not sure if I can finish that today.
johannes
On Mon, 2010-08-02 at 08:42 -0700, Alex Romosan wrote:
> so i think i finally managed to track this down. doing a git bisect i
> get:
>
> 3474ad635db371b0d8d0ee40086f15d223d5b6a4 is the first bad commit
> commit 3474ad635db371b0d8d0ee40086f15d223d5b6a4
> Author: Johannes Berg <[email protected]>
> Date: Thu Apr 29 04:43:05 2010 -0700
>
> iwlwifi: apply filter flags directly
> ...
Thanks. I'll take a closer look tomorrow, am about to leave for today.
johannes
On Wed, 2010-08-04 at 07:51 -0700, Alex Romosan wrote:
> Johannes Berg <[email protected]> writes:
>
> > Could you rebuild your kernel with CONFIG_MAC80211_DRIVER_API_TRACER
> > and CONFIG_IWLWIFI_DEVICE_TRACING, get trace-cmd from
> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
> > and record traces for me? I'd like to have
> > trace-cmd record -e iwlwifi -e mac80211
> > for both the working and non-working case, preferably the same kernel
> > with that single line of code changed. Please compress the output.
>
> you can get both traces from
>
> http://caliban.lbl.gov/iwlwifi/
>
> for the not-working case i also tried to bring down the interface and
> then bring it up again while recording the trace (don't know if it
> matters).
Thanks. The down/up is fine, I'll be able to identify that in the
traces. Except the "working" trace looks like it only starts after you
connected already?
johannes
On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
> > Thanks. The down/up is fine, I'll be able to identify that in the
> > traces. Except the "working" trace looks like it only starts after you
> > connected already?
>
> the driver connects automatically on boot, so, yes, it was after i was
> connected. i can bring down the interface and try again if you want.
Yes, please do that.
johannes
Johannes Berg <[email protected]> writes:
> On Mon, 2010-08-02 at 20:53 -0700, Alex Romosan wrote:
>> Johannes Berg <[email protected]> writes:
>>
>> > On Mon, 2010-08-02 at 08:42 -0700, Alex Romosan wrote:
>> >
>> >> so i think i finally managed to track this down. doing a git bisect i
>> >> get:
>> >>
>> >> 3474ad635db371b0d8d0ee40086f15d223d5b6a4 is the first bad commit
>> >> commit 3474ad635db371b0d8d0ee40086f15d223d5b6a4
>> >> Author: Johannes Berg <[email protected]>
>> >> Date: Thu Apr 29 04:43:05 2010 -0700
>> >>
>> >> iwlwifi: apply filter flags directly
>> >
>> >> ...
>> >
>> > Thanks. I'll take a closer look tomorrow, am about to leave for today.
>>
>> so i looked a little bit more at what happened. the only difference
>> between the non working and the working version is a call to
>> iwlcore_commit_rxon(priv) on line 1327 of iwl-core.c (the version in
>> 2.6.35). if i comment that line out then i can connect to the access
>> point without problems. hope this helps.
>
> Yes, thank you, but it's very strange. But it's probably ok, let's
> remove the call then, it wasn't there before. Want to post a patch
> yourself?
that's ok, i don't really know what's going on, i only noticed the
difference between the two versions. you post the patch.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> On Wed, 2010-08-04 at 07:51 -0700, Alex Romosan wrote:
>> Johannes Berg <[email protected]> writes:
>>
>> > Could you rebuild your kernel with CONFIG_MAC80211_DRIVER_API_TRACER
>> > and CONFIG_IWLWIFI_DEVICE_TRACING, get trace-cmd from
>> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
>> > and record traces for me? I'd like to have
>> > trace-cmd record -e iwlwifi -e mac80211
>> > for both the working and non-working case, preferably the same kernel
>> > with that single line of code changed. Please compress the output.
>>
>> you can get both traces from
>>
>> http://caliban.lbl.gov/iwlwifi/
>>
>> for the not-working case i also tried to bring down the interface and
>> then bring it up again while recording the trace (don't know if it
>> matters).
>
> Thanks. The down/up is fine, I'll be able to identify that in the
> traces. Except the "working" trace looks like it only starts after you
> connected already?
the driver connects automatically on boot, so, yes, it was after i was
connected. i can bring down the interface and try again if you want.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> On Mon, 2010-07-26 at 21:59 -0700, Alex Romosan wrote:
>
>> any ideas on how i can debug this? i tried to do a git-bisect but i
>> didn't get anywhere. i have the driver compiled in the kernel if that
>> makes any difference. as i played with the later kernels (after 2.6.34)
>> i discovered that if kept bringing the interface down and then up again
>> eventually i would get "cfg80211: Calling CRDA to update world
>> regulatory domain" the antenna light on the laptop (i have a thinkpad
>> t61) would go off and then at the next ifup the driver connected. looks
>> like some kind of reset/initialization problem to me.
>
> So is the issue maybe the channel the AP is no, not the fact that it's
> hidden? or something like that?
it's still not working even with kernel 2.6.35 so i decided to play with
it a little bit more. indeed, it has nothing to do with the access
point being hidden or not. it doesn't work even when it's visible
(previously i was able to connect to the wireless at work which is
visible so i wrongly assumed that was the cause).
so it looks like the problem is connecting to this particular access
point which is a proxim ap-200 orinoco wireless ap i got in 2003. right
now the ap is setup on channel 3 and the rate is set to 11 Mbps. should
i try a different channel? which one?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> Alex, thanks. I apologise for the delay. I should've asked you much
> earlier to do this -- could you open a bug report on
> bugzilla.intellinuxwireless.org and attach all the information you
> gathered?
okay, i'll do that.
> Also, have you tried the released 2.6.35.2?
i haven't, tried 2.6.36-rc1 last night but got a series of oopses while
booting so i didn't get a chance to test it. i'll give 2.6.35.2 a try at
some point soon. thanks for all the help.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> Could you rebuild your kernel with CONFIG_MAC80211_DRIVER_API_TRACER
> and CONFIG_IWLWIFI_DEVICE_TRACING, get trace-cmd from
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
> and record traces for me? I'd like to have
> trace-cmd record -e iwlwifi -e mac80211
> for both the working and non-working case, preferably the same kernel
> with that single line of code changed. Please compress the output.
you can get both traces from
http://caliban.lbl.gov/iwlwifi/
for the not-working case i also tried to bring down the interface and
then bring it up again while recording the trace (don't know if it
matters).
the kernels are the same except with line 1327 of iwl-core.c commented
out for the working case. hope this helps.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> From: Johannes Berg <[email protected]>
>
> Applying the filter flags directly as done since
>
> commit 3474ad635db371b0d8d0ee40086f15d223d5b6a4
> Author: Johannes Berg <[email protected]>
> Date: Thu Apr 29 04:43:05 2010 -0700
>
> iwlwifi: apply filter flags directly
>
> broke 3945 under some unknown circumstances, as
> reported by Alex.
>
> Since I want to keep the direct application of
> filter flags on iwlagn, duplicate the code into
> both 3945 and agn and remove committing the
> RXON that broke things from the 3945 version.
just to confirm that it works for me. hopefully this will also be
included in the 2.6.36 series. thanks.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Johannes Berg <[email protected]> writes:
> Also, have you tried the released 2.6.35.2?
just tried it with 2.6.36-rc1 (after applying a reiserfs patch) and i
still need to comment out the call to iwlcore_commit_rxon(priv); on line
1361 of iwl-core.c. i'll file the bug, but if nobody steps forward,
wouldn't it make sense just to remove that call? thanks.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Wed, 2010-08-04 at 08:12 -0700, Alex Romosan wrote:
> Johannes Berg <[email protected]> writes:
>
> > On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
> >
> >> > Thanks. The down/up is fine, I'll be able to identify that in the
> >> > traces. Except the "working" trace looks like it only starts after you
> >> > connected already?
> >>
> >> the driver connects automatically on boot, so, yes, it was after i was
> >> connected. i can bring down the interface and try again if you want.
> >
> > Yes, please do that.
>
> http://caliban.lbl.gov/iwlwifi/trace.dat-working.before.ifup.gz
Alex, thanks. I apologise for the delay. I should've asked you much
earlier to do this -- could you open a bug report on
bugzilla.intellinuxwireless.org and attach all the information you
gathered? That way, hopefully we can find somebody more familiar with
3945 to help you with this. I only joined the team long after it, so I'm
not familiar with the device at all. When you do this, feel free to
paste this link to the thread:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/53539
Also, have you tried the released 2.6.35.2?
johannes
On Mon, 2010-08-16 at 09:40 -0700, Alex Romosan wrote:
> Johannes Berg <[email protected]> writes:
>
> > Also, have you tried the released 2.6.35.2?
>
> just tried it with 2.6.36-rc1 (after applying a reiserfs patch) and i
> still need to comment out the call to iwlcore_commit_rxon(priv); on line
> 1361 of iwl-core.c. i'll file the bug, but if nobody steps forward,
> wouldn't it make sense just to remove that call? thanks.
You're right, I got completely confused and mixed up different bug
reports. I'd prefer to have the call there for AGN hardware, but I'll
make a patch to split it up properly. Sorry about that.
johannes
Johannes Berg <[email protected]> writes:
> On Mon, 2010-08-02 at 08:42 -0700, Alex Romosan wrote:
>
>> so i think i finally managed to track this down. doing a git bisect i
>> get:
>>
>> 3474ad635db371b0d8d0ee40086f15d223d5b6a4 is the first bad commit
>> commit 3474ad635db371b0d8d0ee40086f15d223d5b6a4
>> Author: Johannes Berg <[email protected]>
>> Date: Thu Apr 29 04:43:05 2010 -0700
>>
>> iwlwifi: apply filter flags directly
>
>> ...
>
> Thanks. I'll take a closer look tomorrow, am about to leave for today.
so i looked a little bit more at what happened. the only difference
between the non working and the working version is a call to
iwlcore_commit_rxon(priv) on line 1327 of iwl-core.c (the version in
2.6.35). if i comment that line out then i can connect to the access
point without problems. hope this helps.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
From: Johannes Berg <[email protected]>
Applying the filter flags directly as done since
commit 3474ad635db371b0d8d0ee40086f15d223d5b6a4
Author: Johannes Berg <[email protected]>
Date: Thu Apr 29 04:43:05 2010 -0700
iwlwifi: apply filter flags directly
broke 3945 under some unknown circumstances, as
reported by Alex.
Since I want to keep the direct application of
filter flags on iwlagn, duplicate the code into
both 3945 and agn and remove committing the
RXON that broke things from the 3945 version.
Cc: [email protected] [2.6.35]
Reported-by: Alex Romosan <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 45 ++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-core.c | 45 ------------------------
drivers/net/wireless/iwlwifi/iwl-core.h | 3 -
drivers/net/wireless/iwlwifi/iwl3945-base.c | 51 +++++++++++++++++++++++++++-
4 files changed, 94 insertions(+), 50 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-agn.c 2010-08-17 11:08:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-agn.c 2010-08-17 11:10:50.000000000 +0200
@@ -3669,6 +3669,49 @@ out_exit:
IWL_DEBUG_MAC80211(priv, "leave\n");
}
+static void iwlagn_configure_filter(struct ieee80211_hw *hw,
+ unsigned int changed_flags,
+ unsigned int *total_flags,
+ u64 multicast)
+{
+ struct iwl_priv *priv = hw->priv;
+ __le32 filter_or = 0, filter_nand = 0;
+
+#define CHK(test, flag) do { \
+ if (*total_flags & (test)) \
+ filter_or |= (flag); \
+ else \
+ filter_nand |= (flag); \
+ } while (0)
+
+ IWL_DEBUG_MAC80211(priv, "Enter: changed: 0x%x, total: 0x%x\n",
+ changed_flags, *total_flags);
+
+ CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
+ CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
+ CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
+
+#undef CHK
+
+ mutex_lock(&priv->mutex);
+
+ priv->staging_rxon.filter_flags &= ~filter_nand;
+ priv->staging_rxon.filter_flags |= filter_or;
+
+ iwlcore_commit_rxon(priv);
+
+ mutex_unlock(&priv->mutex);
+
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
+ *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
+ FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
+}
+
static void iwl_mac_flush(struct ieee80211_hw *hw, bool drop)
{
struct iwl_priv *priv = hw->priv;
@@ -3869,7 +3912,7 @@ static struct ieee80211_ops iwl_hw_ops =
.add_interface = iwl_mac_add_interface,
.remove_interface = iwl_mac_remove_interface,
.config = iwl_mac_config,
- .configure_filter = iwl_configure_filter,
+ .configure_filter = iwlagn_configure_filter,
.set_key = iwl_mac_set_key,
.update_tkip_key = iwl_mac_update_tkip_key,
.conf_tx = iwl_mac_conf_tx,
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.c 2010-08-17 11:08:18.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.c 2010-08-17 11:10:49.000000000 +0200
@@ -1328,51 +1328,6 @@ out:
EXPORT_SYMBOL(iwl_apm_init);
-
-void iwl_configure_filter(struct ieee80211_hw *hw,
- unsigned int changed_flags,
- unsigned int *total_flags,
- u64 multicast)
-{
- struct iwl_priv *priv = hw->priv;
- __le32 filter_or = 0, filter_nand = 0;
-
-#define CHK(test, flag) do { \
- if (*total_flags & (test)) \
- filter_or |= (flag); \
- else \
- filter_nand |= (flag); \
- } while (0)
-
- IWL_DEBUG_MAC80211(priv, "Enter: changed: 0x%x, total: 0x%x\n",
- changed_flags, *total_flags);
-
- CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
- CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
- CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
-
-#undef CHK
-
- mutex_lock(&priv->mutex);
-
- priv->staging_rxon.filter_flags &= ~filter_nand;
- priv->staging_rxon.filter_flags |= filter_or;
-
- iwlcore_commit_rxon(priv);
-
- mutex_unlock(&priv->mutex);
-
- /*
- * Receiving all multicast frames is always enabled by the
- * default flags setup in iwl_connection_init_rx_config()
- * since we currently do not support programming multicast
- * filters into the device.
- */
- *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
- FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
-}
-EXPORT_SYMBOL(iwl_configure_filter);
-
int iwl_set_hw_params(struct iwl_priv *priv)
{
priv->hw_params.max_rxq_size = RX_QUEUE_SIZE;
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.h 2010-08-17 11:08:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.h 2010-08-17 11:08:57.000000000 +0200
@@ -372,9 +372,6 @@ int iwl_set_decrypted_flag(struct iwl_pr
u32 decrypt_res,
struct ieee80211_rx_status *stats);
void iwl_irq_handle_error(struct iwl_priv *priv);
-void iwl_configure_filter(struct ieee80211_hw *hw,
- unsigned int changed_flags,
- unsigned int *total_flags, u64 multicast);
int iwl_set_hw_params(struct iwl_priv *priv);
void iwl_post_associate(struct iwl_priv *priv, struct ieee80211_vif *vif);
void iwl_bss_info_changed(struct ieee80211_hw *hw,
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl3945-base.c 2010-08-17 11:08:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl3945-base.c 2010-08-17 11:11:30.000000000 +0200
@@ -3396,6 +3396,55 @@ static int iwl3945_mac_sta_add(struct ie
return 0;
}
+
+static void iwl3945_configure_filter(struct ieee80211_hw *hw,
+ unsigned int changed_flags,
+ unsigned int *total_flags,
+ u64 multicast)
+{
+ struct iwl_priv *priv = hw->priv;
+ __le32 filter_or = 0, filter_nand = 0;
+
+#define CHK(test, flag) do { \
+ if (*total_flags & (test)) \
+ filter_or |= (flag); \
+ else \
+ filter_nand |= (flag); \
+ } while (0)
+
+ IWL_DEBUG_MAC80211(priv, "Enter: changed: 0x%x, total: 0x%x\n",
+ changed_flags, *total_flags);
+
+ CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
+ CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
+ CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
+
+#undef CHK
+
+ mutex_lock(&priv->mutex);
+
+ priv->staging_rxon.filter_flags &= ~filter_nand;
+ priv->staging_rxon.filter_flags |= filter_or;
+
+ /*
+ * Committing directly here breaks for some reason,
+ * but we'll eventually commit the filter flags
+ * change anyway.
+ */
+
+ mutex_unlock(&priv->mutex);
+
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
+ *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
+ FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
+}
+
+
/*****************************************************************************
*
* sysfs attributes
@@ -3801,7 +3850,7 @@ static struct ieee80211_ops iwl3945_hw_o
.add_interface = iwl_mac_add_interface,
.remove_interface = iwl_mac_remove_interface,
.config = iwl_mac_config,
- .configure_filter = iwl_configure_filter,
+ .configure_filter = iwl3945_configure_filter,
.set_key = iwl3945_mac_set_key,
.conf_tx = iwl_mac_conf_tx,
.reset_tsf = iwl_mac_reset_tsf,
On Mon, 2010-08-02 at 20:53 -0700, Alex Romosan wrote:
> Johannes Berg <[email protected]> writes:
>
> > On Mon, 2010-08-02 at 08:42 -0700, Alex Romosan wrote:
> >
> >> so i think i finally managed to track this down. doing a git bisect i
> >> get:
> >>
> >> 3474ad635db371b0d8d0ee40086f15d223d5b6a4 is the first bad commit
> >> commit 3474ad635db371b0d8d0ee40086f15d223d5b6a4
> >> Author: Johannes Berg <[email protected]>
> >> Date: Thu Apr 29 04:43:05 2010 -0700
> >>
> >> iwlwifi: apply filter flags directly
> >
> >> ...
> >
> > Thanks. I'll take a closer look tomorrow, am about to leave for today.
>
> so i looked a little bit more at what happened. the only difference
> between the non working and the working version is a call to
> iwlcore_commit_rxon(priv) on line 1327 of iwl-core.c (the version in
> 2.6.35). if i comment that line out then i can connect to the access
> point without problems. hope this helps.
Yes, thank you, but it's very strange. But it's probably ok, let's
remove the call then, it wasn't there before. Want to post a patch
yourself?
johannes
On Sun, 2010-08-01 at 17:18 -0700, Alex Romosan wrote:
> > So is the issue maybe the channel the AP is no, not the fact that it's
> > hidden? or something like that?
>
> it's still not working even with kernel 2.6.35 so i decided to play with
> it a little bit more. indeed, it has nothing to do with the access
> point being hidden or not. it doesn't work even when it's visible
> (previously i was able to connect to the wireless at work which is
> visible so i wrongly assumed that was the cause).
Ok, thanks for checking, that's good to know.
> so it looks like the problem is connecting to this particular access
> point which is a proxim ap-200 orinoco wireless ap i got in 2003. right
> now the ap is setup on channel 3 and the rate is set to 11 Mbps. should
> i try a different channel? which one?
Channel 3 should be fine, we just had reports about channel 13 failing.
2.6.35 includes the QoS fix, so I'm not sure what the issue could be
here.
Typically such ancient APs have issues with the supported rates bitmap,
could you maybe try to revert 76f273640134f3eb8257179cd5b3bc6ba5fe4a96?
This is the only relevant commit I can find between .34 and .35.
However, if that doesn't help this seems like an ideal candidate for
bisection, would you be willing to try that? I'd restrict to wireless
code, i.e.
git bisect start -- net/wireless net/mac80211 drivers/net/wireless/iwlwifi
johannes