Notification Config Errors worthless v4

Back in the v3 days when you uploaded a config to a radio and there was a problem the Notification error contained the exact text from the line in the config file that caused the problem. You could simply highlight/copy the name of the setting in the error, load the config into a text editor, paste into the search field and BOOM, there you are , setting at the exact place causing the problem where you can change whatever needs to be changed.

Somewhere along the line, maybe it was before v4, ePMP decided that was waaaay to easy and decided to change the error messages into something like this:

05:19:55 Configuration restore failed. Upload failed. General error occurred.

Downlink Max Rate
Reason: Out of range: ‘Integer32 (21…29|31…39)’

So the word “Downlink” is nowhere to be found in the config file… how about “MAX”

acsScanMaxDwellTime: 300,
networkPortSecurityMax: 5,
wirelessInterfaceRateMaxMCS: 15,
wirelessMaximumCellSize: 10,
wirelessMaximumSTA: 60,
wirelessRateMaxMCS: 15,

Is it wireless RateMaxMCS ? Or WirelessInterfaceRateMaxMCS ? I guess it’s talking about MCS rate right ? Even though “MCS” isn’t in the error message at all ! OH wait, I see, the setting is called “Download Max Rate” on the GUI ! Only, we aren’t using the GUI are we… nooo we are using the config file and playing “guess what the setting in the GUI is called in the config file”.

So two things here… (1) Could ePMP maybe either name things the same in the config and the interface or make config restore errors use the syntax in the config file like they use to instead of the label in the GUI which is completely useless here?

2 Likes

I have an apprentice tech (17, first job knid of thing) that was manually setting the base configs on a bunch (10 ish) SMs because he kept getting a similar issue applying a F300 4.6.0.1 config which was pulled from a working SM. All that changed was the removal of the Mac address and device name. What should have taken 30mins at most to upgrade the FW and place the base config (which this process worked many times before with F200’s and early deployments of FW.ver4.5 F300’s) was taking much longer. I gave up the guessing game after 5mins as there is no real way to determine the fault line and even having the skip unsupported elements enabled still generated useless errors.

@cambium give us back useful error codes!

Hi,

In this particular case, the error appears because of wirelessRateMaxMCS.
You can see it is set to 15 in the configuration:

wirelessRateMaxMCS: 15

It’s fine for .11n platforms where MCSs are in rang 0-15.
For .11ac platforms MCSs are complementing .11n MCSs and have the following range in the driver:

Downlink Max Rate
Reason: Out of range: ‘Integer32 (21…29|31…39)

The mapping you can find in the MIB file:

cambiumSTADownlinkMCSMode OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"DL MCS Mode:
This parameter represents Downlink MCS mode number for both 802.11n and 802.11ac standard devices.

  	802.11n HW:

  	1  for MCS1,
  	2  for MCS2,
  	3  for MCS3,
  	4  for MCS4,
  	5  for MCS5,
  	6  for MCS6,
  	7  for MCS7,
  	9  for MCS9,
  	10 for MCS10,
  	11 for MCS11,
  	12 for MCS12,
  	13 for MCS13,
  	14 for MCS14,
  	15 for MCS15,

  	802.11ac HW:

  	20 for 'SS MCS 0 - BPSK 1/2',
  	21 for 'SS MCS 1 - QPSK 1/2',
  	22 for 'SS MCS 2 - QPSK 3/4',
  	23 for 'SS MCS 3 - 16-QAM 1/2',
  	24 for 'SS MCS 4 - 16-QAM 3/4',
  	25 for 'SS MCS 5 - 64-QAM 2/3',
  	26 for 'SS MCS 6 - 64-QAM 3/4',
  	27 for 'SS MCS 7 - 64-QAM 5/6',
  	28 for 'SS MCS 8 - 256-QAM 3/4',
  	29 for 'SS MCS 9 - 256-QAM 5/6',

  	30 for 'DS MCS 0 - BPSK 1/2',
  	31 for 'DS MCS 1 - QPSK 1/2',
  	32 for 'DS MCS 2 - QPSK 3/4',
  	33 for 'DS MCS 3 - 16-QAM 1/2',
  	34 for 'DS MCS 4 - 16-QAM 3/4',
  	35 for 'DS MCS 5 - 64-QAM 2/3',
  	36 for 'DS MCS 6 - 64-QAM 3/4',
  	37 for 'DS MCS 7 - 64-QAM 5/6',
  	38 for 'DS MCS 8 - 256-QAM 3/4',
  	39 for 'DS MCS 9 - 256-QAM 5/6'

I knew when search turned up the MCS 15 that 15 wasn’t an option on AC and thus both those lines would probably need to be changed (actually I just removed them).

The the point of the post is why do error messages now require a decoder ring to decipher when they didn’t use to.

Got it. Thank you for the clarification.
We will check what has changed after moving to 4.x firmware.
I will update you once I we are done.

Thank you.

You are right, the behavior has been changed in 4.x firmware.
Previously the parameter name from JSON configuration has been shown in the Error, but in 4.x it has been replaced with the parameter name from UI.
We will fix that and will be showing both.

Thank you.

1 Like

Woot !

Thanks you rock !