iwlwifi connection problems

PATCH In review Alex Romosan 3 participants 26 messages Jul 23, 2010 – Aug 19, 2010 Networking drivers (wireless)

Share & tools

Alex Romosan

author

2010-07-23 20:23 UTC #0 lore raw

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--

Signature · 4 lines

| 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. |

Guy, Wey-Yi

2010-07-23 20:36 UTC #1 lore raw

Hi Johannes,

Quoted 7 lines · Alex Romosan

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

Quoted 1 line

Johannes Berg

maintainer

2010-07-26 09:17 UTC #2 lore raw

Quoted 8 lines · Wey-Yi

Hi Johannes,
Quoted 5 lines · Alex Romosan
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?

Quoted 4 lines

Quoted 2 lines
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

Alex Romosan

author

2010-07-27 04:59 UTC #3 lore raw

Quoted 9 lines · Johannes Berg

Quoted 8 lines · Wey-Yi
Hi Johannes,
Quoted 5 lines · Alex Romosan
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?

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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--

Signature · 4 lines

| 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

maintainer

2010-07-27 06:37 UTC #4 lore raw

Quoted 8 lines · Alex Romosan

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

Alex Romosan

author

2010-08-02 00:18 UTC #5 lore raw

Quoted 11 lines · Johannes Berg

Quoted 8 lines · Alex Romosan
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.

Quoted 2 lines

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--

Signature · 4 lines

| 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

maintainer

2010-08-02 10:58 UTC #6 lore raw

Quoted 8 lines · Alex Romosan

Quoted 2 lines
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.

Quoted 4 lines

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

Alex Romosan

author

2010-08-02 15:42 UTC #7 lore raw

Quoted 5 lines · Johannes Berg

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

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

Since iwl_configure_filter can now sleep since the mac80211 callback was changed, we can now apply filter flags changes directly.

Also, while at it, make the code a bit more
generic with a local macro. There's no need
to check changed_flags since we apply all at
the same time anyway.

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Reinette Chatre <[email protected]>

:040000 040000 40b7db1c9366981ce696f96a9e4a515bfafa6437 824fbd988db160dc0067bced1a8e907edc0fed97 M drivers

then i did a git revert 3474ad635db371b0d8d0ee40086f15d223d5b6a4 there was a conflict i had to edit by hand but the actual diff between 2.6.35 and the version that works is:

drivers/net/wireless/iwlwifi/iwl-core.c +30 ~~-21~~

index 5bbc529..350a4a6 100644
@@ -1301,32 +1301,41 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
 			  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)
+	__le32 *filter_flags = &priv->staging_rxon.filter_flags;
 
 	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);
+	if (changed_flags & (FIF_OTHER_BSS | FIF_PROMISC_IN_BSS)) {
+		if (*total_flags & (FIF_OTHER_BSS | FIF_PROMISC_IN_BSS))
+			*filter_flags |= RXON_FILTER_PROMISC_MSK;
+		else
+			*filter_flags &= ~RXON_FILTER_PROMISC_MSK;
+	}
+	if (changed_flags & FIF_ALLMULTI) {
+		if (*total_flags & FIF_ALLMULTI)
+			*filter_flags |= RXON_FILTER_ACCEPT_GRP_MSK;
+		else
+			*filter_flags &= ~RXON_FILTER_ACCEPT_GRP_MSK;
+	}
+	if (changed_flags & FIF_CONTROL) {
+		if (*total_flags & FIF_CONTROL)
+			*filter_flags |= RXON_FILTER_CTL2HOST_MSK;
+		else
+			*filter_flags &= ~RXON_FILTER_CTL2HOST_MSK;
+	}
+	if (changed_flags & FIF_BCN_PRBRESP_PROMISC) {
+		if (*total_flags & FIF_BCN_PRBRESP_PROMISC)
+			*filter_flags |= RXON_FILTER_BCON_AWARE_MSK;
+		else
+			*filter_flags &= ~RXON_FILTER_BCON_AWARE_MSK;
+	}
 
