Re: [PATCH v2 0/5] wifi: add opt-in FIPS exception for iwlwifi

[Jose Ignacio Tornos Martinez <jtornosm@redhat.com>]

Hi Johannes,

Sorry for the delay. I wanted to have concrete results
before continuing the conversation.

> No keys at all, but yeah.

Right, no keys at all in firmware.

> What are you testing with now? Still MFP?

Yes, MFP enabled. WPA2-PSK with ieee80211w=2 on the AP,
AX211 as STA, channel 52 80MHz HE.

> That doesn't really make sense. How can TX A-MPDU work
> when you have MFP, this was the bit you disabled earlier
> even with all the other work? And the firmware has to
> send the AddBA request, so that can't make it through??

You are right, it does not work. I was wrong in my
previous mail, sorry about that. Monitoring the frames
with a separate station in monitor mode (mt76) I can
see that firmware sends ADDBA Request unprotected, AP
drops it (MFP), firmware retries every ~2 seconds
followed by DELBA, all dropped. TX throughput is ~26
Mbps (individual MPDUs, no aggregation).

Following the pattern of mt76, I tested triggering
ieee80211_start_tx_ba_session() from the driver so
mac80211 sends an encrypted ADDBA through the normal
TX path. The AP accepts, the BA session is fully
established and persists, no DELBA is sent by the AP.
But TLC does not know about this host-established
session so it still does not aggregate.

Is there a way to allow TX aggregation from mac80211
in this scenario, similar to how the RX path can be
managed from the host? Or any other mechanism to let
TLC know that a BA session has been established for a
TID so it can aggregate? I could not find a TX
equivalent of STA_MODIFY_ADD_BA_TID in the firmware
API, but maybe there is another way I am missing.

> That almost seems low (11g maxed out at ~24 Mbps with
> 54 Mbps PHY rate), but depends on the channel width
> and MCS.

The same setup without fips=1 gives ~500 Mbps, so
the individual MPDU overhead explains the gap.

> I'd have said it should already work that way.

You were right. After debugging I found the places in
the RX path where frames were being dropped without
keys and fixed them (see v3 3/4).

I am sending a v3 (4 patches) with the current working
state as a provisional version to show you the status
and continue with your guidance. The series covers:
fips_allows_exception() infrastructure, MFP re-enabled,
RX AMPDU and A-MSDU fixes, and debug message reduction.
RX throughput is back to ~450 Mbps with these fixes.
TX throughput is the remaining limitation.

I plan to address IGTK/BIGTK offload and 6 GHz
dependencies in later versions of this series once we
settle the aggregation question.

Thank you for the guidance

Best regards
Jose Ignacio