* [PATCH net-next 08/10] net: libertas: inherit addr_assign_type along with dev_addr
From: Bjørn Mork @ 2013-08-23 9:35 UTC (permalink / raw)
To: netdev; +Cc: Bjørn Mork, libertas-dev, linux-wireless, John W. Linville
In-Reply-To: <1377250513-3662-1-git-send-email-bjorn@mork.no>
Cc: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
drivers/net/wireless/libertas/mesh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/libertas/mesh.c b/drivers/net/wireless/libertas/mesh.c
index efae07e..6fef746 100644
--- a/drivers/net/wireless/libertas/mesh.c
+++ b/drivers/net/wireless/libertas/mesh.c
@@ -1017,7 +1017,7 @@ static int lbs_add_mesh(struct lbs_private *priv)
mesh_dev->netdev_ops = &mesh_netdev_ops;
mesh_dev->ethtool_ops = &lbs_ethtool_ops;
- memcpy(mesh_dev->dev_addr, priv->dev->dev_addr, ETH_ALEN);
+ eth_hw_addr_inherit(mesh_dev, priv->dev);
SET_NETDEV_DEV(priv->mesh_dev, priv->dev->dev.parent);
--
1.7.10.4
^ permalink raw reply related
* Re: [linux-nfc] [PATCH RFC] nfc: add a driver for pn532 connected on uart
From: Lars Poeschel @ 2013-08-23 9:28 UTC (permalink / raw)
To: Rymarkiewicz, WaldemarX
Cc: Lars Poeschel, lauro.venancio@openbossa.org,
aloisio.almeida@openbossa.org, sameo@linux.intel.com,
gregkh@linuxfoundation.org, jslaby@suse.cz,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-nfc@lists.01.org
In-Reply-To: <A4DEEF93D8D14A418311321B77DB71E9C9D773@IRSMSX104.ger.corp.intel.com>
On Friday 23 August 2013 at 07:23:00, Rymarkiewicz, WaldemarX wrote:
> Hi Lars,
>
> >This adds a driver for the nxp pn532 nfc chip.
> >It is not meant for merging. Instead it is meant to show that some
> >progress has been made and what the current state is and to help
> >testing.
> >Although I can do some basic things with this driver I expect it to
> >contain lots of bugs. Be aware!
> >This driver is heavily based on the pn533 driver and duplicates much
> >code. This has do be factored out some time.
>
> I'm not sure if this is expected approach adding new drivers. You
> duplicates most of pn533 code which is not good.
Yes, I know that and I explicitly mentioned that. I had to get this chip
working somehow and I had to begin somewhere. The pn533 driver is really
very hard to understand with it's massive use of nested callbacks,
workqueues and usb urbs. So I took the approach to try to understand what
happens while modifying and would then later factor out what both drivers
have in common. The other way is understanding the code first and then
decide what would be needed for both chips, factor that out and then write
the pn532 uart specific stuff. And this uart stuff is a pain itself in
linux. This way seemed much harder to me, especially as I have no pn533
device to test which things will break.
> Also, note that pn533 and pn532 are pretty the same chips (with small
> differences) and it would be quite natural to support both with one
> driver. Pn533 already reads chip version on init, so at this point you
> already know with which chip you are dealing with.
>
> I suggest to separate transport layer from the core in pn533 and add
> support for uart and usb separately. This is exactly what I've planned
> while changing pn533 to support acr122 device.
Yes, I agree with you this should be done. I'll expect it to be challenging
but based on my previous work this could be doable. I'll look into that in
my next free timeslot. I'll not be able to do that in the next two months.
Sorry.
Thank you for your comments,
Lars
^ permalink raw reply
* [PATCH net-next 00/10] set addr_assign_type when inheriting a dev_addr
From: Bjørn Mork @ 2013-08-23 9:35 UTC (permalink / raw)
To: netdev
Cc: Bjørn Mork, Patrick McHardy, Jiri Pirko, John W. Linville,
linux-wireless, Jouni Malinen, libertas-dev, Greg Kroah-Hartman,
devel, Forest Bond
Copying the dev_addr from a parent device is an operation
common to a number of drivers. The addr_assign_type should
be updated accordingly, either by reusing the value from
the source device or explicitly indicating that the address
is stolen by setting addr_assign_type to NET_ADDR_STOLEN.
This patch set adds a helper copying both the dev_addr and
the addr_assign_type, and use this helper in drivers which
don't currently set the addr_assign_type. Using NET_ADDR_STOLEN
might be more appropriate in some of these cases. Please
let me know, and I'll update the patch accordingly.
Bjørn Mork (10):
net: etherdevice: add address inherit helper
net: vlan: inherit addr_assign_type along with dev_addr
net: dsa: inherit addr_assign_type along with dev_addr
net: macvlan: inherit addr_assign_type along with dev_addr
net: team: inherit addr_assign_type along with dev_addr
net: airo: inherit addr_assign_type along with dev_addr
net: hostap: inherit addr_assign_type along with dev_addr
net: libertas: inherit addr_assign_type along with dev_addr
staging: vt6655: inherit addr_assign_type along with dev_addr
staging: vt6656: inherit addr_assign_type along with dev_addr
drivers/net/macvlan.c | 2 +-
drivers/net/team/team.c | 2 +-
drivers/net/wireless/airo.c | 2 +-
drivers/net/wireless/hostap/hostap_hw.c | 2 +-
drivers/net/wireless/hostap/hostap_main.c | 2 +-
drivers/net/wireless/libertas/mesh.c | 2 +-
drivers/staging/vt6655/hostap.c | 2 +-
drivers/staging/vt6655/ioctl.c | 2 +-
drivers/staging/vt6655/wpactl.c | 2 +-
drivers/staging/vt6656/hostap.c | 2 +-
include/linux/etherdevice.h | 19 +++++++++++++++++++
net/8021q/vlan_dev.c | 2 +-
net/dsa/slave.c | 2 +-
13 files changed, 31 insertions(+), 12 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH v2 01/16] wcn36xx: Add main.c
From: Eugene Krasnikov @ 2013-08-23 9:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377249774.14021.15.camel@jlt4.sipsolutions.net>
>> +static const struct ieee80211_iface_limit if_limits[] = {
>> + { .max = 2, .types = BIT(NL80211_IFTYPE_STATION) },
>> + { .max = 1, .types = BIT(NL80211_IFTYPE_AP) },
>> +};
>> +
>> +static const struct ieee80211_iface_combination if_comb = {
>> + .limits = if_limits,
>> + .n_limits = ARRAY_SIZE(if_limits),
>> + .max_interfaces = 2,
>> + .num_different_channels = 1,
>> +};
>
>> +static int wcn36xx_add_interface(struct ieee80211_hw *hw,
>> + struct ieee80211_vif *vif)
>> +{
>> + struct wcn36xx *wcn = hw->priv;
>> +
>> + wcn36xx_dbg(WCN36XX_DBG_MAC, "mac add interface vif %p type %d\n",
>> + vif, vif->type);
>> +
>> + wcn->current_vif = (struct wcn36xx_vif *)vif->drv_priv;
>
> If you actually support two interfaces (and that looks more likely now)
> I don't think this "current_vif" makes any sense at all, it'll be
> randomly pointing to one or the other depending on which one was added
> last.
>
>> +static int wcn36xx_sta_add(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
>> + struct ieee80211_sta *sta)
>> +{
>> + struct wcn36xx *wcn = hw->priv;
>> +
>> + wcn36xx_dbg(WCN36XX_DBG_MAC, "mac sta add vif %p sta %pM\n",
>> + vif, sta->addr);
>> +
>> + wcn->sta = (struct wcn36xx_sta *)sta->drv_priv;
>> + wcn->aid = sta->aid;
>
> You support more than one interface and AP, but there's no way this code
> can then be correct. It seems to me that you're really only supporting a
> single client interface correctly right now.
Exactly. So far wcn36xx supports only one interface.
--
Best regards,
Eugene
^ permalink raw reply
* Re: [PATCH v2 01/16] wcn36xx: Add main.c
From: Johannes Berg @ 2013-08-23 9:47 UTC (permalink / raw)
To: Eugene Krasnikov; +Cc: linux-wireless, wcn36xx
In-Reply-To: <CAFSJ42YsC2qO1iqocfOujZ5TUkKKAQMCiwLxjGZKZW7xy=J=pA@mail.gmail.com>
On Fri, 2013-08-23 at 11:42 +0200, Eugene Krasnikov wrote:
> >> +static const struct ieee80211_iface_limit if_limits[] = {
> >> + { .max = 2, .types = BIT(NL80211_IFTYPE_STATION) },
> >> + { .max = 1, .types = BIT(NL80211_IFTYPE_AP) },
> >> +};
> >> +
> >> +static const struct ieee80211_iface_combination if_comb = {
> >> + .limits = if_limits,
> >> + .n_limits = ARRAY_SIZE(if_limits),
> >> + .max_interfaces = 2,
> >> + .num_different_channels = 1,
> >> +};
> Exactly. So far wcn36xx supports only one interface.
But you're still advertising two.
johannes
^ permalink raw reply
* RE: [linux-nfc] [PATCH RFC] nfc: add a driver for pn532 connected on uart
From: Rymarkiewicz, WaldemarX @ 2013-08-23 9:47 UTC (permalink / raw)
To: Lars Poeschel
Cc: Lars Poeschel, sameo@linux.intel.com, jslaby@suse.cz,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-nfc@lists.01.org
In-Reply-To: <201308231128.47731.poeschel@lemonage.de>
Hi,
>Yes, I know that and I explicitly mentioned that. I had to get this chip working
>somehow and I had to begin somewhere. The pn533 driver is really very hard
>to understand with it's massive use of nested callbacks, workqueues and
>usb urbs. So I took the approach to try to understand what happens while modifying
>and would then later factor out what both drivers have in common.
>The other way is understanding the code first and then decide what would be needed for
> both chips, factor that out and then write the pn532 uart specific stuff. And this uart stuff
>is a pain itself in linux. This way seemed much harder to me,
> especially as I have no pn533 device to test which things will break.
I understand. It took me some time to understand this too. Now, it's even harder after adding protocol ops, but still is pretty well layered.
> I suggest to separate transport layer from the core in pn533 and add
> support for uart and usb separately. This is exactly what I've planned
> while changing pn533 to support acr122 device.
>> Yes, I agree with you this should be done. I'll expect it to be challenging
>> but based on my previous work this could be doable.
Be sure there will be pitfalls separating transport. I've already experienced some of them adding support for acr122.
>> I'll look into that in my next free timeslot. I'll not be able to do that in the next two months.
>>Sorry.
No worries. I know this pain :)
Thanks,
/Waldek
^ permalink raw reply
* Re: [PATCH] mac80211: minstrel_ht: don't use control.flags in TX status path
From: Johannes Berg @ 2013-08-23 10:01 UTC (permalink / raw)
To: linux-wireless; +Cc: Sujith Manoharan
In-Reply-To: <1377153566-15478-1-git-send-email-johannes@sipsolutions.net>
On Thu, 2013-08-22 at 08:39 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Sujith reports that my commit af61a165187bb94b1dc7628ef815c23d0eacf40b
> ("mac80211: add control port protocol TX control flag") broke ath9k
> (aggregation). The reason is that I made minstrel_ht use the flag in
> the TX status path, where it can have been overwritten by the driver.
> Since we have no more space in info->flags, revert that part of the
> change for now, until we can reshuffle the flags or so.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: move setting WIPHY_FLAG_SUPPORTS_SCHED_SCAN into drivers
From: Johannes Berg @ 2013-08-23 10:02 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho
In-Reply-To: <1377077275-19429-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-08-21 at 11:27 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> mac80211 currently sets WIPHY_FLAG_SUPPORTS_SCHED_SCAN based on whether
> the start_sched_scan operation is supported or not, but that will not
> be correct for all drivers, we're adding scheduled scan to the iwlmvm
> driver but it depends on firmware support.
>
> Therefore, move setting WIPHY_FLAG_SUPPORTS_SCHED_SCAN into the drivers
> so that they can control it regardless of implementing the operation.
>
> This currently only affects the TI drivers since they're the only ones
> implementing scheduled scan (in a mac80211 driver.)
Applied.
johannes
^ permalink raw reply
* Re: [PATCH v2 01/16] wcn36xx: Add main.c
From: Eugene Krasnikov @ 2013-08-23 10:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, wcn36xx
In-Reply-To: <1377251223.14021.16.camel@jlt4.sipsolutions.net>
My bad. Did not clean up it completely. if_comb is a dead code and is
not used anywhere. Will fix it.
2013/8/23 Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2013-08-23 at 11:42 +0200, Eugene Krasnikov wrote:
>> >> +static const struct ieee80211_iface_limit if_limits[] = {
>> >> + { .max = 2, .types = BIT(NL80211_IFTYPE_STATION) },
>> >> + { .max = 1, .types = BIT(NL80211_IFTYPE_AP) },
>> >> +};
>> >> +
>> >> +static const struct ieee80211_iface_combination if_comb = {
>> >> + .limits = if_limits,
>> >> + .n_limits = ARRAY_SIZE(if_limits),
>> >> + .max_interfaces = 2,
>> >> + .num_different_channels = 1,
>> >> +};
>
>> Exactly. So far wcn36xx supports only one interface.
>
> But you're still advertising two.
>
> johannes
>
>
--
Best regards,
Eugene
^ permalink raw reply
* [PATCH] staging: vt6656: rxtx.c s_create new function to endian correct uGetTxRsvTime.
From: Malcolm Priestley @ 2013-08-23 10:32 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
We can't endian correct uGetTxRsvTime because it is called by other functions.
Create new function to vnt_rxtx_rsvtime_le16 to return little endian u16
value.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/rxtx.c | 33 +++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 4f36ec8..f1eec60 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -348,6 +348,13 @@ static u32 s_uGetTxRsvTime(struct vnt_private *pDevice, u8 byPktType,
}
}
+static u16 vnt_rxtx_rsvtime_le16(struct vnt_private *priv, u8 pkt_type,
+ u32 frame_length, u16 rate, int need_ack)
+{
+ return cpu_to_le16((u16)s_uGetTxRsvTime(priv, pkt_type,
+ frame_length, rate, need_ack));
+}
+
//byFreqType: 0=>5GHZ 1=>2.4GHZ
static u16 s_uGetRTSCTSRsvTime(struct vnt_private *pDevice,
u8 byRTSRsvType, u8 byPktType, u32 cbFrameLength, u16 wCurrentRate)
@@ -882,8 +889,11 @@ static void s_vGenerateTxParameter(struct vnt_private *pDevice,
byPktType, cbFrameSize, wCurrentRate);
pBuf->wRTSTxRrvTime_bb = s_uGetRTSCTSRsvTime(pDevice, 0,
byPktType, cbFrameSize, wCurrentRate);
- pBuf->wTxRrvTime_a = cpu_to_le16((u16) s_uGetTxRsvTime(pDevice, byPktType, cbFrameSize, wCurrentRate, bNeedACK));//2.4G OFDM
- pBuf->wTxRrvTime_b = cpu_to_le16((u16) s_uGetTxRsvTime(pDevice, PK_TYPE_11B, cbFrameSize, pDevice->byTopCCKBasicRate, bNeedACK));//1:CCK
+ pBuf->wTxRrvTime_a = vnt_rxtx_rsvtime_le16(pDevice,
+ byPktType, cbFrameSize, wCurrentRate, bNeedACK);
+ pBuf->wTxRrvTime_b = vnt_rxtx_rsvtime_le16(pDevice,
+ PK_TYPE_11B, cbFrameSize, pDevice->byTopCCKBasicRate,
+ bNeedACK);
}
//Fill RTS
s_vFillRTSHead(pDevice, byPktType, pvRTS, cbFrameSize, bNeedACK, bDisCRC, psEthHeader, wCurrentRate, byFBOption);
@@ -894,8 +904,11 @@ static void s_vGenerateTxParameter(struct vnt_private *pDevice,
if (pvRrvTime) {
struct vnt_rrv_time_cts *pBuf =
(struct vnt_rrv_time_cts *)pvRrvTime;
- pBuf->wTxRrvTime_a = cpu_to_le16((u16)s_uGetTxRsvTime(pDevice, byPktType, cbFrameSize, wCurrentRate, bNeedACK));//2.4G OFDM
- pBuf->wTxRrvTime_b = cpu_to_le16((u16)s_uGetTxRsvTime(pDevice, PK_TYPE_11B, cbFrameSize, pDevice->byTopCCKBasicRate, bNeedACK));//1:CCK
+ pBuf->wTxRrvTime_a = vnt_rxtx_rsvtime_le16(pDevice, byPktType,
+ cbFrameSize, wCurrentRate, bNeedACK);
+ pBuf->wTxRrvTime_b = vnt_rxtx_rsvtime_le16(pDevice,
+ PK_TYPE_11B, cbFrameSize,
+ pDevice->byTopCCKBasicRate, bNeedACK);
pBuf->wCTSTxRrvTime_ba = s_uGetRTSCTSRsvTime(pDevice, 3,
byPktType, cbFrameSize, wCurrentRate);
}
@@ -912,7 +925,8 @@ static void s_vGenerateTxParameter(struct vnt_private *pDevice,
(struct vnt_rrv_time_ab *)pvRrvTime;
pBuf->wRTSTxRrvTime = s_uGetRTSCTSRsvTime(pDevice, 2,
byPktType, cbFrameSize, wCurrentRate);
- pBuf->wTxRrvTime = cpu_to_le16((u16)s_uGetTxRsvTime(pDevice, byPktType, cbFrameSize, wCurrentRate, bNeedACK));//0:OFDM
+ pBuf->wTxRrvTime = vnt_rxtx_rsvtime_le16(pDevice, byPktType,
+ cbFrameSize, wCurrentRate, bNeedACK);
}
//Fill RTS
s_vFillRTSHead(pDevice, byPktType, pvRTS, cbFrameSize, bNeedACK, bDisCRC, psEthHeader, wCurrentRate, byFBOption);
@@ -922,7 +936,8 @@ static void s_vGenerateTxParameter(struct vnt_private *pDevice,
if (pvRrvTime) {
struct vnt_rrv_time_ab *pBuf =
(struct vnt_rrv_time_ab *)pvRrvTime;
- pBuf->wTxRrvTime = cpu_to_le16((u16)s_uGetTxRsvTime(pDevice, PK_TYPE_11A, cbFrameSize, wCurrentRate, bNeedACK)); //0:OFDM
+ pBuf->wTxRrvTime = vnt_rxtx_rsvtime_le16(pDevice, PK_TYPE_11A,
+ cbFrameSize, wCurrentRate, bNeedACK);
}
}
}
@@ -935,7 +950,8 @@ static void s_vGenerateTxParameter(struct vnt_private *pDevice,
(struct vnt_rrv_time_ab *)pvRrvTime;
pBuf->wRTSTxRrvTime = s_uGetRTSCTSRsvTime(pDevice, 0,
byPktType, cbFrameSize, wCurrentRate);
- pBuf->wTxRrvTime = cpu_to_le16((u16)s_uGetTxRsvTime(pDevice, PK_TYPE_11B, cbFrameSize, wCurrentRate, bNeedACK));//1:CCK
+ pBuf->wTxRrvTime = vnt_rxtx_rsvtime_le16(pDevice, PK_TYPE_11B,
+ cbFrameSize, wCurrentRate, bNeedACK);
}
//Fill RTS
s_vFillRTSHead(pDevice, byPktType, pvRTS, cbFrameSize, bNeedACK, bDisCRC, psEthHeader, wCurrentRate, byFBOption);
@@ -945,7 +961,8 @@ static void s_vGenerateTxParameter(struct vnt_private *pDevice,
if (pvRrvTime) {
struct vnt_rrv_time_ab *pBuf =
(struct vnt_rrv_time_ab *)pvRrvTime;
- pBuf->wTxRrvTime = cpu_to_le16((u16)s_uGetTxRsvTime(pDevice, PK_TYPE_11B, cbFrameSize, wCurrentRate, bNeedACK)); //1:CCK
+ pBuf->wTxRrvTime = vnt_rxtx_rsvtime_le16(pDevice, PK_TYPE_11B,
+ cbFrameSize, wCurrentRate, bNeedACK);
}
}
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH] staging: vt6656: rxtx.c endian correct wTimeStampOff
From: Malcolm Priestley @ 2013-08-23 10:48 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
wTimeStampOff needs to be endian corrected
Create new function vnt_time_stamp_off to return little endian u16 value.
Private variable byPreambleType is common to all calling functions is included.
variable rate to set the desired rate.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/rxtx.c | 33 ++++++++++++++++++++++-----------
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index f1eec60..ed3fdf4 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -323,6 +323,12 @@ static void s_vSWencryption(struct vnt_private *pDevice,
}
}
+static u16 vnt_time_stamp_off(struct vnt_private *priv, u16 rate)
+{
+ return cpu_to_le16(wTimeStampOff[priv->byPreambleType % 2]
+ [rate % MAX_RATE]);
+}
+
/*byPktType : PK_TYPE_11A 0
PK_TYPE_11B 1
PK_TYPE_11GB 2
@@ -519,8 +525,10 @@ static u32 s_uFillDataHead(struct vnt_private *pDevice,
pBuf->wDuration_b = s_uGetDataDuration(pDevice,
PK_TYPE_11B, bNeedAck);
- pBuf->wTimeStampOff_a = wTimeStampOff[pDevice->byPreambleType%2][wCurrentRate%MAX_RATE];
- pBuf->wTimeStampOff_b = wTimeStampOff[pDevice->byPreambleType%2][pDevice->byTopCCKBasicRate%MAX_RATE];
+ pBuf->wTimeStampOff_a = vnt_time_stamp_off(pDevice,
+ wCurrentRate);
+ pBuf->wTimeStampOff_b = vnt_time_stamp_off(pDevice,
+ pDevice->byTopCCKBasicRate);
return (pBuf->wDuration_a);
} else {
// Auto Fallback
@@ -540,8 +548,10 @@ static u32 s_uFillDataHead(struct vnt_private *pDevice,
byPktType, bNeedAck);
pBuf->wDuration_a_f1 = s_uGetDataDuration(pDevice,
byPktType, bNeedAck);
- pBuf->wTimeStampOff_a = wTimeStampOff[pDevice->byPreambleType%2][wCurrentRate%MAX_RATE];
- pBuf->wTimeStampOff_b = wTimeStampOff[pDevice->byPreambleType%2][pDevice->byTopCCKBasicRate%MAX_RATE];
+ pBuf->wTimeStampOff_a = vnt_time_stamp_off(pDevice,
+ wCurrentRate);
+ pBuf->wTimeStampOff_b = vnt_time_stamp_off(pDevice,
+ pDevice->byTopCCKBasicRate);
return (pBuf->wDuration_a);
} //if (byFBOption == AUTO_FB_NONE)
}
@@ -559,7 +569,8 @@ static u32 s_uFillDataHead(struct vnt_private *pDevice,
byPktType, bNeedAck);
pBuf->wDuration_f1 = s_uGetDataDuration(pDevice,
byPktType, bNeedAck);
- pBuf->wTimeStampOff = wTimeStampOff[pDevice->byPreambleType%2][wCurrentRate%MAX_RATE];
+ pBuf->wTimeStampOff = vnt_time_stamp_off(pDevice,
+ wCurrentRate);
return (pBuf->wDuration);
} else {
struct vnt_tx_datahead_ab *pBuf =
@@ -570,8 +581,8 @@ static u32 s_uFillDataHead(struct vnt_private *pDevice,
//Get Duration and TimeStampOff
pBuf->wDuration = s_uGetDataDuration(pDevice,
byPktType, bNeedAck);
- pBuf->wTimeStampOff = wTimeStampOff[pDevice->byPreambleType%2][wCurrentRate%MAX_RATE];
-
+ pBuf->wTimeStampOff = vnt_time_stamp_off(pDevice,
+ wCurrentRate);
return (pBuf->wDuration);
}
}
@@ -584,8 +595,8 @@ static u32 s_uFillDataHead(struct vnt_private *pDevice,
//Get Duration and TimeStampOff
pBuf->wDuration = s_uGetDataDuration(pDevice,
byPktType, bNeedAck);
- pBuf->wTimeStampOff = wTimeStampOff[pDevice->byPreambleType%2][wCurrentRate%MAX_RATE];
-
+ pBuf->wTimeStampOff = vnt_time_stamp_off(pDevice,
+ wCurrentRate);
return (pBuf->wDuration);
}
return 0;
@@ -1830,7 +1841,7 @@ CMD_STATUS csBeacon_xmit(struct vnt_private *pDevice,
//Get Duration and TimeStampOff
pTxDataHead->wDuration = s_uGetDataDuration(pDevice,
PK_TYPE_11A, false);
- pTxDataHead->wTimeStampOff = wTimeStampOff[pDevice->byPreambleType%2][wCurrentRate%MAX_RATE];
+ pTxDataHead->wTimeStampOff = vnt_time_stamp_off(pDevice, wCurrentRate);
cbHeaderSize = wTxBufSize + sizeof(struct vnt_tx_datahead_ab);
} else {
wCurrentRate = RATE_1M;
@@ -1843,7 +1854,7 @@ CMD_STATUS csBeacon_xmit(struct vnt_private *pDevice,
//Get Duration and TimeStampOff
pTxDataHead->wDuration = s_uGetDataDuration(pDevice,
PK_TYPE_11B, false);
- pTxDataHead->wTimeStampOff = wTimeStampOff[pDevice->byPreambleType%2][wCurrentRate%MAX_RATE];
+ pTxDataHead->wTimeStampOff = vnt_time_stamp_off(pDevice, wCurrentRate);
cbHeaderSize = wTxBufSize + sizeof(struct vnt_tx_datahead_ab);
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] mac80211: remove IEEE80211_STA_BEACON_POLL
From: Johannes Berg @ 2013-08-23 13:24 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless
In-Reply-To: <20130823065200.GA3835@redhat.com>
On Fri, 2013-08-23 at 08:52 +0200, Stanislaw Gruszka wrote:
> - if (ifmgd->flags & IEEE80211_STA_BEACON_POLL) {
> + if (ifmgd->flags & IEEE80211_STA_CONNECTION_POLL) {
> mlme_dbg_ratelimited(sdata,
> "cancelling AP probe due to a received beacon\n");
> - mutex_lock(&local->mtx);
> - ifmgd->flags &= ~IEEE80211_STA_BEACON_POLL;
> - ieee80211_run_deferred_scan(local);
> - mutex_unlock(&local->mtx);
> -
> - mutex_lock(&local->iflist_mtx);
> - ieee80211_recalc_ps(local, -1);
> - mutex_unlock(&local->iflist_mtx);
> + ieee80211_reset_ap_probe(sdata);
> }
This is actually a behavioural change for drivers that implement beacon
filtering/monitoring. It means that when the driver reports beacon loss
and we poll, we'd make a received beacon later abort the poll.
That seems like a reasonable change, but you should probably note it.
johannes
^ permalink raw reply
* Re: [PATCH v3] mac80211: only respond to probe request with mesh ID
From: Johannes Berg @ 2013-08-23 13:27 UTC (permalink / raw)
To: Chun-Yeow Yeoh; +Cc: linux-wireless, linville, devel, distro11s
In-Reply-To: <1377192538-5563-1-git-send-email-yeohchunyeow@gmail.com>
On Thu, 2013-08-22 at 10:28 -0700, Chun-Yeow Yeoh wrote:
> From: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
>
> Previously, the mesh STA responds to probe request from legacy STA
> but now it will only respond to legacy STA if the legacy STA does include
> the specific mesh ID or wildcard mesh ID in the probe request.
Applied.
johannes
^ permalink raw reply
* [PATCH 1/2] staging: vt6656: desc.h Remove typedef struct tagSMICHDRHead to new structure in rxtx.h
From: Malcolm Priestley @ 2013-08-23 13:33 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
To new structure.
typedef struct tagSMICHDRHead -> struct vnt_mic_hdr
This is only needed by rxtc.c so moved to rxtx.h
The new structure is the same size as the old but
contains the members as pointer referenced in
rxtx.c s_vFillTxKey
u8 id
*pMICHDR = 0x59;
u8 tx_priority;
*((u8 *)(pMICHDR+1)) = 0; // TxPriority
u8 mic_addr2[6];
memcpy(pMICHDR+2, &(pMACHeader->addr2[0]), 6);
__be32 tsc_47_16;
pMICHDR+8 = HIBYTE(HIWORD(pTransmitKey->dwTSC47_16));
pMICHDR+9 = LOBYTE(HIWORD(pTransmitKey->dwTSC47_16));
pMICHDR+10 = HIBYTE(LOWORD(pTransmitKey->dwTSC47_16));
pMICHDR+11 = LOBYTE(LOWORD(pTransmitKey->dwTSC47_16));
__be16 tsc_15_0;
pMICHDR+12 = HIBYTE(pTransmitKey->wTSC15_0);
pMICHDR+13 = LOBYTE(pTransmitKey->wTSC15_0);
__be16 payload_len;
pMICHDR+14 = HIBYTE(wPayloadLen);
pMICHDR+15 = LOBYTE(wPayloadLen);
__be16 hlen;
pMICHDR+16 = 0; // HLEN[15:8]
pMICHDR+17 = 28; // HLEN[7:0]
__le16 frame_control;
memcpy(pMICHDR+18, (u8 *)&wValue, 2); // MSKFRACTL
u8 addr1[6];
memcpy(pMICHDR+20, &(pMACHeader->addr1[0]), 6);
u8 addr2[6];
memcpy(pMICHDR+26, &(pMACHeader->addr2[0]), 6);
u8 addr3[6];
memcpy(pMICHDR+32, &(pMACHeader->addr3[0]), 6);
__le16 seq_ctrl;
memcpy(pMICHDR+38, (u8 *)&wValue, 2); // MSKSEQCTL
u8 addr4[6];
memcpy(pMICHDR+40, &(pMACHeader->addr4[0]), 6);
u16 packing; /* packing to 48 bytes */
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/desc.h | 12 ------------
drivers/staging/vt6656/rxtx.c | 26 +++++++++++++-------------
drivers/staging/vt6656/rxtx.h | 18 ++++++++++++++++++
3 files changed, 31 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/vt6656/desc.h b/drivers/staging/vt6656/desc.h
index b3e8cc1..4675135 100644
--- a/drivers/staging/vt6656/desc.h
+++ b/drivers/staging/vt6656/desc.h
@@ -163,18 +163,6 @@ typedef struct tagSTxShortBufHead {
STxShortBufHead, *PSTxShortBufHead;
typedef const STxShortBufHead *PCSTxShortBufHead;
-/*
- * MICHDR data header
- */
-typedef struct tagSMICHDRHead {
- u32 adwHDR0[4];
- u32 adwHDR1[4];
- u32 adwHDR2[4];
-} __attribute__ ((__packed__))
-SMICHDRHead, *PSMICHDRHead;
-
-typedef const SMICHDRHead *PCSMICHDRHead;
-
typedef struct tagSBEACONCtl {
u32 BufReady:1;
u32 TSF:15;
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index ed3fdf4..c055c76 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -1004,7 +1004,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
u32 uDuration;
u32 cbHeaderLength = 0, uPadding = 0;
void *pvRrvTime;
- PSMICHDRHead pMICHDR;
+ struct vnt_mic_hdr *pMICHDR;
void *pvRTS;
void *pvCTS;
void *pvTxDataHd;
@@ -1121,7 +1121,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
if (pTransmitKey->byCipherSuite == KEY_CTL_CCMP) {
cbIVlen = 8;//RSN Header
cbICVlen = 8;//MIC
- cbMICHDR = sizeof(SMICHDRHead);
+ cbMICHDR = sizeof(struct vnt_mic_hdr);
}
if (bSoftWEP == false) {
//MAC Header should be padding 0 to DW alignment.
@@ -1146,7 +1146,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
if (bRTS == true) {//RTS_need
pvRrvTime = (struct vnt_rrv_time_rts *)
(pbyTxBufferAddr + wTxBufSize);
- pMICHDR = (PSMICHDRHead)(pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *)(pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_rts));
pvRTS = (struct vnt_rts_g *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_rts) + cbMICHDR);
@@ -1161,7 +1161,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
else { //RTS_needless
pvRrvTime = (struct vnt_rrv_time_cts *)
(pbyTxBufferAddr + wTxBufSize);
- pMICHDR = (PSMICHDRHead) (pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_cts));
pvRTS = NULL;
pvCTS = (struct vnt_cts *) (pbyTxBufferAddr + wTxBufSize +
@@ -1178,7 +1178,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
if (bRTS == true) {//RTS_need
pvRrvTime = (struct vnt_rrv_time_rts *)(pbyTxBufferAddr +
wTxBufSize);
- pMICHDR = (PSMICHDRHead) (pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_rts));
pvRTS = (struct vnt_rts_g_fb *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_rts) + cbMICHDR);
@@ -1193,7 +1193,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
else if (bRTS == false) { //RTS_needless
pvRrvTime = (struct vnt_rrv_time_cts *)
(pbyTxBufferAddr + wTxBufSize);
- pMICHDR = (PSMICHDRHead) (pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_cts));
pvRTS = NULL;
pvCTS = (struct vnt_cts_fb *) (pbyTxBufferAddr + wTxBufSize +
@@ -1212,7 +1212,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
if (bRTS == true) {//RTS_need
pvRrvTime = (struct vnt_rrv_time_ab *) (pbyTxBufferAddr +
wTxBufSize);
- pMICHDR = (PSMICHDRHead)(pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *)(pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_ab));
pvRTS = (struct vnt_rts_ab *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_ab) + cbMICHDR);
@@ -1227,7 +1227,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
else if (bRTS == false) { //RTS_needless, no MICHDR
pvRrvTime = (struct vnt_rrv_time_ab *)(pbyTxBufferAddr +
wTxBufSize);
- pMICHDR = (PSMICHDRHead) (pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_ab));
pvRTS = NULL;
pvCTS = NULL;
@@ -1241,7 +1241,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
if (bRTS == true) {//RTS_need
pvRrvTime = (struct vnt_rrv_time_ab *)(pbyTxBufferAddr +
wTxBufSize);
- pMICHDR = (PSMICHDRHead) (pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_ab));
pvRTS = (struct vnt_rts_a_fb *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_ab) + cbMICHDR);
@@ -1256,7 +1256,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
else if (bRTS == false) { //RTS_needless
pvRrvTime = (struct vnt_rrv_time_ab *)(pbyTxBufferAddr +
wTxBufSize);
- pMICHDR = (PSMICHDRHead)(pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *)(pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_ab));
pvRTS = NULL;
pvCTS = NULL;
@@ -2057,7 +2057,7 @@ void vDMA0_tx_80211(struct vnt_private *pDevice, struct sk_buff *skb)
else if (pDevice->eEncryptionStatus == Ndis802_11Encryption3Enabled) {
cbIVlen = 8;//RSN Header
cbICVlen = 8;//MIC
- cbMICHDR = sizeof(SMICHDRHead);
+ cbMICHDR = sizeof(struct vnt_mic_hdr);
pTxBufHead->wFragCtl |= FRAGCTL_AES;
pDevice->bAES = true;
}
@@ -2076,7 +2076,7 @@ void vDMA0_tx_80211(struct vnt_private *pDevice, struct sk_buff *skb)
if (byPktType == PK_TYPE_11GB || byPktType == PK_TYPE_11GA) {//802.11g packet
pvRrvTime = (struct vnt_rrv_time_cts *) (pbyTxBufferAddr + wTxBufSize);
- pMICHDR = (PSMICHDRHead) (pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_cts));
pvRTS = NULL;
pvCTS = (struct vnt_cts *) (pbyTxBufferAddr + wTxBufSize +
@@ -2091,7 +2091,7 @@ void vDMA0_tx_80211(struct vnt_private *pDevice, struct sk_buff *skb)
else {//802.11a/b packet
pvRrvTime = (struct vnt_rrv_time_ab *) (pbyTxBufferAddr + wTxBufSize);
- pMICHDR = (PSMICHDRHead) (pbyTxBufferAddr + wTxBufSize +
+ pMICHDR = (struct vnt_mic_hdr *) (pbyTxBufferAddr + wTxBufSize +
sizeof(struct vnt_rrv_time_ab));
pvRTS = NULL;
pvCTS = NULL;
diff --git a/drivers/staging/vt6656/rxtx.h b/drivers/staging/vt6656/rxtx.h
index 3484f2b..ad62052 100644
--- a/drivers/staging/vt6656/rxtx.h
+++ b/drivers/staging/vt6656/rxtx.h
@@ -33,6 +33,24 @@
#include "wcmd.h"
#include "baseband.h"
+/* MIC HDR data header */
+struct vnt_mic_hdr {
+ u8 id;
+ u8 tx_priority;
+ u8 mic_addr2[6];
+ __be32 tsc_47_16;
+ __be16 tsc_15_0;
+ __be16 payload_len;
+ __be16 hlen;
+ __le16 frame_control;
+ u8 addr1[6];
+ u8 addr2[6];
+ u8 addr3[6];
+ __le16 seq_ctrl;
+ u8 addr4[6];
+ u16 packing; /* packing to 48 bytes */
+} __packed;
+
/* RsvTime buffer header */
struct vnt_rrv_time_rts {
u16 wRTSTxRrvTime_ba;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] mac80211: assign seqnums for group QoS frames
From: Bob Copeland @ 2013-08-23 13:35 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
According to 802.11-2012 9.3.2.10, paragraph 4, QoS
data frames with a group address in the Address 1 field
have sequence numbers allocated from the same counter
as non-QoS data and management frames. Without this
flag, some drivers may not assign sequence numbers, and
in rare cases frames might get dropped. Set the control
flag accordingly.
Signed-off-by: Bob Copeland <bob@cozybit.com>
---
I noticed seq=0 on DHCP/mDNS frames with mesh on certain
hardware (since mesh sends all data frames as QoS).
Johannes pointed out this only causes issues if a unicast
frame with seq=0 has retries, and if the receiver caches
seqnums from multicast frames (mac80211 does not).
net/mac80211/tx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 098ae85..3456c04 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -781,9 +781,11 @@ ieee80211_tx_h_sequence(struct ieee80211_tx_data *tx)
/*
* Anything but QoS data that has a sequence number field
* (is long enough) gets a sequence number from the global
- * counter.
+ * counter. QoS data frames with a multicast destination
+ * also use the global counter (802.11-2012 9.3.2.10).
*/
- if (!ieee80211_is_data_qos(hdr->frame_control)) {
+ if (!ieee80211_is_data_qos(hdr->frame_control) ||
+ is_multicast_ether_addr(hdr->addr1)) {
/* driver should assign sequence number */
info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
/* for pure STA mode without beacons, we can do it */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] staging: vt6656: rxtx.c s_vFillTxKey fill structure vnt_mic_hdr
From: Malcolm Priestley @ 2013-08-23 13:37 UTC (permalink / raw)
To: gregkh; +Cc: linux-wireless
Replace the pointer offsets with structure of mic_hdr with
endian conversion where needed.
Replace vFillTxKey argument u8 *pMICHDR with struct vnt_mic_hdr *mic_hdr
and fix type of calling functions.
An extra check that mic_hdr is not NULL
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
---
drivers/staging/vt6656/rxtx.c | 71 +++++++++++++++++++------------------------
1 file changed, 32 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index c055c76..14b7def 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -113,7 +113,7 @@ static void s_vGenerateMACHeader(struct vnt_private *pDevice,
static void s_vFillTxKey(struct vnt_private *pDevice, u8 *pbyBuf,
u8 *pbyIVHead, PSKeyItem pTransmitKey, u8 *pbyHdrBuf, u16 wPayloadLen,
- u8 *pMICHDR);
+ struct vnt_mic_hdr *mic_hdr);
static void s_vSWencryption(struct vnt_private *pDevice,
PSKeyItem pTransmitKey, u8 *pbyPayloadHead, u16 wPayloadSize);
@@ -183,11 +183,10 @@ static void s_vSaveTxPktInfo(struct vnt_private *pDevice, u8 byPktNum,
static void s_vFillTxKey(struct vnt_private *pDevice, u8 *pbyBuf,
u8 *pbyIVHead, PSKeyItem pTransmitKey, u8 *pbyHdrBuf,
- u16 wPayloadLen, u8 *pMICHDR)
+ u16 wPayloadLen, struct vnt_mic_hdr *mic_hdr)
{
u32 *pdwIV = (u32 *)pbyIVHead;
u32 *pdwExtIV = (u32 *)((u8 *)pbyIVHead + 4);
- u16 wValue;
struct ieee80211_hdr *pMACHeader = (struct ieee80211_hdr *)pbyHdrBuf;
u32 dwRevIVCounter;
@@ -251,40 +250,34 @@ static void s_vFillTxKey(struct vnt_private *pDevice, u8 *pbyBuf,
//Append IV&ExtIV after Mac Header
*pdwExtIV = cpu_to_le32(pTransmitKey->dwTSC47_16);
- //Fill MICHDR0
- *pMICHDR = 0x59;
- *((u8 *)(pMICHDR+1)) = 0; // TxPriority
- memcpy(pMICHDR+2, &(pMACHeader->addr2[0]), 6);
- *((u8 *)(pMICHDR+8)) = HIBYTE(HIWORD(pTransmitKey->dwTSC47_16));
- *((u8 *)(pMICHDR+9)) = LOBYTE(HIWORD(pTransmitKey->dwTSC47_16));
- *((u8 *)(pMICHDR+10)) = HIBYTE(LOWORD(pTransmitKey->dwTSC47_16));
- *((u8 *)(pMICHDR+11)) = LOBYTE(LOWORD(pTransmitKey->dwTSC47_16));
- *((u8 *)(pMICHDR+12)) = HIBYTE(pTransmitKey->wTSC15_0);
- *((u8 *)(pMICHDR+13)) = LOBYTE(pTransmitKey->wTSC15_0);
- *((u8 *)(pMICHDR+14)) = HIBYTE(wPayloadLen);
- *((u8 *)(pMICHDR+15)) = LOBYTE(wPayloadLen);
-
- //Fill MICHDR1
- *((u8 *)(pMICHDR+16)) = 0; // HLEN[15:8]
- if (pDevice->bLongHeader) {
- *((u8 *)(pMICHDR+17)) = 28; // HLEN[7:0]
- } else {
- *((u8 *)(pMICHDR+17)) = 22; // HLEN[7:0]
- }
- wValue = cpu_to_le16(pMACHeader->frame_control & 0xC78F);
- memcpy(pMICHDR+18, (u8 *)&wValue, 2); // MSKFRACTL
- memcpy(pMICHDR+20, &(pMACHeader->addr1[0]), 6);
- memcpy(pMICHDR+26, &(pMACHeader->addr2[0]), 6);
-
- //Fill MICHDR2
- memcpy(pMICHDR+32, &(pMACHeader->addr3[0]), 6);
- wValue = pMACHeader->seq_ctrl;
- wValue &= 0x000F;
- wValue = cpu_to_le16(wValue);
- memcpy(pMICHDR+38, (u8 *)&wValue, 2); // MSKSEQCTL
- if (pDevice->bLongHeader) {
- memcpy(pMICHDR+40, &(pMACHeader->addr4[0]), 6);
- }
+ if (!mic_hdr)
+ return;
+
+ /* MICHDR0 */
+ mic_hdr->id = 0x59;
+ mic_hdr->payload_len = cpu_to_be16(wPayloadLen);
+ memcpy(mic_hdr->mic_addr2, pMACHeader->addr2, ETH_ALEN);
+
+ mic_hdr->tsc_47_16 = cpu_to_be32(pTransmitKey->dwTSC47_16);
+ mic_hdr->tsc_15_0 = cpu_to_be16(pTransmitKey->wTSC15_0);
+
+ /* MICHDR1 */
+ if (pDevice->bLongHeader)
+ mic_hdr->hlen = cpu_to_be16(28);
+ else
+ mic_hdr->hlen = cpu_to_be16(22);
+
+ memcpy(mic_hdr->addr1, pMACHeader->addr1, ETH_ALEN);
+ memcpy(mic_hdr->addr2, pMACHeader->addr2, ETH_ALEN);
+
+ /* MICHDR2 */
+ memcpy(mic_hdr->addr3, pMACHeader->addr3, ETH_ALEN);
+ mic_hdr->frame_control = cpu_to_le16(pMACHeader->frame_control
+ & 0xc78f);
+ mic_hdr->seq_ctrl = cpu_to_le16(pMACHeader->seq_ctrl & 0xf);
+
+ if (pDevice->bLongHeader)
+ memcpy(mic_hdr->addr4, pMACHeader->addr4, ETH_ALEN);
}
}
@@ -1294,7 +1287,7 @@ static int s_bPacketToWirelessUsb(struct vnt_private *pDevice, u8 byPktType,
if (bNeedEncryption == true) {
//Fill TXKEY
s_vFillTxKey(pDevice, (u8 *)(pTxBufHead->adwTxKey), pbyIVHead, pTransmitKey,
- pbyMacHdr, (u16)cbFrameBodySize, (u8 *)pMICHDR);
+ pbyMacHdr, (u16)cbFrameBodySize, pMICHDR);
if (pDevice->bEnableHostWEP) {
pMgmt->sNodeDBTable[uNodeIndex].dwTSC47_16 = pTransmitKey->dwTSC47_16;
@@ -2203,7 +2196,7 @@ void vDMA0_tx_80211(struct vnt_private *pDevice, struct sk_buff *skb)
}
s_vFillTxKey(pDevice, (u8 *)(pTxBufHead->adwTxKey), pbyIVHead, pTransmitKey,
- pbyMacHdr, (u16)cbFrameBodySize, (u8 *)pMICHDR);
+ pbyMacHdr, (u16)cbFrameBodySize, pMICHDR);
if (pDevice->bEnableHostWEP) {
pMgmt->sNodeDBTable[uNodeIndex].dwTSC47_16 = pTransmitKey->dwTSC47_16;
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] mac80211: assign seqnums for group QoS frames
From: Johannes Berg @ 2013-08-23 13:44 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <1377264938-5333-1-git-send-email-me@bobcopeland.com>
On Fri, 2013-08-23 at 09:35 -0400, Bob Copeland wrote:
> According to 802.11-2012 9.3.2.10, paragraph 4, QoS
> data frames with a group address in the Address 1 field
> have sequence numbers allocated from the same counter
> as non-QoS data and management frames. Without this
> flag, some drivers may not assign sequence numbers, and
> in rare cases frames might get dropped. Set the control
> flag accordingly.
Applied (to -next), thanks.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: ignore obviously bogus ECSAs in probe response frames
From: Johannes Berg @ 2013-08-23 13:47 UTC (permalink / raw)
To: Seth Forshee; +Cc: linux-wireless, John W. Linville
In-Reply-To: <20130822141011.GA24445@thinkpad-t410>
On Thu, 2013-08-22 at 09:10 -0500, Seth Forshee wrote:
> On Thu, Aug 22, 2013 at 04:01:03PM +0200, Johannes Berg wrote:
> > On Thu, 2013-08-22 at 08:53 -0500, Seth Forshee wrote:
> > > The Netgear WNDAP360 sends invalid ECSA IEs in probe response
> > > frames
> >
> > I think we shouldn't be checking probe response frames at all. That
> > seems like a mistake. Can you try this?
>
> I had considered this, but the spec says that it's at least valid for
> the AP to be sending ECSAs in probe responses. IEEE 802.11-2012 section
> 10.3.3.2:
>
> ...an AP shall inform associated STAs that the AP is moving to a new
> channel and/or operating class and maintain the association by
> advertising the switch using Extended Channel Switch Announcement
> elements in any transmitted Beacon frames, Probe Response frames, and
> Extended Channel Switch Announcement frames until the intended channel
> switch time.
>
> Perhaps we can still ignore them though? I suppose we'd expect to
> receive some other frame with the ECSA before it actually happens.
I suppose that's to avoid clients connecting to it when they find the
AP, I don't see any reason to actually react to that in our code - we
should have picked up a beacon already anyway.
johannes
^ permalink raw reply
* [PATCH 3.11] mac80211: ignore (E)CSA in probe response frames
From: Johannes Berg @ 2013-08-23 13:52 UTC (permalink / raw)
To: linux-wireless; +Cc: seth.forshee, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Seth reports that some APs, notably the Netgear WNDAP360, send
invalid ECSA IEs in probe response frames with the operating
class and channel number both set to zero, even when no channel
switch is being done. As a result, any scan while connected to
such an AP results in the connection being dropped.
Fix this by ignoring any channel switch announcment in probe
response frames entirely, since we're connected to the AP we
will be receiving a beacon (and maybe even an action frame) if
a channel switch is done, which is sufficient.
Cc: stable@vger.kernel.org # 3.10
Reported-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index cc9e02d..7a98d52 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2851,14 +2851,6 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
ieee80211_rx_bss_put(local, bss);
sdata->vif.bss_conf.beacon_rate = bss->beacon_rate;
}
-
- if (!sdata->u.mgd.associated ||
- !ether_addr_equal(mgmt->bssid, sdata->u.mgd.associated->bssid))
- return;
-
- ieee80211_sta_process_chanswitch(sdata, rx_status->mactime,
- elems, true);
-
}
@@ -3147,6 +3139,9 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
ieee80211_rx_bss_info(sdata, mgmt, len, rx_status, &elems);
+ ieee80211_sta_process_chanswitch(sdata, rx_status->mactime,
+ &elems, true);
+
if (ieee80211_sta_wmm_params(local, sdata, elems.wmm_param,
elems.wmm_param_len))
changed |= BSS_CHANGED_QOS;
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH V3] cfg80211: vlan priority handling in WMM
From: Johannes Berg @ 2013-08-23 13:57 UTC (permalink / raw)
To: cedric.voncken; +Cc: linux-wireless
In-Reply-To: <1377092917-23411-1-git-send-email-cedric.voncken@acksys.fr>
On Wed, 2013-08-21 at 15:48 +0200, cedric.voncken@acksys.fr wrote:
> + if(vlan_tx_tag_present(skb)) {
need space
> + vlan_priority = (vlan_tx_tag_get(skb) & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
>80 cols
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: implement STA CSA for drivers using channel contexts
From: Johannes Berg @ 2013-08-23 14:01 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfeVtaxqAgWQgSsiMw8uZ6uDmEwba+T8M9-YrUNBwxvshA@mail.gmail.com>
On Fri, 2013-08-16 at 23:09 +0300, Arik Nemtsov wrote:
> > Well, it can't. If you look carefully then the old chan_switch op
> > behaviour is to let the driver switch, not switch in software
> > afterwards.
>
> The right thing for chan_switch drivers would be not to call hw_config()..
chan_switch? or chanctx?
> > Yeah but it's (currently) meant for interfaces controlling the CSA (i.e.
> > AP only right now) ... so I really think we need to make this
> > controllable, I think that when we want to implement it for Intel MVM
> > firmware then we'll let the firmware control the switch timing, etc.
> > None of this can even be done today or with your patch.
>
> The TI driver implements the chan_switch op and uses channel contexts.
Huh, ok, that was a combination I didn't think was going to exist, since
the chanswitch API doesn't really tell you what channel context etc.
OTOH, it does give you the vif so you have the chanctx implicitly.
> If I catch your drift you would rather these kind of drivers (which
> include MVM) use a new API exposed by mac80211 to complete the channel
> switch. This API would basically be ieee80211_vif_change_channel(). Do
> we still need to touch the cfg80211 chandef definition in ifmgd?
That's what I was thinking, yes.
> The above is maybe cleaner, but it's functionally equivalent to the
> solution today - the low level driver decides when the channel switch
> is completed, and ieee80211_chswitch_work() is called, which does the
> right thing for all cases.
Right ... I guess that works.
> Note that with the above, the channel_contexts + software chan-switch
> drivers will still need the kind of code that I wrote. So it would
> just lead to replicated code. Or maybe you meant something else?
We have too many possibilities I guess ... I think for MVM I want the
disconnect, not the channel context change in software. You're taking
that possibility away, hence my suggestion of a new hardware flag for it
or so.
> Also, where would you put csa_active = true (if at all) for a STA
> interface? Unlike AP, the trigger here is mac80211 code. So putting it
> there seemed appropriate.
Yeah, I was really just trying to say that current chanctx drivers need
not really expect a chanctx to change channel unless they implement CSA,
but that currently means AP-CSA - basically what I just said above with
taking away the possibility of doing the deauth instead.
johannes
^ permalink raw reply
* Re: [PATCH v14 1/2] cfg80211: add 'flags' to cfg80211_rx_mgmt()
From: Johannes Berg @ 2013-08-23 14:07 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: linux-wireless, Luis R . Rodriguez, John W . Linville,
Jouni Malinen
In-Reply-To: <1376567489-1863-2-git-send-email-qca_vkondrat@qca.qualcomm.com>
On Thu, 2013-08-15 at 14:51 +0300, Vladimir Kondratiev wrote:
> Flags intended to report various auxiliary information.
> Introduced flag NL80211_RXMGMT_FLAG_REPLIED to report
> whether frame was replied by the device/driver.
Applied, with some small changes.
johannes
^ permalink raw reply
* Re: [PATCH v14 2/2] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-08-23 14:16 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: linux-wireless, Luis R . Rodriguez, John W . Linville,
Jouni Malinen
In-Reply-To: <1376567489-1863-3-git-send-email-qca_vkondrat@qca.qualcomm.com>
On Thu, 2013-08-15 at 14:51 +0300, Vladimir Kondratiev wrote:
[...]
Generally, I think this looks good now. Some small comments:
> - configure rx management filter to get probe-request and probe-response frames
This is misleading, there's no "filter" that the supplicant can
configure. It can (and should) subscribe to these frames, but that's not
really the same thing.
> - start p2p find via driver's cfg80211_ops start_p2p_find method
> - driver start p2p find with hardware and notify wpa_supplicant with
> cfg80211_p2p_find_notify_start()
> - driver/firmware toggle search/listen states. Received probe-request and
> probe-response frames passed to the wpa_supplicant via cfg80211_rx_mgmt;
> replied by driver/firmware probe-request frames indicated with
> NL80211_RXMGMT_FLAG_REPLIED flag
ANSWERED now
> Alternatively, driver/firmware may decide to stop p2p find.
This is somewhat problematic, see below.
> All driver to user space communication done through nl80211 layer.
Well, umm, ok. That seems kinda obvious :)
> @@ -3062,6 +3116,7 @@ struct wireless_dev {
> struct mutex mtx;
>
> bool use_4addr, p2p_started;
> + bool p2p_find_active; /* protected by rtnl */
Should that really be in the wdev, i.e. is it OK to run p2p_find on
multiple wdevs of the same wiphy? That seems odd.
> +/**
> + * cfg80211_p2p_find_notify_end - report p2p find phase ended
> + * @wdev: the wireless device reporting the event
> + * @gfp: allocation flags
> + *
> + * p2p find phase may be ended either unsolicited or in response to
> + * ops->stop_p2p_find. If called out of context of ops->stop_p2p_find,
> + * should be protected with rtnl_lock()
I think this is problematic, how are drivers going to be able to
guarantee this? They'd most likely call this from some RX context if the
firmware gives up, or firmware restart context, and not really know
whether the RTNL is held or not? Then drivers will have to make it
async, but then we might just as well make it async in cfg80211, no?
Thinking about this, I'm also starting to think that requiring this to
be called when the stop_p2p_find() operation is called is pretty
pointless, as cfg80211 can just do it itself? If the driver still calls
it, it can obviously suppress the extra event.
> +void cfg80211_p2p_find_notify_end(struct wireless_dev *wdev, gfp_t gfp);
That gfp argument is also fairly useless, if you must hold the RTNL it's
likely that you're able to sleep, unless doing something 'exotic' like
rtnl_lock()
rcu_read_lock()
...
p2p_find_notify_end()
but that would be strange and not usually needed?
> + if (!wdev->p2p_find_active)
> + return -ENOENT;
> +
> + rdev_stop_p2p_find(rdev, wdev);
Here you could do something like
if p2p_find_active
send_event()
p2p_find_active = false
so drivers don't have to call it?
> +void cfg80211_p2p_find_notify_end(struct wireless_dev *wdev, gfp_t gfp)
> +{
> + ASSERT_RTNL();
In fact, ASSERT_RTNL() can only be called when able to sleep, because it
attempts to lock or so ... unless that changed to lockdep recently?
Ilan also pointed out to me that it might be necessary to document (and
enforce?) that scan/sched_scan can't be executed in parallel? Or can
they?
johannes
^ permalink raw reply
* Re: [PATCH net-next 06/10] net: airo: inherit addr_assign_type along with dev_addr
From: John W. Linville @ 2013-08-23 14:53 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-wireless
In-Reply-To: <1377250513-3662-7-git-send-email-bjorn@mork.no>
On Fri, Aug 23, 2013 at 11:35:09AM +0200, Bjørn Mork wrote:
> Cc: "John W. Linville" <linville@tuxdriver.com>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
> drivers/net/wireless/airo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> index d0adbaf..7fe1964 100644
> --- a/drivers/net/wireless/airo.c
> +++ b/drivers/net/wireless/airo.c
> @@ -2693,7 +2693,7 @@ static struct net_device *init_wifidev(struct airo_info *ai,
> dev->base_addr = ethdev->base_addr;
> dev->wireless_data = ethdev->wireless_data;
> SET_NETDEV_DEV(dev, ethdev->dev.parent);
> - memcpy(dev->dev_addr, ethdev->dev_addr, dev->addr_len);
> + eth_hw_addr_inherit(dev, ethdev);
> err = register_netdev(dev);
> if (err<0) {
> free_netdev(dev);
> --
> 1.7.10.4
Acked-by: "John W. Linville" <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next 08/10] net: libertas: inherit addr_assign_type along with dev_addr
From: John W. Linville @ 2013-08-23 14:52 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, libertas-dev, linux-wireless
In-Reply-To: <1377250513-3662-9-git-send-email-bjorn@mork.no>
On Fri, Aug 23, 2013 at 11:35:11AM +0200, Bjørn Mork wrote:
> Cc: "John W. Linville" <linville@tuxdriver.com>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> ---
> drivers/net/wireless/libertas/mesh.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/libertas/mesh.c b/drivers/net/wireless/libertas/mesh.c
> index efae07e..6fef746 100644
> --- a/drivers/net/wireless/libertas/mesh.c
> +++ b/drivers/net/wireless/libertas/mesh.c
> @@ -1017,7 +1017,7 @@ static int lbs_add_mesh(struct lbs_private *priv)
>
> mesh_dev->netdev_ops = &mesh_netdev_ops;
> mesh_dev->ethtool_ops = &lbs_ethtool_ops;
> - memcpy(mesh_dev->dev_addr, priv->dev->dev_addr, ETH_ALEN);
> + eth_hw_addr_inherit(mesh_dev, priv->dev);
>
> SET_NETDEV_DEV(priv->mesh_dev, priv->dev->dev.parent);
>
> --
> 1.7.10.4
>
>
Acked-by: "John W. Linville" <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ 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