On Fri, Aug 21, 2009 at 09:33:53AM -0700, reinette chatre wrote:
> Hi Gábor,
>
> On Thu, 2009-08-20 at 15:08 -0700, Gábor Stefanik wrote:
> > 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.
>
> > /* 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
--
John W. Linville Someday the world will need a hero, and you
linville@xxxxxxxxxxxxx might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
