netdev - Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4d87c56e-f198-4abf-a414-4b226178d164@quicinc.com>
Date: Tue, 1 Jul 2025 12:38:49 -0700
From: Ramanathan Choodamani <quic_rchoodam@...cinc.com>
To: Ben Greear <greearb@...delatech.com>, <linux-wireless@...r.kernel.org>
CC: <netdev@...r.kernel.org>, <ath12k@...ts.infradead.org>
Subject: Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP



On 6/24/2025 3:31 PM, Ben Greear wrote:
> On 6/24/25 13:57, Ramanathan Choodamani wrote:
>> ===================================
>> Robust AV streaming protocols - QoS
>> ===================================
>>
>> The Robust AV stream protocols are mobile centric protocols - meaning they
>> are initiated by a non-AP STA to the AP. These protocols are implemented
>> at the Access Point (AP) to classify packets sent to the non-AP STA which requests
>> classification using action frames. The non-AP STA initiates Robust AV streaming
>> action frames requesting for specific classification for the IP packets
>> destined to the non-AP STA from the AP. These parameters can be negotiated by both
>> AP and non-AP STA.
>>
>> Upon successful handshake, The AP classifies incoming individually addressed MSDUs
>> (Mac Service Data Unit) based upon parameters provided by the non-AP STA or
>> notifies the non-AP STA to transmit MSDUs with preferred parameters based upon
>> what was exchanged.
>>
>> Robust AV streaming improves AV (Audio and Video) streaming performance when
>> using IEEE Std 802.11 for consumer and enterprise applications.
>>
>> Let's look at the Robust AV streaming protocols which are implemented as a
>> part of this design.
> 
> Thank you for posting this and for the beautiful ascii diagrams!
> 
> Since this will be poking netfilter rules into the kernel,
> is there a good way to clean up all rules created by a previous
> hostapd process in case hostapd crashes or is killed hard and
> cannot do its own cleanup?  Maybe the rules could have some
> special marking that is configurable per hostapd (or per AP or BSS or something)
> so that a (re)started hostapd could clean up any leftovers from a
> previous instance?
> 
hostapd does its own cleanup (cleanup of stations and interfaces) 
when it receives SIGTERM.

An nft chain is created for each AP netdev/interface.

The nft rule handle (stored in internal hostapd data structure) and 
nft chain metadata can be used to cleanup/flush the nft rules as part of the 
interface cleanup.

> And, is there a mechanism to clean up flows that a buggy non-AP STA
> has requested but then forgot to terminate (like phone starts a video call,
> requests some QoS, then forgets to tell AP that it is done with the call
> and packets no longer need to be classified?)
> 
> Thanks,
> Ben
> 
The scs objects of the stations will be cleaned up during the station 
disconnect (by the AP which is maintaining them).
As part of this deletion, the nft rules are also deleted, using the 
stored nft rule handle.

/ram