* ad-hoc in 5GHz
From: Belisko Marek @ 2017-01-11 8:36 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
this should be general question. I'm using [0] ralink driver to setup
ad-hoc mode. It works fine in 2.4GHz band (channel 1) but when I try
to setup ad-hoc for 5GHz (channel 50) it seems it's not working at all
(I tried to scan with other device but I cannot ad-hoc network). So my
question should ad-hoc mode work in 5GHz band also or there are some
restrictions? Many thanks.
[0] - https://github.com/diederikdehaas/rtl8812AU
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 8:02 UTC (permalink / raw)
To: Masashi Honma, linux-wireless, Cedric.Izoard
In-Reply-To: <b72bc51c-1873-6178-9990-7d9e99ee4b88@gmail.com>
On Wed, 2017-01-11 at 08:35 +0900, Masashi Honma wrote:
> I have encountered kernel crash when I have used mesh SAE
> connection
> with ath9k_htc device (Sony UWA-BR100). I have tried to connect 2
> peers
> to each other, then only one peer crashes.
>
> By bisect, this commit looks causes this issue.
>
> commit d8da0b5d64d58f7775a94bcf12dda50f13a76f22
> Author: Cedric Izoard <Cedric.Izoard@ceva-dsp.com>
> Date: Wed Dec 7 09:59:00 2016 +0000
>
> mac80211: Ensure enough headroom when forwarding mesh pkt
I don't think this makes sense - if you only have two peers then you
shouldn't even run into forwarding code paths?
johannes
^ permalink raw reply
* RE: [PATCH v3 1/3] cfg80211: Add support to sched scan to report better BSSs
From: Vamsi, Krishna @ 2017-01-11 7:48 UTC (permalink / raw)
To: Arend Van Spriel, Malinen, Jouni, Johannes Berg
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <25527a43-0458-f9f4-9afb-f5986dffbae1@broadcom.com>
> -----Original Message-----
=20
> > + * @relative_rssi_set: Indicates whether @relative_rssi is set or not.
>=20
> So you see a use-case for doing a scan with @relative_rssi being zero, ri=
ght?
Yes. Zero value for relative_rssi is also valid.
> > + * @relative_rssi: Relative RSSI threshold in dB to restrict scan resu=
lt
> > + * reporting in connected state to cases where a matching BSS is
> determined
> > + * to have better RSSI than the current connected BSS. The relative RS=
SI
> > + * threshold values are ignored in disconnected state.
>=20
> The description says "better RSSI" so I suppose it could be typed as u8.
> The last sentence is intended driver behavior
I like to leave this as s8 only. This will leave more flexibility to usersp=
ace especially in case of more than two bands in future.
=20
> > + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]) {
> > + request->relative_rssi =3D nla_get_s8(
> > + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]);
> > + request->relative_rssi_set =3D true;
> > + }
> > +
> > + if (attrs[NL80211_ATTR_SCHED_SCAN_RSSI_ADJUST]) {
>=20
> Maybe I misread but I thought this attribute to be applicable only if
> request->relative_rssi_set is true.
@relative_rssi is valid only when @relative_rssi_set is set to true and @rs=
si_adjust is valid only when @relative_rssi is valid. I think that is under=
standable to drivers and there is no need of explicit check here.
> >
> > -static int nl80211_send_wowlan_nd(struct sk_buff *msg,
> > +static int nl80211_send_wowlan_nd(struct wiphy *wiphy,
>=20
> This seems to be unrelated change. At least I do not see any reference to=
wiphy
> variable in the added code below.
My bad, Will remove this unnecessary change and upload a patch.
Thanks,
Vamsi
^ permalink raw reply
* [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Masashi Honma @ 2017-01-10 23:35 UTC (permalink / raw)
To: linux-wireless, Cedric.Izoard; +Cc: johannes.berg
I have encountered kernel crash when I have used mesh SAE connection
with ath9k_htc device (Sony UWA-BR100). I have tried to connect 2 peers
to each other, then only one peer crashes.
By bisect, this commit looks causes this issue.
commit d8da0b5d64d58f7775a94bcf12dda50f13a76f22
Author: Cedric Izoard <Cedric.Izoard@ceva-dsp.com>
Date: Wed Dec 7 09:59:00 2016 +0000
mac80211: Ensure enough headroom when forwarding mesh pkt
When a buffer is duplicated during MESH packet forwarding,
this patch ensures that the new buffer has enough headroom.
I do not have any crash log because the computer was fully uncontrollable.
Regards,
Masashi Honma.
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-10 21:27 UTC (permalink / raw)
To: Johannes Berg, Linus Lüssing, Stephen Hemminger
Cc: M. Braun, netdev, David S . Miller, bridge, linux-kernel,
linux-wireless
In-Reply-To: <1484045763.1014.0.camel@sipsolutions.net>
On 2017-01-10 11:56, Johannes Berg wrote:
> On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
>> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
>> > I wonder if MAC80211 should be doing IGMP snooping and not bridge
>> > in this environment.
>>
>> In the long term, yes. For now, not quite sure.
>
> There's no "for now" in the kernel. Code added now will have to be
> maintained essentially forever.
I'm not sure that putting the IGMP snooping code in mac80211 is a good
idea, that would be quite a bit of code duplication.
This implementation works, it's very simple, and it's quite flexible for
a number of use cases.
Is there any remaining objection to merging this in principle (aside
from potential issues with the code)?
- Felix
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Dave Taht @ 2017-01-10 18:24 UTC (permalink / raw)
To: Felix Fietkau
Cc: Johannes Berg, Linus Lüssing, Stephen Hemminger, M. Braun,
netdev@vger.kernel.org, David S . Miller, bridge,
linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <99c01ce6-d80c-790e-25e5-157be31aee9a@nbd.name>
On Tue, Jan 10, 2017 at 9:23 AM, Felix Fietkau <nbd@nbd.name> wrote:
> On 2017-01-10 18:17, Dave Taht wrote:
>> In the case of wifi I have 3 issues with this line of thought.
>>
>> multicast in wifi has generally supposed to be unreliable. This makes
>> it reliable. reliability comes at a cost -
>>
>> multicast is typically set at a fixed low rate today. unicast is
>> retried at different rates until it succeeds - for every station
>> listening. If one station is already at the lowest rate, the total
>> cost of the transmit increases, rather than decreases.
>>
>> unicast gets block acks until it succeeds. Again, more delay.
>>
>> I think there is something like 31 soft-retries in the ath9k driver....
> If I remember correctly, hardware retries are counted here as well.
I chopped this to something more reasonable but never got around to
quantifying it, so never pushed the patch. I figured I'd measure ATF
in a noisy environment (which I'd be doing now if it weren't for
https://bugs.lede-project.org/index.php?do=3Ddetails&task_id=3D368 )
first.
>> what happens to diffserv markings here? for unicast CS1 goes into the
>> BE queue, CS6, the VO queue. Do we go from one flat queue for all of
>> multicast to punching it through one of the hardware queues based on
>> the diffserv mark now with this patch?
I meant CS1=3DBK here. Tracing the path through the bridge code made my
head hurt, I can go look at some aircaps to see if the mcast->unicast
conversion respects those markings or not (my vote is *not*).
>> I would like it if there was a way to preserve the unreliability
>> (which multiple mesh protocols depend on), send stuff with QoSNoack,
>> etc - or dynamically choose (based on the rates of the stations)
>> between conventional multicast and unicast.
>>
>> Or - better, IMHO, keep sending multicast as is but pick the best of
>> the rates available to all the listening stations for it.
> The advantage of the multicast-to-unicast conversion goes beyond simply
> selecting a better rate - aggregation matters a lot as well, and that is
> simply incompatible with normal multicast.
Except for the VO queue which cannot aggregate. And for that matter,
using any other hardware queue than BE tends to eat a txop that would
otherwise possibly be combined with an aggregate.
(and the VI queue has always misbehaved, long on my todo list)
> Some multicast streams use lots of small-ish packets, the airtime impact
> of those is vastly reduced, even if the transmission has to be
> duplicated for a few stations.
The question was basically how far up does it scale. Arguably, for a
very few, well connected stations, this patch would help. For a
network with more - and more badly connected stations, I think it
would hurt.
What sorts of multicast traffic are being observed that flood the
network sufficiently to be worth optimizing out? arp? nd? upnp? mdns?
uftp? tv?
(my questions above are related to basically trying to setup a sane
a/b test, I've been building up a new testbed in noisy environment to
match the one I have in a quiet one, and don't have any "good" mcast
tests defined. Has anyone done an a/b test of this code with some
repeatable test already?)
(In my observations... The only truly heavy creator of a multicast
"burp" has tended to be upnp and mdns on smaller networks. Things like
nd and arp get more problematic as the number of stations go up also.
I can try things like abusing vlc or uftp to see what happens?)
I certainly agree multicast is a "problem" (I've seen 20-80% or more
of a given wifi network eaten by multicast) but I'm not convinced that
making it reliable, aggregatable unicast scales much past
basement-level testing of a few "good" stations, and don't know which
protocols are making it worse, the worst, in typical environments.
Certainly apple gear puts out a lot of multicast.
...
As best as I recall a recommendation in the 802.11-2012 standard was
that multicast packets be rate-limited so that you'd have a fixed
amount of crap after each beacon sufficient to keep the rest of the
unicast traffic flowing rapidly, instead of dumping everything into a
given beacon transmit.
That, combined with (maybe) picking the "best" union of known rates
per station, was essentially the strategy I'd intended[1] to pursue
for tackling the currently infinite wifi multicast queue - fq the
entries, have a fairly short queue (codel is not the best choice here)
drop from head, and limit the number of packets transmitted per beacon
to spread them out. That would solve the issue for sparse multicast
(dhcp etc), and smooth out the burps from bigger chunks while
impacting conventional unicast minimally.
There's also the pursuit of less multicast overall at least in some protoco=
ls
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05
>
> - Felix
[1] but make-wifi-fast has been out of funding since august
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Felix Fietkau @ 2017-01-10 17:23 UTC (permalink / raw)
To: Dave Taht, Johannes Berg
Cc: Linus Lüssing, Stephen Hemminger, M. Braun,
netdev@vger.kernel.org, David S . Miller, bridge,
linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <CAA93jw6+P8um7TxDCYgJ=SJfFzpskboR7njgudMb3NR4JZ34BA@mail.gmail.com>
On 2017-01-10 18:17, Dave Taht wrote:
> In the case of wifi I have 3 issues with this line of thought.
>
> multicast in wifi has generally supposed to be unreliable. This makes
> it reliable. reliability comes at a cost -
>
> multicast is typically set at a fixed low rate today. unicast is
> retried at different rates until it succeeds - for every station
> listening. If one station is already at the lowest rate, the total
> cost of the transmit increases, rather than decreases.
>
> unicast gets block acks until it succeeds. Again, more delay.
>
> I think there is something like 31 soft-retries in the ath9k driver....
If I remember correctly, hardware retries are counted here as well.
> what happens to diffserv markings here? for unicast CS1 goes into the
> BE queue, CS6, the VO queue. Do we go from one flat queue for all of
> multicast to punching it through one of the hardware queues based on
> the diffserv mark now with this patch?
>
> I would like it if there was a way to preserve the unreliability
> (which multiple mesh protocols depend on), send stuff with QoSNoack,
> etc - or dynamically choose (based on the rates of the stations)
> between conventional multicast and unicast.
>
> Or - better, IMHO, keep sending multicast as is but pick the best of
> the rates available to all the listening stations for it.
The advantage of the multicast-to-unicast conversion goes beyond simply
selecting a better rate - aggregation matters a lot as well, and that is
simply incompatible with normal multicast.
Some multicast streams use lots of small-ish packets, the airtime impact
of those is vastly reduced, even if the transmission has to be
duplicated for a few stations.
- Felix
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Dave Taht @ 2017-01-10 17:17 UTC (permalink / raw)
To: Johannes Berg
Cc: Linus Lüssing, Stephen Hemminger, M. Braun, Felix Fietkau,
netdev@vger.kernel.org, David S . Miller, bridge,
linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <1484045763.1014.0.camel@sipsolutions.net>
In the case of wifi I have 3 issues with this line of thought.
multicast in wifi has generally supposed to be unreliable. This makes
it reliable. reliability comes at a cost -
multicast is typically set at a fixed low rate today. unicast is
retried at different rates until it succeeds - for every station
listening. If one station is already at the lowest rate, the total
cost of the transmit increases, rather than decreases.
unicast gets block acks until it succeeds. Again, more delay.
I think there is something like 31 soft-retries in the ath9k driver....
what happens to diffserv markings here? for unicast CS1 goes into the
BE queue, CS6, the VO queue. Do we go from one flat queue for all of
multicast to punching it through one of the hardware queues based on
the diffserv mark now with this patch?
I would like it if there was a way to preserve the unreliability
(which multiple mesh protocols depend on), send stuff with QoSNoack,
etc - or dynamically choose (based on the rates of the stations)
between conventional multicast and unicast.
Or - better, IMHO, keep sending multicast as is but pick the best of
the rates available to all the listening stations for it.
Has anyone actually looked at the effects of this with, say, 5-10
stations at middlin to poor quality (longer distance)? using something
to measure the real effect of the multicast conversion? (uftp, mdns?)
^ permalink raw reply
* Re: pull-request: wireless-drivers 2017-01-10
From: David Miller @ 2017-01-10 16:28 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87a8aztp33.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 10 Jan 2017 08:18:40 +0200
> here's the pull request with the important rtlwifi fix, more info in the
> tag below.
>
> During the long weekend we had here I finally updated Ubuntu on my
> workstation and git was updated along that. If you see anything funny or
> problems in my pull request due to the upgrade, please let me know. The
> upgrade might have broken something, at least git-request-pull needs to
> be now called differently.
Looks good, pulled, thanks.
^ permalink raw reply
* Re: [bug report] rtlwifi: Remove some redundant code
From: Larry Finger @ 2017-01-10 16:18 UTC (permalink / raw)
To: Kalle Valo, Dan Carpenter; +Cc: linux-wireless
In-Reply-To: <8737grjaje.fsf@purkki.adurom.net>
On 01/10/2017 07:43 AM, Kalle Valo wrote:
> Dan Carpenter <dan.carpenter@oracle.com> writes:
>
>> Hello Larry Finger,
>>
>> The patch c93ac39da006: "rtlwifi: Remove some redundant code" from
>> Dec 15, 2016, leads to the following static checker warning:
>>
>> drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:326 rtl92d_download_fw()
>> warn: curly braces intended?
>>
>> drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
>> 306 /* If 8051 is running in RAM code, driver should
>> 307 * inform Fw to reset by itself, or it will cause
>> 308 * download Fw fail.*/
>> 309 /* 8051 RAM code */
>> 310 if (rtl_read_byte(rtlpriv, REG_MCUFWDL) & BIT(7)) {
>> 311 rtl92d_firmware_selfreset(hw);
>> 312 rtl_write_byte(rtlpriv, REG_MCUFWDL, 0x00);
>> 313 }
>> 314 _rtl92d_enable_fw_download(hw, true);
>> 315 _rtl92d_write_fw(hw, version, pfwdata, fwsize);
>> 316 _rtl92d_enable_fw_download(hw, false);
>> 317 spin_lock_irqsave(&globalmutex_for_fwdownload, flags);
>> 318 err = _rtl92d_fw_free_to_go(hw);
>> 319 /* download fw over,clear 0x1f[5] */
>> 320 value = rtl_read_byte(rtlpriv, 0x1f);
>> 321 value &= (~BIT(5));
>> 322 rtl_write_byte(rtlpriv, 0x1f, value);
>> 323 spin_unlock_irqrestore(&globalmutex_for_fwdownload, flags);
>> 324 if (err)
>> 325 pr_err("fw is not ready to run!\n");
>> 326 goto exit;
>>
>> I guess we could add the braces back.
>>
>> 327 exit:
>> 328 err = _rtl92d_fw_init(hw);
>>
>> Should we even be running _rtl92d_fw_init() if _rtl92d_fw_free_to_go()
>> fails? What about preserving the error code?
>>
>> 329 return err;
>> 330 }
>
> A possible fix but which doesn't seem to address all your concerns:
>
> [next] rtlwifi: rtl8192de: fix missing curly braces
>
> https://patchwork.kernel.org/patch/9506837/
Strange, but Gmail put that patch in my spam. In any case, it is better to
remove the goto. Adding the braces back leaves a goto just before the target.
The compiler does the right thing, but it should be fixed.
Larry
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192de: Remove a pointless goto
From: Larry Finger @ 2017-01-10 16:15 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger
In commit c93ac39da0064 ("rtlwifi: Remove some redundant code), a goto
statement was inadvertently left in the code.
Fixes: c93ac39da0064 ("rtlwifi: Remove some redundant code)
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
index 8931bcd..88faeab 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
@@ -271,7 +271,6 @@ int rtl92d_download_fw(struct ieee80211_hw *hw)
spin_unlock_irqrestore(&globalmutex_for_fwdownload, flags);
if (err)
pr_err("fw is not ready to run!\n");
- goto exit;
exit:
err = _rtl92d_fw_init(hw);
return err;
--
2.10.2
^ permalink raw reply related
* [PATCH] ath10k: Fix Tx legacy rate reporting
From: Mohammed Shafi Shajakhan @ 2017-01-10 15:53 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Tx legacy rate is reported 10 fold, as below
iw dev wlan#N station dump | grep "tx bitrate"
tx bitrate: 240.0 MBit/s
This is because by mistake we muliply by the hardware reported
rate twice by 10, fix this.
Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index cb86530..ae10fe1 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2247,7 +2247,7 @@ static inline bool is_valid_legacy_rate(u8 rate)
rate *= 10;
if (rate == 60 && txrate.flags == WMI_RATE_PREAMBLE_CCK)
rate = rate - 5;
- arsta->txrate.legacy = rate * 10;
+ arsta->txrate.legacy = rate;
} else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
arsta->txrate.mcs = txrate.mcs;
--
1.9.1
^ permalink raw reply related
* [PATCH] ath10k: Fix wifi connectivity and warning in Rx with channel 169
From: Mohammed Shafi Shajakhan @ 2017-01-10 15:31 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
In countries where basic operation of channel 169 is allowed,
this fixes the below WARN_ON_ONCE in Rx and fixes the station
connectivity failure in channel 169 as the packet is dropped
in the driver as the current check limits to channel 165. As of
now all the packets beyond channel 165 is dropped, fix this
by extending the range to channel 169.
Call trace:
drivers/net/wireless/ath/ath10k/wmi.c:1505
ath10k_wmi_event_mgmt_rx+0x278/0x440 [ath10k_core]()
Call Trace:
[<c158f812>] ? printk+0x2d/0x2f
[<c105a182>] warn_slowpath_common+0x72/0xa0
[<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440
[<f8b67b58>] ? ath10k_wmi_event_mgmt_rx+0x278/0x440
[<c105a1d2>] warn_slowpath_null+0x22/0x30
[<f8b67b58>] ath10k_wmi_event_mgmt_rx+0x278/0x440
[<f8b0e72b>] ? ath10k_pci_sleep+0x8b/0xb0 [ath10k_pci]
[<f8b6ac63>] ath10k_wmi_10_2_op_rx+0xf3/0x3b0
[<f8b6495e>] ath10k_wmi_process_rx+0x1e/0x60
[<f8b5f077>] ath10k_htc_rx_completion_handler+0x347/0x4d0 [ath10k_core]
[<f8b11dc3>] ? ath10k_ce_completed_recv_next+0x53/0x70 [ath10k_pci]
[<f8b0f921>] ath10k_pci_ce_recv_data+0x171/0x1d0 [ath10k_pci]
[<f8b0ec69>] ? ath10k_pci_write32+0x39/0x80 [ath10k_pci]
[<f8b120bc>] ath10k_ce_per_engine_service+0x5c/0xa0 [ath10k_pci]
[<f8b1215f>] ath10k_ce_per_engine_service_any+0x5f/0x70 [ath10k_pci]
[<c1060dc0>] ? local_bh_enable_ip+0x90/0x90
[<f8b1048b>] ath10k_pci_tasklet+0x1b/0x50 [ath10k_pci]
Fixes: 34c30b0a5e97 ("ath10k: enable advertising support for channel 169, 5Ghz")
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 50d6ee6..d30a68c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2319,7 +2319,7 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
*/
if (channel >= 1 && channel <= 14) {
status->band = NL80211_BAND_2GHZ;
- } else if (channel >= 36 && channel <= 165) {
+ } else if (channel >= 36 && channel <= 169) {
status->band = NL80211_BAND_5GHZ;
} else {
/* Shouldn't happen unless list of advertised channels to
--
1.9.1
^ permalink raw reply related
* Re: [bug report] rtlwifi: Remove some redundant code
From: Kalle Valo @ 2017-01-10 13:43 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Larry.Finger, linux-wireless
In-Reply-To: <20170105111124.GA4548@elgon.mountain>
Dan Carpenter <dan.carpenter@oracle.com> writes:
> Hello Larry Finger,
>
> The patch c93ac39da006: "rtlwifi: Remove some redundant code" from
> Dec 15, 2016, leads to the following static checker warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:326 rtl92d_download_fw()
> warn: curly braces intended?
>
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
> 306 /* If 8051 is running in RAM code, driver should
> 307 * inform Fw to reset by itself, or it will cause
> 308 * download Fw fail.*/
> 309 /* 8051 RAM code */
> 310 if (rtl_read_byte(rtlpriv, REG_MCUFWDL) & BIT(7)) {
> 311 rtl92d_firmware_selfreset(hw);
> 312 rtl_write_byte(rtlpriv, REG_MCUFWDL, 0x00);
> 313 }
> 314 _rtl92d_enable_fw_download(hw, true);
> 315 _rtl92d_write_fw(hw, version, pfwdata, fwsize);
> 316 _rtl92d_enable_fw_download(hw, false);
> 317 spin_lock_irqsave(&globalmutex_for_fwdownload, flags);
> 318 err = _rtl92d_fw_free_to_go(hw);
> 319 /* download fw over,clear 0x1f[5] */
> 320 value = rtl_read_byte(rtlpriv, 0x1f);
> 321 value &= (~BIT(5));
> 322 rtl_write_byte(rtlpriv, 0x1f, value);
> 323 spin_unlock_irqrestore(&globalmutex_for_fwdownload, flags);
> 324 if (err)
> 325 pr_err("fw is not ready to run!\n");
> 326 goto exit;
>
> I guess we could add the braces back.
>
> 327 exit:
> 328 err = _rtl92d_fw_init(hw);
>
> Should we even be running _rtl92d_fw_init() if _rtl92d_fw_free_to_go()
> fails? What about preserving the error code?
>
> 329 return err;
> 330 }
A possible fix but which doesn't seem to address all your concerns:
[next] rtlwifi: rtl8192de: fix missing curly braces
https://patchwork.kernel.org/patch/9506837/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/3] rsi: Renamed the file rsi_91x_pkt.c to rsi_91x_hal.c
From: Kalle Valo @ 2017-01-10 11:52 UTC (permalink / raw)
To: Prameela Rani Garnepudi
Cc: Prameela Rani Garnepudi, linux-wireless, johannes.berg, hofrat,
xypron.glpk
In-Reply-To: <eeeaa63e-b179-be38-afbb-03c3bf9a0158@redpinesignals.com>
Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com> writes:
> Can you please review these patches. You slipped through these patches
> and reviewing resent patches. Is there a specific reason?
As you are new, your patches just take more time to review than others
and haven't had a good slot to look at those yet.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Johannes Berg @ 2017-01-10 10:56 UTC (permalink / raw)
To: Linus Lüssing, Stephen Hemminger
Cc: M. Braun, Felix Fietkau, netdev, David S . Miller, bridge,
linux-kernel, linux-wireless
In-Reply-To: <20170110041816.GJ5513@otheros>
On Tue, 2017-01-10 at 05:18 +0100, Linus Lüssing wrote:
> On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> > I wonder if MAC80211 should be doing IGMP snooping and not bridge
> > in this environment.
>
> In the long term, yes. For now, not quite sure.
There's no "for now" in the kernel. Code added now will have to be
maintained essentially forever.
johannes
^ permalink raw reply
* [PATCH next] rtlwifi: rtl8192de: fix missing curly braces
From: Vincent Stehlé @ 2017-01-10 9:55 UTC (permalink / raw)
To: devel, linux-wireless
Cc: Vincent Stehlé, Larry Finger, Kalle Valo, Joe Perches,
Ping-Ke Shih
In-Reply-To: <20161215182310.13713-15-Larry.Finger@lwfinger.net>
Restore some curly braces that have been removed in commit c93ac39da006457f
("rtlwifi: Remove some redundant code") while removing redundant messages
and extraneous braces.
This fixes the following smatch warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:326 rtl92d_download_fw() warn: curly braces intended?
...and the following coccinelle warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c:325:2-38: code aligned with following code on line 326
Fixes: c93ac39da006457f ("rtlwifi: Remove some redundant code")
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Joe Perches <joe@perches.com>
Cc: Ping-Ke Shih <pkshih@realtek.com>
---
Hi,
I saw that in Linux next-20170110.
Best regards,
Vincent.
drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
index aa1e51c871df..bcde4da4e593 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
@@ -321,9 +321,10 @@ int rtl92d_download_fw(struct ieee80211_hw *hw)
value &= (~BIT(5));
rtl_write_byte(rtlpriv, 0x1f, value);
spin_unlock_irqrestore(&globalmutex_for_fwdownload, flags);
- if (err)
+ if (err) {
pr_err("fw is not ready to run!\n");
goto exit;
+ }
exit:
err = _rtl92d_fw_init(hw);
return err;
--
2.11.0
^ permalink raw reply related
* Re: [ath5k-devel] ath5k keep-alive
From: Sergey Ryazanov @ 2017-01-10 8:35 UTC (permalink / raw)
To: Denis Periša
Cc: open list:ATHEROS ATH5K WIR..., linux-wireless@vger.kernel.org
In-Reply-To: <CAC8mBSUHhwjdWAduhGt4qarV139JW2ERC-8CvRXAM3eMxvBLuA@mail.gmail.com>
Hello Denis.
CC linux-wireless since ath5k-devel not so active for a long time.
On Tue, Sep 13, 2016 at 10:30 AM, Denis Peri=C5=A1a <denis@denis.in> wrote:
> I have issue with frequent disconnects so I have to add watchdog scripts =
in
> cron which is really pain in..
> Is there any chance I can add some code to keep alive connection?
Did you try to use wpa_supplicant? It could take care about reconnection.
--=20
Sergey
^ permalink raw reply
* Re: kernel 4.9 iwlwifi startup error
From: Luca Coelho @ 2017-01-10 8:26 UTC (permalink / raw)
To: Fabio Coatti
Cc: Andrew Donnellan, LKML, linux-wireless@vger.kernel.org, linuxwifi
In-Reply-To: <2231220.vMvt4J1trM@calvin>
On Tue, 2017-01-10 at 09:21 +0100, Fabio Coatti wrote:
> In data martedì 10 gennaio 2017 00:21:51 CET, Luca Coelho ha scritto:
> > On Tue, 2017-01-03 at 13:42 +1100, Andrew Donnellan wrote:
> > > On 02/01/17 21:12, Fabio Coatti wrote:
> > > > Hi all,
> > > > I'm using kernel 4.9 and maybe half of the times I boot my laptop I get
> > > > the
> > > > error reported below, and the wifi does not work. I have to remove
> > > > iwlwifi (like modprobe -r iwldvm iwlwifi) and insert it again to get
> > > > things workig again. This seems a bit random, it does not happens all
> > > > the times so it could be a timing issue or even a flaky hardware
> > > > (unlikely, as I see only this issue with wifi, once it starts it works
> > > > just fine)
> > > > I'm pretty sure to have seen the same behaviour at some point in 4.8.X
> > > > release, but right now I lost the related notes.
> > > > Environment:
> > > > Distro: gentoo
> > > > gcc 5.4.0
> > > > HW: Hewlett-Packard HP EliteBook Folio 9470m/18DF, BIOS 68IBD Ver. F.63
> > > > 04/26/2016
> > > > Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
> > > > Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)
> > > >
> > > > Of course if more info is needed, just drop me a note.
> > > >
> > > > I'm not subscribed to mailing lists, so please keep me in CC: for any
> > > > information request.
> > > >
> > > > Many thanks.
> > >
> > > I've so far seen this once on my laptop, a Samsung NP540U3C (don't have
> > > it with me right now, so I'm not sure what the wifi chipset is), running
> > > with a Debian 4.9 kernel.
> >
> > This bug has already been reported in bugzilla:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=190281
> >
> > Did you have any problems with older kernel versions? If so, would it be
> > possible for you to bisect?
>
>
> Well, it happens on a laptop that I use quite intensively, so it will take
> some time to bisect. However, in the meantime I checked the old logs and the
> first recorded occurrence happened with 4.8.10 release and firmware version
> 18.168.6.1
Thanks! Let's continue tracking this in bugzilla.
--
Cheers,
Luca.
^ permalink raw reply
* Re: kernel 4.9 iwlwifi startup error
From: Fabio Coatti @ 2017-01-10 8:21 UTC (permalink / raw)
To: Luca Coelho
Cc: Andrew Donnellan, LKML, linux-wireless@vger.kernel.org, linuxwifi
In-Reply-To: <1484000511.5227.33.camel@coelho.fi>
In data marted=EC 10 gennaio 2017 00:21:51 CET, Luca Coelho ha scritto:
> On Tue, 2017-01-03 at 13:42 +1100, Andrew Donnellan wrote:
> > On 02/01/17 21:12, Fabio Coatti wrote:
> > > Hi all,
> > > I'm using kernel 4.9 and maybe half of the times I boot my laptop I g=
et
> > > the
> > > error reported below, and the wifi does not work. I have to remove
> > > iwlwifi (like modprobe -r iwldvm iwlwifi) and insert it again to get
> > > things workig again. This seems a bit random, it does not happens all
> > > the times so it could be a timing issue or even a flaky hardware
> > > (unlikely, as I see only this issue with wifi, once it starts it works
> > > just fine)
> > > I'm pretty sure to have seen the same behaviour at some point in 4.8.X
> > > release, but right now I lost the related notes.
> > > Environment:
> > > Distro: gentoo
> > > gcc 5.4.0
> > > HW: Hewlett-Packard HP EliteBook Folio 9470m/18DF, BIOS 68IBD Ver. F.=
63
> > > 04/26/2016
> > > Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
> > > Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 2=
4)
> > >=20
> > > Of course if more info is needed, just drop me a note.
> > >=20
> > > I'm not subscribed to mailing lists, so please keep me in CC: for any
> > > information request.
> > >=20
> > > Many thanks.
> >=20
> > I've so far seen this once on my laptop, a Samsung NP540U3C (don't have
> > it with me right now, so I'm not sure what the wifi chipset is), running
> > with a Debian 4.9 kernel.
>=20
> This bug has already been reported in bugzilla:
>=20
> https://bugzilla.kernel.org/show_bug.cgi?id=3D190281
>=20
> Did you have any problems with older kernel versions? If so, would it be
> possible for you to bisect?
Well, it happens on a laptop that I use quite intensively, so it will take=
=20
some time to bisect. However, in the meantime I checked the old logs and th=
e=20
first recorded occurrence happened with 4.8.10 release and firmware version=
=20
18.168.6.1
=2D-=20
=46abio
^ permalink raw reply
* pull-request: wireless-drivers 2017-01-10
From: Kalle Valo @ 2017-01-10 6:18 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's the pull request with the important rtlwifi fix, more info in the
tag below.
During the long weekend we had here I finally updated Ubuntu on my
workstation and git was updated along that. If you see anything funny or
problems in my pull request due to the upgrade, please let me know. The
upgrade might have broken something, at least git-request-pull needs to
be now called differently.
Kalle
The following changes since commit f5a0aab84b74de68523599817569c057c7ac1622:
net: ipv4: dst for local input routes should use l3mdev if relevant (2016-12-29 22:27:23 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-01-10
for you to fetch changes up to 60f59ce0278557f7896d5158ae6d12a4855a72cc:
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data (2016-12-30 15:38:13 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.10
Only two fixes at this time. The rtlwifi fix is an important one as it
fixes a reported oops and Linus was already asking about it. The
orinoco fix is not tested on a real device, because it's old legacy
hardware and hardly no-one use it, but it should fix a (theoretical)
issue with VMAP_STACK.
----------------------------------------------------------------
Andrew Lutomirski (1):
orinoco: Use shash instead of ahash for MIC calculations
Larry Finger (1):
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
drivers/net/wireless/intersil/orinoco/mic.c | 44 +++++++++++++++----------
drivers/net/wireless/intersil/orinoco/mic.h | 3 +-
drivers/net/wireless/intersil/orinoco/orinoco.h | 4 +--
drivers/net/wireless/realtek/rtlwifi/usb.c | 1 +
4 files changed, 31 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-10 4:18 UTC (permalink / raw)
To: Stephen Hemminger
Cc: M. Braun, Johannes Berg, Felix Fietkau, netdev, David S . Miller,
bridge, linux-kernel, linux-wireless
In-Reply-To: <20170109133032.221f8669@xeon-e3>
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> I wonder if MAC80211 should be doing IGMP snooping and not bridge
> in this environment.
In the long term, yes. For now, not quite sure.
I personally like to go for simple solutions first :).
^ permalink raw reply
* RE: [PATCH v9] Add new mac80211 driver mwlwifi.
From: David Lin @ 2017-01-10 1:32 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo
Cc: linux-wireless@vger.kernel.org, Chor Teck Law, James Lin,
Pete Hsieh
In-Reply-To: <1483624722.4394.21.camel@sipsolutions.net>
PiBKb2hhbm5lcyBCZXJnIFttYWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0gd3JvdGU6
DQo+ID4gT24gV2VkLCAyMDE2LTEyLTIxIGF0IDA0OjExICswMDAwLCBEYXZpZCBMaW4gd3JvdGU6
DQo+ID4gVGhpcyBwYXRjaCBwcm92aWRlcyB0aGUgbXdsd2lmaSBkcml2ZXIgZm9yIE1hcnZlbGwg
ODg2MywgODg2NCBhbmQNCj4gPiA4ODk3DQo+ID4gY2hpcHNldHMuDQo+ID4gVGhpcyBkcml2ZXIg
d2FzIGRldmVsb3BlZCBhcyBwYXJ0IG9mIHRoZSBvcGVud3J0Lm9yZyBwcm9qZWN0IHRvDQo+ID4g
c3VwcG9ydCBMaW5rc3lzIFdSVDE5MDBBQyBhbmQgaXMgbWFpbnRhaW5lZCBvbg0KPiA+IGh0dHBz
Oi8vZ2l0aHViLmNvbS9rYWxvei9td2x3aSBmaS4NCj4gDQo+IEkgZm91bmQgc29tZSBtaW5vciB0
aGluZ3M6DQo+IA0KPiAgKiB1c2luZyBrbWFsbG9jL21lbXNldCBpbnN0ZWFkIG9mIGt6YWxsb2MN
Cg0KSSB3aWxsIGNoYW5nZSBpdC4NCg0KPiAgKiBtd2xfZndjbWRfZ2V0XzgwbV9wcmlfY2hubCgp
IGNvdWxkIHVzZSBzb21lIGFyaXRobWV0aWMgb3IgYXQgbGVhc3QNCj4gICAgc3dpdGNoIGNhc2Ug
Y29uc29saWRhdGlvbiAtIGlmIGl0IHNob3VsZG4ndCBldmVuIGdvIGF3YXkgZW50aXJlbHkNCj4g
ICAgc2luY2UgbWFjODAyMTEgZG9lc24ndCByZWFsbHkgbGltaXQgeW91IHRvIHRoZSBwcmltYXJ5
IGNoYW5uZWwgYXMNCj4gICAgdGhlIHNwZWMgcmVxdWlyZXMgaXQgLSBzbyB0aGUgd2hvbGUgcHVy
cG9zZSBvZiB0aGUgZnVuY3Rpb24gc2VlbXMgYQ0KPiAgICBiaXQgcXVlc3Rpb25hYmxlDQoNClRo
aXMgZnVuY3Rpb24gaXMgdXNlZCBmb3IgdGhlIGhvc3QgY29tbWFuZCBvZiBmaXJtd2FyZS4NCg0K
PiAgKiB3aXBoeV9lcnIoaHctPndpcGh5LCAiZmFpbGVkIGV4ZWN1dGlvblxuIik7IHNlZW1zIGxp
a2UgYSBiaXQgdG9vDQo+ICAgIGdlbmVyaWMgKHlvdSBoYXZlIHRoYXQgbWFueSB0aW1lcyAtIGhv
dyBhcmUgeW91IGdvaW5nIHRvIHRlbGwgd2hpY2gNCj4gICAgaGFwcGVuZWQ/KQ0KDQpJIHdpbGwg
bW9kaWZ5IGl0Lg0KDQo+ICAqIHJhdGVzID0gc3RhLT5zdXBwX3JhdGVzW05MODAyMTFfQkFORF81
R0haXSA8PCA1Ow0KPiAgICBpcyBhIGJpdCBxdWVzdGlvbmFibGUgLSB0aGF0IDUgc2hvdWxkIHBy
b2JhYmx5IGJlIGRlZmluZWQgKGFsc28sDQo+ICAgIGRvZXMgdGhhdCBtZWFuIHlvdSBzdXBwb3J0
IDEsMiwgNS41LCAxMSBhbmQgKjIyTUJwcyo/IGN1cmlvdXMsDQo+ICAgIGFsbW9zdCBub2JvZHkg
ZG9lcyB0aGF0IGFmYWljdCkNCg0KVGhpcyBpcyB1c2VkIHRvIGNvbXBseSB3aXRoIHRoZSBwYXJh
bWV0ZXJzIG9mIGhvc3QgY29tbWFuZCBvZiBmaXJtd2FyZS4NCg0KPiAgKiBhIGxvdCBvZiBpbml0
aWFsaXphdGlvbnMgbGlrZQ0KPiDCoCDCoHN0cnVjdCBtd2xfdmlmICptd2xfdmlmOw0KPiAgICBb
Li4uXQ0KPiDCoCDCoG13bF92aWYgPSBtd2xfZGV2X2dldF92aWYodmlmKTsNCj4gDQo+ICAgIGNv
dWxkIGJlIHJvbGxlZCBpbnRvIGEgc2luZ2xlIGxpbmUgb2YgY29kZSAod2hpY2ggeW91IHNvbWV0
aW1lcyBkbywNCj4gICAgYXBwYXJlbnRseSBhbHdheXMgZm9yICJwcml2IiBidXQgbmV2ZXIgZm9y
ICJtd2xfdmlmIiBvciAicGNtZCI/KQ0KDQpJIHdpbGwgbW9kaWZ5IGl0Lg0KDQo+ICAqICJjZWxj
aXVzIiBpc24ndCByZWFsbHkgc3BlbGxlZCB0aGF0IHdheSAtIGFuZCB5b3UgcHJvYmFibHkgbWVh
bg0KPiAgICAidGVtcGVyYXR1cmUiIGFueXdheSBzaW5jZSBDZWxzaXVzIGlzIGEgdW5pdCA6KQ0K
DQpJIHdpbGwgY2hhbmdlIGl0Lg0KDQo+ICAqIHR5cG86IGZpcndhcmUNCg0KSSB3aWxsIGZpeCBp
dC4NCg0KPiAgKiBhIGJ1bmNoIG9mIHlvdXIgSUUgaGFuZGxpbmcgc3RydWN0cyBzZWVtIGR1cGxp
Y2F0ZSB3aXRoIGllZWU4MDIxMS5oDQoNCk5vLCBvbmx5IHBvaW50ZXIgaXMgZGVmaW5lZCBmb3Ig
ZXh0cmFjdGluZyBjb250ZW50IG9mIGJlYWNvbi4gVGhpcyBkcml2ZXIgZG9lcyBub3QgcmVkZWZp
bmUgSUUgc3RydWN0dXJlIGlmIGl0IGlzIGFscmVhZHkgZGVmaW5lZCBpbiBpZWVlODAyMTEuaC4N
Cg0KPiAgKiBhbmQgcGFydGlhbGx5IHdyb25nIC0gc29tZXRoaW5nIHdpdGggYSB2ZW5kb3IgT1VJ
IGNhbid0IGJlIFJTTg0KPiAgICAobWF5YmUgeW91IG1lYW50IFdQQT8gdGhvdWdoIGl0J3Mgbm90
IHF1aXRlIGNsZWFyIHRvIG1lIHdoeSB5b3UgbmVlZA0KPiAgICB0aGlzIGF0IGFsbCEpDQoNClll
cy4gSXQgbWVhbnMgV1BBLiBUaGlzIGRyaXZlciBkb2VzIG5vdCBoYW5kbGUgY29udGVudCBvZiBp
dC4gSXQgb25seSBuZWVkcyB0aGUgSUUgZm9yIGhvc3QgY29tbWFuZCBvZiBmaXJtd2FyZS4NCg0K
PiAgKiArI2lmZGVmIENPTkZJR19PRg0KPiAgICArI2luY2x1ZGUgPGxpbnV4L29mLmg+DQo+ICAg
ICsjZW5kaWYNCj4gICAgSSBkb24ndCB0aGluayB5b3UgaGF2ZSB0byBndWFyZCB0aGF0IGluY2x1
ZGUgLi4uDQo+ICAqICsjaWZkZWYgQ09ORklHX0RFQlVHX0ZTDQo+ICAgICsjaW5jbHVkZSAiZGVi
dWdmcy5oIg0KPiAgICArI2VuZGlmDQo+ICAgIGxpa2V3aXNlDQo+ICAqIGdpdCBhbSBhbHNvIGNv
bXBsYWluZWQgYWJvdXQgYSBibGFuayBsaW5lIGF0IEVPRg0KPiANCg0KSSB3aWxsIHJlbW92ZSB0
aGVtIGFuZCBmaXggYmxhbmsgbGluZS4NCg0KPiANCj4gVGhlIG9ubHkgdGhpbmcgdGhhdCByZWFs
bHkgc2VlbXMgcXVlc3Rpb25hYmxlIHRvIG1lIGlzIHRoZSB3aG9sZSBiZWFjb24NCj4gcGFyc2lu
ZyAoYW5kIGFwcGFyZW50IHJlYnVpbGRpbmcgaW4gZmlybXdhcmU/KS4gSXQncyB2ZXJ5IG9kZCB0
aGF0IHlvdSBjb3VsZCBkbw0KPiB0aGF0LCB3aXRoIGEgc29mdG1hYyBkZXZpY2Ugd2hlcmUgYWxs
IHRoZSBhdXRoZW50aWNhdGlvbiBhbmQgYXNzb2NpYXRpb24gaXMNCj4gaGFuZGxlZCBieSBob3N0
YXBkIGFueXdheSwgYW5kIHlvdSBjYW4ndCBwb3NzaWJseSBwcmV0ZW5kIHRvIGhhbmRsZQ0KPiBl
dmVyeXRoaW5nIGhvc3RhcGQgbWlnaHQgdGhyb3cgYXQgeW91IC0gdGhpcyB3aWxsIG1lYW4gdGhh
dCB5b3UnbGwgaGF2ZQ0KPiBmZWF0dXJlcyBob3N0YXBkIGFuZCBldmVyeSBvdGhlciBtYWM4MDIx
MSBzdXBwb3J0cyB0aGF0IHlvdSB3aWxsIHNpbGVudGx5DQo+IGRyb3AgYWZhaWN0IC0gd2hpY2gg
aXMgcmF0aGVyIHVuZXhwZWN0ZWQuDQo+IA0KPiBGaXJzdCwgeW91J3JlIHBhcnNpbmcgdGhlIGRh
dGEgb2J0YWluZWQgZnJvbSBob3N0YXBkLCBpbg0KPiBtd2xfZndjbWRfcGFyc2VfYmVhY29uKCks
IGFuZCB0aGVuIHlvdSBzZW5kIHRoZW0gYWxsIHRvIHRoZSBmaXJtd2FyZSBpbg0KPiBtd2xfZndj
bWRfc2V0X2llcygpLCBidXQgb25seSB0aGUgdGhpbmdzIHlvdSBhY3R1YWxseSB1bmRlcnN0b29k
LiBOZXcNCj4gaGlnaGVyLWxldmVsIGZlYXR1cmVzIHlvdSBkb24ndCB1bmRlcnN0YW5kLCBvciB2
ZW5kb3IgYmVhY29uIElFcyB0aGF0IGFyZW4ndA0KPiBXTU0sIHdvdWxkIGJlIGNvbXBsZXRlbHkg
ZHJvcHBlZC4NCj4gDQo+IEknbSBub3QgdmVyeSBoYXBweSB3aXRoIHRoYXQgYmVoYXZpb3VyLg0K
PiANCj4gV2h5IGRvZXMgdGhlIGZpcm13YXJlIHJlcXVpcmUgdGhpcz8gV2h5IG5vdCBqdXN0IHBh
Y2sgYWxsIElFcyBpbnRvIHRoZQ0KPiBwY21kLT5pZV9saXN0X2xlbl9wcm9wcmlldGFyeSwgYW5k
IGxlYXZlIGV2ZXJ5dGhpbmcgZWxzZSAwPyBPciAtIGlmDQo+IHBlcmhhcHMgZmlybXdhcmUgZm9y
IHNvbWUgcmVhc29uIHJlcXVpcmVzIEhUL1ZIVCB0byBiZSB0cmVhdGVkIHNwZWNpYWxseSwNCj4g
b25seSBwYXJzZSBvdXQgdGhlIG9uZXMgdGhhdCBhcmUgcmVhbGx5IG5lZWRlZCBzcGVjaWFsbHkg
YW5kIGxlYXZlIGV2ZXJ5dGhpbmcNCj4gZWxzZSBpbiB0aGUgaWVfbGlzdF9sZW5fcHJvcHJpZXRh
cnk/DQo+IA0KPiBBbHNvLCB0aGlzIGlzIGRyb3BwaW5nIGFsbCB0aGUgZW5jcnlwdGlvbiBzdHVm
ZiAtIGV2ZW4gdGhvc2UgYXJlIGV4dGVuc2libGUgYnR3LA0KPiBhbmQgaG9zdGFwZCBtaWdodCBk
byBzby4gSGF2aW5nIHRoZSBmaXJtd2FyZSByZWJ1aWxkIHRob3NlIG91dCBvZiBvdXQtb2YtYmFu
ZA0KPiBpbmZvcm1hdGlvbiBpcyB2ZXJ5IHVuZXhwZWN0ZWQgZm9yIGEgbWFjODAyMTEgZHJpdmVy
Lg0KPiANCg0KVGhpcyBkcml2ZXIganVzdCBleHRyYWN0cyBuZWVkZWQgSUVzIHdoaWNoIGlzIHVz
ZWQgZm9yIHRoZSBob3N0IGNvbW1hbmQgb2YgZmlybXdhcmUuIEkgdGhpbmsgd2Ugd2lsbCBub3Qg
c3VwcG9ydCBvdGhlciB2ZW5kb3IgSUVzLiBBbmQgaWYgbmVlZGVkLCB3ZSBjYW4gYWRkIHRoZW0g
dG8gcGNtZC0+aWVfbGlzdF9wcm9wcmlldGFyeS4NCg0KPiBqb2hhbm5lcw0K
^ permalink raw reply
* [PATCH] mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print
From: Brian Norris @ 2017-01-09 23:33 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam
Cc: linux-kernel, Kalle Valo, linux-wireless, Cathy Luo, Brian Norris
Similar to commit fcd2042e8d36 ("mwifiex: printk() overflow with 32-byte
SSIDs"), we failed to account for the existence of 32-char SSIDs in our
debugfs code. Unlike in that case though, we zeroed out the containing
struct first, and I'm pretty sure we're guaranteed to have some padding
after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes
long).
So, this is the difference between:
# cat /sys/kernel/debug/mwifiex/mlan0/info
...
essid="0123456789abcdef0123456789abcdef "
...
and the correct output:
# cat /sys/kernel/debug/mwifiex/mlan0/info
...
essid="0123456789abcdef0123456789abcdef"
...
Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Marking the 'Fixes' tag just for completeness, but AIUI, this isn't a security
vulnerability (besides, it's debugfs), so it might not really warrant -stable.
drivers/net/wireless/marvell/mwifiex/debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/debugfs.c b/drivers/net/wireless/marvell/mwifiex/debugfs.c
index b9284b533294..ae2b69db5994 100644
--- a/drivers/net/wireless/marvell/mwifiex/debugfs.c
+++ b/drivers/net/wireless/marvell/mwifiex/debugfs.c
@@ -114,7 +114,8 @@ mwifiex_info_read(struct file *file, char __user *ubuf,
if (GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_STA) {
p += sprintf(p, "multicast_count=\"%d\"\n",
netdev_mc_count(netdev));
- p += sprintf(p, "essid=\"%s\"\n", info.ssid.ssid);
+ p += sprintf(p, "essid=\"%.*s\"\n", info.ssid.ssid_len,
+ info.ssid.ssid);
p += sprintf(p, "bssid=\"%pM\"\n", info.bssid);
p += sprintf(p, "channel=\"%d\"\n", (int) info.bss_chan);
p += sprintf(p, "country_code = \"%s\"\n", info.country_code);
--
2.11.0.390
^ permalink raw reply related
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-09 23:12 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev, David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Felix Fietkau, Michael Braun
In-Reply-To: <1483965843.17582.37.camel@sipsolutions.net>
On Mon, Jan 09, 2017 at 10:42:46PM +0100, Johannes Berg wrote:
> On Mon, 2017-01-09 at 22:33 +0100, Linus Lüssing wrote:
> > On Mon, Jan 09, 2017 at 01:44:03PM +0100, Johannes Berg wrote:
> > >
> > > > > A host SHOULD silently discard a datagram that is
> > > > > received via
> > > > > a link-layer broadcast (see Section 2.4) but does not
> > > > > specify
> > > > > an IP multicast or broadcast destination address.
> > > >
> > > > This example is the other way round. It specifies how the IP
> > > > destination should look like in case of link-layer broadcast. Not
> > > > how the link-layer destination should look like in case of a
> > > > multicast/broadcast IP destination.
> > >
> > > You stopped reading too early - snipped the context part for you :)
> >
> > Sorry for writing to you directly, but I still have some
> > difficulties. In pseudo-code that line says:
> >
> > -----
> > if ll_dst(pkt) == bcast AND ip_dst(pkt) != mcast/bcast:
> > -> drop(pkt)
> > -----
> >
> > But after multicast-to-unicast conversion, we have:
> >
> > -----
> > ll_dst(pkt) == ucast AND ip_dst(pkt) == mcast
> > -----
> >
> > So none of the two requirements for dropping are matched?
> >
>
> Exactly. My point is that this is breaking the expectation that hosts
> are actually able to drop such packets.
[readding CCs I removed earlier]
Ah! Thanks. I was worried about creating packetloss :D.
Hm, for this other other way round, I think it does not apply for
the bridge multicast-to-unicast patch if I'm not misreading the bridge code:
For a packet with a link-layer multicast address but a unicast IP
destination, the bridge MDB lookup will fail.
(http://lxr.free-electrons.com/source/net/bridge/br_multicast.c?v=4.8#L178
returns NULL)
Case A): No multicast router on port:
-> bridge, br_multicast_flood(), will drop the packet already
(no matter if multicast-to-unicast is enabled or not)
Case B): Multicast router present on port:
-> The new patch does not apply multicast-to-unicast but just floods
packet unaltered
("else { port = rport; addr = NULL; }" branch)
Regards, Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox