Re: synchronization question about sdata->skb_queue

sorry, just realized skb_dequeue() will call spin_lock_irqsave() inside. please ignore this question. On Sat, Sep 9, 2017 at 9:28 AM, dztemplor . wrote: > Hi, everyone. > I'm a newbie in mac80211 and have a question about synchronization for > sdata->skb_queue. >

synchronization question about sdata->skb_queue

Hi, everyone. I'm a newbie in mac80211 and have a question about synchronization for sdata->skb_queue. sdata->skb_queue is shared between ieee80211_iface_work() and rx handlers like ieee80211_rx_h_action() ieee80211_iface_work() runs in process context. ieee80211_rx_h_action() runs in softirq

Re: Incorrect mesh path seq num

On Mon, Sep 4, 2017 at 6:19 AM, Johannes Berg wrote: > On Fri, 2017-09-01 at 13:07 -0700, Thomas Pedersen wrote: >> On Thu, Aug 31, 2017 at 11:30 PM, Greg Maitz >> wrote: >> > Hi guys, >> > >> > I'm seeing a problem when I work on the wireless mesh

Re: [PATCH] mwifiex: check for mfg_mode in add_virtual_intf

Hi, Could have used a 'v2' in the subject, but hopefully that doesn't bother Kalle too much. On Fri, Sep 08, 2017 at 02:02:43AM +0530, Ganapathi Bhat wrote: > If driver is loaded with 'mfg_mode' enabled, then the sending > commands are not allowed. So, skip sending commands, to firmware > in

[PATCH 1/3] brcmfmac: Avoid possible out-of-bounds read

In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before the length of rxframe is validated. This could lead to uninitialized data being printed in a debug message. Since we already have a perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec, and ch.chspec is not

[PATCH 3/3] brcmfmac: Add check for short event packets

The length of the data in the received skb is currently passed into brcmf_fweh_process_event() as packet_len, but this value is not checked. event_packet should be followed by DATALEN bytes of additional event data. Ensure that the received packet actually contains at least DATALEN bytes of

[PATCH 0/3] New brcmfmac bounds checks

These were suggested by the Chrome OS security team[1]. Compile-tested only. [1] http://crosreview.com/656260 Kevin Cernekee (3): brcmfmac: Avoid possible out-of-bounds read brcmfmac: Don't print out-of-bounds event data brcmfmac: Add check for short event packets

Re: pull-request: wireless-drivers 2017-09-08

From: Kalle Valo Date: Fri, 08 Sep 2017 18:50:01 +0300 > few fixes to net tree for 4.14. Note that this pull request contains the > iwlwifi fix Linus hopes to have by end of the merge window. Please let > me know if there are any problems. Pulled, thanks for following up

RE: OUTLOOK SLOW PERFORMANCE

From: Iok Chan Sent: Saturday, 9 September 2017 2:11 a.m. Subject: OUTLOOK SLOW PERFORMANCE Opening Statement: Our Outlook platform is currently operational, but running very slower than usual. Support is currently investigating the issue.Please you need

[PATCH v2 2/2] wireless: return correct mandatory rates

Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B to get all mandatory rates in 2.4 GHz band. It is safe to do so because ERP mandatory rates are a superset of HR/DSSS mandatory rates. Also limit to OFDM rates for 10 MHz and 5 MHz channels as originally intended by commit

pull-request: wireless-drivers 2017-09-08

Hi Dave, few fixes to net tree for 4.14. Note that this pull request contains the iwlwifi fix Linus hopes to have by end of the merge window. Please let me know if there are any problems. Kalle The following changes since commit 8e0deed92406d93ae0365cb8a6134db5721e7aca: tipc: remove

[PATCH] rsi: fix a dereference on adapter before it has been null checked

From: Colin Ian King The assignment of dev is dereferencing adapter before adapter has been null checked, potentially leading to a null pointer dereference. Fix this by simply moving the assignment of dev to a later point after the sanity null check of adapter.

Re: [RFC 3/4] mac80211_hwsim: explicitly set netlink parallel ops to false

On Fri, 2017-09-08 at 17:07 +0200, Benjamin Beichler wrote: > > Am 8. September 2017 16:19:20 MESZ schrieb Johannes Berg psolutions.net>: > > On Fri, 2017-09-08 at 16:11 +0200, Benjamin Beichler wrote: > > > The ops field is zero initialized, therefore parallel ops is > > > already

Re: [RFC 3/4] mac80211_hwsim: explicitly set netlink parallel ops to false

