[PATCH 12/12] carl9170: rx: handle zeroed PLCP CCK rate as corrupted frame

[PATCH 12/12] carl9170: rx: handle zeroed PLCP CCK rate as corrupted frame

[Masi Osmani]

The firmware occasionally delivers frames tagged as CCK modulation
with a zeroed PLCP rate byte (plcp[0] == 0x00).  This typically
happens after PHY state degradation from a failed channel change or
from RF noise on weak signals.

Currently these frames fall through to the default case and produce
a rate-limited wiphy_err log:

  ieee80211 phy3: invalid plcp cck rate (0).

The frame is garbage regardless of the log level.  Handle plcp[0]
== 0x00 as a dedicated case: increment the rx_dropped counter
(visible via debugfs) and return -EINVAL silently.  Downgrade the
remaining default case log from wiphy_err to wiphy_dbg so that
genuinely unexpected PLCP values can still be investigated via
dynamic debug without polluting normal dmesg output.

Signed-off-by: Masi Osmani <mas-i@hotmail.de>
---
 drivers/net/wireless/ath/carl9170/rx.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/carl9170/rx.c	2026-03-15 23:51:23.599698582 +0100
+++ b/drivers/net/wireless/ath/carl9170/rx.c	2026-03-15 23:52:21.041912498 +0100
@@ -372,9 +372,18 @@ static int carl9170_rx_mac_status(struct
 		case AR9170_RX_PHY_RATE_CCK_11M:
 			status->rate_idx = 3;
 			break;
+		case 0x00:
+			/*
+			 * Zeroed PLCP rate byte: the firmware delivered a
+			 * corrupted frame, typically after PHY degradation
+			 * from a failed channel change or from RF noise on
+			 * weak signals.  Drop silently.
+			 */
+			ar->rx_dropped++;
+			return -EINVAL;
 		default:
 			if (net_ratelimit()) {
-				wiphy_err(ar->hw->wiphy, "invalid plcp cck "
+				wiphy_dbg(ar->hw->wiphy, "invalid plcp cck "
 				       "rate (%x).\n", head->plcp[0]);
 			}
 

Re: [PATCH 12/12] carl9170: rx: handle zeroed PLCP CCK rate as corrupted frame

[Christian Lamparter]

On 3/15/26 11:56 PM, Masi Osmani wrote:
> The firmware occasionally delivers frames tagged as CCK modulation
> with a zeroed PLCP rate byte (plcp[0] == 0x00).  This typically
> happens after PHY state degradation from a failed channel change or
> from RF noise on weak signals.

And the firmware just "delivers" the frame that it gets from the hardware.
Apart from filtering (if enabled) it doesn't/shouldn't edit it.

> Currently these frames fall through to the default case and produce
> a rate-limited wiphy_err log:
> 
>    ieee80211 phy3: invalid plcp cck rate (0).
> 
> The frame is garbage regardless of the log level.  Handle plcp[0]
> == 0x00 as a dedicated case: increment the rx_dropped counter
> (visible via debugfs) and return -EINVAL silently.  Downgrade the
> remaining default case log from wiphy_err to wiphy_dbg so that
> genuinely unexpected PLCP values can still be investigated via
> dynamic debug without polluting normal dmesg output.
> 
> Signed-off-by: Masi Osmani <mas-i@hotmail.de>
> ---
>   drivers/net/wireless/ath/carl9170/rx.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
> 
> --- a/drivers/net/wireless/ath/carl9170/rx.c	2026-03-15 23:51:23.599698582 +0100
> +++ b/drivers/net/wireless/ath/carl9170/rx.c	2026-03-15 23:52:21.041912498 +0100
> @@ -372,9 +372,18 @@ static int carl9170_rx_mac_status(struct
>   		case AR9170_RX_PHY_RATE_CCK_11M:
>   			status->rate_idx = 3;
>   			break;
> +		case 0x00:
> +			/*
> +			 * Zeroed PLCP rate byte: the firmware delivered a
> +			 * corrupted frame, typically after PHY degradation
> +			 * from a failed channel change or from RF noise on
> +			 * weak signals.  Drop silently.
> +			 */
> +			ar->rx_dropped++;
> +			return -EINVAL;

I don't think we can really tell? From what I know the antenna must have pick up
this frame that way already. Is there some insight in how the hardware works?
Because from what I can gleam this "head->plcp[0]" seems to be pretty much the raw
value from what the PHY produced.

Note: This all might be because AR9170_MAC_RX_CTRL_PASS_TO_HOST is enabled.

>   		default:
>   			if (net_ratelimit()) {
> -				wiphy_err(ar->hw->wiphy, "invalid plcp cck "
> +				wiphy_dbg(ar->hw->wiphy, "invalid plcp cck "
>   				       "rate (%x).\n", head->plcp[0]);
>   			}

Downgrading this to debug? Yes, that I'm totally fine with.

[PATCH 12/12] carl9170: rx: handle zeroed PLCP CCK rate as corrupted frame

[Masi Osmani]

The firmware occasionally delivers frames tagged as CCK modulation
with a zeroed PLCP rate byte (plcp[0] == 0x00).  This typically
happens after PHY state degradation from a failed channel change or
from RF noise on weak signals.

Currently these frames fall through to the default case and produce
a rate-limited wiphy_err log:

  ieee80211 phy3: invalid plcp cck rate (0).

The frame is garbage regardless of the log level.  Handle plcp[0]
== 0x00 as a dedicated case: increment the rx_dropped counter
(visible via debugfs) and return -EINVAL silently.  Downgrade the
remaining default case log from wiphy_err to wiphy_dbg so that
genuinely unexpected PLCP values can still be investigated via
dynamic debug without polluting normal dmesg output.

Signed-off-by: Masi Osmani <mas-i@hotmail.de>
---
 drivers/net/wireless/ath/carl9170/rx.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/net/wireless/ath/carl9170/rx.c	2026-03-15 23:51:23.599698582 +0100
+++ b/drivers/net/wireless/ath/carl9170/rx.c	2026-03-15 23:52:21.041912498 +0100
@@ -372,9 +372,18 @@ static int carl9170_rx_mac_status(struct
 		case AR9170_RX_PHY_RATE_CCK_11M:
 			status->rate_idx = 3;
 			break;
+		case 0x00:
+			/*
+			 * Zeroed PLCP rate byte: the firmware delivered a
+			 * corrupted frame, typically after PHY degradation
+			 * from a failed channel change or from RF noise on
+			 * weak signals.  Drop silently.
+			 */
+			ar->rx_dropped++;
+			return -EINVAL;
 		default:
 			if (net_ratelimit()) {
-				wiphy_err(ar->hw->wiphy, "invalid plcp cck "
+				wiphy_dbg(ar->hw->wiphy, "invalid plcp cck "
 				       "rate (%x).\n", head->plcp[0]);
 			}