* Re: [PATCHv2 1/3] mac80211: fix CMD_FRAME for AP_VLAN
From: Johannes Berg @ 2016-10-12 7:12 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1475493257-21841-1-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-03 at 13:14 +0200, Michael Braun wrote:
> When using IEEE 802.11r FT OVER-DS roaming with AP_VLAN, hostapd
> needs to
> send out a frame using CMD_FRAME for a station assigned to an AP_VLAN
> interface.
>
> Right now, the userspace needs to give the exact AP_VLAN interface
> index
> for CMD_FRAME; hostapd does not do this. Additionally, userspace
> cannot
> use GET_STATION to query the AP_VLAN ifidx, as while GET_STATION
> finds
> stations assigned to AP_VLAN even if the AP iface is queried, it does
> not
> return AP_VLAN ifidx (it returns the queried one).
>
> This breaks IEEE 802.11r over_ds with vlans, as the reply frame does
> not
> get out. This patch fixes this by using get_sta_bss for CMD_FRAME.
>
Applied, thanks.
johannes
^ permalink raw reply
* [PATCH] ath10k: Fix failure to send NULL func frame for 10.4
From: Mohammed Shafi Shajakhan @ 2016-10-12 7:29 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
This partially reverts 'commit 2cdce425aa33
("ath10k: Fix broken NULL func data frame status for 10.4")'
Unfortunately this breaks sending NULL func and the existing
issue of obtaining proper tx status for NULL function will be
fixed. Also update the comments for feature flag added to be
useless and not working
Fixes: 2cdce425aa33 "ath10k: Fix broken NULL func data frame status for
10.4"
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.h | 6 ++----
drivers/net/wireless/ath/ath10k/mac.c | 2 --
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index b367e9c..42c3f1b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -552,10 +552,8 @@ enum ath10k_fw_features {
*/
ATH10K_FW_FEATURE_BTCOEX_PARAM = 14,
- /* Older firmware with HTT delivers incorrect tx status for null func
- * frames to driver, but this fixed in 10.2 and 10.4 firmware versions.
- * Also this workaround results in reporting of incorrect null func
- * status for 10.4. This flag is used to skip the workaround.
+ /* Unused flag and proven to be not working, enable this if you want
+ * to experiment sending NULL func data frames in HTT TX
*/
ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR = 15,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 4565321..86a6610 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3255,8 +3255,6 @@ ath10k_mac_tx_h_get_txmode(struct ath10k *ar,
if (ar->htt.target_version_major < 3 &&
(ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) &&
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX,
- ar->running_fw->fw_file.fw_features) &&
- !test_bit(ATH10K_FW_FEATURE_SKIP_NULL_FUNC_WAR,
ar->running_fw->fw_file.fw_features))
return ATH10K_HW_TXRX_MGMT;
--
1.9.1
^ permalink raw reply related
* Re: [v2,1/2] ath10k: clean up HTT tx buffer allocation and free
From: Valo, Kalle @ 2016-10-12 7:35 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <20161012070918.GA2993@atheros-ThinkPad-T61>
Mohammed Shafi Shajakhan <mohammed@codeaurora.org> writes:
> Hi Kalle,
>
> On Tue, Oct 11, 2016 at 01:36:22PM +0200, Kalle Valo wrote:
>> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
>> > From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>> >=20
>> > cleanup 'ath10k_htt_tx_alloc' by introducing the API's
>> > 'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
>> > re-use them whereever needed
>> >=20
>> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>>=20
>> Applies but fails to build:
>
> [shafi] sorry for the trouble again, I just figured out I had a private p=
atch by
> mistake and it worked for me, I will make sure that v3 is properly rebas=
ed
> without any errors.
Thanks. And no worries, I now have a script which does commit and build
tests semi-automatically and sends an email if it fails. Yay! This was a
good real life test for the script :)
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCHv3 2/3] mac80211: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-10-12 7:16 UTC (permalink / raw)
To: Michael Braun
Cc: linux-wireless, projekt-wlan, kvalo, akarwar, nishants,
Larry.Finger, Jes.Sorensen
In-Reply-To: <1475493257-21841-2-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-03 at 13:14 +0200, Michael Braun wrote:
> When using WPA security, the station and thus the required key is
> identified by its mac address when packets are received. So a
> station usually cannot spoof its source mac address.
>
> But when a station sends an A-MSDU frame, port control and crypto
> is done using the outer mac address, while the packets delivered
> and forwarded use the inner mac address.
> This might affect ARP/IP filtering on the AccessPoint.
>
> IEEE 802.11-2012 mandates that the outer source mac address should
> match the inner source address (section 8.3.2.2). For the destination
> mac address, matching is not required, as a wifi client may send all
> its traffic to the AP in order to have it forwarded.
This doesn't apply over my series now, so I'm dropping it - I have the
bare minimum mwifiex changes to let it compile, but no additional
checks.
Marvell folks: take note, you'll want to have these checks in your
driver, so need to pass the right check_da/check_sa arguments
(depending on the interface type) to the function. See
https://git.kernel.org/cgit/linux/kernel/git/jberg/mac80211.git/commit/?id=002a02b6d1be6aba55c7391a030c0358fada81c5
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-12 7:57 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476258794.5271.12.camel@sipsolutions.net>
On Wed, 2016-10-12 at 09:53 +0200, Johannes Berg wrote:
> On Mon, 2016-10-10 at 18:52 +0200, Michael Braun wrote:
> >
> > According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer
> > SA/DA of A-MSDU frames need to be changed depending on FromDS/ToDS
> > values.
>
> "Need to" is perhaps a bit strongly worded, but whatever :)
>
> I was going to write a long reply and whatever - but I think that's
> all moot. As far as I can tell, you got this completely wrong, as
> you're changing the *inner* headers, not the *outer* header as you
> should?
Oh, no, my mistake - this happens before 802.3->.11 conversion.
So this does look correct, but I don't like that you write to
amsdu_hdr.h_{source,dest} twice after the patch.
I think you should have da and sa variables and set those, and then
memcpy only once.
johannes
^ permalink raw reply
* Re: Revert "rtlwifi: rtl818x: constify local structures"
From: Kalle Valo @ 2016-10-12 8:00 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Larry Finger, Stable, Julia Lawall
In-Reply-To: <20161010152520.9812-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> This reverts commit d86e64768859fca82c78e52877ceeba04e25d27a.
>
> For drivers rtl8188ee, rtl8192ce, rtl8192ee, rtl8723ae, and rtl8821ae,
> the Coccinelle script missed the fact that the code changes the firmware
> name. When that happens, the kernel issues a BUG splat because
> it is unable to overwrite the old name.
>
> Although this bug only affects 5 of the 8 drivers it touched, I decided to
> revert the entire patch. Continuing to constantify the other three could
> too easily lead to introduction of future bugs.
>
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Dropping as requested.
Patch set to Superseded.
--
https://patchwork.kernel.org/patch/9369621/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix regression caused by commit d86e64768859
From: Kalle Valo @ 2016-10-12 7:53 UTC (permalink / raw)
To: Larry Finger
Cc: devel, linux-wireless, Stable [ 4 . 8+ ], Julia Lawall,
Thorsten Leemhuis
In-Reply-To: <20161010233211.13519-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
> the configuration struct for most of the drivers was changed to be
> constant. The problem is that five of the modified drivers need to be
> able to update the firmware name based on the exact model of the card.
> As the file names were stored in one of the members of that struct,
> these drivers would fail with a kernel BUG splat when they tried to
> update the firmware name.
>
> Rather than reverting the previous commit, I used a suggestion by
> Johannes Berg and made the firmware file name pointers be local to
> the routines that update the software variables.
>
> The configuration struct of rtl8192cu, which was not touched in the
> previous patch, is now constantfied.
>
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable [4.8+] <stable@vger.kernel.org>
This should be:
Cc: Stable <stable@vger.kernel.org> # 4.8
And the plus sign isn't needed as I'll push this to 4.9.
> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
> ---
> Kalle,
>
> My apologies for letting these bugs to get by my review and testing.
No worries, this is business as usual :) Excellent that you noticed this
so early.
And this again shows that simple cleanup patches are not without cost,
there is a clear risk. Has anyone done any statistics how much cleanup
patches cause regressions? My guess is that in a 5% ballpark of the
cleanup patches have some sort of issues. Of course in this case the
cleanup patch revealed a design flaw in the driver, so in this case it
was very useful.
> As they affect kernel 4.8, please push this patch as soon as possible.
> To reiterate, this patch replaces the one entitled 'Revert "rtlwifi:
> rtl818x: constify local structures"'
Ok, understood. Many thanks for making this super clear for me, makes my
life a lot easier. I'm hoping that this will make it to 4.9-rc2.
CCing Thorsten to get this regression to his radar.
--
Kalle Valo
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Arend Van Spriel @ 2016-10-12 8:11 UTC (permalink / raw)
To: Jörg Krause
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <F306F99A-DCEC-4C28-8805-AE0BA50D485F@embedded.rocks>
On 11-10-2016 8:14, Jörg Krause wrote:
>
>
> Hi Arend,
>
> Am 22. September 2016 16:00:36 MESZ, schrieb Arend Van Spriel <arend.vanspriel@broadcom.com>:
>> Op 22 sep. 2016 14:52 schreef "Jörg Krause"
>> <joerg.krause@embedded.rocks>:
>>>
>>> On Do, 2016-09-22 at 10:09 +0200, Arend Van Spriel wrote:
>>>> On 19-9-2016 8:36, Jörg Krause wrote:
>>>>>
>>>>> Hi Arend,
>>>>>
>>>>> On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
>>>>>>
>>>>>> On 14-9-2016 15:41, Jörg Krause wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 22-8-2016 15:37, Jörg Krause wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I am back from vacation and I'd like to do more
>>>>>>>>>> investigations
>>>>>>>>>> about
>>>>>>>>>> this issue. Please see my comments below...
>>>>>>>>>>
>>>>>>>>>> On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 06-08-16 16:12, Jörg Krause wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> A bit weird email format making it a bit hard to
>>>>>>>>>>> determine
>>>>>>>>>>> where
>>>>>>>>>>> your
>>>>>>>>>>> last reply starts...
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause
>>>>>>>>>>>> <joerg.krause
>>>>>>>>>>>> @emb
>>>>>>>>>>>> ed
>>>>>>>>>>>> ded.
>>>>>>>>>>>> ro
>>>>>>>>>>>> cks>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van
>>>>>>>>>>>> Spriel
>>>>>>>>>>>> <
>>>>>>>>>>>> arend.vanspriel@broadcom.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Op 5 aug. 2016 22:46 schreef "Jörg Krause"
>>>>>>>>>>>> <joerg.krause@embedded.rocks>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm using a custom ARM board with an BCM43362 wifi
>>>>>>>>>>>> chip
>>>>>>>>>>>> from
>>>>>>>>>>>>
>>>>>>>>>>>> Broadcom.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The wifi chip is attached via SDIO to the
>> controller
>>>>>>>>>>>> with
>>>>>>>>>>>> a
>>>>>>>>>>>> clock of
>>>>>>>>>>>> 48MHz. Linux kernel version is 4.7.
>>>>>>>>>>>>
>>>>>>>>>>>> When measuring the network bandwidth with iperf3 I
>>>>>>>>>>>> get a
>>>>>>>>>>>> bandwith of
>>>>>>>>>>>> only around 5 Mbps. I found a similar thread at the
>>>>>>>>>>>> Broadcom
>>>>>>>>>>>>
>>>>>>>>>>>> community
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [1] where the test was done with a M4 CPU +
>> BCM43362
>>>>>>>>>>>> and
>>>>>>>>>>>> an
>>>>>>>>>>>> average
>>>>>>>>>>>> result of 3.3 Mbps.
>>>>>>>>>>>>
>>>>>>>>>>>> Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a
>>>>>>>>>>>> TCP
>>>>>>>>>>>> data
>>>>>>>>>>>>
>>>>>>>>>>>> throughput
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> greater than 20 Mbps.
>>>>>>>>>>>>
>>>>>>>>>>>> Why is the throughput I measured much lower? Note
>>>>>>>>>>>> that I
>>>>>>>>>>>> measured
>>>>>>>>>>>> several times with almost no neighbor devices or
>>>>>>>>>>>> networks.
>>>>>>>>>>>>
>>>>>>>>>>>> This is a test sample measured with iperf3:
>>>>>>>>>>>>
>>>>>>>>>>>> $ iperf3 -c 192.168.2.1 -i 1 -t 10
>>>>>>>>>>>> Connecting to host 192.168.2.1, port 5201
>>>>>>>>>>>> [ 4] local 192.168.2.155 port 36442 connected
>> to
>>>>>>>>>>>> 192.168.2.1
>>>>>>>>>>>>
>>>>>>>>>>>> port
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 5201
>>>>>>>>>>>> [ ID]
>>>>>>>>>>>> Interval Transfer Bandwidth
>> Retr
>>>>>>>>>>>> Cwn
>>>>>>>>>>>> d
>>>>>>>>>>>> [ 4] 0.00-1.00 sec 615 KBytes 5.04
>>>>>>>>>>>> Mbits/sec 0 56.6
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 1.00-2.00 sec 622 KBytes 5.10
>>>>>>>>>>>> Mbits/sec 0 84.8
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 2.00-3.00 sec 625 KBytes 5.12
>>>>>>>>>>>> Mbits/sec 0 113
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 3.00-4.00 sec 571 KBytes 4.68
>>>>>>>>>>>> Mbits/sec 0 140
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 4.00-5.00 sec 594 KBytes 4.87
>>>>>>>>>>>> Mbits/sec 0 167
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 5.00-6.00 sec 628 KBytes 5.14
>>>>>>>>>>>> Mbits/sec 0 195
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 6.00-7.00 sec 619 KBytes 5.07
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 7.00-8.00 sec 608 KBytes 4.98
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 8.00-9.00 sec 602 KBytes 4.93
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> [ 4] 9.00-10.00 sec 537 KBytes 4.40
>>>>>>>>>>>> Mbits/sec 0 202
>>>>>>>>>>>> KBytes
>>>>>>>>>>>> - - - - - - - - - - - - - - - - - - - - - - - -
>> -
>>>>>>>>>>>> [ ID]
>>>>>>>>>>>> Interval Transfer Bandwidth
>> Retr
>>>>>>>>>>>> [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
>>>>>>>>>>>> Mbits/sec 0 sender
>>>>>>>>>>>> [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
>>>>>>>>>>>> Mbits/sec receiver
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not overly familiar with iperf3. Do these lines
>> mean
>>>>>>>>>>>> you
>>>>>>>>>>>> are
>>>>>>>>>>>> doing
>>>>>>>>>>>> bidirectional test, ie. upstream and downstream at
>>>>>>>>>>>> the
>>>>>>>>>>>> same
>>>>>>>>>>>> time.
>>>>>>>>>>>> Another
>>>>>>>>>>>> thing affecting tput could be power-save.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, iperf3 does not support bidrectional test.
>> Power-
>>>>>>>>>>>> save
>>>>>>>>>>>> is
>>>>>>>>>>>> turned
>>>>>>>>>>>> off.
>>>>>>>>>>>>
>>>>>>>>>>>> What does iw link say?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> but I guess it starts here!
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I compared the results with a Cubietruck I have:
>>>>>>>>>>>>
>>>>>>>>>>>> # iperf3 -s
>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>> ----
>>>>>>>>>>>> ----
>>>>>>>>>>>> Server listening on 5201
>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>> ----
>>>>>>>>>>>> ----
>>>>>>>>>>>> Accepted connection from 192.168.178.46, port 42906
>>>>>>>>>>>> [ 5] local 192.168.178.38 port 5201 connected to
>>>>>>>>>>>> 192.168.178.46
>>>>>>>>>>>> port
>>>>>>>>>>>> 42908
>>>>>>>>>>>> [ ID] Interval Transfer Bandwidth
>>>>>>>>>>>> [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
>>>>>>>>>>>> Mbits/sec
>>>>>>>>>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>>>>>>>>> [ ID]
>>>>>>>>>>>> Interval Transfer Bandwidth
>> Retr
>>>>>>>>>>>> [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
>>>>>>>>>>>> Mbits/sec 0 sender
>>>>>>>>>>>> [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
>>>>>>>>>>>> Mbits/sec receiver
>>>>>>>>>>>>
>>>>>>>>>>>> # iw dev wlan0 link
>>>>>>>>>>>> Connected to xx:xx:xx:xx:xx (on wlan0)
>>>>>>>>>>>> SSID: xxx
>>>>>>>>>>>> freq: 2437
>>>>>>>>>>>> tx bitrate: 65.0 MBit/s
>>>>>>>>>>>>
>>>>>>>>>>>> bss flags: short-preamble short-slot-
>>>>>>>>>>>> time
>>>>>>>>>>>> dtim period: 1
>>>>>>>>>>>> beacon int: 100
>>>>>>>>>>>
>>>>>>>>>>> Too bad RSSI is not in the output above. That may be
>>>>>>>>>>> due to
>>>>>>>>>>> a
>>>>>>>>>>> regression
>>>>>>>>>>> in our driver which has been fixed by commit
>>>>>>>>>>> 94abd778a7bb
>>>>>>>>>>> ("brcmfmac:
>>>>>>>>>>> add fallback for devices that do not report per-chain
>>>>>>>>>>> values").
>>>>>>>>>>> However,
>>>>>>>>>>> the tx bitrate seems within the same range as the
>> other
>>>>>>>>>>> platform.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The Cubietruck works also with the brcmfmac driver.
>>>>>>>>>>>>
>>>>>>>>>>>> May it depend on the NVRAM file?
>>>>>>>>>>>
>>>>>>>>>>> Not sure. Can you tell me a bit more about the custom
>>>>>>>>>>> ARM
>>>>>>>>>>> board.
>>>>>>>>>>> Does
>>>>>>>>>>> it
>>>>>>>>>>> use the same wifi module as Cubietruck, ie. the AMPAK
>>>>>>>>>>> AP6210?
>>>>>>>>>>> If
>>>>>>>>>>> you
>>>>>>>>>>> can
>>>>>>>>>>> make a wireshark sniff we can check the actual
>> bitrate
>>>>>>>>>>> and
>>>>>>>>>>> medium
>>>>>>>>>>> density in terms of packets. Another thing to look at
>>>>>>>>>>> is
>>>>>>>>>>> the
>>>>>>>>>>> SDIO
>>>>>>>>>>> host
>>>>>>>>>>> controller. In brcmf_sdiod_sgtable_alloc() some key
>>>>>>>>>>> values
>>>>>>>>>>> are
>>>>>>>>>>> used
>>>>>>>>>>> from
>>>>>>>>>>> the host controller. It only logs the number of
>> entries
>>>>>>>>>>> of
>>>>>>>>>>> the
>>>>>>>>>>> scatter-gather table, but could you add the other
>>>>>>>>>>> values in
>>>>>>>>>>> this
>>>>>>>>>>> function that are used to determine the number of
>>>>>>>>>>> entries.
>>>>>>>>>>
>>>>>>>>>> My board uses the BCM43362 chip solely (no Bluetooth)
>>>>>>>>>> attached to
>>>>>>>>>> the
>>>>>>>>>> SDIO interface of a NXP i.MX28 processor.
>>>>>>>>>>
>>>>>>>>>> I added some additional printk() to
>>>>>>>>>> brcmf_sdiod_sgtable_alloc().
>>>>>>>>>> These
>>>>>>>>>> are the values printed after modprobe brcmfmac:
>>>>>>>>>>
>>>>>>>>>> [ 8.926657] sg_support=1
>>>>>>>>>> [ 8.929440] max_blocks=511
>>>>>>>>>> [ 8.932213] max_request_size=261632
>>>>>>>>>> [ 8.935741] max_segment_count=52
>>>>>>>>>> [ 8.939005] max_segment_size=65280
>>>>>>>>>> [ 8.946095] nents=35
>>>>>>>>>
>>>>>>>>> Thanks. That looks good.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Additionally I attached a xz compresses wireshark sniff
>>>>>>>>>> while
>>>>>>>>>> running
>>>>>>>>>> iper3 between the BCM43362 running as in AP mode with
>>>>>>>>>> iperf3
>>>>>>>>>> as a
>>>>>>>>>> server and a PC in station mode running iperf3 as a
>>>>>>>>>> client.
>>>>>>>>>
>>>>>>>>> Looking at the sniff it seems you captured on the
>> ethernet
>>>>>>>>> side.
>>>>>>>>> That
>>>>>>>>> does not give me any 802.11 specific info. Can you make a
>>>>>>>>> wireless
>>>>>>>>> capture preferably without encryption.
>>>>>>>>
>>>>>>>> You,re right! Sorry for this mistake. I did a re-capture on
>>>>>>>> the
>>>>>>>> wireless side now.
>>>>>>>
>>>>>>> Anything new about this? Anything I can do to help?
>>>>>>
>>>>>> I missed your previous email. Was already wondering whether to
>>>>>> ping
>>>>>> you.
>>>>>> Digging around in my email folders I found it so will take a
>> look
>>>>>> at
>>>>>> it.
>>>>>
>>>>> Did you had some time to look at this?
>>>>
>>>> Ehm. I still only see TCP stuff. To capture 802.11 management
>> frames
>>>> you
>>>> need preferably a dedicated device using monitor mode [1].
>>>
>>> Stupid me! Now I used a monitor interface on a desktop to monitor the
>>> traffic between the BCM43362 operating in soft-AP mode and a notebook
>>> operating in managed mode.
>>>
>>> The BCM43362 runs the iperf server, the notebook the iperf client.
>>
>> Thanks.
>>
>> Week almost through so might next week.
>
> Did you had some time to look at this?
So the bcm43362 is your AP and running iperf server. What specs does the
ARM on your custom board have? The trace shows that it does not do
aggregation. What it does not show is whether A-MPDU was setup, ie.
ADDBA message exchange. So could you create a similar capture including
connection setup, ie. AUTH/ASSOC, etc.
Just to confirm. You are using the firmware from linux-firmware, right?
Or are you using firmware from the wiced dev kit?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-12 7:53 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476118360-29009-1-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-10 at 18:52 +0200, Michael Braun wrote:
> According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer
> SA/DA of A-MSDU frames need to be changed depending on FromDS/ToDS
> values.
"Need to" is perhaps a bit strongly worded, but whatever :)
I was going to write a long reply and whatever - but I think that's all
moot. As far as I can tell, you got this completely wrong, as you're
changing the *inner* headers, not the *outer* header as you should?
johannes
^ permalink raw reply
* [bug report] mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue
From: Dan Carpenter @ 2016-10-12 6:14 UTC (permalink / raw)
To: toke; +Cc: linux-wireless
Hello Toke Høiland-Jørgensen,
This is a semi-automatic email about new static checker warnings.
The patch bb42f2d13ffc: "mac80211: Move reorder-sensitive TX handlers
to after TXQ dequeue" from Sep 22, 2016, leads to the following
Smatch complaint:
net/mac80211/tx.c:3242 ieee80211_xmit_fast_finish()
error: we previously assumed 'key' could be null (see line 3209)
net/mac80211/tx.c
3208
3209 if (key)
^^^
Check.
3210 info->control.hw_key = &key->conf;
3211
3212 ieee80211_tx_stats(skb->dev, skb->len);
3213
3214 if (hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_QOS_DATA)) {
3215 tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
3216 *ieee80211_get_qos_ctl(hdr) = tid;
3217 hdr->seq_ctrl = ieee80211_tx_next_seq(sta, tid);
3218 } else {
3219 info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
3220 hdr->seq_ctrl = cpu_to_le16(sdata->sequence_number);
3221 sdata->sequence_number += 0x10;
3222 }
3223
3224 if (skb_shinfo(skb)->gso_size)
3225 sta->tx_stats.msdu[tid] +=
3226 DIV_ROUND_UP(skb->len, skb_shinfo(skb)->gso_size);
3227 else
3228 sta->tx_stats.msdu[tid]++;
3229
3230 info->hw_queue = sdata->vif.hw_queue[skb_get_queue_mapping(skb)];
3231
3232 /* statistics normally done by ieee80211_tx_h_stats (but that
3233 * has to consider fragmentation, so is more complex)
3234 */
3235 sta->tx_stats.bytes[skb_get_queue_mapping(skb)] += skb->len;
3236 sta->tx_stats.packets[skb_get_queue_mapping(skb)]++;
3237
3238 if (pn_offs) {
^^^^^^^
Maybe when pn_offs is non-zero that implies key is non-NULL?
3239 u64 pn;
3240 u8 *crypto_hdr = skb->data + pn_offs;
3241
3242 switch (key->conf.cipher) {
^^^^^
Unchecked dereference.
3243 case WLAN_CIPHER_SUITE_CCMP:
3244 case WLAN_CIPHER_SUITE_CCMP_256:
regards,
dan carpenter
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-12 9:05 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andy Lutomirski, David S. Miller, linux-wireless, netdev,
linux-kernel, Sergey Senozhatsky, linux-next, Stephen Rothwell,
Herbert Xu
In-Reply-To: <20161010153050.GA836@swordfish>
Hi,
Sorry - I meant to look into this yesterday but forgot.
> Andy, can this be related to CONFIG_VMAP_STACK?
I think it is.
> > current -git kills my system.
Can you elaborate on how exactly it kills your system?
> > adding
> >
> > if (!virt_addr_valid(&aad[2])) {
> > WARN_ON(1);
> > return -EINVAL;
> > }
That's pretty obviously false with VMAP_STACK, since the caller
(ieee80211_crypto_ccmp_decrypt) puts the aad on the stack. b_0 is also
on the stack, but maybe that doesn't matter.
Herbert, do you know what could cause this, and how we should fix it?
We can't really afford to do an allocation here, and we don't have
space in the skb (not even in skb->cb at that point), so if we really
have no way to continue using the stack we'd ... not sure, use a per-
CPU buffer perhaps.
We need 32 bytes for aad and 16 bytes for b_0, if that also can't be on
the stack any more.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: enable to inject a-msdu frames using monitor interface
From: Johannes Berg @ 2016-10-12 7:33 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476118105-7641-1-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-10 at 18:48 +0200, Michael Braun wrote:
> Problem: When injecting an A-MSDU using a PF_PACKET socket, the qos
> flag
> IEEE80211_QOS_CTL_A_MSDU_PRESENT is cleared.
>
> How to reproduce: Inject a frame on a mac80211 hwsim monitor
> interface and
> have tshark sniffing on this monitor interface.
> You'll see the packet twice: Once with correct flag and once with
> flag
> cleared. On hwsim0, you'll only see the packet with a cleared flag.
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
> ---
> net/mac80211/wme.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
> index 9eb0aee..f6a708c 100644
> --- a/net/mac80211/wme.c
> +++ b/net/mac80211/wme.c
> @@ -248,6 +248,11 @@ void ieee80211_set_qos_hdr(struct
> ieee80211_sub_if_data *sdata,
> /* preserve EOSP bit */
> ack_policy = *p & IEEE80211_QOS_CTL_EOSP;
>
> + /* preserve A-MSDU bit for MONITOR interfaces to allow
> injecting
> + * A-MSDU frames
> + */
> + ack_policy |= *p & IEEE80211_QOS_CTL_A_MSDU_PRESENT;
Conceptually this seems OK, though I'd probably make some adjustments
to the commit log.
However, re-reading *p looks strange to me. Why don't we just refactor
this to preserve everything but the TID and ACK policy, after all, we
have just previous created this all zeroed in most cases, so it won't
really matter.
Like this:
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index f6a708c67219..3e3d3014e9ab 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -236,31 +236,35 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_hdr *hdr = (void *)skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ u8 tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
+ u8 flags;
u8 *p;
- u8 ack_policy, tid;
if (!ieee80211_is_data_qos(hdr->frame_control))
return;
p = ieee80211_get_qos_ctl(hdr);
- tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- /* preserve EOSP bit */
- ack_policy = *p & IEEE80211_QOS_CTL_EOSP;
+ /* set up the first byte */
- /* preserve A-MSDU bit for MONITOR interfaces to allow injecting
- * A-MSDU frames
+ /*
+ * preserve everything but the TID and ACK policy
+ * (which we both write here)
*/
- ack_policy |= *p & IEEE80211_QOS_CTL_A_MSDU_PRESENT;
+ flags = *p & ~(IEEE80211_QOS_CTL_TID_MASK |
+ IEEE80211_QOS_CTL_ACK_POLICY_MASK);
if (is_multicast_ether_addr(hdr->addr1) ||
sdata->noack_map & BIT(tid)) {
- ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
+ flags |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
info->flags |= IEEE80211_TX_CTL_NO_ACK;
}
- /* qos header is 2 bytes */
- *p++ = ack_policy | tid;
+ *p = flags | tid;
+
+ /* set up the second byte */
+ p++;
+
if (ieee80211_vif_is_mesh(&sdata->vif)) {
/* preserve RSPI and Mesh PS Level bit */
*p &= ((IEEE80211_QOS_CTL_RSPI |
johannes
^ permalink raw reply related
* Re: [PATCH] cfg80211: Create structure for combination check/iter function parameters
From: Johannes Berg @ 2016-10-12 8:55 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath
In-Reply-To: <1476101219-29599-1-git-send-email-pkushwah@qti.qualcomm.com>
On Mon, 2016-10-10 at 17:36 +0530, Purushottam Kushwaha wrote:
> Move growing parameter list to a structure for check/iter combination
> functions in cfg80211 and mac80211.
Looking at this, and how it changes brcmfmac, I'd prefer you did this
as the first patch in the series so we only have to touch that once.
Also, for the conversions, consider C99 initializers instead of the
memset() and setting values.
Then perhaps we can also consider squashing the first and third patch,
but let's keep them separate for now.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: enable to inject a-msdu frames using monitor interface
From: michael-dev @ 2016-10-12 11:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476257614.5271.8.camel@sipsolutions.net>
Am 12.10.2016 09:33, schrieb Johannes Berg:
> However, re-reading *p looks strange to me. Why don't we just refactor
> this to preserve everything but the TID and ACK policy, after all, we
> have just previous created this all zeroed in most cases, so it won't
> really matter.
Looks good to me.
I've re-run the amsdu spoofing hwsim test as it includes an amsdu
injection test and as expected it still works.
Regards,
M. Braun
^ permalink raw reply
* [PATCH v2] mac80211: fix A-MSDU outer SA/DA
From: Michael Braun @ 2016-10-12 10:57 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan
According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer SA/DA
of A-MSDU frames need to be changed depending on FromDS/ToDS values.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--
v2:
- avoid the extra write to amsdu_hdr
- avoid copy of asmdu_hdr into skb, use ptr instead
---
net/mac80211/tx.c | 45 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5023966..ebd2aa6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3046,11 +3046,12 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
struct ieee80211_local *local = sdata->local;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr;
- struct ethhdr amsdu_hdr;
+ struct ethhdr *amsdu_hdr;
int hdr_len = fast_tx->hdr_len - sizeof(rfc1042_header);
int subframe_len = skb->len - hdr_len;
void *data;
u8 *qc;
+ const u8 *src_addr, *dst_addr, *bssid;
if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
return false;
@@ -3058,19 +3059,45 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
if (info->control.flags & IEEE80211_TX_CTRL_AMSDU)
return true;
- if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(amsdu_hdr),
+ if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr),
&subframe_len))
return false;
- amsdu_hdr.h_proto = cpu_to_be16(subframe_len);
- memcpy(amsdu_hdr.h_source, skb->data + fast_tx->sa_offs, ETH_ALEN);
- memcpy(amsdu_hdr.h_dest, skb->data + fast_tx->da_offs, ETH_ALEN);
+ data = skb_push(skb, sizeof(*amsdu_hdr));
+ memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
+ hdr = data;
+ amsdu_hdr = data + hdr_len;
+
+ /* according to IEEE 802.11-2012 8.3.2 table 8-19, the outer SA/DA
+ * fields needs to be changed to BSSID for A-MSDU frames depending
+ * on FromDS/ToDS values.
+ */
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
+ bssid = sdata->u.mgd.bssid;
+ break;
+ case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_AP_VLAN:
+ bssid = sdata->vif.addr;
+ break;
+ default:
+ bssid = NULL;
+ }
+
+ if (bssid && ieee80211_has_fromds(hdr->frame_control))
+ src_addr = bssid;
+ else
+ src_addr = skb->data + fast_tx->sa_offs;
+
+ if (bssid && ieee80211_has_tods(hdr->frame_control))
+ dst_addr = bssid;
+ else
+ dst_addr = skb->data + fast_tx->da_offs;
- data = skb_push(skb, sizeof(amsdu_hdr));
- memmove(data, data + sizeof(amsdu_hdr), hdr_len);
- memcpy(data + hdr_len, &amsdu_hdr, sizeof(amsdu_hdr));
+ amsdu_hdr->h_proto = cpu_to_be16(subframe_len);
+ memcpy(amsdu_hdr->h_source, src_addr, ETH_ALEN);
+ memcpy(amsdu_hdr->h_dest, dst_addr, ETH_ALEN);
- hdr = data;
qc = ieee80211_get_qos_ctl(hdr);
*qc |= IEEE80211_QOS_CTL_A_MSDU_PRESENT;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v6 2/4] mac80211: filter multicast data packets on AP / AP_VLAN
From: Johannes Berg @ 2016-10-12 12:16 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, netdev
In-Reply-To: <1476119543-24509-2-git-send-email-michael-dev@fami-braun.de>
On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote:
> This patch adds filtering for multicast data packets on AP_VLAN
> interfaces
>
[...]
Applied patches 1 and 2 for now, I'll look at the others again later.
johannes
^ permalink raw reply
* [PATCH] mac80211: preserve more bits when building QoS header
From: Johannes Berg @ 2016-10-12 12:19 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Michael Braun reported that when trying to inject A-MSDUs over
monitor interfaces, the frame doesn't come out right since the
QoS header A-MSDU bit is overwritten.
Rather than adding that bit specifically simply preserve those
bits that we don't set here, since we typically get here with
a zeroed-out QoS header anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/wme.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index 9eb0aee9105b..3e3d3014e9ab 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -236,26 +236,35 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
{
struct ieee80211_hdr *hdr = (void *)skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ u8 tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
+ u8 flags;
u8 *p;
- u8 ack_policy, tid;
if (!ieee80211_is_data_qos(hdr->frame_control))
return;
p = ieee80211_get_qos_ctl(hdr);
- tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- /* preserve EOSP bit */
- ack_policy = *p & IEEE80211_QOS_CTL_EOSP;
+ /* set up the first byte */
+
+ /*
+ * preserve everything but the TID and ACK policy
+ * (which we both write here)
+ */
+ flags = *p & ~(IEEE80211_QOS_CTL_TID_MASK |
+ IEEE80211_QOS_CTL_ACK_POLICY_MASK);
if (is_multicast_ether_addr(hdr->addr1) ||
sdata->noack_map & BIT(tid)) {
- ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
+ flags |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
info->flags |= IEEE80211_TX_CTL_NO_ACK;
}
- /* qos header is 2 bytes */
- *p++ = ack_policy | tid;
+ *p = flags | tid;
+
+ /* set up the second byte */
+ p++;
+
if (ieee80211_vif_is_mesh(&sdata->vif)) {
/* preserve RSPI and Mesh PS Level bit */
*p &= ((IEEE80211_QOS_CTL_RSPI |
--
2.8.1
^ permalink raw reply related
* USB WiFi driver for AP mode
From: Simon Wunderlich @ 2016-10-12 12:19 UTC (permalink / raw)
To: linux-wireless, bb; +Cc: Pannirselvam Kanagaratnam
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
Hi,
we are looking for well supported USB WiFi chips/modules with the following
requirements
* Be able to support AP mode
* Support at least 20 concurrent clients (stations)
* Support multiple SSIDs
* (preferred, optional: Support 2x2 802.11gn)
We did a survey through the various wiki pages and online information, but
didn't find anything yet matching those requirements (and only found out
limitations after trying ...). Any pointers are appreciated. :)
Thanks!
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-12 12:24 UTC (permalink / raw)
To: Chris Rorvick, Paul Bolle
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAEUsAPbEf=hr1ki267qKpenWW_UBO93KY8q6-EdqWpk15Yhcnw@mail.gmail.com>
On Tue, 2016-10-11 at 23:32 -0500, Chris Rorvick wrote:
> On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle@tiscali.nl> wrote:
> > For what it's worth, on my machine I have twenty (!) SPLX entries, all
> > reading:
> > Name (SPLX, Package (0x04)
> > {
> > Zero,
> > Package (0x03)
> > {
> > 0x80000000,
> > 0x80000000,
> > 0x80000000
> > },
> >
> > Package (0x03)
> > {
> > 0x80000000,
> > 0x80000000,
> > 0x80000000
> > },
> >
> > Package (0x03)
> > {
> > 0x80000000,
> > 0x80000000,
> > 0x80000000
> > }
> > })
>
>
> I actually see exactly the same on my Dell XPS 13 (9350) when I use
> acpidump, etc. I typed the entry I included in the commit log by hand
> based on what the driver gets back from the SPLC method (I added a
> function to dump the returned object.)
Okay... Actually this is a structure in the BIOS and the actual method
we call is SPLC. The SPLC method may return one item from this table,
or something entirely different, possible one of the three values
depending on a configuration option or so.
Can you to find and send me the actual SPLC method that we call, from
your BIOS?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-12 12:25 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, Felix Fietkau
In-Reply-To: <1476269870-32007-1-git-send-email-michael-dev@fami-braun.de>
On Wed, 2016-10-12 at 12:57 +0200, Michael Braun wrote:
> According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer
> SA/DA of A-MSDU frames need to be changed depending on FromDS/ToDS
> values.
actually ...
> struct ieee80211_hdr *hdr;
802.11 header
> - struct ethhdr amsdu_hdr;
> + struct ethhdr *amsdu_hdr;
> int hdr_len = fast_tx->hdr_len - sizeof(rfc1042_header);
802.11 header length
> + data = skb_push(skb, sizeof(*amsdu_hdr));
push ethernet header in
> + memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
move 802.11 header from back to front
> + hdr = data;
hdr is at the beginning of the frame
> + amsdu_hdr = data + hdr_len;
amsdu_hdr is actually the *inner* header after all.
So, I actually think my first instinct that you were erroneously
changing the inner header *was* right.
Seems like this code should be inserted towards the end of
ieee80211_amsdu_aggregate() instead, where it's adding the RFC 1042
header?
Need Felix to take a look, I guess.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix sequence number allocation regression
From: Bob Copeland @ 2016-10-12 12:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Felix Fietkau, linux-wireless, Toke Høiland-Jørgensen
In-Reply-To: <1476254985.5271.1.camel@sipsolutions.net>
On Wed, Oct 12, 2016 at 08:49:45AM +0200, Johannes Berg wrote:
> On Tue, 2016-10-11 at 11:28 +0200, Felix Fietkau wrote:
> > The recent commit that moved around TX handlers dropped the sequence
> > number allocation at the end of ieee80211_tx_dequeue and calls
> > ieee80211_tx_h_sequence instead (for the non-fast-xmit case).
> > However, it did not change the fast-xmit sequence allocation
> > condition
> > in ieee80211_xmit_fast_finish, which skipped seqno alloc if
> > intermediate
> > tx queues are being used.
> >
> > Drop the now obsolete condition.
>
> Hm. I don't know what tree you're looking at, but it looks like I *did*
> in fact resolve this correctly; the (now) erroneous condition doesn't
> exist in mac80211 nor in mac80211-next (nor net, net-next, linux).
>
> It does seem to exist in wireless-testing, but that's not something I
> can control.
Sorry about that, I should've rechecked this after Johannes did the merge.
I applied this patch (to wireless-testing) and pushed tag wt-2016-10-12.
Let me know of any further issues.
As a check I also diffed against mac80211-next/master and found additional
merge damage in the diff which I fixed up. Once the merge window closes
in a few days, I'll resync to the masters of all the trees.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Paul Bolle @ 2016-10-12 12:36 UTC (permalink / raw)
To: Luca Coelho, Chris Rorvick
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <1476275099.7776.28.camel@coelho.fi>
On Wed, 2016-10-12 at 15:24 +0300, Luca Coelho wrote:
> Okay... Actually this is a structure in the BIOS and the actual method
> we call is SPLC. The SPLC method may return one item from this table,
> or something entirely different, possible one of the three values
> depending on a configuration option or so.
>
> Can you to find and send me the actual SPLC method that we call, from
> your BIOS?
It seems Chris and I basically have identical setups, so I'll answer.
There are 20 SPLC methods in the BIOS. The first reads
Method (SPLC, 0, Serialized)
{
DerefOf (SPLX [One]) [Zero] = DOM1 /* \DOM1 */
DerefOf (SPLX [One]) [One] = LIM1 /* \LIM1 */
DerefOf (SPLX [One]) [0x02] = TIM1 /* \TIM1 */
DerefOf (SPLX [0x02]) [Zero] = DOM2 /* \DOM2 */
DerefOf (SPLX [0x02]) [One] = LIM2 /* \LIM2 */
DerefOf (SPLX [0x02]) [0x02] = TIM2 /* \TIM2 */
DerefOf (SPLX [0x03]) [Zero] = DOM3 /* \DOM3 */
DerefOf (SPLX [0x03]) [One] = LIM3 /* \LIM3 */
DerefOf (SPLX [0x03]) [0x02] = TIM3 /* \TIM3 */
Return (SPLX) /* \_SB_.PCI0.RP01.PXSX.SPLX */
}
The only difference is in the last comment. Ie, RP01 is increased until
it reaches RP20. (The machine has 20 PCI devices according to lspci. I
have no clue how to match that RPxx number to the 20 devices showing up
in lspci, sorry.)
Paul Bolle
^ permalink raw reply
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-10-12 12:53 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless, devicetree
In-Reply-To: <87shskwaxh.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
>> I thought about _adding_ a devicetree binding document before sending
>> the patch. But in the end it would be an empty file, since I neither
>> add any bindings nor introduce a compatible string. I'm just add
>> support for the generic of_get_mac_address() devicetree property,
>> which is meant to be used via a devicetree pci childnode.
>>
>> I grepped though the 4.7 code and found a few driver using
>> of_get_mac_address() without having a devicetree binding document:
>>
>> - drivers/net/usb/smsc95xx.c
>> - drivers/net/usb/smsc75xx.c
>> - drivers/net/ethernet/marvell/sky2.c
>> - drivers/net/ethernet/cavium/thunder/thunder_bgx.c
>> - drivers/net/ethernet/wiznet/w5100-spi.c
>> - drivers/net/ethernet/arc/emac_main.c
>>
>> Just let me know if you are still the opinion that a devicetree
>> binding document is required to get this patch accepted.
>
> I'm not familiar enough device tree to really comment. Can someone from
> the device tree list (CCed) help?
>
> Full patch here:
>
> https://patchwork.kernel.org/patch/9300893/
I didn't get any comments so I guess we don't need to document the use
of mac-address in the driver binding document. At least
Documentation/devicetree/bindings/net/ethernet.txt supports that, even
if rt2x00 is a wireless driver.
Unless I get any objections I'm planning to apply this to
wireless-drivers-next (once it's open again).
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Purushottam Kushwaha @ 2016-10-12 12:57 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This commit enhances the current beacon interval validation to also consider
the "radar_detect" and "num_different_channels".
Rename "cfg80211_validate_beacon_int" to "cfg80211_validate_beacon_combination"
as the validation considers other parameters.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
net/wireless/core.h | 7 +++++--
net/wireless/mesh.c | 7 +++++++
net/wireless/nl80211.c | 32 ++++++++++++++-----------------
net/wireless/util.c | 51 +++++++++++++++++++++++++++++++++++++++++++++-----
4 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 21e3188..e39c8a9 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -474,8 +474,11 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
const u8 *rates, unsigned int n_rates,
u32 *mask);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype, u32 beacon_int);
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index fa2066b..1d864b4 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -178,6 +178,13 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
NL80211_IFTYPE_MESH_POINT))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ NL80211_IFTYPE_MESH_POINT,
+ &setup->chandef,
+ setup->beacon_interval);
+ if (err)
+ return err;
+
err = rdev_join_mesh(rdev, dev, conf, setup);
if (!err) {
memcpy(wdev->ssid, setup->mesh_id, setup->mesh_id_len);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 903cd5a..eb2bfae 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3807,11 +3807,6 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
- params.beacon_interval);
- if (err)
- return err;
-
/*
* In theory, some of these attributes should be required here
* but since they were not used when the command was originally
@@ -3899,6 +3894,13 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
wdev->iftype))
return -EINVAL;
+ err = cfg80211_validate_beacon_combination(rdev,
+ dev->ieee80211_ptr->iftype,
+ ¶ms.chandef,
+ params.beacon_interval);
+ if (err)
+ return err;
+
if (info->attrs[NL80211_ATTR_TX_RATES]) {
err = nl80211_parse_tx_bitrate_mask(info, ¶ms.beacon_rate);
if (err)
@@ -8157,11 +8159,6 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
- ibss.beacon_interval);
- if (err)
- return err;
-
if (!rdev->ops->join_ibss)
return -EOPNOTSUPP;
@@ -8188,6 +8185,12 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
+ err = cfg80211_validate_beacon_combination(rdev, NL80211_IFTYPE_ADHOC,
+ &ibss.chandef,
+ ibss.beacon_interval);
+ if (err)
+ return err;
+
if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef,
NL80211_IFTYPE_ADHOC))
return -EINVAL;
@@ -9419,17 +9422,10 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
nla_get_u32(info->attrs[NL80211_ATTR_MCAST_RATE])))
return -EINVAL;
- if (info->attrs[NL80211_ATTR_BEACON_INTERVAL]) {
+ if (info->attrs[NL80211_ATTR_BEACON_INTERVAL])
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev,
- NL80211_IFTYPE_MESH_POINT,
- setup.beacon_interval);
- if (err)
- return err;
- }
-
if (info->attrs[NL80211_ATTR_DTIM_PERIOD]) {
setup.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 3f3d684..a5810ba 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1558,15 +1558,21 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
}
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
-int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- enum nl80211_iftype iftype,
- u32 beacon_int)
+int
+cfg80211_validate_beacon_combination(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
+ struct cfg80211_chan_def *chandef,
+ u32 beacon_int)
{
struct wireless_dev *wdev;
- int res = 0;
+ int res = 0, i;
u32 bi_prev, tmp_bi;
+ struct ieee80211_channel *ch;
+ enum cfg80211_chan_mode chmode;
+ struct ieee80211_channel
+ *used_channels[CFG80211_MAX_NUM_DIFFERENT_CHANNELS];
struct iface_combination_params params = {
- .num_different_channels = 0,
+ .num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
.beacon_gcd = beacon_int, /* GCD(n) = n */
@@ -1576,11 +1582,46 @@ int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ used_channels[0] = chandef->chan;
params.iftype_num[iftype] = 1;
+
+ res = cfg80211_chandef_dfs_required(&rdev->wiphy, chandef, iftype);
+ if (res < 0)
+ return res;
+ if (res)
+ params.radar_detect = BIT(chandef->width);
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
+ mutex_lock_nested(&wdev->mtx, 1);
+ __acquire(wdev->mtx);
+ cfg80211_get_chan_state(wdev, &ch, &chmode,
+ ¶ms.radar_detect);
+ wdev_unlock(wdev);
+
+ switch (chmode) {
+ case CHAN_MODE_UNDEFINED:
+ break;
+ case CHAN_MODE_SHARED:
+ for (i = 0; i < CFG80211_MAX_NUM_DIFFERENT_CHANNELS; i++)
+ if (!used_channels[i] || used_channels[i] == ch)
+ break;
+
+ if (i == CFG80211_MAX_NUM_DIFFERENT_CHANNELS)
+ return -EBUSY;
+
+ if (!used_channels[i]) {
+ used_channels[i] = ch;
+ params.num_different_channels++;
+ }
+ break;
+ case CHAN_MODE_EXCLUSIVE:
+ params.num_different_channels++;
+ break;
+ }
+
params.iftype_num[wdev->iftype]++;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v10] cfg80211: Provision to allow the support for different beacon intervals
From: Purushottam Kushwaha @ 2016-10-12 12:56 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This commit provides a mechanism for the host drivers to advertise the
support for different beacon intervals among the respective interface
combinations in a group, through beacon_int_min_gcd (u32).
This beacon_int_min_gcd will be compared against GCD of all beaconing
interfaces of matching combinations.
Following sets the expectation for beacon_int_min_gcd.
= 0 - all beacon intervals for different interfaces must be same.
> 0 - any beacon interval for the interface part of this combination AND
*GCD* of all beacon intervals from beaconing interfaces of this
combination must be greator or equal to this value.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +++
include/net/cfg80211.h | 14 +++++++-
include/uapi/linux/nl80211.h | 8 +++--
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 14 ++++++--
net/wireless/util.c | 37 ++++++++++++++++++++--
6 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 44e1c70..2624569 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -421,6 +421,8 @@ static int brcmf_vif_change_validate(struct brcmf_cfg80211_info *cfg,
.num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
+ .beacon_gcd = 0,
+ .diff_bi = false,
};
list_for_each_entry(pos, &cfg->vif_list, list)
@@ -446,6 +448,8 @@ static int brcmf_vif_add_validate(struct brcmf_cfg80211_info *cfg,
.num_different_channels = 1,
.radar_detect = 0,
.iftype_num = {0},
+ .beacon_gcd = 0,
+ .diff_bi = false,
};
list_for_each_entry(pos, &cfg->vif_list, list)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 21bbe44..f0bcd55 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -784,11 +784,15 @@ struct cfg80211_csa_settings {
* @iftype_num: array with the numbers of interfaces of each interface
* type. The index is the interface type as specified in &enum
* nl80211_iftype.
+ * @beacon_gcd: a value specifying GCD of all beaconing interfaces.
+ * @diff_bi: a flag which denotes beacon intervals are different or same.
*/
struct iface_combination_params {
int num_different_channels;
u8 radar_detect;
int iftype_num[NUM_NL80211_IFTYPES];
+ u32 beacon_gcd;
+ bool diff_bi;
};
/**
@@ -3100,6 +3104,12 @@ struct ieee80211_iface_limit {
* only in special cases.
* @radar_detect_widths: bitmap of channel widths supported for radar detection
* @radar_detect_regions: bitmap of regions supported for radar detection
+ * @beacon_int_min_gcd: This interface combination supports different
+ * beacon intervals.
+ * = 0 - all beacon intervals for different interface must be same.
+ * > 0 - any beacon interval for the interface part of this combination AND
+ * *GCD* of all beacon intervals from beaconing interfaces of this
+ * combination must be greator or equal to this value.
*
* With this structure the driver can describe which interface
* combinations it supports concurrently.
@@ -3120,7 +3130,7 @@ struct ieee80211_iface_limit {
* };
*
*
- * 2. Allow #{AP, P2P-GO} <= 8, channels = 1, 8 total:
+ * 2. Allow #{AP, P2P-GO} <= 8, BI min gcd = 10, channels = 1, 8 total:
*
* struct ieee80211_iface_limit limits2[] = {
* { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
@@ -3131,6 +3141,7 @@ struct ieee80211_iface_limit {
* .n_limits = ARRAY_SIZE(limits2),
* .max_interfaces = 8,
* .num_different_channels = 1,
+ * .beacon_int_min_gcd = 10,
* };
*
*
@@ -3158,6 +3169,7 @@ struct ieee80211_iface_combination {
bool beacon_int_infra_match;
u8 radar_detect_widths;
u8 radar_detect_regions;
+ u32 beacon_int_min_gcd;
};
struct ieee80211_txrx_stypes {
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 56368e9..3c19cca 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4280,6 +4280,9 @@ enum nl80211_iface_limit_attrs {
* of supported channel widths for radar detection.
* @NL80211_IFACE_COMB_RADAR_DETECT_REGIONS: u32 attribute containing the bitmap
* of supported regulatory regions for radar detection.
+ * @NL80211_IFACE_COMB_BI_MIN_GCD: u32 attribute specifying the minimum GCD of
+ * different beacon intervals supported by all the interface combinations
+ * in this group (if not present, all beacon interval must match).
* @NUM_NL80211_IFACE_COMB: number of attributes
* @MAX_NL80211_IFACE_COMB: highest attribute number
*
@@ -4287,8 +4290,8 @@ enum nl80211_iface_limit_attrs {
* limits = [ #{STA} <= 1, #{AP} <= 1 ], matching BI, channels = 1, max = 2
* => allows an AP and a STA that must match BIs
*
- * numbers = [ #{AP, P2P-GO} <= 8 ], channels = 1, max = 8
- * => allows 8 of AP/GO
+ * numbers = [ #{AP, P2P-GO} <= 8 ], BI min gcd, channels = 1, max = 8,
+ * => allows 8 of AP/GO that can have BI gcd >= min gcd
*
* numbers = [ #{STA} <= 2 ], channels = 2, max = 2
* => allows two STAs on different channels
@@ -4314,6 +4317,7 @@ enum nl80211_if_combination_attrs {
NL80211_IFACE_COMB_NUM_CHANNELS,
NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
+ NL80211_IFACE_COMB_BI_MIN_GCD,
/* keep last */
NUM_NL80211_IFACE_COMB,
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 08d2e94..21e3188 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -475,7 +475,7 @@ int ieee80211_get_ratemask(struct ieee80211_supported_band *sband,
u32 *mask);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
- u32 beacon_int);
+ enum nl80211_iftype iftype, u32 beacon_int);
void cfg80211_update_iface_num(struct cfg80211_registered_device *rdev,
enum nl80211_iftype iftype, int num);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c510810..903cd5a 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1075,6 +1075,10 @@ static int nl80211_put_iface_combinations(struct wiphy *wiphy,
nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
c->radar_detect_regions)))
goto nla_put_failure;
+ if (c->beacon_int_min_gcd &&
+ nla_put_u32(msg, NL80211_IFACE_COMB_BI_MIN_GCD,
+ c->beacon_int_min_gcd))
+ goto nla_put_failure;
nla_nest_end(msg, nl_combi);
}
@@ -3803,7 +3807,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
params.dtim_period =
nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
- err = cfg80211_validate_beacon_int(rdev, params.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr->iftype,
+ params.beacon_interval);
if (err)
return err;
@@ -8152,7 +8157,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
ibss.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, ibss.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev, NL80211_IFTYPE_ADHOC,
+ ibss.beacon_interval);
if (err)
return err;
@@ -9417,7 +9423,9 @@ static int nl80211_join_mesh(struct sk_buff *skb, struct genl_info *info)
setup.beacon_interval =
nla_get_u32(info->attrs[NL80211_ATTR_BEACON_INTERVAL]);
- err = cfg80211_validate_beacon_int(rdev, setup.beacon_interval);
+ err = cfg80211_validate_beacon_int(rdev,
+ NL80211_IFTYPE_MESH_POINT,
+ setup.beacon_interval);
if (err)
return err;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 0d69b25..3f3d684 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1559,24 +1559,49 @@ bool ieee80211_chandef_to_operating_class(struct cfg80211_chan_def *chandef,
EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
+ enum nl80211_iftype iftype,
u32 beacon_int)
{
struct wireless_dev *wdev;
int res = 0;
+ u32 bi_prev, tmp_bi;
+ struct iface_combination_params params = {
+ .num_different_channels = 0,
+ .radar_detect = 0,
+ .iftype_num = {0},
+ .beacon_gcd = beacon_int, /* GCD(n) = n */
+ .diff_bi = false,
+ };
if (beacon_int < 10 || beacon_int > 10000)
return -EINVAL;
+ params.iftype_num[iftype] = 1;
+ list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
+ if (!wdev->beacon_interval)
+ continue;
+
+ params.iftype_num[wdev->iftype]++;
+ }
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
if (wdev->beacon_interval != beacon_int) {
- res = -EINVAL;
+ params.diff_bi = true;
+ /* Get the GCD */
+ bi_prev = wdev->beacon_interval;
+ while (bi_prev != 0) {
+ tmp_bi = bi_prev;
+ bi_prev = params.beacon_gcd % bi_prev;
+ params.beacon_gcd = tmp_bi;
+ }
break;
}
}
- return res;
+ res = cfg80211_check_combinations(&rdev->wiphy, ¶ms);
+ return (res < 0) ? res : 0;
}
int cfg80211_iter_combinations(struct wiphy *wiphy,
@@ -1652,6 +1677,14 @@ int cfg80211_iter_combinations(struct wiphy *wiphy,
if ((all_iftypes & used_iftypes) != used_iftypes)
goto cont;
+ if (params->beacon_gcd) {
+ if (c->beacon_int_min_gcd &&
+ params->beacon_gcd < c->beacon_int_min_gcd)
+ return -EINVAL;
+ if (!c->beacon_int_min_gcd && params->diff_bi)
+ goto cont;
+ }
+
/* This combination covered all interface types and
* supported the requested numbers, so we're good.
*/
--
1.9.1
^ permalink raw reply related
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