-	mutex_unlock(&priv->mutex);
+	/* 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.
+	 */
 
 	/*
 	 * Receiving all multicast frames is always enabled by the

and now 2.6.35 with this commit reverted (the above patch applied) connects to my access point.

i am willing to test an official patch against 2.6.35 (i'm just about to leave for work so it might not happen until later today though).

--alex--

Signature · 4 lines

| 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

maintainer

2010-08-02 16:23 UTC #8 lore raw

Quoted 11 lines · Alex Romosan

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

Alex Romosan

author

2010-08-03 03:54 UTC #9 lore raw

Quoted 10 lines · Johannes Berg

Quoted 8 lines · Alex Romosan
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

Quoted 5 lines

Quoted 3 lines
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--

Signature · 4 lines

| 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

maintainer

2010-08-03 06:40 UTC #10 lore raw

Quoted 16 lines · Alex Romosan

Quoted 14 lines · Johannes Berg
Quoted 11 lines · Alex Romosan
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
...

Quoted 7 lines

Quoted 1 line
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

Alex Romosan

author

2010-08-03 12:33 UTC #11 lore raw

Quoted 25 lines · Johannes Berg

Quoted 16 lines · Alex Romosan
Quoted 14 lines · Johannes Berg
Quoted 11 lines · Alex Romosan
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
...
Quoted 7 lines
Quoted 1 line
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.

Quoted 3 lines

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--

Signature · 4 lines

| 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. |

Alex Romosan

author

2010-08-03 12:43 UTC #12 lore raw

In reply to Johannes Berg

Quoted 3 lines · Johannes Berg

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--

Signature · 4 lines

| 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

maintainer

2010-08-04 07:51 UTC #13 lore raw

Quoted 6 lines · Alex Romosan

Quoted 3 lines · Johannes Berg
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?

Quoted 7 lines

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

Alex Romosan

author

2010-08-04 14:51 UTC #14 lore raw

Quoted 7 lines · Johannes Berg

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--

Signature · 4 lines

| 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

maintainer

2010-08-04 15:03 UTC #15 lore raw

Quoted 10 lines · Alex Romosan

Quoted 7 lines · Johannes Berg
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.

Quoted 7 lines

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

Alex Romosan

author

2010-08-04 15:08 UTC #16 lore raw

Quoted 15 lines · Johannes Berg

Quoted 14 lines · Alex Romosan
Quoted 7 lines · Johannes Berg
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/

Quoted 7 lines

Quoted 3 lines
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--

Signature · 4 lines

| 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

maintainer

2010-08-04 15:11 UTC #17 lore raw

Quoted 6 lines · Alex Romosan

Quoted 3 lines
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

Alex Romosan

author

2010-08-04 15:12 UTC #18 lore raw

Quoted 10 lines · Johannes Berg

Quoted 6 lines · Alex Romosan
Quoted 3 lines
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--

Signature · 4 lines

| 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

maintainer

2010-08-04 15:23 UTC #19 lore raw

Quoted 8 lines · Alex Romosan

Quoted 6 lines · Johannes Berg
Quoted 4 lines · Alex Romosan
Quoted 3 lines
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?

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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

Johannes Berg

maintainer

2010-08-16 13:17 UTC #20 lore raw

In reply to Alex Romosan

Quoted 8 lines · Alex Romosan

Quoted 6 lines · Johannes Berg
Quoted 4 lines · Alex Romosan
Quoted 3 lines
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?

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
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

Alex Romosan

author

2010-08-16 13:44 UTC #21 lore raw

Quoted 4 lines · Johannes Berg

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.

Quoted 1 line

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--

Signature · 4 lines

| 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. |

Alex Romosan

author

2010-08-16 16:41 UTC #22 lore raw

In reply to Johannes Berg

Quoted 1 line · Johannes Berg

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--

Signature · 4 lines

| 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

maintainer

2010-08-16 19:06 UTC #23 lore raw

Quoted 8 lines · Alex Romosan

Quoted 1 line · Johannes Berg
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

maintainer

2010-08-17 09:24 UTC #24 lore raw

PATCH 1/1 iwlwifi: fix 3945 filter flags

In reply to Alex Romosan

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(-)

drivers/net/wireless/iwlwifi/iwl-agn.c +44 -1

@@ -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,

drivers/net/wireless/iwlwifi/iwl-core.c +0 ~~-45~~

51 lines not on this page · raw message

drivers/net/wireless/iwlwifi/iwl-core.h +0 -3

@@ -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,

drivers/net/wireless/iwlwifi/iwl3945-base.c +50 -1

63 lines not on this page · raw message

Alex Romosan

author

2010-08-19 16:01 UTC #25 lore raw

Re: [PATCH] iwlwifi: fix 3945 filter flags

Quoted 10 lines · Johannes Berg

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

Quoted 7 lines

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--

Signature · 4 lines

| 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. |