From nobody Sun May 24 19:33:40 2026 Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 914153A6B90 for ; Sat, 23 May 2026 14:25:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.45 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779546314; cv=none; b=UQHA022ZDiKARznYZe59lS2mwHnkrFc7ILhSeXISlsy0EqnDQR/q8mDkyypnc5QDvRFaYtm23urEt+NeU/g9tmMlF7NsrRgbcSCCvNdINDqHzvsh3AJML7XGFggL7hI6gqwP5KEetwly6oOe46re8GBn2kM3cKEO6ScmgjzJ678= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779546314; c=relaxed/simple; bh=fxeEt8WOJ8LIimxgCQJSjj/eTbmjRqeA5dJmCD7G15k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=DGfsXnXaMQNWAoHLOUfqDhYre3X4wI7m37raJyKt5bonPkbinC3UcVC9tyz1PDJxiaC8QaH0ZNruktpJmUbbHIMpygSjOiiKGLdE/uRPzH4jSBVnLDQkMKm8TM5Jvn9zGGOg48/vT7bwTv+6K+AzKFTFRcx2cPm8psyd76hI6Ww= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=J/DjFZUA; arc=none smtp.client-ip=209.85.219.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="J/DjFZUA" Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-8acb856a674so101891446d6.0 for ; Sat, 23 May 2026 07:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779546313; x=1780151113; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=JsSvQplB7jvK5Z1Ih49srVWHDqYh9wF4q8heYj0Wpvo=; b=J/DjFZUAP7r2Oqfeuf3Gc90NjKD73HXNb1UM8gRRjiQ2lpjd0sxv7k3KUx+ul/Rjck lQAcT2xMignzVZDVWpM19nPdYD/d9Pa4ZFOoBgmKTWLIFCKDzFVrCCHliUYt32m82FbQ INKiPVBQ9yEGHLYcvyEOs/F3SKDAs5pMpBTA3emBnTuE3HfaHxhFc+Q4shhhqJ30c5pm rx6ZMardSB7sP0vvDd9ZIpXFuqx4sAxIBiRawwIZLbbqOJdu/EjMTgfHEFVhF6ysH1xB Xur+zXDslG9179QE4QNdhTZopJBgRecFPo4iKH8zMcmIN3CIW8Y4HKvnBzB9rr4VjYIY Giag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779546313; x=1780151113; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JsSvQplB7jvK5Z1Ih49srVWHDqYh9wF4q8heYj0Wpvo=; b=IURTi/IS4tCJJrxy5ZlVVYhPhsSy/M6N8ep2XJ98pxlT61xCjpIMNM2ug85kNDzpaz 0sofn2wWro2s4eo/+tfC47PPH2Xqmy4OrYcgPWiSK5tqo8Ri20AkW+/FBukB2SN7fCml Yoby0/sIR4yydChnVDj9KAFcWzl2j721PjsTmg2TfYAc4g316pu7SPoaEy/gzNvtSAge PLJ8Ow1sqrc+aTekO7Yr4olYmY3xr/xnmFalk0fgWZjLMgFW2dYtw+kS+cctYlaKHbHn GO5t+7mVDSkuUfPIZljJ+S029kwtrjZGEU8mLXFt6QeV1wL8H82GUHLdYDN1jxk4KTr7 7cig== X-Forwarded-Encrypted: i=1; AFNElJ9BTS+aDtK/s8dAbEYn5t7IO+Mi1IzfLjF/UMomin9cNpaFwJQOjQ+hqqkduS8IsAhWhdBTVWXxxxldZOA=@vger.kernel.org X-Gm-Message-State: AOJu0Yw3qRDLXDX3gkNJlUlkHQyzWX/eTjKq8I+aPDVjR9cKe0kyCGLS i0vnIAnEb0VYOhGQpdxHIHB8hObnuJ7oJQr7aDc/9Y0GCW1MV+T9BFxV X-Gm-Gg: Acq92OGYqy+x32zvwW4sOAUlAkSarSQoLn6fzzecMDiyhCsn9rrcnPU6x2BSTzsAxWD PSaApC0654OV7K0WVjyL6Vi2bej293NO5ztlgwsd+M429TlS0MgrMyCc9f+847waiPc+n7FtIYe bmSX35vO03vRq8W8CfHM51lN963wJffhVqBSf6gKO+MF2MUGSA809t7cp6xBiBIROGbqik7u9oq 0i8OAPz9ROuQWhjkVcfEclyD0yvEoPCcIRbm0/V+DcpE17wlT2EirLmLuCeNX4artJgqqX09t0z WMWQkotzH9YCykQ1W4fdk581DloWNtwMW5XQo1EXGpDWgJNNXL9sr8KGi6FbmY8c0RWGOrJ+QUD b+VRmvmr8CPqBK19MKfRmE+kjWNjtZqLDOAsL3YnGy8kXCV4kAq8nEpqTUWi1GjuSf1lf9fgf6X midGEV6fpH5P6VrNIlCusX7eblORJCq+R0LOSRCLS2sa/tWRhqBxrPhp2hQJDv8/u2VepNxGU1k SokiAgr95DssPgRQ2B7 X-Received: by 2002:a05:6214:498b:b0:8ae:6293:78ca with SMTP id 6a1803df08f44-8cc7bee818fmr122390976d6.18.1779546312568; Sat, 23 May 2026 07:25:12 -0700 (PDT) Received: from mobile5 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8cc812e2018sm47914196d6.28.2026.05.23.07.25.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 May 2026 07:25:12 -0700 (PDT) From: Mike Bommarito To: Miri Korenblit Cc: Johannes Berg , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] wifi: iwlwifi: mvm: handle SEC_UNKNOWN in non-AMPDU rx path Date: Sat, 23 May 2026 10:24:38 -0400 Message-ID: <20260523142438.118284-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" iwl_mvm_rx_crypto() does not handle IWL_RX_MPDU_STATUS_SEC_UNKNOWN explicitly in the non-AMPDU path: the switch's default case fires "Unhandled alg: 0x71b" for what the firmware documents as a benign condition (a cipher class not enumerated in the RX status field, or frames arriving before key install). On a Meteor Lake laptop with an AX210 this produced 152 warnings across ~43.5 hours of normal use; net_ratelimit spaced them out but did not silence them. The AMPDU sibling path at the top of the function already handles this status explicitly. Add an explicit SEC_UNKNOWN case that breaks to the final return 0 (passing the frame undecrypted to mac80211, matching the default's effective behavior), with a dev_info_once() so the condition stays observable at default log levels without per-frame spam, and an IWL_DEBUG_DROP per occurrence mirroring the AMPDU handler. Behavior for every other status value is unchanged. Link: https://lore.kernel.org/all/0e1a890d2896791d7291f0174cc0e96832d7ed33.= camel@intel.com/ Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Mike Bommarito --- Historical context (for reviewers, not the changelog) The same warning was reported on Intel 9260 in 2019 [1]. Emmanuel Grumbach acknowledged then that "this print is harmless really", attributed it to a deprecated firmware flag, and suggested two fixes: "remove the warning message entirely or limit it to unicast packets only -- this has been merged in our internal repository and it will be upstreamed following the regular process." The unicast restriction is now in tree (the default case guards on !is_multicast_ether_addr() && net_ratelimit()), but the remove-the-warning half never landed upstream. This patch is the narrower of Grumbach's two suggestions: only IWL_RX_MPDU_STATUS_SEC_UNKNOWN is special-cased, the existing default-case warning is preserved for genuinely unknown status values. Test data Pre-patch baseline on Framework Laptop 13 (Intel Core Ultra 5 125H, AX210, Linux 7.1-rc4): 152 "Unhandled alg: 0x71b" entries in dmesg across ~43.5 hours of mixed use, plus a burst of three within 70 ms during a single re-association: [162152.782317] iwlwifi 0000:aa:00.0: Unhandled alg: 0x71b [162152.813440] iwlwifi 0000:aa:00.0: Unhandled alg: 0x71b [162152.844499] iwlwifi 0000:aa:00.0: Unhandled alg: 0x71b Status decoding: 0x71b & 0x700 =3D=3D SEC_UNKNOWN; low bits are informational and vary between frames. Post-patch: module rebuilt + reloaded. Triggered scans and nmcli reconnect cycles until a SEC_UNKNOWN frame was received. The new switch case fired its dev_info_once exactly once: iwlwifi 0000:aa:00.0: RX SEC_UNKNOWN (status=3D0x707) Zero "Unhandled alg" warnings observed during the same window. A CONFIG_IWLWIFI_DEBUG=3Dy build with IWL_DL_DROP enabled would additionally show one IWL_DEBUG_DROP per qualifying frame; the test kernel had CONFIG_IWLWIFI_DEBUG=3Dn so those entries are absent but the dev_info_once carries the per-controller signature. drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wi= reless/intel/iwlwifi/mvm/rxmq.c index 7f0b4f5daa21..f36e99c90ee3 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c @@ -494,6 +494,19 @@ static int iwl_mvm_rx_crypto(struct iwl_mvm *mvm, stru= ct ieee80211_sta *sta, return 0; case RX_MPDU_RES_STATUS_SEC_CMAC_GMAC_ENC: break; + case IWL_RX_MPDU_STATUS_SEC_UNKNOWN: + /* + * Firmware-indicated unknown cipher; the AMPDU case is + * already handled at the top of this function. For + * non-AMPDU frames this is valid (cipher not enumerated + * by the RX status field, or frame before key install). + * Pass undecrypted to mac80211. + */ + dev_info_once(mvm->dev, + "RX SEC_UNKNOWN (status=3D0x%x)\n", status); + IWL_DEBUG_DROP(mvm, + "RX SEC_UNKNOWN (status=3D0x%x)\n", status); + break; default: /* * Sometimes we can get frames that were not decrypted --=20 2.53.0