Am 8. September 2017 16:19:20 MESZ schrieb Johannes Berg : >On Fri, 2017-09-08 at 16:11 +0200, Benjamin Beichler wrote: >> The ops field is zero initialized, therefore parallel ops is already >> false. > >Therefore this patch is completely pointless? Sorry my first

Re: [RFC 4/4] mac80211_hwsim: add radio idx param to netlink callback of radio creation

Uh. Is there anything you can do not to mangle your replies? I don't even know what you're replying to etc. > AFAIK, you can change the MAC-Address of an interface on > the phy, but not the perm address of the phy. But for frames sent to > a wmediumd always the perm address is used to identify

Re: [RFC 4/4] mac80211_hwsim: add radio idx param to netlink callback of radio creation

>> Since the radio index is already a valid NL attribute, this patch >> simply >> try to read it and create the radio specific to this index >> by the previously used scheme. >> >> Since this allows to create radios out of row, we need to search >> for a free index for a new radio, when the

Re: [RFC 4/4] mac80211_hwsim: add radio idx param to netlink callback of radio creation

On Fri, 2017-09-08 at 16:11 +0200, Benjamin Beichler wrote: > Since the radio index is already a valid NL attribute, this patch > simply > try to read it and create the radio specific to this index by the > previously used scheme. > > Since this allows to create radios out of row, we need to

[RFC 0/4] mac80211_hwsim: improvements for wmediumd-like simulations and config enhancements

This patch series includes our efforts for more sophisticated simulations for wifi-networks. Especially Patch 2 and 4 add missing functionality. The patch 1 adds an obvious performance improvement for many radios, since for every received frame a linear search through all radios is done.

Re: [RFC 2/4] mac80211_hwsim: add hwsim_tx_rate_flags to Netlink Attributes

On Fri, 2017-09-08 at 16:11 +0200, Benjamin Beichler wrote: > For correct interpretation of a tx rate, the corresponding rate flags > are needed (e.g. whether a HT-MCS rate or a legacy rate) and > moreover for more correct simulation the other infos of the flags are > important (like short-GI).

Re: [RFC 1/4] mac80211_hwsim: changed hwsim_radios from list to hashlist keyed by MAC-Address

On Fri, 2017-09-08 at 16:11 +0200, Benjamin Beichler wrote: > Use hashlist to improve lookup speed for every received NL-message, > especially for higher counts of radios, like 100 or more. The > stringhash > should be neglible for 6 Bytes MAC-Address, could be improved by > using > cast to 64bit

Re: [RFC 3/4] mac80211_hwsim: explicitly set netlink parallel ops to false

On Fri, 2017-09-08 at 16:11 +0200, Benjamin Beichler wrote: > The ops field is zero initialized, therefore parallel ops is already > false. Therefore this patch is completely pointless? johannes

[RFC 2/4] mac80211_hwsim: add hwsim_tx_rate_flags to Netlink Attributes

For correct interpretation of a tx rate, the corresponding rate flags are needed (e.g. whether a HT-MCS rate or a legacy rate) and moreover for more correct simulation the other infos of the flags are important (like short-GI). Keeping compability, the flags are not integrated into the existing

[RFC 1/4] mac80211_hwsim: changed hwsim_radios from list to hashlist keyed by MAC-Address

Use hashlist to improve lookup speed for every received NL-message, especially for higher counts of radios, like 100 or more. The stringhash should be neglible for 6 Bytes MAC-Address, could be improved by using cast to 64bit integer and hash this instead. For a more reliable implementation of

[RFC 4/4] mac80211_hwsim: add radio idx param to netlink callback of radio creation

Since the radio index is already a valid NL attribute, this patch simply try to read it and create the radio specific to this index by the previously used scheme. Since this allows to create radios out of row, we need to search for a free index for a new radio, when the index is not present as

[RFC 3/4] mac80211_hwsim: explicitly set netlink parallel ops to false

The ops field is zero initialized, therefore parallel ops is already false. This implicates that the netlink callbacks are not processed in parallel. Maybe this could be utilized to reduce locking overhead or maybe also parallel ops could be implemented. Signed-off-by: Benjamin Beichler

Update WiFi card by one that does not use _Private_ Firmware

Hello, My name is Cristian Aravena Romero, [1]Free Software enthusiast in Chile. My _Notebook_ has a WiFi card [2]"Intel® Centrino® Advanced-N 6235" running from version 3.2 of the Linux kernel and above; and also occupies the firmware "iwlwifi-6000g2b-ucode-18.168.6.1.tgz". The complete

