On Mon, 2015-06-29 at 19:41 +0100, Tom Hughes wrote:
On 29/06/15 11:28, Tom Hughes wrote:
On 29/06/15 11:24, Tom Hughes wrote:
So I think this happens when hostapd switches the interface
to AP mode, which causes the netdev to be torn down and then
recreated, and the debugfs
On Sat, 2015-06-27 at 16:34 +0100, Tom Hughes wrote:
Interestingly from what I can see this is trying to create a file
for the station at a path something like:
ieee80211/phy0/netdev:/stations/XX
indeed.
but in my (currently working) boot under 4.0.4 there is no netdev
directory
On Sat, 2015-06-13 at 10:16 -0400, Bob Copeland wrote:
We already set a station to be associated when peering completes, both
in user space and in the kernel. Thus we should always have an
associated sta before sending data frames to that station.
Failure to check assoc state can cause
On Thu, 2014-12-04 at 12:22 +0200, Arik Nemtsov wrote:
In the already-set and intersect case of a driver-hint, the previous
wiphy regdomain was not freed before being reset with a copy of the
cfg80211 regdomain.
Applied.
johannes
--
To unsubscribe from this list: send the line unsubscribe
On Tue, 2014-12-02 at 09:53 +0200, Emmanuel Grumbach wrote:
This can happen and there is no point in added more
detection code lower in the stack. Catching these in one
single point (cfg80211) is enough. Stop WARNING about this
case.
Applied.
johannes
--
To unsubscribe from this list: send
From: Johannes Berg johannes.b...@intel.com
Upstream commit 4f031fa9f188b2b0641ac20087d9e16bcfb4e49d.
Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to
cryptoapi's CCM driver) introduced a regression when decrypting empty
packets (data_len == 0). This will lead
On Mon, 2014-10-13 at 14:34 +0200, Karl Beldan wrote:
From: Karl Beldan karl.bel...@rivierawaves.com
It affects non-(V)HT rates and can lead to selecting an rts_cts rate
that is not a basic rate or way superior to the reference rate (ATM
rates[0] used for the 1st attempt of the protected
From: Johannes Berg johannes.b...@intel.com
Upstream commit bd8c78e78d5011d8111bc2533ee73b13a3bd6c42.
In testmode and vendor command reply/event SKBs we use the
skb cb data to store nl80211 parameters between allocation
and sending. This causes the code for CONFIG_NETLINK_MMAP
to get confused
From: Johannes Berg johannes.b...@intel.com
Upstream commit 08b9939997df30e42a228e1ecb97f99e9c8ea84e, adjusted for
lack of ieee80211_is_bufferable_mmpdu() helper function.
This reverts commit 277d916fc2e959c3f106904116bb4f7b1148d47a as it was
at least breaking iwlwifi by setting
From: Johannes Berg johannes.b...@intel.com
Upstream commit 08b9939997df30e42a228e1ecb97f99e9c8ea84e, adjusted for
lack of ieee80211_is_bufferable_mmpdu() helper function.
This reverts commit 277d916fc2e959c3f106904116bb4f7b1148d47a as it was
at least breaking iwlwifi by setting
From: Johannes Berg johannes.b...@intel.com
Upstream commit 0229cdafb6f67064a217591d48b0f6abf14e8385.
If we have no beacon data before association, delay smart FIFO
enablement until after we have this data.
Not doing so can cause association failures in extremely silent
environments (usually
From: Johannes Berg johannes.b...@intel.com
Upstream commit b4b177a5556a686909e643f1e9b6434c10de079f.
Jouni reported that if a remain-on-channel was active on the
same channel as the current operating channel, then the ROC
would start, but any frames transmitted using mgmt-tx on the
same channel
On Tue, 2014-05-13 at 12:54 +0300, Emmanuel Grumbach wrote:
If the association is in progress while we suspend, the
stack will be in a messed up state. Clean it before we
suspend.
This patch completes Johannes's patch:
1a1cb744de160ee70086a77afff605bbc275d291
Author: Johannes Berg
From: Johannes Berg johannes.b...@intel.com
Upstream commit 1a1cb744de160ee70086a77afff605bbc275d291, fixed
for cfg80211 API and locking changes.
Since Stanislaw's patch removing the quiescing code, mac80211 had
a race regarding suspend vs. authentication: as cfg80211 doesn't
track
On Thu, 2014-03-06 at 15:08 +0100, Michael Braun wrote:
commit de74a1d9032f4d37ea453ad2a647e1aff4cd2591
mac80211: fix WPA with VLAN on AP side with ps-sta
fixed an issue where queued multicast packets would
be sent out encrypted with the key of an other bss.
commit
On Thu, 2014-02-20 at 08:18 +0200, Emmanuel Grumbach wrote:
There is a race between the Tx path and the STA wake up
flow.
If a station is asleep, mac80211 buffers frames, but up to
a certain limit. When this limit is reached, mac80211 begins
to drop the oldest buffered frames. This is done in
On Thu, 2014-01-30 at 14:17 +0530, Sujith Manoharan wrote:
From: Sujith Manoharan c_man...@qca.qualcomm.com
Currently, when a station leaves an IBSS network, the
corresponding BSS is not dropped from cfg80211 if there are
other active stations in the network. But, the small
window that is
On Thu, 2014-01-23 at 14:28 +0200, Emmanuel Grumbach wrote:
sdata-u.ap.request_smps_work can’t be flushed synchronously
under wdev_lock(wdev) since ieee80211_request_smps_ap_work
itself locks the same lock.
Applied.
johannes
--
To unsubscribe from this list: send the line unsubscribe stable
On Fri, 2014-01-17 at 23:19 +0800, ZHAO Gang wrote:
Use the right function to update status.freq. The wrong frequency
value can cause problem that bss info can't be updated when it
should be.
This bug is introduced by commit 8318d78a44d49ac1edf2bdec7299de3617c4232e
cfg80211 API for
On Sun, 2014-01-12 at 04:24 +, Ben Hutchings wrote:
You could switch back to synchronous firmware loading soon, as it's not
going to support a usermode helper any more.
But until then, the proper fix for this is going to be to cancel the
waiter earlier in teardown.
I don't think we
From: Johannes Berg johannes.b...@intel.com
Upstream commit 79845c662eeb95c9a180b9bd0d3ad848ee65b94c.
Since rdev-sched_scan_req is dereferenced outside the
lock protecting it, this might be done at the wrong
time, causing crashes. Move the dereference to where
it should be - inside the RTNL
On Mon, 2013-08-19 at 11:52 -0700, Hugh Dickins wrote:
We could use the semaphore instead, I believe, but I don't really
understand the mutex vs. semaphore well enough to be sure that's
correct.
I don't believe so, the semaphore and cb_mutex don't have a dependency
yet, afaict.
On Tue, 2013-08-20 at 10:28 +0200, Johannes Berg wrote:
The only way to fix this that I see right now (that doesn't rewrite the
locking completely) would be to make genetlink use parallel_ops itself,
thereby removing the genl_lock() in genl_rcv_msg() and breaking all
those lock chains
On Tue, 2013-08-20 at 21:02 +0200, Johannes Berg wrote:
On Tue, 2013-08-20 at 10:28 +0200, Johannes Berg wrote:
The only way to fix this that I see right now (that doesn't rewrite the
locking completely) would be to make genetlink use parallel_ops itself,
thereby removing the genl_lock
want to
do this so close to a release?
johannes
From 5b4790a1188c40422e99b4fc8840e4860d57f0d0 Mon Sep 17 00:00:00 2001
From: Johannes Berg johannes.b...@intel.com
Date: Tue, 20 Aug 2013 21:31:48 +0200
Subject: [PATCH] genetlink: convert family dump code to use RCU
In my previous commit
On Tue, 2013-08-20 at 13:00 -0700, Guenter Roeck wrote:
Does this patch have to be reverted in 3.10 as well ? Linus' e-mail seems to
suggest it, but Shuah didn't see the problem there. I ran a quick test with
3.10.8 on an x86 system and did not see a problem either, at least not
immediately.
3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race)
gives me the lockdep trace below at startup.
Hmm. Yes, I see now how this happens, not sure why I didn't run into it.
The problem is that genl_family_rcv_msg() is called with the genl_lock
held, and then calls
On Mon, 2013-08-19 at 19:00 +0800, Ding Tianhong wrote:
On 2013/8/19 16:00, Johannes Berg wrote:
3.11-rc6's commit 58ad436fcf49 (genetlink: fix family dump race)
gives me the lockdep trace below at startup.
Hmm. Yes, I see now how this happens, not sure why I didn't run
On Sun, 2013-08-11 at 21:29 -0700, David Miller wrote:
BUG: unable to handle kernel paging request at f8467360
IP: [c14c56bb] ctrl_dumpfamily+0x6b/0xe0
EIP: 0060:[c14c56bb] EFLAGS: 00210297 CPU: 2
EIP is at ctrl_dumpfamily+0x6b/0xe0
EAX: f8467378 EBX: f8467340 ECX: EDX:
[Emmanuel is on vacation, I'll cover for him]
On Fri, 2013-08-02 at 17:02 +0800, Greg KH wrote:
On Mon, Jul 15, 2013 at 02:44:57PM +0300, Emmanuel Grumbach wrote:
This small patch series enables 7260 and 3160 devices on 3.10
kernel. Three patches are already in linux.git (3.11-rc1).
One
passive-to-active switching, causing us to
not find all desired networks.
Remove the unused passive scan mask constant.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: David Spinadel david.spina...@intel.com
Signed-off-by: Johannes Berg johannes.b
From: Johannes Berg johannes.b...@intel.com
Upstream commit 707aee401d2467baa785a697f40a6e2d9ee79ad5.
The BT_CONFIG command that is sent to the device during
startup will enable BT coex unless the module parameter
turns it off, but on devices without Bluetooth this may
cause problems
From: Johannes Berg johannes.b...@intel.com
Upstream commit 35d865afbbdf79e492f7d61df92b1a9e1d93d26f.
There are some APs, notably 2G/3G/4G Wifi routers, specifically the
Onda PN51T, Vodafone PocketWiFi 2, ZTE MF60 and a similar
T-Mobile branded device [1] that erroneously don't include all
From: Johannes Berg johannes.b...@intel.com
Unfortunately, advertising P2P_DEVICE support was a little
premature, a number of issues came up in testing and have
been fixed for 3.10. Rather than try to backport all the
different fixes, disable P2P_DEVICE support in the drivers
using it.
Signed
From: Johannes Berg johannes.b...@intel.com
Unfortunately, advertising P2P_DEVICE support was a little
premature, a number of issues came up in testing and have
been fixed for 3.10. Rather than try to backport all the
different fixes, disable P2P_DEVICE support in the drivers
using it. For iwlmvm
because neither you
nor the AP have it ;-)
I fixed it in
commit 586e01ededf9b713a1512dd658806791a7ca1a50
Author: Johannes Berg johannes.b...@intel.com
Date: Thu Feb 14 12:13:53 2013 +0100
mac80211: prevent spurious HT/VHT downgrade message
but I guess that didn't make it to 3.8, maybe it should
On Mon, 2012-09-17 at 17:41 +0300, Artem Bityutskiy wrote:
OK, finally I got it. After 3 days of hardcore intelligent bisecting
I've found out that tethering in 3.5 works for me if I revert
these 2
patches:
56138f5 iwlwifi: dont pull too much payload in
From: Johannes Berg johannes.b...@intel.com
Commit 586e01ededf9b713a1512dd658806791a7ca1a50 upstream.
Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT
From: Johannes Berg johannes.b...@intel.com
Commit 5b36ebd8249f403c7edf7cf68d68e9a0d0f55243 upstream.
In some cases when disconnecting after (or during?) CSA
the queues might not recover, and then the only way to
recover is reloading the module.
Fix this by always unblocking the queue CSA
On Wed, 2013-02-06 at 01:16 +, Ben Hutchings wrote:
I don't know why USB differs from PCI, but we do need the dynamic ID here
as
there are always new IDs being issued. One of the criteria for adding the
ID to
the table is that it works OK with dynamic addition. These devices are
: 987c285c2ae2e4e32aca3a9b3252d28171c75711
Author: Johannes Berg johannes.b...@intel.com
AuthorDate: Fri Nov 9 09:47:27 2012 +0100
Committer: Johannes Berg johannes.b...@intel.com
CommitDate: Fri Nov 9 09:48:43 2012 +0100
mac80211: fix memory leak in device registration error path
Looks like this patch
Hi Eddie,
The AP is a Netgear WNR2000v3 running DD-WRT v24-sp2 (03/19/12) std.
After sshing into it and playing around with the iw command, the phy is
phy0 and the device is ath0.
iw ath0 scan dump returns nothing unfortunately.
Yeah, sorry, I guess I confused you. I did want this info
On Tue, 2012-11-06 at 16:54 +0100, Johannes Berg wrote:
BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
[...]
HT operation:
* primary channel: 9
* secondary channel offset: above
As you can see, it's using HT40+ on channel 9 (2452 MHz). Your HT40
allow
On Tue, 2012-11-06 at 17:39 +0100, Johannes Berg wrote:
On Tue, 2012-11-06 at 16:54 +0100, Johannes Berg wrote:
BSS 82:e1:fa:1a:65:00 (on wlan0) -- associated
[...]
HT operation:
* primary channel: 9
* secondary channel offset: above
As you can see
Hi Eddie,
In the AP's dmesg output which I included in my other message, I see this:
6[9.30] cfg80211: Regulatory domain changed to country: GB
So it seems the AP knows where it is, but is it not transmitting that to
the client?
Evidently, I don't see a country IE in the iw scan
On Tue, 2012-11-06 at 17:55 +0100, Johannes Berg wrote:
Hi Eddie,
In the AP's dmesg output which I included in my other message, I see this:
6[9.30] cfg80211: Regulatory domain changed to country: GB
So it seems the AP knows where it is, but is it not transmitting
On Tue, 2012-11-06 at 18:59 +, Eddie Chapman wrote:
On 06/11/12 15:54, Johannes Berg wrote:
The problem here is that some devices (notably iwlwifi) will not allow
(by firmware) to connect to such an AP as HT40- if that is not allowed.
So I prevented it generally, but we can make
On Tue, 2012-11-06 at 19:35 +, Eddie Chapman wrote:
Right, we're still looking at that. It seems that it's not an ideal
solution, the regulatory change I proposed is probably better. Could you
check if it helps as well? That is, remove this patch, and apply this
one:
On Wed, 2012-11-07 at 08:36 +0100, Greg KH wrote:
Great, thanks. I'm not really sure which one to apply, and if we apply
the 8877 one we'll also want to update the reg db (that you aren't
using). A lot of people are in Barcelona right now though, so that might
be a week or so until we can
On Mon, 2012-11-05 at 11:04 +, Eddie Chapman wrote:
And, can you also test 3.7-rc4, to ensure that the problem isn't there
as well?
I've narrowed it down to this patch which introduces the problem:
Johannes Berg:
mac80211: connect with HT20 if HT40 is not permitted
commit
On Mon, 2012-11-05 at 10:27 +0200, Arik Nemtsov wrote:
These are accessed without a lock when ending STA PSM. If the
sta_cleanup timer accesses these lists at the same time, we might crash.
This may fix some mysterious crashes we had during
ieee80211_sta_ps_deliver_wakeup.
Cc:
Hi Eddie,
Here is the output of /sys/kernel/debug/ieee80211/phy0/ht40allow_map:
Ok, thanks.
2412 HT40 +
2417 HT40 +
2422 HT40 +
2427 HT40 +
2432 HT40 -+
2437 HT40 -+
2442 HT40 -+
2447 HT40 -
2452 HT40 -
2457 HT40 -
2462 HT40 -
2467 HT40
2472 HT40
2484 HT40
That looks
...@intel.com
Tested-by: Brian Cockrell brian.cockr...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
---
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c |1 +
1 file
From: Johannes Berg johannes.b...@intel.com
Upstream commit 4fc79db178f0a0ede479b4713e00df2d106028b3.
If the device is not started, we can't read its
SRAM and attempting to do so will cause issues.
Protect the debugfs read.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg johannes.b
From: Johannes Berg johannes.b...@intel.com
Upstream commit 94543a8d4fb302817014981489f15cb3b92ec3c2.
iwl_dbgfs_fh_reg_read() can cause crashes and/or
BUG_ON in slub because the ifdefs are wrong, the
code in iwl_dump_fh() should use DEBUGFS, not
DEBUG to protect the buffer writing code.
Also
the average rssi for the interface
(the function assumes that the vif is valid and that the type
is station).
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Ilan Peer ilan.p...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
This patch narrowly missed 3.5
On Wed, 2012-08-01 at 12:14 -0400, Paul Gortmaker wrote:
[...]
However, things still weren't right unless he also cherry picked the
8e8b41f9d8c8e6 (cfg80211: enforce lack of interface combinations)
to get the later mentioned total == 1 check within, so that we
avoid the EBUSY above. But
On Wed, 2012-08-01 at 13:38 -0400, Paul Gortmaker wrote:
1) cherry pick 8e8b41f9d, and all the driver specific changes it requires
2) make a sub-commit for stable that just takes the total==1 from #1.
3) patch iwlwifi/iwl-mac80211.c and add .types =
BIT(NL80211_IFTYPE_ADHOC)
Signed-off-by: Ilan Peer ilan.p...@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index
From: Johannes Berg johannes.b...@intel.com
No upstream commit, the buggy code was removed in 3.5.
Rajkumar changed code for handling channel switching in
mac80211 to stop the queues in
commit 7cc44ed48d0ec0937c1f098642540b6c9ca38de5
Author: Rajkumar Manoharan rmano...@qca.qualcomm.com
On Wed, 2012-06-27 at 15:32 -0500, Jonathan Nieder wrote:
Johannes Berg wrote:
No upstream commit, the buggy code was removed in 3.5.
What upstream commit removed the buggy code?
Nothing git can't answer :-)
7213cf2cb0dfbb4d6b55a1da000d34338f76c0e3
But of course that just removed
] inet_ioctl+0x95/0xb0
[ 6427.080304] [c147a0f0] sock_ioctl+0x70/0x270
Cc: stable@vger.kernel.org
Reported-by: Antonio Quartulli or...@autistici.org
Tested-by: Antonio Quartulli or...@autistici.org
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg johannes.b
version for 6035
is v6.
Also correct the minimum supported firmware
version for the 6000g2 series of devices.
Cc: sta...@kernel.org
Signed-off-by: Meenakshi Venkataraman meenakshi.venkatara...@intel.com
Reviewed-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Signed-off-by: Johannes Berg
From: Johannes Berg johannes.b...@intel.com
commit a5fdde28b4f5fb756032e7ad2c6fcdcffde20958 upstream.
Since my commit
iwlwifi: use valid TX/RX antenna from hw_params
the config values are pure overrides, not the
real values for all hardware. Therefore, the
EEPROM TX power reading code checks
On Sun, 2012-06-03 at 23:32 +0300, Arik Nemtsov wrote:
sta_info_cleanup locks the sta_list using rcu_read_lock however
the delete operation isn't rcu safe. A race between sta_info_cleanup
timer being called and a STA being removed can occur which leads
to a panic while traversing sta_list. Fix
Hi Mohammed,
You could just remove the entire check since the interface combinations
you advertise don't allow it, I think? Or just fix those
combinations :-)
i did not check this before, thanks a lot for your inputs. will send a
proper v2 after checking this out.
If this is
On Fri, 2012-06-01 at 12:39 +0530, Mohammed Shafi Shajakhan wrote:
Hi Johannes,
On Friday 01 June 2012 12:14 PM, Johannes Berg wrote:
On Fri, 2012-06-01 at 12:09 +0530, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
In ath9k we make sure
John,
The logic that allows to have a short TFD queue was completely wrong.
We do maintain 256 Transmit Frame Descriptors, but they point to
recycled buffers. We used to attach and de-attach different TFDs for
the same buffer and it worked since they pointed to the same buffer.
Also zero
/0x270
Cc: stable@vger.kernel.org
Reported-by: Antonio Quartulli or...@autistici.org
Tested-by: Antonio Quartulli or...@autistici.org
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
Reviewed-by: Wey-Yi W Guy wey-yi.w@intel.com
Signed-off-by: Johannes Berg johannes.b...@intel.com
...@qca.qualcomm.com
Tested-by: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
Signed-off-by: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
Acked-by: Johannes Berg johannes.b...@intel.com
---
net/mac80211/main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net
70 matches
Mail list logo
