iwlwifi: Make injection of non-broadcast frames work again

PATCH Superseded Gábor Stefanik 4 participants 11 messages Aug 20, 2009 – Aug 21, 2009 Networking drivers (wireless)

Share & tools

Gábor Stefanik

author

2009-08-20 22:08 UTC #0 lore raw

PATCH 1/1 iwlwifi: Make injection of non-broadcast frames work again

Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode") broke injection of non-broadcast frames to unassociated stations (causing a SYSASSERT for all such injected frames), due to injected frames no longer automatically getting a broadcast station ID assigned, and instead ending up with invalid station IDs.
This patch restores the old behavior, fixing the aforementioned regression.

Signed-off-by Gábor Stefanik <[email protected]>

---
This fixes a regression introduced between 2.6.30 and 2.6.31-rc1. Please apply to 2.6.31.

drivers/net/wireless/iwlwifi/iwl-sta.c | 3 ++-

1 files changed, 2 insertions(+), 1 deletions(-)

drivers/net/wireless/iwlwifi/iwl-sta.c +0 -0

index c6633fe..81a656f 100644
@@ -1054,7 +1054,8 @@ int iwl_get_sta_id(struct iwl_priv *priv, struct ieee80211_hdr *hdr)

	__le16 fc = hdr->frame_control;

	/* If this frame is broadcast or management, use broadcast station id */