[PATCH v2] rtl8xxxu: Don't printk raw binary if serial number is not burned in.

I assume that a blank efuse comes with all ones, thus I did not bother recognizing other possible junk values. This matches 100% of dongles I've seen (a single Gembird 8192eu). Signed-off-by: Adam Borowski --- v2: strncmp("goofy string") -> memchr_inv() Stefano Brivio

Re: [PATCH 2/2] wireless: return correct mandatory rates

On Fri, 2017-09-08 at 12:10 +0200, Richard Schütz wrote: > > This would leave us with 1, 2, 5.5 and 11 Mb/s for ERP PHYs again > when it really should be 1, 2, 5.5, 6, 11, 12 and 24 Mb/s. > Yes, you're right - I had thought about that but forgot. The places that check it would have to be

Re: [PATCH 2/2] wireless: return correct mandatory rates

Am 08.09.2017 um 11:03 schrieb Johannes Berg: On Fri, 2017-09-08 at 10:43 +0200, Richard Schütz wrote: Am 08.09.2017 um 08:55 schrieb Johannes Berg: On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B for comparison to

[PATCH] mac80211: use offsetofend()

From: Johannes Berg This was created using the following spatch: @find@ type S; expression M, M2; position p; @@ offsetof(S, M) + sizeof(M2)@p @script:python@ m << find.M; m2 << find.M2; @@ if not m2.endswith('-> ' + m):

Re: [PATCH 2/2] wireless: return correct mandatory rates

Hi, On Friday, September 8, 2017 10:53:37 AM CEST Richard Schütz wrote: > Am 08.09.2017 um 10:43 schrieb Richard Schütz: > > Am 08.09.2017 um 08:55 schrieb Johannes Berg: > >> On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: > >>> Use IEEE80211_RATE_MANDATORY_G instead of

Re: [v2] brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices

Ian W MORRISON wrote: > The firmware feature check introduced for multi-scheduled scan is also > failing for bcm4345 devices resulting in a firmware crash. > The reason for this crash has not yet been root cause so this patch avoids > the feature check for those device as

Re: Fwd: [PATCH v2] brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices

Hi Ian, please don't send me email privately, instead always send the questions to the list. You get better answers faster and I get less email :) Ian W MORRISON writes: > With the below patch how can I track when it has been merged into 4.13 > so I can check and start

[PATCH 09/10] iwlwifi: mvm: set status before calling iwl_mvm_send_cmd_status()

From: Luca Coelho We always must set the status to what we consider success before calling iwl_mvm_send_cmd_status() (also iwl_mvm_send_cmd_pdu_status() which calls it). Fix a few places where initialization is missing. Signed-off-by: Luca Coelho

[PATCH 04/10] iwlwifi: mvm: change state when queueing agg start work

From: Naftali Goldstein Add a new state to enum iwl_mvm_agg_state, which is used between queueing the work that starts tx aggregations and actually starting that work (changing to state IWL_AGG_STARTING). This solves a race where ieee80211_start_tx_ba_session is

[PATCH 10/10] iwlwifi: mvm: fix reorder buffer for 9000 devices

From: Sara Sharon The condition to check if reorder buffer ran out of space is faulty, as it takes into account only the NSSN. In case the head SN was too far behind the reorder buffer should move forward, regardless of the NSSN status. This caused the driver to release

[PATCH 08/10] iwlwifi: mvm: initialize status in iwl_mvm_add_int_sta_common()

From: Luca Coelho We always need to initialize the status argument to the success case before calling iwl_mvm_send_cmd_status() or iwl_mvm_send_cmd_pdu_status() (which calls the former) otherwise we may get an uninitialized value back. In this case, we use

[PATCH 07/10] iwlwifi: mvm: handle FIF_ALLMULTI when setting multicast addresses

From: Luca Coelho We were ignoring the FIF_ALLMULTI flag when setting the multicast addresses with MCAST_FILTER_CMD. Check if this flag is set and enable pass_all accordingly. We also need to set the count to 0 if pass_all is enable so we don't pass addresses to the

[PATCH 06/10] iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD

From: Luca Coelho The MCAST_FILTER_CMD can get quite large when we have many mcast addresses to set (we support up to 255). So the command should be send as NOCOPY to prevent a warning caused by too-long commands: WARNING: CPU: 0 PID: 9700 at

