RSN ERROR: Received a data frame when no keys are plumbed

[pengus]

All access points (APs) under my C9800-80 controller are operating in local mode. I have two different SSIDs: one with WPA2 Enterprise and the other with open (central web authentication with ISE). There doesn’t appear to be a general issue, everything seems okay. However, I am receiving the log message "RSN ERROR: Received a data frame when no keys are plumbed" on the APs.

What could be the cause of this error? Is there a misconfiguration on my part? Does this error negatively impact the users?

[marce1000]

         - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa73906
                   The bug report refers to older planforms but also states that the messages are harmless

M.

[Rich R]

What version of software are you using?

[pengus]

17.9.5

[Rich R]

What's the exact version running on the AP @pengus 
If it's 17.9.5.47 or later 17.9.5 version (which is supposed to have the fix for CSCwa73906) then best to open a TAC case.

[pengus]

AP's version in my environment is 17.9.5.205 but i experienced this error in other versions too.

[Rich R]

CSCwa73906 should have been fixed in 17.9.5.205 so best to open a TAC case if it bothers you.

But either way since these messages are cosmetic you can just ignore them.

[yaya]

same here:

iosxe 17.9.5 and a lot of our 3802 aps are shown as ROGUE APs.

checking the APs shown as rogue are ending up with the given error:

Jul 10 08:25:21 kernel: [*07/10/2024 08:25:21.0614]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:25:21 kernel: [*07/10/2024 08:25:21.0706]
Jul 10 08:28:04 kernel: [*07/10/2024 08:25:21.0707]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:28:04 kernel: [*07/10/2024 08:28:04.1992]
Jul 10 08:28:04 kernel: [*07/10/2024 08:28:04.1992]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:28:04 kernel: [*07/10/2024 08:28:04.2007]
Jul 10 08:38:12 kernel: [*07/10/2024 08:28:04.2007]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:38:12 kernel: [*07/10/2024 08:38:12.6477]
Jul 10 08:38:12 kernel: [*07/10/2024 08:38:12.6477]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:38:12 kernel: [*07/10/2024 08:38:12.6524]
Jul 10 08:38:17 kernel: [*07/10/2024 08:38:12.6524]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:38:17 kernel: [*07/10/2024 08:38:17.0543]
Jul 10 08:38:17 kernel: [*07/10/2024 08:38:17.0543]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:38:17 kernel: [*07/10/2024 08:38:17.0557]
Jul 10 08:39:07 kernel: [*07/10/2024 08:38:17.0557]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:39:07 kernel: [*07/10/2024 08:39:07.9174]
Jul 10 08:39:07 kernel: [*07/10/2024 08:39:07.9174]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:39:07 kernel: [*07/10/2024 08:39:07.9214]
Jul 10 08:39:17 kernel: [*07/10/2024 08:39:07.9215]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:39:17 kernel: [*07/10/2024 08:39:17.2928]
Jul 10 08:39:17 kernel: [*07/10/2024 08:39:17.2928]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 08:39:17 kernel: [*07/10/2024 08:39:17.2965]
Jul 10 09:07:55 kernel: [*07/10/2024 08:39:17.2965]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 09:07:55 kernel: [*07/10/2024 09:07:55.0917]
Jul 10 09:07:55 kernel: [*07/10/2024 09:07:55.0918]  *** RSN ERROR: Received a data frame when no keys are plumbed
Jul 10 09:07:55 kernel: [*07/10/2024 09:07:55.0948]

from our point of view, these are not harmless...

at least Catalyst Center showing these as ROGUE APs and calculating channel interference for these

[Rich R · Accepted solution]

@yaya not sure how you linked those debug messages to rogue APs?

> from our point of view, these are not harmless...
CSCwa73906 is quite clear "These messages are considered to be normal and can be ignored - they will be logged immediately after a client connects, for a very brief period. This bug commits a change to keep them from being logged by default; with this fix, they will be logged only at debugging level."
The "fix" is simply to stop logging them except when debug is enabled.