Initially I didn't think this was a bug  ( I've described it here first: https://community.tp-link.com/en/business/forum/topic/870230?page=1 ),

but once pieces started to fall into place, I'm leaning towards submitting a bug report. I'll clean up the mentioned post once this one gains traction.

Let me be clear from the start - those are *different* bugs, but they're chained and all result in the same thing - no access to part of the configuration of the wireless client.

I have some clients (wireless ones) that exhibit the same behaviour - they're seen as wired by the controller.
I ran a query on the API and I could confirm it, I got the:
"wireless": false

in JSON output.

For that reason, there are no "rate limit" and "lock to ap" options available. There also doesn't seem to be a way to switch the client state, trying to run a PATCH request, flipping "wireless" from false to true, did nothing. It's been completely ignored. I got a reply with even more parameters like:
"connectDevType":"gateway",
"connectedToWirelessRouter":false,
"stackableSwitch":false

that don't even exist on a wireless client. Overall, the only way to not waste hours to figure out how can I alter the record and get these options back is to forget the client, removing the configuration entirely, make it reconnect and set up it again.

Now, this isn't much of a problem when the client is connected and remembered - it can be deleted from GUI and configured again once it connects.

But there are some edge cases where this behaviour can cause people to rip their hair out - i.e., if they use "lock to ap" function.

Say the AP that the clients were assigned to breaks or is disconnected from the network. You can even plug a new one in its place, but it won't matter because, looking at the API reply, the controller stores the MAC of the old AP. If the device was set to connect to a single, particular AP, it won't be able to connect to the network at all.

In case of the device recognized as wireless, it looks like this:

    "clientLockToApSetting": {
      "enable": true,
      "aps":[{"name":"AA-BB-CC-DD-EE-FF","mac":"AA-BB-CC-DD-EE-FF"}]

User has to either:

- remove the client from the list entirely, losing all the associated information, let it reconnect and configure it again (name, lock to ap, rate limit, etc.) - that's the best-case scenario, but it still requires manual labour - from my POV, this shouldn't happen, as it may not cover 3 or 5 but dozens of devices and admin won't notice immediately that he has to deal with multiple "silent fail" cases

- curse and swear because controller can store the client info but will not display it in the GUI anywhere, effectively requiring to carry out DELETE query with API - without it, the device is effectively banned from joining the network - and that is only possible if the client MAC is known - if it can't be easily obtained, the situation is even worse

This case has shown there are multiple issues present:

1) Removing the AP from the device menu doesn't purge its entries from the clients' configuration. There doesn't seem to be any fail-safe to either remove the "aps" value or clear the "lock to ap" flag entirely for clients that were bound to a specific AP. No warn/error, no popup to let the admin choose what to do with the clients that were bound to the now non-existent AP.

2) Clients that were supposed to connect only to that certain AP and are recognized as wired for some reason, won't be able to join the network again unless they're "forgotten"

3) Controller can still store information about the clients that don't show up in the GUI for some reason, requiring manual deletion, and that requires the client MAC to be known