* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Johannes Berg @ 2017-09-14 11:44 UTC (permalink / raw)
To: Arend van Spriel, Arend van Spriel, Jouni Malinen
Cc: Avraham Stern, linux-wireless, Denis Kenzior
In-Reply-To: <e4a3ab99-f49a-0849-56d7-71ce19b1f323@broadcom.com>
On Thu, 2017-09-14 at 13:21 +0200, Arend van Spriel wrote:
> Yep. Toggling the OPER_STATE seems to go against what roaming is
> about.
Agree.
> Come to think of it, is it a good idea to tightly couple
> PORT_AUTHORIZED to OPER_STATE. Aren't these separate concepts in
> different layers of the network stack.
Well, I think that coupling would make the most sense, since once you
have oper state UP you'll try to get IPv6 etc., no? And before being
authorized there's no point.
Note that we *can't* do this right now, otherwise we can't transfer the
EAPOL frames; but once we do that over nl80211 we'd be able to.
> In earlier discussions the proposal for a separate event was made by
> Jithu (colleague). In brcmfmac it would become a bit less
> complicated with a separate event so it has my vote as well. So the
> AUTHORIZED event will have no attributes, right? So if the event
> occurs it is AUTHORIZED.
I think so, yes. I pondered having the attribute in there so you could
explicitly have a "not authorized" event, but do we really need that?
If you get disconnected that's pretty much implied, so ... I don't
think we need it.
> > (*) is anyone working on that? I'll throw it on my list if not.
["that" being EAPOL-over-nl80211]
> The last I saw on this was Denis Kenzior volunteering for it, but
> that was about it.
Oh, thanks for the reminder, I'd forgotten entirely...
Denis?
> By the way, I still have wpa_supplicant patches for 4way-hs
> offloading. I need to dust it off a little and obviously did not
> foresee the change above ;-) Let me know if you (Intel) plan to
> submit patches for it.
We also have some patches, we can go either way.
Thanks!
johannes
^ permalink raw reply
* Re: ROAM/CONNECT event with PORT_AUTHORIZED
From: Arend van Spriel @ 2017-09-14 11:21 UTC (permalink / raw)
To: Johannes Berg, Arend van Spriel, Jouni Malinen
Cc: Avraham Stern, linux-wireless
In-Reply-To: <1505378361.31630.2.camel@sipsolutions.net>
On 14-09-17 10:39, Johannes Berg wrote:
> Hi Arend, Jouni, all,
>
> Avi and I just discussed another use case for the PORT_AUTHORIZED flag,
> which is PMKSA caching.
>
> Assume you have 4-way-HS offloaded, then if you send a PMKID in the new
> connection (doesn't matter if it's roaming or not), the AP may chose to
> use it and start the 4-way-HS, or it may not be able to and start the
> 802.1X handshake.
>
> In the supplicant, if you are waiting for the 1X handshake, then in the
> case the PMKSA gets used the supplicant would wait forever, and
> eventually terminate the connection because the handshake isn't
> successful.
>
> Thus, *both* cases need to know about the PORT_AUTHORIZED flag.
>
> I previously didn't apply the patch for the flag in CONNECT
> notification, but nobody is using it in ROAM notification so far, so
> that we still have a chance of revisiting this.
>
> Throwing a potential EAPOL-over-nl80211 (*) into the mix complicates
> the picture further. For example, in that case the OPER_STATE might not
> be set to UP until the port is authorized. In the case of roaming, this
> might - on first sight - lead to toggling DOWN/UP if a new 1X handshake
> needs to be done and the PORT_AUTHORIZED flag doesn't come with the
> ROAM event. However, I think this is actually wrong as it would
> probably lose IPv6 address assignment etc. - so I think we don't want
> to do this even if we do have EAPOL-over-nl80211 and don't need the
> oper_state to be up in order to do the 1X handshake. Do you agree with
> this assessment?
Yep. Toggling the OPER_STATE seems to go against what roaming is about.
Come to think of it, is it a good idea to tightly couple PORT_AUTHORIZED
to OPER_STATE. Aren't these separate concepts in different layers of the
network stack.
> Assuming this assessment is correct, this opens up another possibility:
> tracking the PORT_AUTHORIZED state with a separate event:
>
> * new connection case - no PMKSA (usage)
> - CONNECT event
> - [if !eapol-over-nl: toggle oper state up]
> - initialize 1X state machines/timeouts
> - 1X handshake
> - send PMK to device for 4-way-HS
> - AUTHORIZED event
> - [if eapol-over-nl: toggle oper state up]
>
> * new connection case - PMKSA usage
> - CONNECT event
> - [if !eapol-over-nl: toggle oper state up]
> - initialize 1X state machines/timeouts
> - AUTHORIZED event
> - stop 1X state machine/timeouts
> - [if eapol-over-nl: toggle oper state up]
>
> * roaming case - no PMKSA (usage)
> - ROAM event
> - [no touching oper state]
> - initialize 1X state machines/timeouts
> - 1X handshake
> - AUTHORIZED event
> - [no touching oper state]
>
> * roaming case - PMKSA usage
> - ROAM event
> - [no touching oper state]
> - initialize 1X state machines/timeouts
> - AUTHORIZED event
> - stop 1X state machine/timeouts
> - [no touching oper state]
>
>
> Does this seem reasonable? If possible, I prefer this to just having
> the attribute, because with the attribute the roaming case will be
> difficult, the natural code flow in the driver would probably make it
> end up looking like this:
>
> * roaming case - no PMKSA (usage)
> - ROAM event
> - [no touching
> oper state]
> - initialize 1X state machines/timeouts
> - 1X
> handshake
> - CONNECT event w/ PORT_AUTHORIZED
> - [no touching oper
> state]
>
> which seems awkward.
>
> Any other thoughts?
In earlier discussions the proposal for a separate event was made by
Jithu (colleague). In brcmfmac it would become a bit less complicated
with a separate event so it has my vote as well. So the AUTHORIZED event
will have no attributes, right? So if the event occurs it is AUTHORIZED.
> johannes
>
> (*) is anyone working on that? I'll throw it on my list if not.
The last I saw on this was Denis Kenzior volunteering for it, but that
was about it.
By the way, I still have wpa_supplicant patches for 4way-hs offloading.
I need to dust it off a little and obviously did not foresee the change
above ;-) Let me know if you (Intel) plan to submit patches for it.
Regards,
Arend
^ permalink raw reply
* Re: rtl8821ae keep alive not set, connection lost
From: James Cameron @ 2017-09-14 9:27 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, Kalle Valo
In-Reply-To: <5f16881e-471b-4ffc-5e5e-93785bb999b6@lwfinger.net>
On Wed, Sep 13, 2017 at 07:39:35PM -0500, Larry Finger wrote:
> On 09/13/2017 04:46 PM, James Cameron wrote:
> >
> >I'll give it some more testing and let you know, but it seems as
> >capable of keeping a connection as 4.13 plus my earlier revert.
> >
Testing went well; removing the call to enable ASPM was as good as
changing the DBI read back to 16-bit width.
> The change I sent earlier should be as good as reverting the change
> to write_byte in your reversion.
Yes, that would be the hope.
But with the 16-bit DBI read, the register REG_DBI_CTRL+0 is being
read as well, in the first read in _rtl8821ae_enable_aspm_back_door,
so perhaps reading that register has an unexpected side-effect.
Is there any documentation for that register? I see other code writes
to REG_DBI_CTRL+3, in _rtl8821ae_check_pcie_dma_hang
Evidence of read from REG_DBI_CTRL was captured with an instrumented
kernel; git diff http://dev.laptop.org/~quozl/y/1dsQ6B.txt yielding
these dmesg lines;
[ 6.010255] rtl_pci: _rtl_pci_update_default_setting const_amdpci_aspm=03
[ 6.010338] rtl_pci: rtl_pci_enable_aspm
[ 6.034295] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 6.034806] rtlwifi: rtlwifi: wireless switch is on
[ 6.196958] rtl8821ae 0000:02:00.0 wlp2s0: renamed from wlan0
[ 7.979186] rtl_pci: rtl_pci_disable_aspm
[ 7.979306] rtl8821ae: _rtl8821ae_check_pcie_dma_hang
[ 8.295360] rtl8821ae: _rtl8821ae_enable_aspm_back_door
[ 8.295437] rtl8821ae: _rtl8821ae_dbi_read 070f -> ffff (@034f)
[ 8.295449] rtl8821ae: _rtl8821ae_dbi_write 070f <- ff (@870c)
[ 8.295462] rtl8821ae: _rtl8821ae_dbi_read 0719 -> 0200 (@034d)
[ 8.295474] rtl8821ae: _rtl8821ae_dbi_write 0719 <- 18 (@2718)
[ 8.295477] rtl_pci: rtl_pci_enable_aspm
[ 8.469734] rtl_pci: rtl_pci_disable_aspm
[ 8.469857] rtl8821ae: _rtl8821ae_check_pcie_dma_hang
[ 8.686955] rtl8821ae: _rtl8821ae_enable_aspm_back_door
[ 8.687013] rtl8821ae: _rtl8821ae_dbi_read 070f -> ffff (@034f)
[ 8.687025] rtl8821ae: _rtl8821ae_dbi_write 070f <- ff (@870c)
[ 8.687038] rtl8821ae: _rtl8821ae_dbi_read 0719 -> 0218 (@034d)
[ 8.687050] rtl8821ae: _rtl8821ae_dbi_write 0719 <- 18 (@2718)
[ 8.687053] rtl_pci: rtl_pci_enable_aspm
Observe how the windowed read of DBI register 0x70f causes a read of
16-bits at 0x34f, which includes first 8-bits of 0x350 REG_DBI_CTRL.
By the way, the cold boot value of DBI register 0x719 is 0x00, and
the warm boot value is 0x18, so I'm confident there isn't a
comprehensive register reset. It means that BIOS has relevance; and
this BIOS is outside my control. BIOS variation may explain
difficulty reproducing.
> There has been a report (in Russian unfortunately) at
> https://www.linux.org.ru/forum/desktop/12620193 of delays in ARP
> handling.
Thanks. I've considered and excluded ARP handling delay. Though ARP
renewal is typical reason for device sleep to end.
With the call to enable ASPM disabled, instead of changing the DBI
read to 16-bit width, what happens is that the device stops accepting
data from the access point, packets are buffered there, and are
transmitted as soon as the device makes the next transmission.
http://dev.laptop.org/~quozl/z/1dsQBf.txt has the ping and IP tcpdump
to confirm this.
I've a monitor mode tcpdump I can send by private mail if required.
In that the burst of packets shows ICMP echo requests were buffered by
the access point.
> According to Google translate is as follows:
>
> ============================================================
> Periodically, Wi-Fi networker rtl8821ae ceases to respond to ARP,
> which causes the Internet to end. Wireshark looks quite interesting:
> ARP replays can be sent by one large packet a few seconds after
> receiving the requests, ie. they seem to be buffered somewhere.
Yes, buffering at access point.
> I need to explore that ENOBUFS return code.
I've seen ENOBUFS up at the application level with ping too, when the
original problem happens with v4.10 plus stable.
> Your case where the device is unresponsive to pings from another NIC
> until the device transmits may also be an ARP problem.
>
> For completeness, are you using the 2.4 of 5 GHz band? What is the
> make/model your AP? If possible for you to determine, what firmware
> is it running?
2.4 GHz and 5 GHz reproduces the problem.
Open or WPA reproduces the problem.
Netgear WNDR3800 OpenWrt 12.09-beta, r33312.
Several other access points reproduce the problem, including a
customer's TP-Link TL-WR1042ND with unknown firmware version.
No access point as yet does not reproduce the problem.
Hope that helps, thanks for your ideas.
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: [PATCH v1] iwlwifi: mvm: allow monitor mode capture in STA mode
From: Johannes Berg @ 2017-09-14 8:54 UTC (permalink / raw)
To: gavinli, Emmanuel Grumbach, Luca Coelho, Intel Linux Wireless
Cc: linux-wireless, Gavin Li
In-Reply-To: <20170914085006.15933-1-gavinli@thegavinli.com>
On Thu, 2017-09-14 at 01:50 -0700, gavinli@thegavinli.com wrote:
>
> cmd->filter_flags = cpu_to_le32(MAC_FILTER_ACCEPT_GRP);
>
> + if (mvm->hw->conf.flags & IEEE80211_CONF_MONITOR)
> + cmd->filter_flags |=
> cpu_to_le32(MAC_FILTER_IN_PROMISC |
> + MAC_FILTER_IN_CONTR
> OL_AND_MGMT |
> + MAC_FILTER_IN_BEACO
> N |
> + MAC_FILTER_IN_PROBE
> _REQUEST);
[...]
> + if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
> + mutex_lock(&mvm->mutex);
> + ieee80211_iterate_active_interfaces(hw,
> IEEE80211_IFACE_ITER_NORMAL,
> + iwl_mvm_monitor_changed_iterator,
> mvm);
> + mutex_unlock(&mvm->mutex);
> + }
This isn't right from a mac80211 perspective - at the very least it
should follow the monitor flags; checking CONF_CHANGE_MONITOR is always
a bad idea.
johannes
^ permalink raw reply
* [PATCH v1] iwlwifi: mvm: allow monitor mode capture in STA mode
From: gavinli @ 2017-09-14 8:50 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless
Cc: linux-wireless, Gavin Li
From: Gavin Li <git@thegavinli.com>
Open up the filter if there is a monitor interface configured; this
allows all packets on the channel to be captured even if the device is
in STA mode and associated to a BSS.
Signed-off-by: Gavin Li <git@thegavinli.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 6 ++++++
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 15 +++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index a2bf530eeae4..38b933dc8545 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -654,6 +654,12 @@ static void iwl_mvm_mac_ctxt_cmd_common(struct iwl_mvm *mvm,
cmd->filter_flags = cpu_to_le32(MAC_FILTER_ACCEPT_GRP);
+ if (mvm->hw->conf.flags & IEEE80211_CONF_MONITOR)
+ cmd->filter_flags |= cpu_to_le32(MAC_FILTER_IN_PROMISC |
+ MAC_FILTER_IN_CONTROL_AND_MGMT |
+ MAC_FILTER_IN_BEACON |
+ MAC_FILTER_IN_PROBE_REQUEST);
+
for (i = 0; i < IEEE80211_NUM_ACS; i++) {
u8 txf = iwl_mvm_mac_ac_to_tx_fifo(mvm, i);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 15f2d826bb4b..c529fb8228df 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -1530,8 +1530,23 @@ static void iwl_mvm_mac_remove_interface(struct ieee80211_hw *hw,
mutex_unlock(&mvm->mutex);
}
+static void iwl_mvm_monitor_changed_iterator(void *_mvm, u8 *mac, struct ieee80211_vif *vif)
+{
+ struct iwl_mvm *mvm = _mvm;
+ iwl_mvm_mac_ctxt_changed(mvm, vif, false, NULL);
+}
+
static int iwl_mvm_mac_config(struct ieee80211_hw *hw, u32 changed)
{
+ struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
+
+ if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
+ mutex_lock(&mvm->mutex);
+ ieee80211_iterate_active_interfaces(hw, IEEE80211_IFACE_ITER_NORMAL,
+ iwl_mvm_monitor_changed_iterator, mvm);
+ mutex_unlock(&mvm->mutex);
+ }
+
return 0;
}
--
2.14.1
^ permalink raw reply related
* ROAM/CONNECT event with PORT_AUTHORIZED
From: Johannes Berg @ 2017-09-14 8:39 UTC (permalink / raw)
To: Arend van Spriel, Jouni Malinen; +Cc: Avraham Stern, linux-wireless
Hi Arend, Jouni, all,
Avi and I just discussed another use case for the PORT_AUTHORIZED flag,
which is PMKSA caching.
Assume you have 4-way-HS offloaded, then if you send a PMKID in the new
connection (doesn't matter if it's roaming or not), the AP may chose to
use it and start the 4-way-HS, or it may not be able to and start the
802.1X handshake.
In the supplicant, if you are waiting for the 1X handshake, then in the
case the PMKSA gets used the supplicant would wait forever, and
eventually terminate the connection because the handshake isn't
successful.
Thus, *both* cases need to know about the PORT_AUTHORIZED flag.
I previously didn't apply the patch for the flag in CONNECT
notification, but nobody is using it in ROAM notification so far, so
that we still have a chance of revisiting this.
Throwing a potential EAPOL-over-nl80211 (*) into the mix complicates
the picture further. For example, in that case the OPER_STATE might not
be set to UP until the port is authorized. In the case of roaming, this
might - on first sight - lead to toggling DOWN/UP if a new 1X handshake
needs to be done and the PORT_AUTHORIZED flag doesn't come with the
ROAM event. However, I think this is actually wrong as it would
probably lose IPv6 address assignment etc. - so I think we don't want
to do this even if we do have EAPOL-over-nl80211 and don't need the
oper_state to be up in order to do the 1X handshake. Do you agree with
this assessment?
Assuming this assessment is correct, this opens up another possibility:
tracking the PORT_AUTHORIZED state with a separate event:
* new connection case - no PMKSA (usage)
- CONNECT event
- [if !eapol-over-nl: toggle oper state up]
- initialize 1X state machines/timeouts
- 1X handshake
- send PMK to device for 4-way-HS
- AUTHORIZED event
- [if eapol-over-nl: toggle oper state up]
* new connection case - PMKSA usage
- CONNECT event
- [if !eapol-over-nl: toggle oper state up]
- initialize 1X state machines/timeouts
- AUTHORIZED event
- stop 1X state machine/timeouts
- [if eapol-over-nl: toggle oper state up]
* roaming case - no PMKSA (usage)
- ROAM event
- [no touching oper state]
- initialize 1X state machines/timeouts
- 1X handshake
- AUTHORIZED event
- [no touching oper state]
* roaming case - PMKSA usage
- ROAM event
- [no touching oper state]
- initialize 1X state machines/timeouts
- AUTHORIZED event
- stop 1X state machine/timeouts
- [no touching oper state]
Does this seem reasonable? If possible, I prefer this to just having
the attribute, because with the attribute the roaming case will be
difficult, the natural code flow in the driver would probably make it
end up looking like this:
* roaming case - no PMKSA (usage)
- ROAM event
- [no touching
oper state]
- initialize 1X state machines/timeouts
- 1X
handshake
- CONNECT event w/ PORT_AUTHORIZED
- [no touching oper
state]
which seems awkward.
Any other thoughts?
johannes
(*) is anyone working on that? I'll throw it on my list if not.
^ permalink raw reply
* Re: rtl8821ae keep alive not set, connection lost
From: Larry Finger @ 2017-09-14 0:39 UTC (permalink / raw)
To: James Cameron; +Cc: linux-wireless, Ping-Ke Shih, Kalle Valo
In-Reply-To: <20170913214649.GC20283@us.netrek.org>
On 09/13/2017 04:46 PM, James Cameron wrote:
>
> I'll give it some more testing and let you know, but it seems as
> capable of keeping a connection as 4.13 plus my earlier revert.
>
The change I sent earlier should be as good as reverting the change to
write_byte in your reversion.
There has been a report (in Russian unfortunately) at
https://www.linux.org.ru/forum/desktop/12620193 of delays in ARP handling.
According to Google translate is as follows:
============================================================
Periodically, Wi-Fi networker rtl8821ae ceases to respond to ARP, which causes
the Internet to end. Wireshark looks quite interesting: ARP replays can be sent
by one large packet a few seconds after receiving the requests, ie. they seem to
be buffered somewhere.
arping, launched under strace, also hints at certain problems:
sendto(3,
"\0\1\10\0\6\4\0\1\334\205\336\3572\343\300\250\0h\377\377\377\377\377\377\300\250\0\1",
28, 0, {sa_family=AF_PACKET, proto=0x806, if3, pkttype=PACKET_HOST, addr(6)={1,
ffffffffffff}, 20) = -1 ENOBUFS (No buffer space available)
alarm(1) = 0
rt_sigreturn() = 45
recvfrom(3, 0x7fffc1646030, 4096, 0, 0x7fffc1645fb0, 0x7fffc1645eac) = ?
ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
sendto(3,
"\0\1\10\0\6\4\0\1\334\205\336\3572\343\300\250\0h\377\377\377\377\377\377\300\250\0\1",
28, 0, {sa_family=AF_PACKET, proto=0x806, if3, pkttype=PACKET_HOST, addr(6)={1,
ffffffffffff}, 20) = -1 ENOBUFS (No buffer space available)
alarm(1) = 0
rt_sigreturn() = 45
recvfrom(3, 0x7fffc1646030, 4096, 0, 0x7fffc1645fb0, 0x7fffc1645eac) = ?
ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
recvfrom(3, 0x7fffc1646030, 4096, 0, 0x7fffc1645fb0, 0x7fffc1645eac) = ?
ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
sendto(3,
"\0\1\10\0\6\4\0\1\334\205\336\3572\343\300\250\0h\377\377\377\377\377\377\300\250\0\1",
28, 0, {sa_family=AF_PACKET, proto=0x806, if3, pkttype=PACKET_HOST, addr(6)={1,
ffffffffffff}, 20) = -1 ENOBUFS (No buffer space available)
============================================================
I need to explore that ENOBUFS return code.
Your case where the device is unresponsive to pings from another NIC until the
device transmits may also be an ARP problem.
For completeness, are you using the 2.4 of 5 GHz band? What is the make/model
your AP? If possible for you to determine, what firmware is it running?
Thanks,
Larry
^ permalink raw reply
* Re: rtl8821ae keep alive not set, connection lost
From: James Cameron @ 2017-09-13 21:46 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih, Kalle Valo
In-Reply-To: <59e28611-9840-8873-2f15-1263e4e93d1c@lwfinger.net>
On Wed, Sep 13, 2017 at 10:01:37AM -0500, Larry Finger wrote:
> Thank you very much for making the effort to bisect this problem. I
> know that several people have reported the problem, which we cannot
> duplicate; however, most of them just say it drops the connection
> and do nothing more. In fact, we are lucky to have them even report
> which kernel version they are running!
Yes, in the reported bugs that style is common; almost animistic, very
mystical, and based on heuristics rather than analysis. ;-)
> As we do not see the problem, we will be relying on you to help
> diagnose the issue. Merely changing the read from 8 to 16 bits
> should not cause any change.
Agreed.
> As _rtl8821ae_dbi_read() is only called from
> _rtl8821ae_enable_aspm_back_door(), we want to test turning off
> ASPM. The following patch will accomplish this. Unfortunately, the
> patch is white-space damaged, thus you will need to apply it
> manually. Please try it to see if it helps your connection
> loss. Note that ASPM settings are preserved through a module
> unload/reload sequence. Thus you will need to reboot after
> rebuilding the driver.
Went back to 4.13, added your test patch, and built kernel.
http://dev.laptop.org/~quozl/z/1dsFOW.txt is dmesg.
New symptom occurs; after 23 seconds since last transmission, the
device becomes unresponsive to ping from another host, but begins to
respond if the device transmits. Flurry of responses then it settles
down to regular ping.
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=39 ttl=64 time=1.71 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=40 ttl=64 time=1.93 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=41 ttl=64 time=1.71 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=42 ttl=64 time=1.66 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=43 ttl=64 time=1.70 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=44 ttl=64 time=1.69 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=45 ttl=64 time=37.7 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=46 ttl=64 time=383 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=47 ttl=64 time=11464 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=48 ttl=64 time=10465 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=49 ttl=64 time=9465 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=50 ttl=64 time=8466 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=51 ttl=64 time=7466 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=52 ttl=64 time=6466 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=53 ttl=64 time=5466 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=54 ttl=64 time=4467 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=55 ttl=64 time=3467 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=56 ttl=64 time=2468 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=57 ttl=64 time=1468 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=58 ttl=64 time=469 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=59 ttl=64 time=1.79 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=60 ttl=64 time=1.75 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=61 ttl=64 time=1.72 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=62 ttl=64 time=1.68 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=63 ttl=64 time=1.68 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=64 ttl=64 time=1.95 ms
64 bytes from nl3-e.lan (10.0.0.94): icmp_seq=65 ttl=64 time=1.68 ms
I'll give it some more testing and let you know, but it seems as
capable of keeping a connection as 4.13 plus my earlier revert.
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* [PATCH] ath10k: make ath10k_hw_ce_regs const
From: Bhumika Goyal @ 2017-09-13 19:01 UTC (permalink / raw)
To: julia.lawall, kvalo, ath10k, linux-wireless, netdev, linux-kernel
Cc: Bhumika Goyal
Make them const as they are not modified in the file referencing
them. They are only stored in the const field 'hw_ce_reg' of an ath10k
structure. Also, make the declarations in the header const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/wireless/ath/ath10k/hw.c | 4 ++--
drivers/net/wireless/ath/ath10k/hw.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.c b/drivers/net/wireless/ath/ath10k/hw.c
index a860691..07df7c6 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -310,7 +310,7 @@
.wm_high = &wcn3990_dst_wm_high,
};
-struct ath10k_hw_ce_regs wcn3990_ce_regs = {
+const struct ath10k_hw_ce_regs wcn3990_ce_regs = {
.sr_base_addr = 0x00000000,
.sr_size_addr = 0x00000008,
.dr_base_addr = 0x0000000c,
@@ -457,7 +457,7 @@ struct ath10k_hw_ce_regs wcn3990_ce_regs = {
.wm_high = &qcax_dst_wm_high,
};
-struct ath10k_hw_ce_regs qcax_ce_regs = {
+const struct ath10k_hw_ce_regs qcax_ce_regs = {
.sr_base_addr = 0x00000000,
.sr_size_addr = 0x00000004,
.dr_base_addr = 0x00000008,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 0c089f6..f80840f 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -369,8 +369,8 @@ struct ath10k_hw_values {
extern const struct ath10k_hw_values qca9888_values;
extern const struct ath10k_hw_values qca4019_values;
extern const struct ath10k_hw_values wcn3990_values;
-extern struct ath10k_hw_ce_regs wcn3990_ce_regs;
-extern struct ath10k_hw_ce_regs qcax_ce_regs;
+extern const struct ath10k_hw_ce_regs wcn3990_ce_regs;
+extern const struct ath10k_hw_ce_regs qcax_ce_regs;
void ath10k_hw_fill_survey_time(struct ath10k *ar, struct survey_info *survey,
u32 cc, u32 rcc, u32 cc_prev, u32 rcc_prev);
--
1.9.1
^ permalink raw reply related
* Re: rtl8821ae keep alive not set, connection lost
From: Larry Finger @ 2017-09-13 15:01 UTC (permalink / raw)
To: James Cameron, linux-wireless; +Cc: Ping-Ke Shih, Kalle Valo
In-Reply-To: <20170912220916.GB32211@us.netrek.org>
On 09/12/2017 05:09 PM, James Cameron wrote:
> Summary: 40b368af4b75 ("rtlwifi: Fix alignment issues") breaks
> rtl8821ae keep alive, causing "Connection to AP lost" and deauth, but
> why?
>
> Wireless connection is lost after a few seconds or minutes, on every
> OLPC NL3 laptop with rtl8821ae, with any stable kernel after 4.10.1,
> and any kernel with 40b368af4b75.
>
> dmesg contains
>
> wlp2s0: Connection to AP 2c:b0:5d:a6:86:eb lost
>
> iw event shows
>
> wlp2s0: del station 2c:b0:5d:a6:86:eb
> wlp2s0 (phy #0): deauth 74:c6:3b:09:b5:0d -> 2c:b0:5d:a6:86:eb reason 4: Disassociated due to inactivity
> wlp2s0 (phy #0): disconnected (local request)
>
> Workaround is to bounce the link, then reconnect;
>
> ip link set wlp2s0 down
> ip link set wlp2s0 up
> iw dev wlp2s0 connect qz
>
> A nearby monitor host captures a deauthentication packet sent by the
> device.
>
> Bisection showed cause is 40b368af4b75 ("rtlwifi: Fix alignment
> issues") which changes the width of DBI register read.
>
> On the face of it, 40b368af4b75 looks correct, especially compared
> against same function in rtl8723be.
>
> I've no idea why reverting fixes the problem. I'm hoping someone here
> might speculate and suggest ways to test.
>
> As keep alive is set through this path, my guess is that keep alive is
> not being set in the device. Or perhaps reading 16-bits perturbs
> another register. Is there a way to test?
>
> http://dev.laptop.org/~quozl/z/1drtGD.txt dmesg of 4.13
>
> http://dev.laptop.org/~quozl/z/1drt7c.txt dmesg with 4.13 and revert
> of 40b368af4b75
James,
Thank you very much for making the effort to bisect this problem. I know that
several people have reported the problem, which we cannot duplicate; however,
most of them just say it drops the connection and do nothing more. In fact, we
are lucky to have them even report which kernel version they are running!
As we do not see the problem, we will be relying on you to help diagnose the
issue. Merely changing the read from 8 to 16 bits should not cause any change.
As _rtl8821ae_dbi_read() is only called from _rtl8821ae_enable_aspm_back_door(),
we want to test turning off ASPM. The following patch will accomplish this.
Unfortunately, the patch is white-space damaged, thus you will need to apply it
manually. Please try it to see if it helps your connection loss. Note that ASPM
settings are preserved through a module unload/reload sequence. Thus you will
need to reboot after rebuilding the driver.
diff --git a/rtl8821ae/hw.c b/rtl8821ae/hw.c
index 305b3abbf..755d3704b 100644
--- a/rtl8821ae/hw.c
+++ b/rtl8821ae/hw.c
@@ -1982,8 +1982,8 @@ int rtl8821ae_hw_init(struct ieee80211_hw *hw)
ppsc->rfpwr_state = ERFON;
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_ETHER_ADDR, mac->mac_addr);
- _rtl8821ae_enable_aspm_back_door(hw);
- rtlpriv->intf_ops->enable_aspm(hw);
+ //_rtl8821ae_enable_aspm_back_door(hw);
+ //rtlpriv->intf_ops->enable_aspm(hw);
if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE &&
(rtlhal->rfe_type == 1 || rtlhal->rfe_type == 5))
Thanks,
Larry
^ permalink raw reply related
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Kalle Valo @ 2017-09-13 4:20 UTC (permalink / raw)
To: Greg KH
Cc: Arend van Spriel, Kevin Cernekee, franky.lin,
brcm80211-dev-list.pdl, linux-wireless, mnissler
In-Reply-To: <20170912123341.GA19179@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Tue, Sep 12, 2017 at 10:18:00AM +0200, Arend van Spriel wrote:
>> + Greg KH
>>
>> On 9/12/2017 10:05 AM, Kalle Valo wrote:
>> > Arend van Spriel <arend.vanspriel@broadcom.com> writes:
>> >
>> > > It is actually in the stable-kernel-rules documentation [1]:
>> > >
>> > > """
>> > > Also, some patches may have kernel version prerequisites. This can be
>> > > specified in the following format in the sign-off area:
>> > >
>> > > .. code-block:: none
>> > >
>> > > Cc: <stable@vger.kernel.org> # 3.3.x
>> > >
>> > > The tag has the meaning of:
>> > >
>> > > .. code-block:: none
>> > >
>> > > git cherry-pick <this commit>
>> > >
>> > > For each "-stable" tree starting with the specified version.
>> > > """
>> >
>> > Yeah, but it says "starting with" which I interpret as "starting with
>> > string '3.3'". For example the commit here would be applied to 3.3.1,
>> > 3.3.2 and 3.3.3 etc but _not_ to 3.4, 3.4.1, 3.5 or any later release.
>> >
>> > Of course I can be way off here, wouldn't be the first :)
>>
>> Dito. I interpret "each -stable tree" as each stable branch in the stable
>> repository. Would Greg know?
>
> "# 3.8+" and "# 3.8" mean the same thing to me, we would never backport
> something to only a very specific kernel version, and leave newer kernel
> versions to not have that fix. That would be crazy, and would break our
> "no regressions" rule (i.e. newer kernels should always work as good as
> older kernels.)
Indeed, that would be crazy. Didn't think it like that, thanks for the
clarification.
> Don't get hung up on the semantics here people, it's not all that
> complicated, and I do it all by hand anyway :)
Manually? Oh man, that has to be so hard. I cannot understand how you
can do it.
--
Kalle Valo
^ permalink raw reply
* [PATCH] nl80211: check for the required netlink attributes presence
From: Vladis Dronov @ 2017-09-12 22:21 UTC (permalink / raw)
To: Johannes Berg, Johannes Berg, linux-wireless, linux-kernel
Cc: Vladis Dronov, # v3 . 1-rc1
nl80211_set_rekey_data() does not check if the required attributes
NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
users with CAP_NET_ADMIN privilege and may result in NULL dereference
and a system crash. Add a check for the required attributes presence.
This patch is based on the patch by bo Zhang.
This fixes CVE-2017-12153.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046
Fixes: e5497d766ad ("cfg80211/nl80211: support GTK rekey offload")
Cc: <stable@vger.kernel.org> # v3.1-rc1
Reported-by: bo Zhang <zhangbo5891001@gmail.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
---
net/wireless/nl80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 0df8023..fbd5593 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10903,6 +10903,9 @@ static int nl80211_set_rekey_data(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
+ if (!tb[NL80211_REKEY_DATA_REPLAY_CTR] || !tb[NL80211_REKEY_DATA_KEK] ||
+ !tb[NL80211_REKEY_DATA_KCK])
+ return -EINVAL;
if (nla_len(tb[NL80211_REKEY_DATA_REPLAY_CTR]) != NL80211_REPLAY_CTR_LEN)
return -ERANGE;
if (nla_len(tb[NL80211_REKEY_DATA_KEK]) != NL80211_KEK_LEN)
--
2.9.5
^ permalink raw reply related
* rtl8821ae keep alive not set, connection lost
From: James Cameron @ 2017-09-12 22:09 UTC (permalink / raw)
To: linux-wireless; +Cc: Ping-Ke Shih, Larry Finger, Kalle Valo
Summary: 40b368af4b75 ("rtlwifi: Fix alignment issues") breaks
rtl8821ae keep alive, causing "Connection to AP lost" and deauth, but
why?
Wireless connection is lost after a few seconds or minutes, on every
OLPC NL3 laptop with rtl8821ae, with any stable kernel after 4.10.1,
and any kernel with 40b368af4b75.
dmesg contains
wlp2s0: Connection to AP 2c:b0:5d:a6:86:eb lost
iw event shows
wlp2s0: del station 2c:b0:5d:a6:86:eb
wlp2s0 (phy #0): deauth 74:c6:3b:09:b5:0d -> 2c:b0:5d:a6:86:eb reason 4: Disassociated due to inactivity
wlp2s0 (phy #0): disconnected (local request)
Workaround is to bounce the link, then reconnect;
ip link set wlp2s0 down
ip link set wlp2s0 up
iw dev wlp2s0 connect qz
A nearby monitor host captures a deauthentication packet sent by the
device.
Bisection showed cause is 40b368af4b75 ("rtlwifi: Fix alignment
issues") which changes the width of DBI register read.
On the face of it, 40b368af4b75 looks correct, especially compared
against same function in rtl8723be.
I've no idea why reverting fixes the problem. I'm hoping someone here
might speculate and suggest ways to test.
As keep alive is set through this path, my guess is that keep alive is
not being set in the device. Or perhaps reading 16-bits perturbs
another register. Is there a way to test?
http://dev.laptop.org/~quozl/z/1drtGD.txt dmesg of 4.13
http://dev.laptop.org/~quozl/z/1drt7c.txt dmesg with 4.13 and revert
of 40b368af4b75
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Johannes Berg @ 2017-09-12 20:04 UTC (permalink / raw)
To: Jens Axboe, Luca Coelho, Grumbach, Emmanuel
Cc: linuxwifi, linux-wireless@vger.kernel.org, srinath.mannam,
Bjorn Helgaas
In-Reply-To: <4bcbcbc1-7c79-09f0-5071-bc2f53bf6574@kernel.dk>
On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
> CC'ing the guilty part and Bjorn. I'm assuming it's the
> pci_is_enabled() check, since the rest of the patch shouldn't have
> functional changes.
and pci_enable_bridge() already checks if it's already enabled, but
still enables mastering in that case if it isn't:
static void pci_enable_bridge(struct pci_dev *dev)
{
[...]
if (pci_is_enabled(dev)) {
if (!dev->is_busmaster)
pci_set_master(dev);
return;
}
so I guess due to the new check we end up with mastering disabled, and
thus the firmware can't load since that's a DMA thing?
johannes
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Luca Coelho @ 2017-09-12 19:51 UTC (permalink / raw)
To: Jens Axboe, Grumbach, Emmanuel, Berg, Johannes
Cc: linuxwifi, linux-wireless@vger.kernel.org, srinath.mannam,
Bjorn Helgaas
In-Reply-To: <4bcbcbc1-7c79-09f0-5071-bc2f53bf6574@kernel.dk>
On Tue, 2017-09-12 at 13:43 -0600, Jens Axboe wrote:
> On 09/12/2017 10:36 AM, Luca Coelho wrote:
> > On Tue, 2017-09-12 at 16:11 +0000, Coelho, Luciano wrote:
> > > Hi Jens,
> > >
> > > On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
> > > > Hi,
> > > >
> > > > I have no wifi in current git (8fac2f96ab8), it simply fails with:
> > > >
> > > > [ 4.363481] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
> > > > [ 4.363733] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
> > > > [ 4.363744] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
> > > > [ 4.368077] iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
> > > > [ 4.461753] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> > > > [ ... ]
> > > > [ 9.510570] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
> > > > [ 9.513903] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
> > > > [ 9.516201] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
> > > > [ 9.530842] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
> > > >
> > > > I get the same thing with -27 of the firmware:
> > > >
> > > > [ 60.990831] Intel(R) Wireless WiFi driver for Linux
> > > > [ 60.990833] Copyright(c) 2003- 2015 Intel Corporation
> > > > [ 60.991936] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
> > > > [ 60.991941] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
> > > > [ 60.991946] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
> > > > [ 60.991957] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-31.ucode failed with error -2
> > > > [ 60.991964] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-30.ucode failed with error -2
> > > > [ 60.991969] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-29.ucode failed with error -2
> > > > [ 60.991975] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-28.ucode failed with error -2
> > > > [ 61.029852] iwlwifi 0000:04:00.0: loaded firmware version 27.541033.0 op_mode iwlmvm
> > > > [ 61.043660] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> > > > [ 66.070135] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
> > > > [ 66.070149] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
> > > > [ 66.070165] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
> > > > [ 66.083462] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
> > > >
> > > > Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
> > >
> > > This is strange, Linus has been running this same combination with -31
> > > (with -27 we had a regression, but it was fixed recently and the fix is
> > > in the current master). I have also tried this combination with both
> > > -27 and -31 after my fix and it works fine.
> > >
> > > There are only a couple of other patches that may affect iwlwifi since
> > > the previous net-next.git pull request...
> > >
> > > I'll try this combination on my machine and see if I can reproduce the
> > > problem.
> >
> > I just booted my machine with the latest linux.git/master (8fac2f96ab86)
> > and it works without a problem:
> >
> > [ 8.902174] Intel(R) Wireless WiFi driver for Linux
> > [ 8.902174] Copyright(c) 2003- 2015 Intel Corporation
> > [ 8.995112] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
> > [ 8.995136] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
> > [ 9.026455] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
> > [ 9.348325] iwlwifi 0000:02:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
> > [ 9.369307] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> > [ 9.435915] iwlwifi 0000:02:00.0: base HW address: 34:13:e8:2d:65:ef
> > [ 9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
> >
> >
> > So this seems to be something that doesn't happen in all machines, maybe
> > a PCIe problem?
> >
> > Is there any chance you could try to bisect this?
>
> Bisect done, it tells me that this:
>
> commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9
> Author: Srinath Mannam <srinath.mannam@broadcom.com>
> Date: Fri Aug 18 21:50:48 2017 -0500
>
> PCI: Avoid race while enabling upstream bridges
>
> is the first bad commit. Reverting that on top of master makes things
> work fine again, so that commit is definitely b0rken.
>
> CC'ing the guilty part and Bjorn. I'm assuming it's the pci_is_enabled()
> check, since the rest of the patch shouldn't have functional changes.
Great! I'm glad that you could track it down to a single commit.
Bjorn/Srinath, let me know if it is something that the iwlwifi is not
doing properly. But AFAICT the !pci_is_enabled() is checking the bridge
*above* the iwlwifi device, so I don't think that will be the case.
--
Cheers,
Luca.
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Jens Axboe @ 2017-09-12 19:43 UTC (permalink / raw)
To: Luca Coelho, Grumbach, Emmanuel, Berg, Johannes
Cc: linuxwifi, linux-wireless@vger.kernel.org, srinath.mannam,
Bjorn Helgaas
In-Reply-To: <1505234187.5400.249.camel@coelho.fi>
On 09/12/2017 10:36 AM, Luca Coelho wrote:
> On Tue, 2017-09-12 at 16:11 +0000, Coelho, Luciano wrote:
>> Hi Jens,
>>
>> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> I have no wifi in current git (8fac2f96ab8), it simply fails with:
>>>
>>> [ 4.363481] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
>>> [ 4.363733] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
>>> [ 4.363744] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
>>> [ 4.368077] iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
>>> [ 4.461753] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
>>> [ ... ]
>>> [ 9.510570] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
>>> [ 9.513903] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
>>> [ 9.516201] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
>>> [ 9.530842] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
>>>
>>> I get the same thing with -27 of the firmware:
>>>
>>> [ 60.990831] Intel(R) Wireless WiFi driver for Linux
>>> [ 60.990833] Copyright(c) 2003- 2015 Intel Corporation
>>> [ 60.991936] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
>>> [ 60.991941] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
>>> [ 60.991946] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
>>> [ 60.991957] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-31.ucode failed with error -2
>>> [ 60.991964] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-30.ucode failed with error -2
>>> [ 60.991969] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-29.ucode failed with error -2
>>> [ 60.991975] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-28.ucode failed with error -2
>>> [ 61.029852] iwlwifi 0000:04:00.0: loaded firmware version 27.541033.0 op_mode iwlmvm
>>> [ 61.043660] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
>>> [ 66.070135] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
>>> [ 66.070149] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
>>> [ 66.070165] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
>>> [ 66.083462] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
>>>
>>> Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
>>
>> This is strange, Linus has been running this same combination with -31
>> (with -27 we had a regression, but it was fixed recently and the fix is
>> in the current master). I have also tried this combination with both
>> -27 and -31 after my fix and it works fine.
>>
>> There are only a couple of other patches that may affect iwlwifi since
>> the previous net-next.git pull request...
>>
>> I'll try this combination on my machine and see if I can reproduce the
>> problem.
>
> I just booted my machine with the latest linux.git/master (8fac2f96ab86)
> and it works without a problem:
>
> [ 8.902174] Intel(R) Wireless WiFi driver for Linux
> [ 8.902174] Copyright(c) 2003- 2015 Intel Corporation
> [ 8.995112] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
> [ 8.995136] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
> [ 9.026455] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
> [ 9.348325] iwlwifi 0000:02:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
> [ 9.369307] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> [ 9.435915] iwlwifi 0000:02:00.0: base HW address: 34:13:e8:2d:65:ef
> [ 9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
>
>
> So this seems to be something that doesn't happen in all machines, maybe
> a PCIe problem?
>
> Is there any chance you could try to bisect this?
Bisect done, it tells me that this:
commit 40f11adc7cd9281227f0a6a627d966dd0a5f0cd9
Author: Srinath Mannam <srinath.mannam@broadcom.com>
Date: Fri Aug 18 21:50:48 2017 -0500
PCI: Avoid race while enabling upstream bridges
is the first bad commit. Reverting that on top of master makes things
work fine again, so that commit is definitely b0rken.
CC'ing the guilty part and Bjorn. I'm assuming it's the pci_is_enabled()
check, since the rest of the patch shouldn't have functional changes.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 3/3] brcmfmac: Add check for short event packets
From: Arend van Spriel @ 2017-09-12 19:16 UTC (permalink / raw)
To: Kevin Cernekee
Cc: Mattias Nissler, Franky Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
linux-wireless, kvalo
In-Reply-To: <CAJzqFta2+4=AKFPRkzi=da2hsYo3RxDXzUmv7eU9VS-416VK-A@mail.gmail.com>
On 12-09-17 17:04, Kevin Cernekee wrote:
> On Mon, Sep 11, 2017 at 12:09 PM, Arend van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>>> index 5aabdc9ed7e0..4cad1f0d2a82 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>>> @@ -429,7 +429,8 @@ void brcmf_fweh_process_event(struct brcmf_pub *drvr,
>>>> if (code != BRCMF_E_IF && !fweh->evt_handler[code])
>>>> return;
>>>>
>>>> - if (datalen > BRCMF_DCMD_MAXLEN)
>>>> + if (datalen > BRCMF_DCMD_MAXLEN ||
>>>> + datalen + sizeof(*event_packet) < packet_len)
>>>
>>>
>>> Shouldn't this check be larger-than, i.e. we need the packet to be at
>>> least sizeof(*event_packet) + its payload size?
>>
>> That depends on how you formulate the requirement. packet_len here is the
>> length for the received skbuff. The event message (= sizeof(*event_packet))
>> and its variable payload (= datalen) shall not exceed length of received
>> skbuff (= packet_len).
>
> Or should it be an exact match, i.e. datalen + sizeof(*event_packet)
> != packet_len
Checking for exact match might not work, because the skbuff length could
differ because of host interface alignment requirements.
> What did Franky's version of the check look like?
the check Franky had was:
datalen > packet_len - sizeof(*event_packet)
> If Broadcom has a test suite that tries different event types and
> notices if events are getting unexpectedly dropped, that would be
> helpful in validating the change. I would be wary of pushing this to
> -stable until we know the check is 100% correct.
Agree. I quickly browsed through our collection of tests in our test
framework, but found none covering this.
Regards,
Arend
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Jens Axboe @ 2017-09-12 16:59 UTC (permalink / raw)
To: Luca Coelho, Grumbach, Emmanuel, Berg, Johannes
Cc: linuxwifi, linux-wireless@vger.kernel.org
In-Reply-To: <1505234187.5400.249.camel@coelho.fi>
On 09/12/2017 10:36 AM, Luca Coelho wrote:
> On Tue, 2017-09-12 at 16:11 +0000, Coelho, Luciano wrote:
>> Hi Jens,
>>
>> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> I have no wifi in current git (8fac2f96ab8), it simply fails with:
>>>
>>> [ 4.363481] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
>>> [ 4.363733] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
>>> [ 4.363744] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
>>> [ 4.368077] iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
>>> [ 4.461753] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
>>> [ ... ]
>>> [ 9.510570] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
>>> [ 9.513903] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
>>> [ 9.516201] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
>>> [ 9.530842] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
>>>
>>> I get the same thing with -27 of the firmware:
>>>
>>> [ 60.990831] Intel(R) Wireless WiFi driver for Linux
>>> [ 60.990833] Copyright(c) 2003- 2015 Intel Corporation
>>> [ 60.991936] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
>>> [ 60.991941] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
>>> [ 60.991946] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
>>> [ 60.991957] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-31.ucode failed with error -2
>>> [ 60.991964] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-30.ucode failed with error -2
>>> [ 60.991969] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-29.ucode failed with error -2
>>> [ 60.991975] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-28.ucode failed with error -2
>>> [ 61.029852] iwlwifi 0000:04:00.0: loaded firmware version 27.541033.0 op_mode iwlmvm
>>> [ 61.043660] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
>>> [ 66.070135] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
>>> [ 66.070149] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
>>> [ 66.070165] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
>>> [ 66.083462] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
>>>
>>> Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
>>
>> This is strange, Linus has been running this same combination with -31
>> (with -27 we had a regression, but it was fixed recently and the fix is
>> in the current master). I have also tried this combination with both
>> -27 and -31 after my fix and it works fine.
>>
>> There are only a couple of other patches that may affect iwlwifi since
>> the previous net-next.git pull request...
>>
>> I'll try this combination on my machine and see if I can reproduce the
>> problem.
>
> I just booted my machine with the latest linux.git/master (8fac2f96ab86)
> and it works without a problem:
>
> [ 8.902174] Intel(R) Wireless WiFi driver for Linux
> [ 8.902174] Copyright(c) 2003- 2015 Intel Corporation
> [ 8.995112] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
> [ 8.995136] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
> [ 9.026455] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
> [ 9.348325] iwlwifi 0000:02:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
> [ 9.369307] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> [ 9.435915] iwlwifi 0000:02:00.0: base HW address: 34:13:e8:2d:65:ef
> [ 9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
>
>
> So this seems to be something that doesn't happen in all machines, maybe
> a PCIe problem?
>
> Is there any chance you could try to bisect this?
I can try, but it might be an all day thing on the laptop. I'll get it going.
--
Jens Axboe
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Luca Coelho @ 2017-09-12 16:36 UTC (permalink / raw)
To: Grumbach, Emmanuel, axboe@kernel.dk, Berg, Johannes
Cc: linuxwifi, linux-wireless@vger.kernel.org
In-Reply-To: <1505232673.5400.243.camel@intel.com>
On Tue, 2017-09-12 at 16:11 +0000, Coelho, Luciano wrote:
> Hi Jens,
>
> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
> > Hi,
> >
> > I have no wifi in current git (8fac2f96ab8), it simply fails with:
> >
> > [ 4.363481] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
> > [ 4.363733] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
> > [ 4.363744] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
> > [ 4.368077] iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
> > [ 4.461753] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> > [ ... ]
> > [ 9.510570] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
> > [ 9.513903] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
> > [ 9.516201] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
> > [ 9.530842] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
> >
> > I get the same thing with -27 of the firmware:
> >
> > [ 60.990831] Intel(R) Wireless WiFi driver for Linux
> > [ 60.990833] Copyright(c) 2003- 2015 Intel Corporation
> > [ 60.991936] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
> > [ 60.991941] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
> > [ 60.991946] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
> > [ 60.991957] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-31.ucode failed with error -2
> > [ 60.991964] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-30.ucode failed with error -2
> > [ 60.991969] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-29.ucode failed with error -2
> > [ 60.991975] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-28.ucode failed with error -2
> > [ 61.029852] iwlwifi 0000:04:00.0: loaded firmware version 27.541033.0 op_mode iwlmvm
> > [ 61.043660] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
> > [ 66.070135] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
> > [ 66.070149] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
> > [ 66.070165] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
> > [ 66.083462] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
> >
> > Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
>
> This is strange, Linus has been running this same combination with -31
> (with -27 we had a regression, but it was fixed recently and the fix is
> in the current master). I have also tried this combination with both
> -27 and -31 after my fix and it works fine.
>
> There are only a couple of other patches that may affect iwlwifi since
> the previous net-next.git pull request...
>
> I'll try this combination on my machine and see if I can reproduce the
> problem.
I just booted my machine with the latest linux.git/master (8fac2f96ab86)
and it works without a problem:
[ 8.902174] Intel(R) Wireless WiFi driver for Linux
[ 8.902174] Copyright(c) 2003- 2015 Intel Corporation
[ 8.995112] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
[ 8.995136] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
[ 9.026455] iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
[ 9.348325] iwlwifi 0000:02:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
[ 9.369307] iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
[ 9.435915] iwlwifi 0000:02:00.0: base HW address: 34:13:e8:2d:65:ef
[ 9.509217] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
So this seems to be something that doesn't happen in all machines, maybe
a PCIe problem?
Is there any chance you could try to bisect this?
--
Cheers,
Luca.
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Jens Axboe @ 2017-09-12 16:35 UTC (permalink / raw)
To: Coelho, Luciano, Grumbach, Emmanuel, Berg, Johannes
Cc: linuxwifi, linux-wireless@vger.kernel.org
In-Reply-To: <1505232673.5400.243.camel@intel.com>
On 09/12/2017 10:11 AM, Coelho, Luciano wrote:
> Hi Jens,
>
> On Tue, 2017-09-12 at 09:48 -0600, Jens Axboe wrote:
>> Hi,
>>
>> I have no wifi in current git (8fac2f96ab8), it simply fails with:
>>
>> [ 4.363481] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
>> [ 4.363733] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
>> [ 4.363744] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
>> [ 4.368077] iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
>> [ 4.461753] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
>> [ ... ]
>> [ 9.510570] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
>> [ 9.513903] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
>> [ 9.516201] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
>> [ 9.530842] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
>>
>> I get the same thing with -27 of the firmware:
>>
>> [ 60.990831] Intel(R) Wireless WiFi driver for Linux
>> [ 60.990833] Copyright(c) 2003- 2015 Intel Corporation
>> [ 60.991936] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
>> [ 60.991941] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
>> [ 60.991946] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
>> [ 60.991957] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-31.ucode failed with error -2
>> [ 60.991964] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-30.ucode failed with error -2
>> [ 60.991969] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-29.ucode failed with error -2
>> [ 60.991975] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-28.ucode failed with error -2
>> [ 61.029852] iwlwifi 0000:04:00.0: loaded firmware version 27.541033.0 op_mode iwlmvm
>> [ 61.043660] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
>> [ 66.070135] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
>> [ 66.070149] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
>> [ 66.070165] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
>> [ 66.083462] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
>>
>> Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
>
> This is strange, Linus has been running this same combination with -31
> (with -27 we had a regression, but it was fixed recently and the fix is
> in the current master). I have also tried this combination with both
> -27 and -31 after my fix and it works fine.
It's 100% reproducible, I booted in and out of current -git and 4.13-rc7+
a few times and the latter never works while the former works fine. I
haven't seen this issue before on previous kernels.
> There are only a couple of other patches that may affect iwlwifi since
> the previous net-next.git pull request...
>
> I'll try this combination on my machine and see if I can reproduce the
> problem.
Let me know if you have something I can try.
--
Jens Axboe
^ permalink raw reply
* Re: iwlwifi firmware load broken in current -git
From: Coelho, Luciano @ 2017-09-12 16:11 UTC (permalink / raw)
To: Grumbach, Emmanuel, axboe@kernel.dk, Berg, Johannes
Cc: linuxwifi, linux-wireless@vger.kernel.org
In-Reply-To: <04c9b578-693c-1dc6-9f0f-904580231b21@kernel.dk>
SGkgSmVucywNCg0KT24gVHVlLCAyMDE3LTA5LTEyIGF0IDA5OjQ4IC0wNjAwLCBKZW5zIEF4Ym9l
IHdyb3RlOg0KPiBIaSwNCj4gDQo+IEkgaGF2ZSBubyB3aWZpIGluIGN1cnJlbnQgZ2l0ICg4ZmFj
MmY5NmFiOCksIGl0IHNpbXBseSBmYWlscyB3aXRoOg0KPiANCj4gWyAgICA0LjM2MzQ4MV0gaXds
d2lmaSAwMDAwOjA0OjAwLjA6IERpcmVjdCBmaXJtd2FyZSBsb2FkIGZvciBpd2x3aWZpLTgwMDBD
LTM0LnVjb2RlIGZhaWxlZCB3aXRoIGVycm9yIC0yDQo+IFsgICAgNC4zNjM3MzNdIGl3bHdpZmkg
MDAwMDowNDowMC4wOiBEaXJlY3QgZmlybXdhcmUgbG9hZCBmb3IgaXdsd2lmaS04MDAwQy0zMy51
Y29kZSBmYWlsZWQgd2l0aCBlcnJvciAtMg0KPiBbICAgIDQuMzYzNzQ0XSBpd2x3aWZpIDAwMDA6
MDQ6MDAuMDogRGlyZWN0IGZpcm13YXJlIGxvYWQgZm9yIGl3bHdpZmktODAwMEMtMzIudWNvZGUg
ZmFpbGVkIHdpdGggZXJyb3IgLTINCj4gWyAgICA0LjM2ODA3N10gaXdsd2lmaSAwMDAwOjA0OjAw
LjA6IGxvYWRlZCBmaXJtd2FyZSB2ZXJzaW9uIDMxLjUzMjk5My4wIG9wX21vZGUgaXdsbXZtDQo+
IFsgICAgNC40NjE3NTNdIGl3bHdpZmkgMDAwMDowNDowMC4wOiBEZXRlY3RlZCBJbnRlbChSKSBE
dWFsIEJhbmQgV2lyZWxlc3MgQUMgODI2MCwgUkVWPTB4MjA4DQo+IFsgLi4uIF0NCj4gWyAgICA5
LjUxMDU3MF0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IEZhaWxlZCB0byBsb2FkIGZpcm13YXJlIGNo
dW5rISAgICAgICAgICAgICANCj4gWyAgICA5LjUxMzkwM10gaXdsd2lmaSAwMDAwOjA0OjAwLjA6
IENvdWxkIG5vdCBsb2FkIHRoZSBbMF0gdUNvZGUgc2VjdGlvbiAgICAgICANCj4gWyAgICA5LjUx
NjIwMV0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IEZhaWxlZCB0byBzdGFydCBJTklUIHVjb2RlOiAt
MTEwICAgICAgICAgICANCj4gWyAgICA5LjUzMDg0Ml0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IEZh
aWxlZCB0byBydW4gSU5JVCB1Y29kZTogLTExMCAgICAgICAgICAgICANCj4gDQo+IEkgZ2V0IHRo
ZSBzYW1lIHRoaW5nIHdpdGggLTI3IG9mIHRoZSBmaXJtd2FyZToNCj4gDQo+IFsgICA2MC45OTA4
MzFdIEludGVsKFIpIFdpcmVsZXNzIFdpRmkgZHJpdmVyIGZvciBMaW51eCAgICAgICAgICAgICAg
ICAgICAgICAgICAgDQo+IFsgICA2MC45OTA4MzNdIENvcHlyaWdodChjKSAyMDAzLSAyMDE1IElu
dGVsIENvcnBvcmF0aW9uICAgICAgICAgICAgICAgICAgICAgICAgDQo+IFsgICA2MC45OTE5MzZd
IGl3bHdpZmkgMDAwMDowNDowMC4wOiBEaXJlY3QgZmlybXdhcmUgbG9hZCBmb3IgaXdsd2lmaS04
MDAwQy0zNC51Y29kZSBmYWlsZWQgd2l0aCBlcnJvciAtMg0KPiBbICAgNjAuOTkxOTQxXSBpd2x3
aWZpIDAwMDA6MDQ6MDAuMDogRGlyZWN0IGZpcm13YXJlIGxvYWQgZm9yIGl3bHdpZmktODAwMEMt
MzMudWNvZGUgZmFpbGVkIHdpdGggZXJyb3IgLTINCj4gWyAgIDYwLjk5MTk0Nl0gaXdsd2lmaSAw
MDAwOjA0OjAwLjA6IERpcmVjdCBmaXJtd2FyZSBsb2FkIGZvciBpd2x3aWZpLTgwMDBDLTMyLnVj
b2RlIGZhaWxlZCB3aXRoIGVycm9yIC0yDQo+IFsgICA2MC45OTE5NTddIGl3bHdpZmkgMDAwMDow
NDowMC4wOiBEaXJlY3QgZmlybXdhcmUgbG9hZCBmb3IgaXdsd2lmaS04MDAwQy0zMS51Y29kZSBm
YWlsZWQgd2l0aCBlcnJvciAtMg0KPiBbICAgNjAuOTkxOTY0XSBpd2x3aWZpIDAwMDA6MDQ6MDAu
MDogRGlyZWN0IGZpcm13YXJlIGxvYWQgZm9yIGl3bHdpZmktODAwMEMtMzAudWNvZGUgZmFpbGVk
IHdpdGggZXJyb3IgLTINCj4gWyAgIDYwLjk5MTk2OV0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IERp
cmVjdCBmaXJtd2FyZSBsb2FkIGZvciBpd2x3aWZpLTgwMDBDLTI5LnVjb2RlIGZhaWxlZCB3aXRo
IGVycm9yIC0yDQo+IFsgICA2MC45OTE5NzVdIGl3bHdpZmkgMDAwMDowNDowMC4wOiBEaXJlY3Qg
ZmlybXdhcmUgbG9hZCBmb3IgaXdsd2lmaS04MDAwQy0yOC51Y29kZSBmYWlsZWQgd2l0aCBlcnJv
ciAtMg0KPiBbICAgNjEuMDI5ODUyXSBpd2x3aWZpIDAwMDA6MDQ6MDAuMDogbG9hZGVkIGZpcm13
YXJlIHZlcnNpb24gMjcuNTQxMDMzLjAgb3BfbW9kZSBpd2xtdm0NCj4gWyAgIDYxLjA0MzY2MF0g
aXdsd2lmaSAwMDAwOjA0OjAwLjA6IERldGVjdGVkIEludGVsKFIpIER1YWwgQmFuZCBXaXJlbGVz
cyBBQyA4MjYwLCBSRVY9MHgyMDgNCj4gWyAgIDY2LjA3MDEzNV0gaXdsd2lmaSAwMDAwOjA0OjAw
LjA6IEZhaWxlZCB0byBsb2FkIGZpcm13YXJlIGNodW5rISAgICAgICAgICAgICANCj4gWyAgIDY2
LjA3MDE0OV0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IENvdWxkIG5vdCBsb2FkIHRoZSBbMF0gdUNv
ZGUgc2VjdGlvbiAgICAgICANCj4gWyAgIDY2LjA3MDE2NV0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6
IEZhaWxlZCB0byBzdGFydCBJTklUIHVjb2RlOiAtMTEwICAgICAgICAgICANCj4gWyAgIDY2LjA4
MzQ2Ml0gaXdsd2lmaSAwMDAwOjA0OjAwLjA6IEZhaWxlZCB0byBydW4gSU5JVCB1Y29kZTogLTEx
MCAgICAgICAgICAgICANCj4gDQo+IFRoaW5ncyB3b3JrIGZpbmUgaW4gNC4xMy1yYzcrLCB3aGlj
aCB3YXMgdGhlIGxhc3Qga2VybmVsIEkgcmFuIG9uIG15IGxhcHRvcC4NCg0KVGhpcyBpcyBzdHJh
bmdlLCBMaW51cyBoYXMgYmVlbiBydW5uaW5nIHRoaXMgc2FtZSBjb21iaW5hdGlvbiB3aXRoIC0z
MQ0KKHdpdGggLTI3IHdlIGhhZCBhIHJlZ3Jlc3Npb24sIGJ1dCBpdCB3YXMgZml4ZWQgcmVjZW50
bHkgYW5kIHRoZSBmaXggaXMNCmluIHRoZSBjdXJyZW50IG1hc3RlcikuICBJIGhhdmUgYWxzbyB0
cmllZCB0aGlzIGNvbWJpbmF0aW9uIHdpdGggYm90aA0KLTI3IGFuZCAtMzEgYWZ0ZXIgbXkgZml4
IGFuZCBpdCB3b3JrcyBmaW5lLg0KDQpUaGVyZSBhcmUgb25seSBhIGNvdXBsZSBvZiBvdGhlciBw
YXRjaGVzIHRoYXQgbWF5IGFmZmVjdCBpd2x3aWZpIHNpbmNlDQp0aGUgcHJldmlvdXMgbmV0LW5l
eHQuZ2l0IHB1bGwgcmVxdWVzdC4uLg0KDQpJJ2xsIHRyeSB0aGlzIGNvbWJpbmF0aW9uIG9uIG15
IG1hY2hpbmUgYW5kIHNlZSBpZiBJIGNhbiByZXByb2R1Y2UgdGhlDQpwcm9ibGVtLg0KDQotLQ0K
Q2hlZXJzLA0KTHVjYS4NCg0K
^ permalink raw reply
* iwlwifi firmware load broken in current -git
From: Jens Axboe @ 2017-09-12 15:48 UTC (permalink / raw)
To: Johannes Berg, emmanuel.grumbach, Coelho, Luciano
Cc: linuxwifi, linux-wireless
Hi,
I have no wifi in current git (8fac2f96ab8), it simply fails with:
[ 4.363481] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
[ 4.363733] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
[ 4.363744] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
[ 4.368077] iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
[ 4.461753] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
[ ... ]
[ 9.510570] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
[ 9.513903] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
[ 9.516201] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
[ 9.530842] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
I get the same thing with -27 of the firmware:
[ 60.990831] Intel(R) Wireless WiFi driver for Linux
[ 60.990833] Copyright(c) 2003- 2015 Intel Corporation
[ 60.991936] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
[ 60.991941] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
[ 60.991946] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
[ 60.991957] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-31.ucode failed with error -2
[ 60.991964] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-30.ucode failed with error -2
[ 60.991969] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-29.ucode failed with error -2
[ 60.991975] iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-28.ucode failed with error -2
[ 61.029852] iwlwifi 0000:04:00.0: loaded firmware version 27.541033.0 op_mode iwlmvm
[ 61.043660] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
[ 66.070135] iwlwifi 0000:04:00.0: Failed to load firmware chunk!
[ 66.070149] iwlwifi 0000:04:00.0: Could not load the [0] uCode section
[ 66.070165] iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
[ 66.083462] iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
Things work fine in 4.13-rc7+, which was the last kernel I ran on my laptop.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 3/3] brcmfmac: Add check for short event packets
From: Kevin Cernekee @ 2017-09-12 15:04 UTC (permalink / raw)
To: Arend van Spriel
Cc: Mattias Nissler, Franky Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
linux-wireless, kvalo
In-Reply-To: <0960e44e-baa7-ac36-4906-cb2d0a39ac3e@broadcom.com>
On Mon, Sep 11, 2017 at 12:09 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> index 5aabdc9ed7e0..4cad1f0d2a82 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
>>> @@ -429,7 +429,8 @@ void brcmf_fweh_process_event(struct brcmf_pub *drvr,
>>> if (code != BRCMF_E_IF && !fweh->evt_handler[code])
>>> return;
>>>
>>> - if (datalen > BRCMF_DCMD_MAXLEN)
>>> + if (datalen > BRCMF_DCMD_MAXLEN ||
>>> + datalen + sizeof(*event_packet) < packet_len)
>>
>>
>> Shouldn't this check be larger-than, i.e. we need the packet to be at
>> least sizeof(*event_packet) + its payload size?
>
> That depends on how you formulate the requirement. packet_len here is the
> length for the received skbuff. The event message (= sizeof(*event_packet))
> and its variable payload (= datalen) shall not exceed length of received
> skbuff (= packet_len).
Or should it be an exact match, i.e. datalen + sizeof(*event_packet)
!= packet_len
What did Franky's version of the check look like?
If Broadcom has a test suite that tries different event types and
notices if events are getting unexpectedly dropped, that would be
helpful in validating the change. I would be wary of pushing this to
-stable until we know the check is 100% correct.
^ permalink raw reply
* Re: [PATCH V2 1/3] brcmfmac: Avoid possible out-of-bounds read
From: Greg KH @ 2017-09-12 12:33 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo, Kevin Cernekee, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <59B79838.6090408@broadcom.com>
On Tue, Sep 12, 2017 at 10:18:00AM +0200, Arend van Spriel wrote:
> + Greg KH
>
> On 9/12/2017 10:05 AM, Kalle Valo wrote:
> > Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> >
> > > On 9/12/2017 9:47 AM, Kalle Valo wrote:
> > > > Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> > > >
> > > > > On 9/12/2017 7:48 AM, Kalle Valo wrote:
> > > > > > Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> > > > > >
> > > > > > > On 09-09-17 21:30, Kevin Cernekee wrote:
> > > > > > > > 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 accessed (but not printed). Since we already have a
> > > > > > > > perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
> > > > > > > > and ch.chspec is not modified by decchspec(), avoid the extra
> > > > > > > > assignment and use ch.chspec in the debug print.
> > > > > > > >
> > > > > > > > Suggested-by: Mattias Nissler <mnissler@chromium.org>
> > > > > > > > Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
> > > > > > > > Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> > > > > > > > ---
> > > > > > > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 3 +--
> > > > > > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > > > > > >
> > > > > > > >
> > > > > > > > V1->V2: Clarify changelog re: whether the uninitialized data is printed.
> > > > > > >
> > > > > > > This patch and the others in this series look fine to me.
> > > > > >
> > > > > > Should these go to v4.14?
> > > > >
> > > > > I have no strong opinion. These are certainly improvements, but it
> > > > > does not seem an -rc fix to me. Within this series I would say patch
> > > > > 3/3 adds an additional sanity check in the event processing against an
> > > > > attack so you may consider adding just that one to v4.14
> > > >
> > > > Ok, I'll queue patch 3 to v4.14.
> > > >
> > > > > and tag it for stable, ie.:
> > > > >
> > > > > Cc: stable@vger.kernel.org # v3.8.x
> > > >
> > > > But why v3.8.x? I admit that I haven't fully figured out the stable tags
> > > > yet, but doesn't that mean that it will be only applied to v3.8.x and
> > > > nothing else? I was expecting it to be:
> > > >
> > > > Cc: stable@vger.kernel.org # v3.8+
> > > >
> > >
> > > It is actually in the stable-kernel-rules documentation [1]:
> > >
> > > """
> > > Also, some patches may have kernel version prerequisites. This can be
> > > specified in the following format in the sign-off area:
> > >
> > > .. code-block:: none
> > >
> > > Cc: <stable@vger.kernel.org> # 3.3.x
> > >
> > > The tag has the meaning of:
> > >
> > > .. code-block:: none
> > >
> > > git cherry-pick <this commit>
> > >
> > > For each "-stable" tree starting with the specified version.
> > > """
> >
> > Yeah, but it says "starting with" which I interpret as "starting with
> > string '3.3'". For example the commit here would be applied to 3.3.1,
> > 3.3.2 and 3.3.3 etc but _not_ to 3.4, 3.4.1, 3.5 or any later release.
> >
> > Of course I can be way off here, wouldn't be the first :)
>
> Dito. I interpret "each -stable tree" as each stable branch in the stable
> repository. Would Greg know?
"# 3.8+" and "# 3.8" mean the same thing to me, we would never backport
something to only a very specific kernel version, and leave newer kernel
versions to not have that fix. That would be crazy, and would break our
"no regressions" rule (i.e. newer kernels should always work as good as
older kernels.)
Don't get hung up on the semantics here people, it's not all that
complicated, and I do it all by hand anyway :)
thanks,
greg k-h
^ permalink raw reply
* [PATCH 7/7] brcmfmac: move configuration of probe request IEs
From: Arend van Spriel @ 2017-09-12 9:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1505208143-30166-1-git-send-email-arend.vanspriel@broadcom.com>
The configuration of the IEs for probe requests was done in a P2P
related function, which is not very obvious. Moving it to
.scan callback function, ie. brcmf_cfg80211_scan().
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 6 ++----
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 35e9cac..b6d1aaa 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -1119,6 +1119,11 @@ static void brcmf_escan_prep(struct brcmf_cfg80211_info *cfg,
if (err)
goto scan_out;
+ err = brcmf_vif_set_mgmt_ie(vif, BRCMF_VNDR_IE_PRBREQ_FLAG,
+ request->ie, request->ie_len);
+ if (err)
+ goto scan_out;
+
err = brcmf_do_escan(vif->ifp, request);
if (err)
goto scan_out;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index 8e0b3f4..cec25dd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -881,7 +881,7 @@ int brcmf_p2p_scan_prep(struct wiphy *wiphy,
{
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
struct brcmf_p2p_info *p2p = &cfg->p2p;
- int err = 0;
+ int err;
if (brcmf_p2p_scan_is_p2p_request(request)) {
/* find my listen channel */
@@ -904,9 +904,7 @@ int brcmf_p2p_scan_prep(struct wiphy *wiphy,
/* override .run_escan() callback. */
cfg->escan_info.run = brcmf_p2p_run_escan;
}
- err = brcmf_vif_set_mgmt_ie(vif, BRCMF_VNDR_IE_PRBREQ_FLAG,
- request->ie, request->ie_len);
- return err;
+ return 0;
}
--
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