-	if (!ieee80211_is_data(fc) ||  is_multicast_ether_addr(hdr->addr1))
+	if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
+	    iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
		return priv->hw_params.bcast_sta_id;

	switch (priv->iw_mode) {

Signature · 1 line

1.6.2.4

Johannes Berg

maintainer

2009-08-21 08:21 UTC #1 lore raw

Review

Quoted 5 lines · Gábor Stefanik

(quoted diff) +2 -1

 	/* If this frame is broadcast or management, use broadcast station id */
-	if (!ieee80211_is_data(fc) ||  is_multicast_ether_addr(hdr->addr1))
+	if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
+	    iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
 		return priv->hw_params.bcast_sta_id;

Now you still can't transmit frames to another AP when connected to one, which will, for example, be required for 11r. IMHO that code should, in STATION mode, be checking the RA against the BSSID, and if they match use the AP ID, otherwise the bcast ID. And remove the warning in the default case, since that's what happens if in pure monitor mode afaict.

johannes

Gábor Stefanik

author

2009-08-21 13:22 UTC #2 lore raw

2009/8/21 Johannes Berg <[email protected]>:

Quoted 8 lines · Gábor Stefanik

Quoted 6 lines
/* If this frame is broadcast or management, use broadcast station id */
-     if (!ieee80211_is_data(fc) ||  is_multicast_ether_addr(hdr->addr1))
+     if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
+ iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */ return priv->hw_params.bcast_sta_id;

Quoted 4 lines

Now you still can't transmit frames to another AP when connected to one, which will, for example, be required for 11r. IMHO that code should, in STATION mode, be checking the RA against the BSSID, and if they match use the AP ID, otherwise the bcast ID.

I'll probably do that, in a separate patch. This patch is a regression fix targeted at the next 2.6.31-rc (injection of non-broadcasts works fine in 2.6.30, but causes an ucode SYSASSERT in 2.6.31 and up). The problem you are describing is not a regression AFAIK, it's something that never worked; so it should be targeted @ 2.6.32.

Quoted 4 lines

And remove the warning in the
default case, since that's what happens if in pure monitor mode afaict.
From my limited testing, in monitor mode, the vif type will be

IFTYPE_STATION, so the default case is never hit. (Is this a bug?)

(BTW now that in mac80211, we internally use IFTYPE_MONITOR in monitor mode, as opposed to just checking for a missing STA - why can't we propagate this to the drivers, and have a much saner way of informing the driver of monitor mode? This is especially a problem for zd1211rw, where to get proper monitor mode, ZD_SNIFFER_ON needs to be turned on.)

Quoted 3 lines

johannes

Signature · 1 line

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Johannes Berg

maintainer

2009-08-21 13:28 UTC #3 lore raw

Quoted 5 lines · Gábor Stefanik

Quoted 2 lines
And remove the warning in the
default case, since that's what happens if in pure monitor mode afaict.
From my limited testing, in monitor mode, the vif type will be IFTYPE_STATION, so the default case is never hit. (Is this a bug?)

It's the way iwlwifi handles things I guess.

Quoted 6 lines

(BTW now that in mac80211, we internally use IFTYPE_MONITOR in monitor mode, as opposed to just checking for a missing STA - why can't we propagate this to the drivers, and have a much saner way of informing the driver of monitor mode? This is especially a problem for zd1211rw, where to get proper monitor mode, ZD_SNIFFER_ON needs to be turned on.)

Think about it again (hint: multiple interfaces), and then ask the question again.

johannes

reinette chatre

2009-08-21 16:33 UTC #4 lore raw

In reply to Gábor Stefanik

Hi Gábor,

Quoted 8 lines · Gábor Stefanik

Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode") broke injection of non-broadcast frames to unassociated stations (causing a SYSASSERT for all such injected frames), due to injected frames no longer automatically getting a broadcast station ID assigned, and instead ending up with invalid station IDs.
This patch restores the old behavior, fixing the aforementioned regression.

The patch you are quoting cannot be the culprit here. As that commit message indicates we never set NL80211_IFTYPE_MONITOR for the interface type, so when that code removed the test for this interface type in iwl_get_sta_id it essentially removed dead code.

Review

Quoted 5 lines

(quoted diff) +2 -1

 	/* If this frame is broadcast or management, use broadcast station id */
-	if (!ieee80211_is_data(fc) ||  is_multicast_ether_addr(hdr->addr1))
+	if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
+	    iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
 		return priv->hw_params.bcast_sta_id;

I think my comment ties in with what Johannes said. When we are associated (whether in station, adhoc, or AP mode) we want this function to return the correct station ID. We also know that an interface can be in monitor mode while it is in any of these other modes. When this happens we do not want to return the broadcast station id ... we still want to return the station id. Your patch changes this behavior and will in this case always return the broadcast station id.

Reinette

John W. Linville

2009-08-21 16:45 UTC #5 lore raw

Quoted 17 lines · reinette chatre

Hi Gábor,
Quoted 8 lines · Gábor Stefanik
Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode") broke injection of non-broadcast frames to unassociated stations (causing a SYSASSERT for all such injected frames), due to injected frames no longer automatically getting a broadcast station ID assigned, and instead ending up with invalid station IDs.
This patch restores the old behavior, fixing the aforementioned regression.
The patch you are quoting cannot be the culprit here. As that commit message indicates we never set NL80211_IFTYPE_MONITOR for the interface type, so when that code removed the test for this interface type in iwl_get_sta_id it essentially removed dead code.

Quoted 13 lines

Review
Quoted 5 lines
(quoted diff) +2 -1
 	/* If this frame is broadcast or management, use broadcast station id */
-	if (!ieee80211_is_data(fc) ||  is_multicast_ether_addr(hdr->addr1))
+	if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
+	    iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
 		return priv->hw_params.bcast_sta_id;
I think my comment ties in with what Johannes said. When we are associated (whether in station, adhoc, or AP mode) we want this function to return the correct station ID. We also know that an interface can be in monitor mode while it is in any of these other modes. When this happens we do not want to return the broadcast station id ... we still want to return the station id. Your patch changes this behavior and will in this case always return the broadcast station id.

Dropping on the basis of this. Please repost when/if this is resolved.

John

Signature · 2 lines

John W. Linville		Someday the world will need a hero, and you
[email protected]			might be all we have.  Be ready.

Gábor Stefanik

author

2009-08-21 17:24 UTC #6 lore raw

In reply to reinette chatre

2009/8/21 reinette chatre <[email protected]>:

Quoted 12 lines

Hi Gábor,
Quoted 8 lines · Gábor Stefanik
Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy ("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode") broke injection of non-broadcast frames to unassociated stations (causing a SYSASSERT for all such injected frames), due to injected frames no longer automatically getting a broadcast station ID assigned, and instead ending up with invalid station IDs.
This patch restores the old behavior, fixing the aforementioned regression.

Quoted 4 lines

The patch you are quoting cannot be the culprit here. As that commit message indicates we never set NL80211_IFTYPE_MONITOR for the interface type, so when that code removed the test for this interface type in iwl_get_sta_id it essentially removed dead code.

For some odd reason, reverting Wei-Yi Guy's patch makes the bug go away... should we do that instead for 2.6.31? (I'm all for it, if this patch is not the right thing to do, as Wey-Yi's patch was not a bug fix, just a cleanup.) My guess is that the "default to MONITOR mode" change is the culprit.

Quoted 7 lines

Quoted 6 lines
/* If this frame is broadcast or management, use broadcast station id */
-     if (!ieee80211_is_data(fc) ||  is_multicast_ether_addr(hdr->addr1))
+     if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
+ iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */ return priv->hw_params.bcast_sta_id;

Quoted 7 lines

I think my comment ties in with what Johannes said. When we are associated (whether in station, adhoc, or AP mode) we want this function to return the correct station ID. We also know that an interface can be in monitor mode while it is in any of these other modes. When this happens we do not want to return the broadcast station id ... we still want to return the station id. Your patch changes this behavior and will in this case always return the broadcast station id.

Maybe we should check info->flags & IEEE80211_TX_CTL_INJECTED instead... is there a way to access the ieee80211_tx_info structure from this function (e.g. through priv)?

Quoted 7 lines

Reinette

Signature · 1 line

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

reinette chatre

2009-08-21 18:00 UTC #7 lore raw

Hi Gábor,

Quoted 2 lines · Gábor Stefanik

For some odd reason, reverting Wei-Yi Guy's patch makes the bug go away

ah - now I see. The driver defaulted to monitor mode in iwl_mac_start. This is not correct and this patch rightly removed that code.

Quoted 3 lines

... should we do that instead for 2.6.31? (I'm all for it, if this patch is not the right thing to do, as Wey-Yi's patch was not a bug fix, just a cleanup.)

No, this patch was more than code cleanup - it changed the driver to behave correctly wrt monitor interface type. Unfortunately the workaround to get packet injection working was not apparent enough and was missed.

Quoted 2 lines

My guess is that the "default to MONITOR mode"
change is the culprit.

yeah ...

Quoted 3 lines

Maybe we should check info->flags & IEEE80211_TX_CTL_INJECTED instead... is there a way to access the ieee80211_tx_info structure from this function (e.g. through priv)?

No, but it may not be necessary. Why is is necessary to call this function in the first place if you know this is an injection packet? Specifically, in iwl_tx_skb and iwl3945_tx_skb (where ieee80211_tx_info) is known) there could just be a test if this is an injected packet, if it is, then do not call iwl_get_sta_id, but just use "bcast_sta_id" directly. Would this work? Is a test for monitor mode still needed in this case?

Reinette

Gábor Stefanik

author

2009-08-21 18:10 UTC #8 lore raw

2009/8/21 reinette chatre <[email protected]>:

Quoted 30 lines

Hi Gábor,
Quoted 2 lines · Gábor Stefanik
For some odd reason, reverting Wei-Yi Guy's patch makes the bug go away
ah - now I see. The driver defaulted to monitor mode in iwl_mac_start. This is not correct and this patch rightly removed that code.
Quoted 3 lines
... should we do that instead for 2.6.31? (I'm all for it, if this patch is not the right thing to do, as Wey-Yi's patch was not a bug fix, just a cleanup.)
No, this patch was more than code cleanup - it changed the driver to behave correctly wrt monitor interface type. Unfortunately the workaround to get packet injection working was not apparent enough and was missed.
Quoted 2 lines
My guess is that the "default to MONITOR mode"
change is the culprit.
yeah ...
Quoted 3 lines
Maybe we should check info->flags & IEEE80211_TX_CTL_INJECTED instead... is there a way to access the ieee80211_tx_info structure from this function (e.g. through priv)?

Quoted 7 lines

No, but it may not be necessary. Why is is necessary to call this function in the first place if you know this is an injection packet? Specifically, in iwl_tx_skb and iwl3945_tx_skb (where ieee80211_tx_info) is known) there could just be a test if this is an injected packet, if it is, then do not call iwl_get_sta_id, but just use "bcast_sta_id" directly. Would this work? Is a test for monitor mode still needed in this case?

That can be done, yes. It is also a good idea to convert iwl_is_monitor_mode(priv) calls with TX_CTL_INJECTED checks, as mac80211 will set IEEE80211_TX_CTL_INJECTED if and only if the packet arrived from a monitor interface. (However, when I submitted the first patches to iwlwifi to enable injection, they were rejected specifically because I checked INJECTED in iwl_tx_skb/iwl394_tx_skb, rather than adding a monitor mode case to iwl_get_sta_id... times change I guess.) I'll submit a patch for this.

Quoted 5 lines

Reinette

Signature · 1 line

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

reinette chatre

2009-08-21 18:24 UTC #9 lore raw

Hi Gábor,

Quoted 4 lines · Gábor Stefanik

That can be done, yes. It is also a good idea to convert iwl_is_monitor_mode(priv) calls with TX_CTL_INJECTED checks, as mac80211 will set IEEE80211_TX_CTL_INJECTED if and only if the packet arrived from a monitor interface.

I don't think that is the intention of that function. iwl_is_monitor_mode() needs to return whether the interface is in monitor mode or not and being in monitor mode is specifically when some filter flags are set up. This is what is tested in this function.

Quoted 5 lines

(However, when I submitted the first
patches to iwlwifi to enable injection, they were rejected specifically because I checked INJECTED in iwl_tx_skb/iwl394_tx_skb, rather than adding a monitor mode case to iwl_get_sta_id... times change I guess.) I'll submit a patch for this.

Sure - you can move the check to iwl_get_sta_id. You will need to indicate to that function that the frame is being injected.

Reinette

Gábor Stefanik

author

2009-08-21 18:37 UTC #10 lore raw

2009/8/21 reinette chatre <[email protected]>:

Quoted 9 lines

Hi Gábor,
Quoted 4 lines · Gábor Stefanik
That can be done, yes. It is also a good idea to convert iwl_is_monitor_mode(priv) calls with TX_CTL_INJECTED checks, as mac80211 will set IEEE80211_TX_CTL_INJECTED if and only if the packet arrived from a monitor interface.

Quoted 4 lines

I don't think that is the intention of that function. iwl_is_monitor_mode() needs to return whether the interface is in monitor mode or not and being in monitor mode is specifically when some filter flags are set up. This is what is tested in this function.

Thanks for the clarification. Will submit a corrected patch soon.

Quoted 17 lines

Quoted 6 lines
(However, when I submitted the first
patches to iwlwifi to enable injection, they were rejected specifically because I checked INJECTED in iwl_tx_skb/iwl394_tx_skb, rather than adding a monitor mode case to iwl_get_sta_id... times change I guess.) I'll submit a patch for this.
Sure - you can move the check to iwl_get_sta_id. You will need to indicate to that function that the frame is being injected.
Reinette

Signature · 1 line

Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)