* Re: ad-hoc in 5GHz
From: Belisko Marek @ 2017-01-11 10:23 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20170111101031.GA2927@redhat.com>
Hi Stanislaw,
On Wed, Jan 11, 2017 at 11:10 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Hi
>
> On Wed, Jan 11, 2017 at 09:36:00AM +0100, Belisko Marek wrote:
>> this should be general question. I'm using [0] ralink driver to setup
>
> It's Realtek not Ralink, right ?
Ah sorry yes it's Realtek.
>
>> 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.
>
> Depending on regulatory setting IBSS or IR (initialize radiation) can be
> prohibited on some 5GHz channels, check "iw phy" to see which 5GHz channels
> are allowed to use. If HW hardcoded regulatory do not prohibits IBSS on all
> 5GHZ channels it can be matter or setting proper regulatory domain
> (configure timezone properly and then setregdomain will set domain based
> on it).
I did check that and I use 'iw reg set US' (to setup other regulatory
than 00). But despite of that
I still cannot get 5GHz working. Maybe it's driver issue. Thanks.
>
> Regards
> Stanislaw
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: ad-hoc in 5GHz
From: Stanislaw Gruszka @ 2017-01-11 10:10 UTC (permalink / raw)
To: Belisko Marek; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAAfyv37ZFHkZWfq_gAB7XiqtDqVeT+SG7jfXxnCq2fyzYEKX_w@mail.gmail.com>
Hi
On Wed, Jan 11, 2017 at 09:36:00AM +0100, Belisko Marek wrote:
> this should be general question. I'm using [0] ralink driver to setup
It's Realtek not Ralink, right ?
> 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.
Depending on regulatory setting IBSS or IR (initialize radiation) can be
prohibited on some 5GHz channels, check "iw phy" to see which 5GHz channels
are allowed to use. If HW hardcoded regulatory do not prohibits IBSS on all
5GHZ channels it can be matter or setting proper regulatory domain
(configure timezone properly and then setregdomain will set domain based
on it).
Regards
Stanislaw
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 10:00 UTC (permalink / raw)
To: Masashi Honma, linux-wireless, Cedric.Izoard
In-Reply-To: <12d8a797-6c51-4a79-2820-1f9e2e72b2f5@gmail.com>
> I will call the mesh peers "STA A" and "STA B".
>
> Both STA has one physical wireless I/F and wired I/F.
Ok.
[snip configuration]
> Then STA A or STA B crashes, not both.
Nevertheless, I don't have hardware to try to reproduce it, and I can't
see any such issues (even with real forwarding, I even just wrote a
wpa_s test for that) in hwsim.
Even a photo of the crash on the VT would help. Or maybe you can set up
netconsole on the wired interface?
johannes
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Masashi Honma @ 2017-01-11 9:38 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, Cedric.Izoard
In-Reply-To: <1484125220.23671.1.camel@sipsolutions.net>
On 2017年01月11日 18:00, Johannes Berg wrote:
> Ok, that's strange, but maybe there's a reason.
>
> Can you extract *any* information whatsoever? Like maybe if you switch
> to a VT console before running into the crash? I don't have any
> hardware to run this on, and hwsim doesn't have any issues.
I will call the mesh peers "STA A" and "STA B".
Both STA has one physical wireless I/F and wired I/F.
I have connected to both with SSH via wired I/F and started
wpa_supplicant with this command for both.
sudo ./hostap/wpa_supplicant/wpa_supplicant -i <ifname> -D nl80211 -c
mesh_sae.conf
STA A's mesh_sae.conf is this.
----------------------
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
user_mpm=1
update_config=0
network={
ssid="mesh0"
key_mgmt=SAE
mode=5
frequency=2412
psk="01234567"
}
----------------------
STA B's mesh_sae.conf is this. The difference is "no_auto_peer=1".
----------------------
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
user_mpm=1
update_config=0
network={
ssid="mesh0"
key_mgmt=SAE
mode=5
frequency=2412
psk="01234567"
no_auto_peer=1
}
----------------------
Booting the wpa_supplicant finishes successfully.
After the successfull peering process, I could see
MESH-PEER-CONNECTED
message on both side.
Then STA A or STA B crashes, not both.
Masashi Honma.
^ permalink raw reply
* Re: [PATCH v9] Add new mac80211 driver mwlwifi.
From: Johannes Berg @ 2017-01-11 9:25 UTC (permalink / raw)
To: David Lin, Kalle Valo
Cc: linux-wireless@vger.kernel.org, Chor Teck Law, James Lin,
Pete Hsieh
In-Reply-To: <5b561668eb5b4804b0007d03bc723f9d@SC-EXCH02.marvell.com>
On Tue, 2017-01-10 at 01:32 +0000, David Lin wrote:
> > The only thing that really seems questionable to me is the whole
> > beacon parsing (and apparent rebuilding in firmware?). It's very
> > odd that you could do that, with a softmac device where all the
> > authentication and association is handled by hostapd anyway, and
> > you can't possibly pretend to handle everything hostapd might throw
> > at you - this will mean that you'll have features hostapd and every
> > other mac80211 supports that you will silently drop afaict - which
> > is rather unexpected.
> >
> > First, you're parsing the data obtained from hostapd, in
> > mwl_fwcmd_parse_beacon(), and then you send them all to the
> > firmware in mwl_fwcmd_set_ies(), but only the things you actually
> > understood. New higher-level features you don't understand, or
> > vendor beacon IEs that aren't WMM, would be completely dropped.
> >
> > I'm not very happy with that behaviour.
> >
> > Why does the firmware require this? Why not just pack all IEs into
> > the pcmd->ie_list_len_proprietary, and leave everything else 0? Or
> > - if perhaps firmware for some reason requires HT/VHT to be treated
> > specially, only parse out the ones that are really needed specially
> > and leave everything else in the ie_list_len_proprietary?
> >
> > Also, this is dropping all the encryption stuff - even those are
> > extensible btw, and hostapd might do so. Having the firmware
> > rebuild those out of out-of-band information is very unexpected for
> > a mac80211 driver.
> >
>
> This driver just extracts needed IEs which is used for the host
> command of firmware. I think we will not support other vendor IEs.
> And if needed, we can add them to pcmd->ie_list_proprietary.
Sure, I see that you're doing this. It still makes no sense though,
since all management frames are handled by hostapd anyway. It would
make some sense if you actually were going to handle association in the
firmware, but it makes no sense here, as far as I can tell.
I'm not sure how hard a line I should draw here, but I'll warn you now
that I won't take this into consideration when adding new features to
mac80211, and certainly Jouni won't take it into account when adding
new features to hostapd, so that such new features will then SILENTLY
and UNEXPECTEDLY (due to mac80211) not work with your driver.
I strongly advise you to reconsider this and try to pass through all
the IEs so that newly added features that shouldn't require firmware
interaction (since hostapd is handling all the association handshake
and IEs to advertise the feature) will automatically and cleanly work.
If you really can't do that, for some reason, then for my benefit as
the mac80211 maintainer and future maintainers of your driver, I'd like
to have documentation in the driver as to why the firmware needs the
driver to split up all those IEs and what it does with them. After all,
a common-sense analysis would suggest that the firmware has no need for
it, since all configuration should come through other places and all
IEs are just for going out on the air.
johannes
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Johannes Berg @ 2017-01-11 9:17 UTC (permalink / raw)
To: Linus Lüssing
Cc: netdev, David S . Miller, Stephen Hemminger, bridge, linux-kernel,
linux-wireless, Felix Fietkau, Michael Braun
In-Reply-To: <20170109231203.GC5513@otheros>
> > 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.
Ah, well, no - at least not in this case.
> 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)
Ah, interesting. This is different then - the mac80211 code is not L3
aware at all.
johannes
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Johannes Berg @ 2017-01-11 9:00 UTC (permalink / raw)
To: Masashi Honma, linux-wireless, Cedric.Izoard
In-Reply-To: <aa60ffb2-b756-b807-4976-20f2eca6665d@gmail.com>
On Wed, 2017-01-11 at 17:50 +0900, Masashi Honma wrote:
> On 2017年01月11日 17:02, Johannes Berg wrote:
> > I don't think this makes sense - if you only have two peers then
> > you
> > shouldn't even run into forwarding code paths?
> >
> > johannes
>
> Though it looks odd, the code has run into forwarding code path even
> though peer to peer mesh connection.
>
> fwd_skb = skb_copy(skb, GFP_ATOMIC);
>
> I checked it with printk().
>
> # I know printk() should not be used in the context, just for
> checking.
Ok, that's strange, but maybe there's a reason.
Can you extract *any* information whatsoever? Like maybe if you switch
to a VT console before running into the crash? I don't have any
hardware to run this on, and hwsim doesn't have any issues.
johannes
^ permalink raw reply
* Re: [REGRESSION, bisect] mesh: SAE connection causes kernel crash
From: Masashi Honma @ 2017-01-11 8:50 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, Cedric.Izoard
In-Reply-To: <1484121737.23671.0.camel@sipsolutions.net>
On 2017年01月11日 17:02, Johannes Berg wrote:
> I don't think this makes sense - if you only have two peers then you
> shouldn't even run into forwarding code paths?
>
> johannes
Though it looks odd, the code has run into forwarding code path even
though peer to peer mesh connection.
fwd_skb = skb_copy(skb, GFP_ATOMIC);
I checked it with printk().
# I know printk() should not be used in the context, just for checking.
Masashi Honma.
^ permalink raw reply
* 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
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