Roaming between different models

[Moudar]

Have 2802 and 2702 at the same floor (only one floor). Should the roaming work or there are buggs somewhere?

The 2802 AP sends many logs as this one:

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

Someone here:

 https://community.cisco.com/t5/wireless/rsn-error-received-a-data-frame-when-no-keys-are-plumbed/td-p/4612689

said "I saw that every time they reported the issue with the "Connecting" status they were connected, but they weren't finishing the  roaming process between APs."

I have 2 locations with the same problem and with mixed environment 2702 and 2802. only 2802 have these logs.

Clients say that they loose connection very often when they come to a room that has 2802 and the room before has 2702 AP.

[Moudar]

WLC 5520

Software: 8.10.181.3 upgrading to 8.10.182 is planned in January

[Rich R]

Ok well at least that is fairly up to date but you should be planning for upgrade to 8.10.183.0 now, not 8.10.182.0.

8.10.181.0 and 8.10.182.0 have been deferred:
https://www.cisco.com/web/software/DefTracker/280775080/DT/ac107255.html

This means if you have any problems with the deferred software TAC will just tell you to upgrade - it's essentially regarded as unsupported.

[Scott Fella]

Reading through this thread, you now have ideas of what others would do.  You already have an issue when you introduced a mix of ap models on the same floor, so the only real fix for that is when you migrate to all 2800's as an example.  Have I mixed models in my environments, sure I have, but it is a whole floor or an area where roaming between the two does not happen.  Any migration I do, is really for a complete upgrade, when I introduce a new access point model, its because the other is probably EOS or I recently upgraded those less than a few years ago.  

Did you think of maybe migration one site first so you are not mixing models?  You could always move the 2800's to one site and then replace them with the older ap's you took out.

I know this might not be helpful, but trying to give you some options before the experience gets bad and complaints go up the chain.  Since this was something you implemented, saying, "well we shouldn't of mixed models" will not go well with management.  You need to figure out your next steps, which might just be finding the old ap's and putting them back up.  Waiting to upgrade is just extending the pain the users have to deal with and when you upgrade and that doesn't fix the issue, what will your response be to management?

[JPavonM]

Yes that could happen if the device has associated using 802.11ax protocol.

As part of the device association to a BSSID, the device sends an association request informang about its capabilities that are selected betweeen those in the beacon from the AP (or probe responses), and the AP sends an association response with the same.

Within that information which is shared, the devices inform about HT Capabilities, VHT Capabilities, HE Capabilities, Extended Capabilities between others (see "MLME-ASSOCIATE.join" and "MLME-ASSOCIATE.request" in 802.11 standard and 802.11ax amendment), and all that information must much to create an association. As the device coming from a WiFi6 AP has negotiated all that paramenters, the new connection to a WiFi5 AP must be also negotiated as none HE features exist anymore there.

But I'm still doing some testing when this is a WiFi5 device which roams from WiFi6 AP to WiFi5 AP, as all paramenters that are negotiatedare the same so it would be up to the logic inside the device's driver if they need to perform a full asociation, or re-associate as part of a seamless roaming.