On 2018-06-29 15:05, Johannes Berg wrote:
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
Add cfg80211_sta_mon_rssi_notify api to update user space upon
crossing the configured rssi threshold of a station.
NL80211_CMD_NOTIFY_STA_MON introduced to send this event to
userspace along with
On 2018-06-29 14:59, Johannes Berg wrote:
On Wed, 2018-06-13 at 16:15 +0530, Tamizh chelvam wrote:
+ * @NL80211_ATTR_STA_MON: Station's connection monitor configuration
in a
+ * nested attribute with %NL80211_ATTR_STA_MON_* sub-attributes.
Can't we reuse the existing attributes in this
On 2018-06-29 15:01, Johannes Berg wrote:
The subjects are a bit confusing - I think you should align the
cfg80211
and mac80211 ones so it's clearer that this one is implementing the
previous one's API. Peer vs. station, and mac80211 doesn't add API but
implements it.
This patch doesn't really
On 07/03/2018 04:48 PM, Johannes Berg wrote:
On Tue, 2018-07-03 at 13:40 -0700, Peter Oh wrote:
On 07/03/2018 05:47 AM, Johannes Berg wrote:
From: Johannes Berg
Since (QoS) NDP frames shouldn't be put into aggregation nor are
assigned real sequence numbers, etc. it's better to treat them
Hello,
>
>> I was wrong here, this is not an issue. Tkip is simply dropping frames
>> when the IV is too small and never verifies the MIC. And since only MIC
>> errors can trigger counter measures we are fine as it is...
>
> Err, yes, of course. My bad.
>
3) Is what I implemented. We try
On Tue, 2018-07-03 at 21:54 +0200, Alexander Wetzel wrote:
> > I think easier would be to just disconnect ourselves? At least if we're
> > in managed mode...
> >
>
> I still have much to learn about 802.11, but so far I did not see way to
> directly disconnect a STA. (Maybe spoofing a "signal l
On Tue, 2018-07-03 at 13:40 -0700, Peter Oh wrote:
>
> On 07/03/2018 05:47 AM, Johannes Berg wrote:
> > From: Johannes Berg
> >
> > Since (QoS) NDP frames shouldn't be put into aggregation nor are
> > assigned real sequence numbers, etc. it's better to treat them as
> > non-data packets and not
From: Peter Oh
NL80211_ATTR_OFFCHANNEL_TX_OK does not mean given channel is always
off channel, but it means the channel given could be off channel.
Hence it should not block the given channel to be used if given
channel does not require off channel mgmt tx although regulatory
domain is non-ETSI.
On 07/03/2018 05:47 AM, Johannes Berg wrote:
From: Johannes Berg
Since (QoS) NDP frames shouldn't be put into aggregation nor are
assigned real sequence numbers, etc. it's better to treat them as
non-data packets and not put them on the normal TXQs, for example
when building A-MPDUs they nee
The current implementation of cfg80211_rx_control_port assumed that the
caller could provide a contiguous region of memory for the control port
frame to be sent up to userspace. Unfortunately, many drivers produce
non-linear skbs, especially for data frames. This resulted in userspace
getting not
Hi Arend,
On 07/03/2018 02:18 PM, Arend van Spriel wrote:
Hi Denis,
I prefer the subject summarizes the issue, eg. "allow non-linear skb
data passed to cfg80211_rx_control_port".
Right, I'll fix this in the next version.
On 7/3/2018 8:26 PM, Denis Kenzior wrote:
The current implementatio
Hi Denis,
I prefer the subject summarizes the issue, eg. "allow non-linear skb
data passed to cfg80211_rx_control_port".
On 7/3/2018 8:26 PM, Denis Kenzior wrote:
The current implementation of cfg80211_rx_control_port assumed that the
caller could provide a contiguous region of memory for the
The current implementation of cfg80211_rx_control_port assumed that the
caller could provide a contiguous region of memory for the control port
frame to be sent up to userspace. Unfortunately, many drivers produce
non-linear skbs, especially for data frames. This resulted in userspace
getting not
Hi
>
> On Mon, Jun 25, 2018 at 02:55:51PM +0200, Lorenzo Bianconi wrote:
> > Not sure why many integration commits in upstream is a problem. I think
> > having patches posted on mailing list is better than doing them in my
> > "private" tree without any review.
> >
> > > What do you think?
> >
>
On 07/03/2018 05:57 AM, Kalle Valo wrote:
Felix Fietkau writes:
On 2018-07-03 08:14, Kalle Valo wrote:
Pkshih writes:
On Fri, 2018-06-29 at 10:30 +0300, Kalle Valo wrote:
Pkshih writes:
On Tue, 2018-05-29 at 08:18 +0300, Kalle Valo wrote:
writes:
Because C2H data is little endia
Johannes Berg writes:
> On Tue, 2018-07-03 at 16:31 +0200, Toke Høiland-Jørgensen wrote:
>> Johannes Berg writes:
>>
>> > From: Johannes Berg
>> >
>> > Since (QoS) NDP frames shouldn't be put into aggregation nor are
>> > assigned real sequence numbers, etc. it's better to treat them as
>> >
On Tue, 2018-07-03 at 16:31 +0200, Toke Høiland-Jørgensen wrote:
> Johannes Berg writes:
>
> > From: Johannes Berg
> >
> > Since (QoS) NDP frames shouldn't be put into aggregation nor are
> > assigned real sequence numbers, etc. it's better to treat them as
> > non-data packets and not put them
Johannes Berg writes:
> From: Johannes Berg
>
> Since (QoS) NDP frames shouldn't be put into aggregation nor are
> assigned real sequence numbers, etc. it's better to treat them as
> non-data packets and not put them on the normal TXQs, for example
> when building A-MPDUs they need to be treated
From: Johannes Berg
Since (QoS) NDP frames shouldn't be put into aggregation nor are
assigned real sequence numbers, etc. it's better to treat them as
non-data packets and not put them on the normal TXQs, for example
when building A-MPDUs they need to be treated specially, and they
are more used
On 2018-07-03 12:57, Kalle Valo wrote:
>>> To me that does not make any sense, I have never heard about bit
>>> endianness any of the devices I have worked on.
>>
>> Unfortunately, the order in which these fields are laid out is different
>> between big and little endian, even when only dealing wit
Felix Fietkau writes:
> On 2018-07-03 08:14, Kalle Valo wrote:
>> Pkshih writes:
>>
>>> On Fri, 2018-06-29 at 10:30 +0300, Kalle Valo wrote:
Pkshih writes:
> On Tue, 2018-05-29 at 08:18 +0300, Kalle Valo wrote:
>> writes:
>>
>
> Because C2H data is little
On Fri, 2018-06-29 at 23:14 +0200, Alexander Wetzel wrote:
> I was wrong here, this is not an issue. Tkip is simply dropping frames
> when the IV is too small and never verifies the MIC. And since only MIC
> errors can trigger counter measures we are fine as it is...
Err, yes, of course. My bad.
On Mon, 2018-07-02 at 14:48 +0530, Manikanta Pubbisetty wrote:
> >
> > > @@ -298,10 +354,15 @@ static void __ieee80211_wake_queue(struct
> > > ieee80211_hw *hw, int queue,
> > > if (local->q_stop_reasons[queue][reason] == 0)
> > > __clear_bit(reason, &local->queue_stop
On 2018-07-03 08:14, Kalle Valo wrote:
> Pkshih writes:
>
>> On Fri, 2018-06-29 at 10:30 +0300, Kalle Valo wrote:
>>> Pkshih writes:
>>>
>>> > On Tue, 2018-05-29 at 08:18 +0300, Kalle Valo wrote:
>>> >> writes:
>>> >>
>>> >
>>> > Because C2H data is little endian order, the struct will look l
24 matches
Mail list logo
