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] [day] [month] [year] [list]

Message-ID: <0bc6c957-a0c4-c0f7-ed37-c8b44852c26c@candelatech.com>
Date: Tue, 24 Jun 2025 15:31:26 -0700
From: Ben Greear <greearb@...delatech.com>
To: Ramanathan Choodamani <quic_rchoodam@...cinc.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/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?

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

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com