| 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
| ||
|
Message-ID: <ffc40c71b73eb1366435c09bd5cc25dd9e128c72.camel@sipsolutions.net> Date: Fri, 27 Jun 2025 09:24:14 +0200 From: Johannes Berg <johannes@...solutions.net> 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 Hi, (With my cfg80211/mac80211 maintainer hat on) > 2.1.3 - QoS Provisioning > ------------------------- > > Hostapd extracts the QoS parameters from SCS/MSCS request, and > sends the parameters via NL80211 command (NL80211_CMD_QOS_MGMT). Do you have any idea yet what that would entail? I'm thinking it would also need add/remove, perhaps, and some kind of lifetime tracking on the station? > > 2.1.4 - Networking Provisioning > ------------------------------- > Hostapd if required and as indicated by the WLAN driver > capabilities, would add rules in the netfilter subsystem > via libnftables, such that flows matching the TCLAS > parameters are marked with certain meta data using skb->mark > to assist in prioritization in the MSDU processing in the WLAN > driver data path. > > In MSCS, hostapd will receive the Rx flow tuple from WLAN > driver using NL80211 command (NL80211_CMD_QOS_MGMT) and then > make a decision to install an nftable rule in the netfilter > subsystem based on MSCS parameters exchanged > during handshake. > > The WLAN driver will be responsible for classifying the > new flow received and parse the tuple information from the MSDU > and use the framework to send event to hostapd. For > identifying a new flow, the WLAN driver can make use of > any HW offload assist features it supports, as maintaining > flow information in software on a per-packet basis will be > expensive for flow classification. How would the classification propagate through the layers? > (B) cfg80211 > ------------- > > The cfg80211 layer receives the NL(NL80211_CMD_QOS_MGMT), parses > the parameters and passes further down into the mac80211 layer. > > (C) mac80211 > ------------- > > The mac80211 calls into the WLAN driver with the QoS and > networking parameters. > > (D) WLAN driver > ----------------- > > The WLAN driver receives the QoS characteristics and the > TCLAS elements and can do the required resource allocation and > the Firmware(FW)/Hardware(HW) programming based on the underlying HW > capabilities. Without really going into the actual implementation, structurally, what would this contain? And architecturally, is it really just one set of parameters? It would seem to be more specific, like for a given station? > 2.3 - Data Path (MSCS/SCS) - done at WLAN driver > -------------------------------------------------- > 3. Hostapd provisions the rule to NFT > ┌─────────────────────────────────┐ > │ │ N/W provisioning > │ hostapd ┌─────────┐┼────────────────────────┐ > │ │libnftnl ││ │ > └──────────────────────└──▲──────┘┘ │ > user space │ │ > ───────────────────────────────────┼──────────────── │ > ┌──────────────────────────┼─────────┐ │ > │ │ │ 4. │ > kernel space │ ┌────────────────────────┴──────┐ │ NFT updates skb->mark│ > │ │ nl80211/cfg80211 │ │ while adding the rule│ > │ │ │ │ ┌──────────────────┼──┐ > │ └────────────────────────▲──────┘ │ │ │ │ > │ │ │ │ │ │ > │ ┌────────────────────────┼──────┐ │ │ Linux N/W stack │ │ > │ │ mac80211 ◄──┼───┼ │ │ > │ │ │ │ │ ┌──────────▼─┐│ > │ └───┬────────────────────▲──────┘ │ │ │netfilter ││ > 5. The DL packet │ │ │ │ └───────└────────────┘┘ > comes with │ ┌───▼────────────────────┼──────┐ │ > skb->mark │ │ │ │ > which is used │ │ │ │ > for classification │ │ WLAN drv │ │2. > along with │ │ │ │Driver then programs the rule to hostapd > stored QoS │ │ │ │using NL80211 > params at the │ │ │ │ > driver │ │ │ │1. > │ └───┬────────────────────▲──────┘ │For MSCS flows, driver learns a new rx flow > │ │ │ │using HW assist > └─────┼────────────────────┼─────────┘ > ┌─────▼────────────────────┼─────────┐ > │ │ > │ Hardware │ > │ │ > └────────────────────────────────────┘ Terminology wise, "driver then programs the rule to hostapd" seems ... confusing. It's more like "notifies hostapd of the new flow" or so? > * The Datapath decision making logic for the QoS features > would be handled in the WLAN driver. What decision making logic is even in the datapath? > * In MSCS, Driver will be responsible to track all the uplink flows > for a non-AP STA with MSCS session, based on > TCLAS mask and should prioritize the corresponding downlink flows. > > * For prioritization in DL for MSCS, the driver should notify hostapd > using NL80211 framework (via mac80211, cfg80211) to program the > netfilter rules, when a new Rx uplink flow is received. Here I don't follow - I can see how uplink needs the driver to parse/classify the flow and tell hostapd about the mark or so, but on DL the whole thing starts at higher layers, no? > * As mentioned in Section 2.1.4., In MSCS hostapd receives the > Rx flow tuple from the driver via NL80211_CMD_QOS_MGMT, > then decides whether to install an nftables rule in netfilter > based on MSCS handshake parameters. For an uplink flow, I'm not even sure what netfilter rules need to be there be at all? Once a packet is received, it's effectively game over for classification / air competition / etc. no? johannes
Powered by blists - more mailing lists