API issues

There are a lot of them.

Extra config

logging server

API endpoint: v1/configuration/object/log_lvl_syslog_ipv6_options
CLI config: logging <ipv6 addr> [options]

Best way to explain this one is to show a series of POSTing to the endpoint, show the resulting config, GETting the endpoint, then POSTing the received json blob. Notably, these operations should be invertible. That is, POSTing what was received from the GET should do nothing.

POST:

[{ "ipv6addr": "2001:468:c80:210f:0:177:fd2a:cb4e" }]

Sets:

logging 2001:468:c80:210f:0:177:fd2a:cb4e

GET/POST:

[{
  "ipv6addr": "2001:468:c80:210f:0:177:fd2a:cb4e",
  "fac": "local1",
  "lvl_severity": "warnings"
}]

Sets:

logging 2001:468:c80:210f:0:177:fd2a:cb4e facility local1 severity warnings

GET:

[{
  "ipv6addr": "2001:468:c80:210f:0:177:fd2a:cb4e",
  "facility": true,
  "fac": "local1",
  "severity": true,
  "lvl_severity": "warnings"
}]

Missing config

Description: Certain config items have an API object with no definition.

Symptoms:

These configuration items do not show up in the config JSON.

The API endpoint can still be queried directly:

>>> # Configuration present
>>> md.get(arubaos.api_object("telnet_cli"))
{'_data': {'telnet_cli': {}}}

>>> # Configuration not present
>>> md.get(arubaos.api_object("telnet_cli"))
{'_data': {'telnet_cli': None}}

Notably, all instances of this seem to have the API definition:
```
{ "type": "object" }
```

`ipv6_enable`

API definition file: Controller.josn
Full API endpoint path: v1/configuration/object/ipv6_enable
CLI configuration: ipv6 enable

`telnet_cli`

API definition file: Controller.json
Full API endpoint path: v1/configuration/object/telnet_cli
CLI configuration: telnet cli

`telnet_soe`

API definition file: Controller.json
Full API endpoint path: v1/configuration/object/telnet_soe
CLI configuration: telnet soe

`ssh disable_dsa`

API definition file: Authentication.json
Full API endpoint path: v1/configuration/object/aaa_ssh_dsa
CLI configuration: ssh disable_dsa

Note that when this command is present, DSA keys are disabled for ssh. Thus, when API returns:

{"_data": {"aaa_ssh_dsa": {}}}

DSA keys are disabled, counter to the natural reading of the output.

Can't upgrade via API

Description: Trying to execute commands used in an upgrade process via API throws permission errors.

Symptoms:

Sample interactive python session:

>>> import arubaos.arubaos as aos
>>> import passpy
>>> domain = "mobility.nis.vt.edu"
>>> creds = {"username": waldrep, "pwpath": "waldrep@vt.edu/netadmin"}
>>> vtc1 = aos.Controller(f"vtc-md-1."{domain}, creds}
>>> endpoint = aos.api_object("copy_scp_system")
>>> body = {
...     "scphost": "2001:468:c80:210f:0:165:9b7d:7dcb",
...     "username": "waldrep",
...     "passwd": passpy.store.Store() \
...         .get_key("waldrep@vt.edu/conehead") \
...         .split('\n', maxsplit=1)[0],
...     "filename": "C_ArubaOS_72xx_8.7.1.5_81619",
...     "partition_num": "partition1"
... }
>>> vtc1.post(endpoint, body)
{'_global_result': {'status': 1, 'status_str': 'You do not have permissions to execute the commands'}}

Including or excluding the optional partition_num makes no difference.
Using a v4 or v6 scphost makes no difference.

Same error when trying to preload APs:

>>> endpoint = aos.api_object("ap_image_preload")
>>> body = {'ap_info': 'all-aps' }

Workaround:
- Upload via webui or cli

Inconsistent errors for not being authenticated/authorized

Trying to do something without being logged in returns the HTML for the login page and a 401 code.

Trying to do something that the user's role is not allowed to do returns:

code 200

The following XML:

<aruba>
  <status>Error</status>
  <reason>no permission to execute opcode/program.</reason>