[PATCH 03/10] iwlwifi: mvm: send all non-bufferable frames on the probe queue

From: Avraham Stern AP interfaces now send all non-bufferable frames using the broadcast station. Thus allow them to use the probe queue and don't warn about it. Fixes: eb045e6e0389 ("iwlwifi: mvm: Avoid deferring non bufferable frames") Signed-off-by: Avraham Stern

[PATCH 02/10] iwlwifi: mvm: Flush non STA TX queues

From: David Spinadel When starting wowlan mac80211 requests flush w/o vif and we ignore this request. As a result some packets stay stuck in the queue and it may end up with a queue hang. Allow the driver to flush queues even if station isn't specified. Signed-off-by:

[PATCH 05/10] iwlwifi: mvm: wake the correct mac80211 queue

From: Avraham Stern iwl_mvm_start_mac_queues() takes a bitmap of the queues to wake. When deferred tx is purged, set the bit of the hw_queue so the correct queue will be waken up. Fixes: 7e39a00d5931 ("iwlwifi: mvm: start mac queues when deferred tx frames are purged")

[PATCH 01/10] iwlwifi: mvm: fix wowlan resume failed to load INIT ucode

From: Matt Chen If we set disconnect on wowlan and run suspend/resume, will run into: ...snipped iwlwifi :01:00.0: Failed to load firmware chunk! iwlwifi :01:00.0: Could not load the [0] uCode section iwlwifi :01:00.0: Failed to start INIT ucode: -110 iwlwifi

[PATCH 00/10] iwlwifi: fixes intended for 4.14 2017-09-08

From: Luca Coelho Hi, Here is my first batch of fixes intended for 4.14. Since it is very early in the release process, I was a bit liberal with the fixes I'm sending, but they all fix real issues. These are the fixes: * A couple of bugzilla bugs related to

Re: [PATCH 2/2] wireless: return correct mandatory rates

On Fri, 2017-09-08 at 10:43 +0200, Richard Schütz wrote: > Am 08.09.2017 um 08:55 schrieb Johannes Berg: > > On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: > > > Use IEEE80211_RATE_MANDATORY_G instead of > > > IEEE80211_RATE_MANDATORY_B > > > for comparison to get all mandatory rates in

Re: [PATCH 1/2] wireless: set correct mandatory rate flags

On Fri, 2017-09-08 at 10:43 +0200, Richard Schütz wrote: > > Hmm, I guess technically you're correct, since 11b added what's now > > Clause 16 (was Clause 18 at the time), and that has all of them > > mandatory? But perhaps this was actually intended for Clause 15 > > compatibility? > >

Re: [PATCH 2/2] wireless: return correct mandatory rates

Am 08.09.2017 um 10:43 schrieb Richard Schütz: Am 08.09.2017 um 08:55 schrieb Johannes Berg: On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B for comparison to get all mandatory rates in 2.4 GHz band. It is safe to do

Re: [PATCH 1/2] wireless: set correct mandatory rate flags

Am 08.09.2017 um 08:54 schrieb Johannes Berg: On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: According to IEEE Std 802.11-2016 (16.2.3.4 Long PHY SIGNAL field) all of the following rates are mandatory for a HR/DSSS PHY: 1 Mb/s, 2 Mb/s, 5.5 Mb/s and 11 Mb/s. Set

Re: [PATCH 2/2] wireless: return correct mandatory rates

Am 08.09.2017 um 08:55 schrieb Johannes Berg: On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B for comparison to get all mandatory rates in 2.4 GHz band. It is safe to do so because ERP mandatory rates are a superset

Re: [PATCH 2/2] wireless: return correct mandatory rates

On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: > Use IEEE80211_RATE_MANDATORY_G instead of IEEE80211_RATE_MANDATORY_B > for comparison to get all mandatory rates in 2.4 GHz band. It is safe > to do so because ERP mandatory rates are a superset of HR/DSSS > mandatory rates. This I don't

Re: [PATCH 1/2] wireless: set correct mandatory rate flags

On Thu, 2017-09-07 at 17:47 +0200, Richard Schütz wrote: > According to IEEE Std 802.11-2016 (16.2.3.4 Long PHY SIGNAL field) > all of > the following rates are mandatory for a HR/DSSS PHY: 1 Mb/s, 2 Mb/s, > 5.5 Mb/s and 11 Mb/s. Set IEEE80211_RATE_MANDATORY_B flag for all of > these instead of