msm760 + msm430/460 : RRM issues

[orbital]

Hi everyone

We're running an MSM760 with 17 APs (MSM 430 & MSM460).  Since several months, wifi users are experiencing tons of network interruptions. (more than 10disconnects a day for some users. Sometimes , they can't even reconnect until I reboot AP's).

As our radio environment is very pertubate (lot of others companies in a small area, we'are in the middle of a business district), I have enabled RRM on all my AP's.

However, I have noticed a lot of RRM errors in the msm760 system log. I don't know if it is the main cause of my reliability problems, but in all cases, I really don't think it's normal.

Exemple:

Date Level Program Message

May  5 17:01:01.491 warn rfmgr_sc RRM message channel to AP [E8:39:35:F1:70:79] lost connection May  5 17:00:57.516 warn rfmgr_sc RRM message channel to AP [E8:39:35:F1:E0:26] lost connection May  5 17:00:57.507 warn rfmgr_sc RRM message channel to AP [E8:39:35:F1:E0:25] lost connection May  5 17:00:57.498 warn rfmgr_sc RRM message channel to AP [AC:16:2D:E9:3E:5D] lost connection May  5 17:00:57.497 warn rfmgr_sc RRM message channel to AP [E8:39:35:F1:70:7E] lost connection May  5 17:00:57.482 warn rfmgr_sc RRM message channel to AP [E8:39:35:F1:21:07] lost connection May  5 17:00:57.469 warn rfmgr_sc RRM message channel to AP [AC:16:2D:E9:14:60] lost connection May  5 17:00:57.466 warn rfmgr_sc RRM message channel to AP [AC:16:2D:E9:3E:60] lost connection May  5 17:00:57.461 warn rfmgr_sc RRM message channel to AP [2C:41:38:DB:7E:28] lost connection May  5 17:00:46.861 warn rfmgr_sc RRM message channel to AP [AC:16:2D:E9:3E:4F] lost connection May  5 17:00:38.888 warn rfmgr_sc RRM message channel to AP [A0:48:1C:56:53:03] lost connection May  5 17:00:38.888 err rfmgr_sc Disconnecting RRM message channel to AP [A0:48:1C:56:53:03]

May  5 17:00:37.577 err rfmgr_sc Connection reset requested with AP [A0:48:1C:56:53:03] due to error with radio [A0:48:1C:50:3B:E0]

May  5 17:00:37.577 err rfmgr_sc AP [A0:48:1C:56:53:03] radio [A0:48:1C:50:3B:E0] did not provide full report in time May  5 16:56:50.959 warn rfmgr_sc RRM message channel to AP [FC:15:B4:BC:6D:F7] lost connection May  5 16:56:50.958 err rfmgr_sc Disconnecting RRM message channel to AP [FC:15:B4:BC:6D:F7]

May  5 16:56:49.870 err rfmgr_sc Connection reset requested with AP [FC:15:B4:BC:6D:F7] due to error with radio [28:80:23:27:DA:60]

May  5 16:56:49.870 err rfmgr_sc AP [FC:15:B4:BC:6D:F7] radio [28:80:23:27:DA:60] did not provide full report in time May  5 16:55:51.506 warn rfmgr_sc RRM message channel to AP [E8:39:35:F1:21:07] lost connection May  5 16:55:46.777 warn rfmgr_sc RRM message channel to AP [AC:16:2D:E9:3E:60] lost connection

Is someone has any idea why I have all those RRM errors? 

Thanks you everyone :)

[Arimo]

Hi Orbital

What FW are you running?

[orbital]

Hi Arimo

I'm running FW 6.4.0.0-16925.

Maybe I should upgrade to the latest version, even if didn't see anything about RRM in changelog...

Thanks you!

Julien 

[Arimo]

Hi Julien

Yeah, you should :-)

If you don't have HP 560 APs, I'd recommend 6.4.2.1. 6.5 is not a direct update, it's a separate, independent FW branch. 6.4 is active and under development, and 6.4.2 has been out longer, so it's a mature code. Besides it appears that only 6.5.0.1 is currently available from the website and that's already oudated, current is actually 6.5.1.0.

There are 2 enhancments in 6.5.1.0 which you might need: you can now configure RADIUS attributes for groups, and another allows a FW update to occur automatically when an AP is reastarted. If you want to have 6.5.1.0, you will at the moment to contact support.

[gCumm-bt]

Did 6.4.2.1 resolve your issue?  I'm seeing a similar issue where radio 1  (5GHz) on the MSM460 APs does not respond to a status report request while radio 2 (2.4GHz) does on 17 of 57 APs with 2 MSM765zl controllers running 6.4.2.0.  The other 40 seem to be responding with both reports.  This is spread across 2 buildings and 7 switches with some in adjacent rooms on the same switch act differently.