</aruba>

Trying to do something that should be allowed but is broken (like upgrading the OS image):

code 200

The following JSON:

 {
   '_global_result': {
     'status': 1,
     'status_str': 'You do not have permissions to execute the commands'
   }
 }

Using an invalid show command (e.g., show ap database long}):
- code 200
- empty HTTP payload

Leaking secrets

Using a read-only account to get certain items reveals secrets, such as snmp community secrets, radius keys, etc.

At least for a cluster's vrrp secret, it seems to become obfuscated on reboot.

Ordering of unordered things

Things that have no inherent ordering (such as a virtual_ap definition) is returned in a list, which is ordered. Nor is there any metadata which indicates which things are order sensitive and which are not.

Actual:

{
  "virtual_ap": [
    {
      "aaa_prof": {
        "profile-name": "aaa-eduroam"
      },
      "drop_mcast": {},
      "profile-name": "vap-eduroam",
      "ssid_prof": {
        "profile-name": "ssid-eduroam"
      },
      "vlan": {
        "vlan": "vlan-user"
      }
    },
    {
      "aaa_prof": {
        "profile-name": "aaa-vtopenwifi"
      },
      "drop_mcast": {},
      "profile-name": "vap-vtopenwifi",
      "ssid_prof": {
        "profile-name": "ssid-vtopenwifi"
      },
      "vlan": {
        "vlan": "vlan-user"
      }
    }
  ],
  "ap_group": [
    {
      "dot11a_prof": {
        "profile-name": "rpa-default"
      },
      "profile-name": "agp-ageng",
      "reg_domain_prof": {
        "profile-name": "rdp-blacksburg"
      },
      "virtual_ap": [
        {
          "profile-name": "vap-eduroam"
        },
        {
          "profile-name": "vap-vtopenwifi"
        }
      ]
    }
  ]
}

Better:

{
  "virtual_ap": {
    "_data": [
      {
        "aaa_prof": {
          "profile-name": "aaa-eduroam"
        },
        "drop_mcast": {},
        "profile-name": "vap-eduroam",
        "ssid_prof": {
          "profile-name": "ssid-eduroam"
        },
        "vlan": {
          "vlan": "vlan-user"
        }
      },
      {
        "aaa_prof": {
          "profile-name": "aaa-vtopenwifi"
        },
        "drop_mcast": {},
        "profile-name": "vap-vtopenwifi",
        "ssid_prof": {
          "profile-name": "ssid-vtopenwifi"
        },
        "vlan": {
          "vlan": "vlan-user"
        }
      }
    ],
    "_flags": {
      "ordered": false
    }
  },
  "ap_group": {
    "_data": [
      {
        "dot11a_prof": {
          "profile-name": "rpa-default"
        },
        "profile-name": "agp-ageng",
        "reg_domain_prof": {
          "profile-name": "rdp-blacksburg"
        },
        "virtual_ap": {
          "_data": [
            {
              "profile-name": "vap-eduroam"
            },
            {
              "profile-name": "vap-vtopenwifi"
            }
          ],
          "_flags": {
            "ordered": false
          }
        }
      }
    ],
    "_flags": {
      "ordered": false
    }
  }
}

Best:

{
  "virtual_ap": {
    "vap-eduroam": {
      "aaa_prof": "aaa-eduroam",
      "drop_mcast": {},
      "ssid_prof": "ssid-eduroam",
      "vlan": "vlan-user"
    },
    "vap-vtopenwifi": {
      "aaa_prof": "aaa-vtopenwifi",
      "drop_mcast": {},
      "ssid_prof": "ssid-vtopenwifi",
      "vlan": "vlan-user"
    }
  },
  "ap_group": {
    "apg-ageng": {
      "dot11a_prof": "rpa-default",
      "profile-name": "agp-ageng",
      "reg_domain_prof": "rdp-blacksburg",
      "virtual_ap": {
        "vap-eduroam": {},
        "vap-vtopenwifi": {}
      }
    }
  }
}

Unpredictable ordering

Making the above problem worse, such ordering is somewhat static. It seems to be the order is altered when the device reboots.

Wi-Fi Service