Add wave2 Wi-Fi settings

[mthoodlum]

Wi-Fi settings are configured differently with MikroTik's wave2 product line. For 802.11 AC Wave2 devices there is an optional extra package to configure Wave2. For 802.11 AX devices Wave2 will be default.

We have a device on the demo server with Wave2:

MikroTik hAP AC^3 RouterOS v7.5 with Wi-Fi Wave2 extra package

[andrewhodel]

@mthoodlum Which host?

When I search for wave there are no results.

[mthoodlum]

lab-ROSv7-hAP-AC3

[andrewhodel]

Here is the device link, it updates but does not send chart data https://demo.ispapp.co/#host/635462f4bbb1d166b6f1f01e

[andrewhodel]

This is waiting on Mikrotik https://help.mikrotik.com/servicedesk/servicedesk/customer/portal/1/SUP-99759

[andrewhodel]

wave2 devices don't have a /interface wireless menu and the detection of that menu works with short commands but not long commands.

/interface wireless fails normally and can be detected

/interface wireless security-profiles get [find name=ifname] wpa2-pre-shared-key causes the compiler to fail.

It's obvious that Mikrotik is trying to make type detection difficult when writing scripts for the devices they sell.

[andrewhodel]

Response from Mikrotik.

Hello.

Thank you for the script example. I see the problem now.

It arises because of how '[find]' is interpreted differently, depending on whether the menu for the preceding command exists or not.

If the wifiwave2 package is not installed , the [find] block in /interface wireless security profiles get [find name=test] value-name=wpa2-pre-shared-key invokes /interface/wireless/security-profiles/find

When the wifiwave2 package is installed and there is no /interface/wireless/security-profiles/find to invoke, the [find] block invokes /find

'/find' does not take 'name' for an argument. Invoking it leads to a syntax error and syntax errors are not handled by 'do {} on-error={}'.

So, as a solution, I can suggest rewriting the supplied script so to avoid ambiguity

:do {
   :local wIfKey ([/interface/wireless/security-profiles/get [/interface/wireless/security-profiles/find name=test] value-name=wpa2-pre-shared-key]);
} on-error={
}

Or just using the profile name with the 'get' command

:do {
   :local wIfKey [/interface/wireless/security-profiles/get number=test value-name=wpa2-pre-shared-key];
} on-error={
}

I'll consult with my colleagues what could be improved in the scripting behaviour. Perhaps it would be more consistent if calling an existing command with a non-existent parameter resulted in the same type of error as calling a non-existent command.

Best regards, Toms Filatovs

[andrewhodel]

Fixed in 2.20