mac80211: minstrel: remove divisions in tx status path
mac80211: minstrel_ht: replace rate stats ewma with a better moving
average
mac80211: minstrel_ht: rename prob_ewma to prob_avg, use it for the new
average
Johannes Berg (2):
mac80211: pass internal sta to ieee80211_tx_frags
On Tue, 2019-10-08 at 11:33 -0500, Denis Kenzior wrote:
> nl80211 requires NL80211_CMD_ABORT_SCAN to have a wdev or netdev
> attribute present and checks that if netdev is provided it is UP.
> However, mac80211 does not check that an ongoing scan actually belongs
> to the netdev/wdev provided by th
On Tue, 2019-10-08 at 15:55 -0500, Denis Kenzior wrote:
> Right, so you're talking in the context of this implementation which
> performs a remove/add interface. You're right about that.
>
> But I was asking more in general terms. If all we're doing is scanning,
> can we just change the mac?
On Wed, 2019-10-09 at 11:43 +0200, Greg KH wrote:
>
> > + for_each_element(elem, data, len) {
> > + /* nothing */
> > + }
>
> for_each_element() is not in 4.4, 4.9, 4.14, or 4.19, so this breaks the
> build :(
Oh, right. I had previously also said:
You also need to cherry-pick
0f3
On Wed, 2019-10-09 at 11:27 +0200, Greg KH wrote:
> On Wed, Oct 09, 2019 at 08:41:09AM +0200, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > Commit 8a3347aa110c76a7f87771999aed491d1d8779a8 upstream.
>
> I don't see that commit in Linus's tree :(
Hmmm
From: Johannes Berg
Commit 8a3347aa110c76a7f87771999aed491d1d8779a8 upstream.
We currently don't validate the beacon head, i.e. the header,
fixed part and elements that are to go in front of the TIM
element. This means that the variable elements there can be
malformed, e.g. have a l
tch:
[...]
> WARNING: Duplicate signature
> #14:
> Signed-off-by: Johannes Berg
Hmm, yeah, so ... I was actually not sure about that and I guess it
slipped by. Most of the time, I've been editing it out, but what happens
is this:
1) I send a patch to our internal tree, to fix up
On Tue, 2019-10-08 at 13:50 -0500, Denis Kenzior wrote:
> Hi Johannes,
>
> > > But they shouldn't change due a mac address change? I wonder if we can
> > > further relax the requirements to allow mac change if
> > > NL80211_SCAN_FLAG_RANDOM_ADDR was used?
> >
> > No, at least with HW scan that w
> > > > No, this typically cannot be fixed, and it doesn't really make sense.
> > > > The NIC cannot possibly do two scans at a time since it has only a
> > > > single radio resource :-)
> > >
> > > So why is the scan request not per phy then? And should mac address
> > > even affect the ongoin
Hi,
> > The scan_req struct contains a reference to which interface is scanning,
> > so it should very well be possible to have
> >
> > phy0:
> > wlan0: IFF_UP & scanning
> > wlan1: IFF_UP & change MAC address all the time
> >
> > just like it's possible to change the MAC address when wlan1
Hi,
> > You could have two interfaces, one which is scanning right now, right?
> > And then theoretically you don't care about the other one - it *should*
> > be OK to remove/re-add (with new MAC address) the one that *isn't*
> > scanning, right?
>
> Actually, I don't think you can? Unless I'm m
Hi,
> I concur that scanning should be checked as
> if (sdata->local->scanning). So Johannes you're right that the polarity
> is reversed. However, __ieee80211_start_scan seems to check for
> local->scan_req instead to take deferred scans into account. So I
> wonder if that is a better appro
D was too long
Aaron Komisar (1):
mac80211: fix scan when operating on DFS channels in ETSI domains
Johannes Berg (1):
mac80211: accept deauth frames in IBSS mode
Michael Vassernis (1):
mac80211_hwsim: fix incorrect
Hi,
> > > If you do care about this being more granular then you should check
> > > *which* interface is scanning, and then you can still switch the
> > > MAC
> > > address for *other* interfaces - but I'd still argue it should be
> > > independent of interface type.
>
> So yes these can scan, bu
On Fri, 2019-10-04 at 09:25 -0700, James Prestwood wrote:
>
> > I'm not even entirely sure it _is_ needed - if we've still not
> > created
> > the IBSS but are scanning for it or trying to merge the MAC address
> > won't really matter yet? Probably?
>
> I guess its just paranoia, rather be safe t
On Mon, 2019-10-07 at 21:40 +0200, Toke Høiland-Jørgensen wrote:
> > > So if and when we start supporting true multi-band devices we'll have to
> > > change these things anyway. So might as well keep everything together so
> > > it all gets fixed :)
> >
> > I guess I'm OK with that, but I'm prett
On Sun, 2019-10-06 at 21:31 -0700, Kan Yan wrote:
> +/**
> + * ieee80211_sta_update_pending_airtime - update txq's estimated airtime
> + *
> + * Update the estimated total airtime of frames queued in the lower layer
> queue.
> + *
> + * The airtime is estimated using frame length and the last rep
On Sun, 2019-10-06 at 19:40 +0200, Toke Høiland-Jørgensen wrote:
> > That's a good point. I haven't thought about real simultaneous dual
> > band chipset and such chipset do exists now. Is RSDB support coming to
> > mac80211 soon? Just curious if it will be just virtual interfaces or
> > somethin
On Sat, 2019-10-05 at 18:13 +0900, Taehee Yoo wrote:
>
> If we place lockdep keys into "struct net_device", this macro would be a
> little bit modified and reused. And driver code shape will not be huge
> changed. I think this way is better than this v4 way.
> So I will try it.
What I was thinkin
On Thu, 2019-10-03 at 23:21 -0700, Kan Yan wrote:
>
> +/* The firmware's transmit queue size limit in airtime */
> +#define IEEE80211_DEFAULT_AQL_INTERFACE_LIMIT24000
I'm not sure I understand this completely, but IMHO rewording it to be
like a "NIC limit" would be better.
However, I'm n
Just took a very brief look so I can think about it while offline ;-)
But some (editorial) comments:
> +/**
> + * ieee80211_sta_register_pending_airtime - register the estimated airtime
> for
> + * the frames pending in lower layer (firmware/hardware) txq.
That doesn't work - the short descript
On Thu, 2019-10-03 at 08:13 +, Aaron Komisar wrote:
> > The real reason of scan failure is because mac80211 checks if it's DFS
> > channel, but it doesn't check if CAC is done or not.
>
> The problem is that scan request is blocked in ETSI reg domains. In non-ETSI
> reg domains the behavior i
Hi,
I was tempted to apply this (sans the feature advertisement part that I
don't think should be in nl80211), but:
>
> Signed-off-by: James Prestwood
Please add a commit log.
> +static int ieee80211_can_live_addr_change(struct ieee80211_sub_if_data
> *sdata)
> +{
> + if (netif_carrier_o
From: Johannes Berg
There really is no need to make drivers call the
ieee80211_start_tx_ba_cb_irqsafe() function and then
schedule the worker if all we want is to set a bit.
Add a new return value (that was previously considered
invalid) to indicate that the driver is immediately
ready for the
On Wed, 2019-10-02 at 11:08 +0200, Stanislaw Gruszka wrote:
> On Tue, Oct 01, 2019 at 10:06:29PM +0200, Johannes Berg wrote:
> > index f1cdcd61c54a..b74e758cce09 100644
> > --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> > +++ b/drivers/net/wireless/ralink/rt2x00/rt2800
From: Johannes Berg
There really is no need to make drivers call the
ieee80211_start_tx_ba_cb_irqsafe() function and then
schedule the worker if all we want is to set a bit.
Add a new return value (that was previously considered
invalid) to indicate that the driver is immediately
ready for the
From: Johannes Berg
This simplifies the code somewhat, and if necessary would let
us access the sta itself in that code.
Signed-off-by: Johannes Berg
---
net/mac80211/tx.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211
From: Johannes Berg
There really is no need to make drivers call the
ieee80211_start_tx_ba_cb_irqsafe() function and then
schedule the worker if all we want is to set a bit.
Add a new return value (that was previously considered
invalid) to indicate that the driver is immediately
ready for the
On Wed, 2019-09-18 at 15:33 +, Aaron Komisar wrote:
> In non-ETSI reg domains scan is blocked when operating channel is a DFS ch.
> For ETSI domains, however, once DFS channel is marked as available afer
> the CAC, this channel will remain available even after leaving this channel.
> Therefore
ld be validated
----
Johannes Berg (4):
nl80211: validate beacon head
cfg80211: validate SSID/MBSSID element ordering assumption
cfg80211: initialize on-stack chandefs
mac80211: keep BHs disabled while calling drv_tx_wake_qu
Hi,
(jumping out now, forgive me for being so brief)
> If I understand correctly, you said about the alignment of
> "lower_level" and "upper_level".
> I thought this place is a fine position for variables as regards the
> alignment and I didn't try to put each variable in different places.
>
> I
On Tue, 2019-10-01 at 10:19 -0300, Ramon Fontes wrote:
> > Do they also have the same version of wmediumd?
>
> Yes, they have the same version. As you can also see through the
> video, I only change the kernel and all the packages have the same
> version. I also tried to check the latest commits o
From: Johannes Berg
Drivers typically expect this, as it's the case for almost all cases
where this is called (i.e. from the TX path). Also, the code in mac80211
itself (if the driver calls ieee80211_tx_dequeue()) expects this as it
uses this_cpu_ptr() without additional protection.
This s
On Tue, 2019-10-01 at 13:06 +0200, Johannes Berg wrote:
> On Tue, 2019-10-01 at 12:52 +0200, Felix Fietkau wrote:
> > Might be useful, yes. The main issue here is that the period / window
> > size has to be hardcoded through the coefficient values, unless we find
> > a way
On Tue, 2019-10-01 at 12:52 +0200, Felix Fietkau wrote:
>
> Might be useful, yes. The main issue here is that the period / window
> size has to be hardcoded through the coefficient values, unless we find
> a way to do floating point math, including exp() and cos() at compile
> time, including conv
On Tue, 2019-10-01 at 12:56 +0200, Jiri Kosina wrote:
> On Tue, 1 Oct 2019, Toke Høiland-Jørgensen wrote:
>
> > > - spin_unlock_bh(&fq->lock);
> > > + spin_unlock(&fq->lock);
> > > drv_wake_tx_queue(local, txqi);
> > > - spin_lock_b
On Tue, 2019-10-01 at 12:53 +0200, Toke Høiland-Jørgensen wrote:
>
> > - spin_unlock_bh(&fq->lock);
> > + spin_unlock(&fq->lock);
> > drv_wake_tx_queue(local, txqi);
> > - spin_lock_bh(&fq->lock);
> > + spi
> This change replaces the EWMA implementation with a moving average that's
> designed to significantly reduce lag while keeping a bigger window size
> by being better at filtering out noise.
>
> It is only slightly more expensive than the simple EWMA and still avoids
> divisions in its calculat
From: Johannes Berg
Drivers typically expect this, as it's the case for almost all cases
where this is called (i.e. from the TX path). Also, the code in mac80211
itself (if the driver calls ieee80211_tx_dequeue()) expects this as it
uses this_cpu_ptr() without additional protection.
This s
Hi,
> > Yeah, that does seem reasonable, especially if we're moving to bigger
> > messages anyway. If we do add something huge to each channel, we can
> > recover that code I suppose.
>
> So do you want me to drop the channel splitting logic and only allow
> this for bands? Or just keep this si
Hi,
> > > Because userspace needs to know if this is supported?
> > > IFF_LIVE_ADDR_CHANGE is a private flag... AFAIK userspace has no
> > > way of
> > > obtaining this.
> >
> > Oh, annoying.
> >
> > But that doesn't really mean that nl80211 is an appropriate place to
> > advertise it, IMHO?
>
On Tue, 2019-10-01 at 11:08 +0200, Toke Høiland-Jørgensen wrote:
>
> Awesome! Any idea for how to make it work on big-endian systems? I got a
> splat from the kbuild robot that triggered the BUILD_BUG_ON when
> building for m68k. I assume it's the union with codel_time_t that ends
> up being align
quot;cfg80211: Use const more consistently in for_each_element
macros")
as dependencies - the latter doesn't apply cleanly as it has a change
that doesn't apply, but that part of the change isn't necessary.
johannes
>From 35b3085c0087933b77e36e28776cffac9cf27338 Mon Sep 1
On Thu, 2019-09-19 at 14:22 +0200, Toke Høiland-Jørgensen wrote:
Given a ULL constant:
> +/* constants for calculating reciprocals to avoid division in fast path */
> +#define IEEE80211_RECIPROCAL_DIVISOR 0x1ULL
[...]
> +void ieee80211_sta_set_last_tx_bitrate(struct ieee80211_sta *pubst
Hi,
Sorry for the long time to review here ...
On Thu, 2019-09-19 at 14:22 +0200, Toke Høiland-Jørgensen wrote:
> From: Toke Høiland-Jørgensen
>
> To implement airtime queue limiting, we need to keep a running account of
> the estimated airtime of all skbs queued into the device. Do to this
> c
On Mon, 2019-09-30 at 15:28 -0300, Ramon Fontes wrote:
> > Based on this info, looks like hostapd/wpa_s versions might be causing
> > the difference,
> > can you please confirm the versions on both?
>
> They have the same hostap (hostapd + wpa_s) version:
> Hostapd v2.10-devel-hostap_2_9-102-g12de
On Sun, 2019-09-29 at 17:31 +0900, Taehee Yoo wrote:
> virt_wifi case is a little bit different case.
Well, arguably, it was also just missing this - it just looks different
:)
> I add the last patch that is to fix refcnt leaks in the virt_wifi module.
> The way to fix this is to add notifier ro
Hi,
> Since 5.3 landed, brcmfmac has been broken both on bcm4329 and bcm4330
> sdio devices.
Yep, thanks for the report. I don't think you mean 5.3, as that doesn't
contain the problematic commit as far as I can tell? That was commit
2a38075cd0be ("nl80211: Add support for EDMG channels").
I hav
Hi,
> > I didn't see any discussion on this, but perhaps I missed it? The cost
> > would be a bigger netdev struct (when lockdep is enabled), but we
> > already have that for all the VLANs etc. it's just in the private data,
> > so it's not a _huge_ difference really I'd think, and this is quite a
Hi,
Sorry for the delay.
> These functions are used as a callback function of
> netdev_walk_all_{upper/lower}_dev(). So these return types are needed.
Ah yes, I missed that, sorry.
> Without storing level storing, a walking graph routine is needed only
> once. The routine would work as a nestin
On Sat, 2019-09-28 at 16:48 +, Taehee Yoo wrote:
> This patch removes variables and callback these are related to the nested
> device structure.
> devices that can be nested have their own nest_level variable that
> represents the depth of nested devices.
> In the previous patch, new {lower/upp
Hi,
> int netdev_walk_all_upper_dev_rcu(struct net_device *dev,
> int (*fn)(struct net_device *dev,
> void *data),
> void *data)
> {
[...]
> }
>
> return 0;
> +
> }
that seem
> VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI and VXLAN.
> But I couldn't test all interface types so there could be more device
> types which have similar problems.
Did you test virt_wifi? I don't see how it *doesn't* have the nesting
problem, and you didn't change it?
No, I see. Y
Hi,
I hadn't seen the previous patchsets of this, and looking briefly in the
archives didn't really seem to say anything about this.
However, I'm wondering now: patches 2-7 of this patchset look basically
all identical in a way:
* you set the addr_list_lock's class to a newly registered key ins
On Sat, 2019-09-28 at 16:48 +, Taehee Yoo wrote:
> virt_wifi_newlink() calls netdev_upper_dev_link() and it internally
> holds reference count of lower interface.
[...]
> This patch adds notifier routine to delete upper interface before deleting
> lower interface.
Good catch, thanks!
For now
On Fri, 2019-09-27 at 10:01 -0300, Ramon Fontes wrote:
> > A monitor interface created on one of the (hwsim or other!) wiphys shows
> > all packets seen by that device.
>
> Weird. When I try to reproduce the same with a physical network
> interface, I can see no packets. It only shows the 802.11 p
[please quote properly]
On Fri, 2019-09-27 at 09:30 -0300, Ramon Fontes wrote:
> Yes, I agree that they are different things, but I can also see the
> packets through the monitor interface created via iw. Is this expected
> too?
The hwsim0 interface shows *all* packets on the virtual air.
A moni
On Thu, 2019-09-26 at 22:54 -0300, Ramon Fontes wrote:
> Hello,
>
> I've noticed that packets transmitted between two clients connected to
> a hostapd AP are also transmitted (injected) through the monitor
> interface. Is this expected behavior?
You mean on 'hwsim0'? That interface is just for m
On Fri, 2019-09-20 at 16:34 +0100, Bruno Antunes wrote:
> Hello,
>
> Does anyone knows if the new intel AX200 or intel AX201 have support
> for multiple virtual interfaces?
> Is there any intel Wi-Fi device that does support it?
TBH I'm not really sure what exactly it does now, but the driver doe
On Mon, 2019-09-23 at 15:12 +0300, Dmitry Osipenko wrote:
>
> Tested-by: Dmitry Osipenko
That was quick, heh!
Thanks,
johannes
From: Johannes Berg
In a few places we don't properly initialize on-stack chandefs,
resulting in EDMG data to be non-zero, which broke things.
Additionally, in a few places we rely on the driver to init the
data completely, but perhaps we shouldn't as non-EDMG drivers
may not init
From: Johannes Berg
The code copying the data assumes that the SSID element is
before the MBSSID element, but since the data is untrusted
from the AP, this cannot be guaranteed.
Validate that this is indeed the case and ignore the MBSSID
otherwise, to avoid having to deal with both cases for
From: Johannes Berg
We currently don't validate the beacon head, i.e. the header,
fixed part and elements that are to go in front of the TIM
element. This means that the variable elements there can be
malformed, e.g. have a length exceeding the buffer size, but
most downstream code from
On Fri, 2019-09-20 at 11:09 -0400, Tim Higgins wrote:
> On 9/19/2019 6:05 PM, Johannes Berg wrote:
> > Hi Tim,
> >
> > > I have been using the debug hw_sniffer_params file to tune the AX200 to a
> > > specific AID. This
> > > works well for capturing
Hi Tim,
> I have been using the debug hw_sniffer_params file to tune the AX200 to a
> specific AID. This
> works well for capturing OFDMA DL. But I have yet to capture any UL OFDMA
> frames, or at least I
> don't think I have.
>
> I am looking for QoS data frames that have HE_MU PPDU format.
On Fri, 2019-09-13 at 13:56 -0700, James Prestwood wrote:
> Hi,
>
> On Fri, 2019-09-13 at 22:48 +0200, Johannes Berg wrote:
> > On Fri, 2019-09-13 at 12:59 -0700, James Prestwood wrote:
> > > Add a new feature bit signifying that the wireless hardware
> > > suppor
On Fri, 2019-09-13 at 12:59 -0700, James Prestwood wrote:
> Add a new feature bit signifying that the wireless hardware supports
> changing the mac address while the underlying net_device is UP. Note
> that this is slightly different from IFF_LIVE_ADDR_CHANGE as additional
> restrictions might be
On Wed, 2019-09-11 at 12:20 -0700, James Prestwood wrote:
> I see what your saying, but theses kind of state changes are all over
> the place in other APIs, and undocumented: One example is
> SCAN_FLAG_FLUSH clearing out the scanning state for all other
> processes.
Scanning always changes scan l
On Wed, 2019-09-11 at 08:54 -0700, James Prestwood wrote:
>
> I could have made this a bit more clear. I initially did measure the
> time to a full connection, including EAPoL, but the more I timed the
> more chance there was for scheduling delays that really threw off the
> results. Not that thes
On Wed, 2019-09-11 at 07:41 -0500, Denis Kenzior wrote:
>
> For my dual band cards the channel dump all fits into a ~1k attribute if
> I recall correctly. So there may not really be a need for this. Or at
> the very least we could keep things simple(r) and only split at the band
> level, not
On Wed, 2019-09-11 at 07:20 -0500, Denis Kenzior wrote:
> > I'm not sure I see how the applications could do buffers that are
> > "inherently" large enough, there's no practical message size limit, is
> > there (32-bits for the size).
>
> The kernel caps this to 32k right now if I read the code c
ng (1):
mac80211: minstrel_ht: fix infinite loop because supported is not being
shifted
Denis Kenzior (1):
cfg80211: Purge frame registrations on iftype change
Felix Fietkau (1):
cfg80211: add local BSS receive time to survey information
Johannes Berg (4):
cfg80211: always shut
send out the VLAN binding update only if the STA
> entry has already been authorized.
Reviewed-by: Johannes Berg
Dave, if you were still planning to send a pull request to Linus before
he closes the tree on Sunday this would be good to include (and we
should also backport it to stable later).
If not, I can pick it up afterwards, let me know.
Thanks,
johannes
Hi,
On Fri, 2019-08-30 at 01:32 -0500, Denis Kenzior wrote:
> Hi Johannes,
>
> On 8/30/19 3:53 AM, Johannes Berg wrote:
> > On Wed, 2019-08-28 at 16:11 -0500, Denis Kenzior wrote:
> > > Currently frame registrations are not purged, even when changing the
> > >
On Fri, 2019-09-06 at 10:43 -0500, Denis Kenzior wrote:
>
> + * There are no limits (outside of netlink protocol limits) on
> + * message sizes that can be sent over the "config2" multicast group. It
> + * is assumed that applications utilizing "config2" multicast group
> + * utilize buffe
Hi,
The first patch looks good, couple of nits/comments on this one below.
On Fri, 2019-09-06 at 10:43 -0500, Denis Kenzior wrote:
> For historical reasons, NEW_WIPHY messages generated by dumps or
> GET_WIPHY commands were limited to 4096 bytes. This was due to the
> fact that the kernel only a
Hi James,
TBH, I'm still not really convinced.
> I have taken some timings for all 3 ways of changing the MAC. Powered
> change via RTNL, non powered via RTNL, and changing through
> CMD_CONNECT. All times were taken in microseconds and tested on an
> Intel 7260 PCI wireless adapter:
>From where
On Wed, 2019-09-04 at 11:22 -0500, Denis Kenzior wrote:
> To state another way, it is
> currently not possible to write a userspace application that utilizes a
> single nl80211 genl socket, instead it must open multiple genl sockets
> for multiple wdevs on multiple phys.
I don't see how this is to
Hi,
> Agreed. I guess I just view nl80211.h as a sort of combination between
> a uapi file and an actual manpage. And manpages do mention which kernel
> version a certain feature/flag/whatever was added. Such info can be
> useful in many ways, e.g. figuring out which kernel version might be
On Fri, 2019-08-30 at 14:24 +0300, Luca Coelho wrote:
> From: Ilan Peer
>
> To support Pre Association Security Negotiation (PASN) while already
> associated to one AP, allow user space to register to Rx authentication
> frames, so that the user space logic would be able to receive/handle
> authe
On Mon, 2019-09-09 at 10:03 -0700, Ben Greear wrote:
> Hello,
>
> Looks like we managed to crash the AX200 firmware. This was running 5.2.7+
> kernel
> in an apu2 platform.
>
> Is there a better place to report/discuss this?
This is OK for first reports, but usually we'll ask to file a bug on
On Fri, 2019-09-06 at 08:45 +0530, Sriram R wrote:
> Currently, self managed drivers cannot update the global regulatory
> using a regulatory hint from driver if the wiphy regd is already set
> from other sources.
> Due to this, when a regulatory hint is provided to cfg80211 from
> self managed dev
On Thu, 2019-09-05 at 11:20 -0700, Ben Greear wrote:
> Is anyone working on getting iw to print out /AX (HE) related
> info?
Good question, I wonder why we didn't do that. But no, we're not working
on it as far as I know, and I haven't seen anything from anyone else
either.
johannes
On Thu, 2019-09-05 at 15:29 +0300, Kalle Valo wrote:
>
> Yeah, I was supposed to write:
>
> "maybe we should change mac80211 to not require this op to be present"
>
> But of course I could have just misunderstood, let's see what Johannes
> says :)
:-)
Yes, that's what I meant.
johannes
On Fri, 2019-08-30 at 16:37 +0300, Jouni Malinen wrote:
> On Fri, Aug 30, 2019 at 12:38:20PM +0200, Johannes Berg wrote:
> > > > mesh_secure_ocv_mix_legacy
> > > > wpas_mesh_open_ht40
> > > > mesh_secure_ocv_mix_ht
> > > No, these also failed
On Fri, 2019-08-30 at 12:47 +0200, Arend Van Spriel wrote:
> On 8/30/2019 12:32 PM, Johannes Berg wrote:
> > On Thu, 2019-08-29 at 15:21 -0700, Amar Singhal wrote:
> > > Enhance function ieee80211_frequency_to_channel by adding 6 GHz
> > > channels.
> >
> &
On Fri, 2019-08-30 at 12:40 +0200, Arend Van Spriel wrote:
> > +EXPORT_SYMBOL(ieee80211_channel_op_class_to_frequency);
>
> The function ieee80211_operating_class_to_band() uses ranges within
> switch statement, eg.:
>
> case 128 ... 130:
> *band = NL80211_BAND_5GHZ;
>
On Fri, 2018-07-06 at 14:31 +0200, Johannes Berg wrote:
> On Tue, 2018-07-03 at 16:04 -0700, peter...@bowerswilkins.com wrote:
> > From: Peter Oh
> >
> > NL80211_ATTR_OFFCHANNEL_TX_OK does not mean given channel is always
> > off channel, but it means the channel
Hi,
> > mesh_secure_ocv_mix_legacy
> > wpas_mesh_open_ht40
> > mesh_secure_ocv_mix_ht
> No, these also failed for me without the mac80211_hwsim patch [3] in a full
> test run. And thus not analyzed further by me.
I also see these fail if (and only if) I have this patch applied.
I'm going to dr
On Thu, 2019-08-29 at 15:21 -0700, Amar Singhal wrote:
> Enhance function ieee80211_frequency_to_channel by adding 6 GHz
> channels.
Wait, this is already supported, no? Just implemented slightly
differently?
johannes
On Mon, 2019-08-26 at 11:26 -0500, Denis Kenzior wrote:
>
> + * Prior to Kernel 5.4, userspace applications should implement the
> + * following behavior:
I'm not sure mentioning the kernel version here does us any good? I
mean, you really need to implement that behaviour regardless of kernel
On Fri, 2019-08-16 at 14:27 -0500, Denis Kenzior wrote:
> Send large NEW_WIPHY events on a new multicast group so that clients
> that can accept larger messages do not need to round-trip to the kernel
> and perform extra filtered wiphy dumps.
>
> A new multicast group is introduced and the large m
On Fri, 2019-08-30 at 11:40 +0200, Johannes Berg wrote:
> On Fri, 2019-08-30 at 11:10 +0200, Johannes Berg wrote:
> > On Fri, 2019-08-30 at 11:03 +0200, Johannes Berg wrote:
> > > On Fri, 2019-08-16 at 14:27 -0500, Denis Kenzior wrote:
> > > > If a (legacy) client
On Fri, 2019-08-30 at 11:10 +0200, Johannes Berg wrote:
> On Fri, 2019-08-30 at 11:03 +0200, Johannes Berg wrote:
> > On Fri, 2019-08-16 at 14:27 -0500, Denis Kenzior wrote:
> > > If a (legacy) client requested a wiphy dump but did not provide the
> > > NL80211_ATTR_SPLI
On Fri, 2019-08-16 at 14:27 -0500, Denis Kenzior wrote:
> For historical reasons, NEW_WIPHY messages generated by dumps or
> GET_WIPHY commands were limited to 4096 bytes due to userspace tools
> using limited buffers.
I think now that I've figured out why, it'd be good to note that it
wasn't due
On Fri, 2019-08-30 at 11:03 +0200, Johannes Berg wrote:
> On Fri, 2019-08-16 at 14:27 -0500, Denis Kenzior wrote:
> > If a (legacy) client requested a wiphy dump but did not provide the
> > NL80211_ATTR_SPLIT_WIPHY_DUMP attribute, the dump was supposed to be
> > compose
On Fri, 2019-08-16 at 14:27 -0500, Denis Kenzior wrote:
> If a (legacy) client requested a wiphy dump but did not provide the
> NL80211_ATTR_SPLIT_WIPHY_DUMP attribute, the dump was supposed to be
> composed of purely non-split NEW_WIPHY messages, with 1 wiphy per
> message. At least this was the
On Wed, 2019-08-28 at 16:11 -0500, Denis Kenzior wrote:
> Currently frame registrations are not purged, even when changing the
> interface type. This can lead to potentially weird / dangerous
> situations where frames possibly not relevant to a given interface
> type remain registered and mgmt_fra
On Fri, 2019-08-30 at 00:35 +0530, Krishna Chaitanya wrote:
>
> Is this supposed to work at all? AFAICS, in hwsim channel matching
> checks are only done in non-mediumd path (no_nl), and wmediumd also
> doesn't have any checks? So, hostapd responds to all probe requests in all
> channels. Am I mis
On Thu, 2019-08-29 at 15:09 -0700, Amar Singhal wrote:
> A channel is completely defined by (oper_class, channel number) tuple,
> and not just by center frequency. Operating class also tells about the
> bandwidth supported by the channel. Therefore add the operating class and
> channel number to th
1 - 100 of 4576 matches
Mail list logo
