[Feature] WFA-CA commands handling

[morantr]

Introduction

To pass EasyMesh certification, the system is required to be able to receive WFA-CA commands from TestSuit(UCC) application, and reply one or more answers for each command. The way to communicate with the system externally is by using BML CLI, which allows entering commands and prints to the console the response.

There are two ways to get a response from BML:

1. Request/Response: Sending a request command to BML which will be blocked for at most 5 seconds until a response is received and print it to the console.
2. Register event: Same as "Request/Response" but with adding of a callback function. Two messages are necessary here, one message for the register response, which will release the callback, and a second message for the event itself, which will be sent to the console function and eventually will be printed.

WFA-CA requirements:

Response syntax

A command response consists of one or more Response Elements. Each Response Element consists of an Element Name and Element Value. These tokens are also separated by commas. The general response format is: <Response Element 1>: <Response Element 2>: , , [,]

The first Response Element token is always the status. For some commands, the status element is followed by other command-specific response elements. The status can have the values given in the following table:

Status Value	Description
RUNNING	The previous command was well-formed and the Control Agent is busy executing the command.
INVALID	The previous command was either malformed, or a parameter value was invalid or not understood. TheControl Agent should use the errorCode Response Element to return more details on the error.
ERROR	The previous command produced errors when it was executed on the DUT. The Control Agent should use the errorCode Response Element to return more details on the error.
COMPLETE	The previous command was well-formed and the Control Agent has finished executing the command. The results of executing the command are also returned using zero or more command-specific response elements.

Response timeouts After the UCC sends a command to the Control Agent, it waits for a response with a timeout length of one second. The Control Agent must parse the command to verify that it is well-formed and return a response element within this timeout with a status ‘RUNNING’. If a response element with a status of RUNNING is received, the UCC will then block for a follow-up response from the Control Agent. The Control Agent shall return a status ‘ERROR’ or ‘COMPLETE’, or ‘INVALID’. The timeout threshold for the Control Agent is 120 seconds unless specified otherwise in a particular command definition.

Control Agent state machine

Once a connection has been made, the Control Agent waits until a new-line terminated text string is received. After a line of text is received, the values are parsed to ensure that the command name, parameter names, and parameter values are syntactically correct. If the command is syntactically correct, then a status of RUNNING is reported, and the vendor-proprietary method of communication with the Device begins. Once the Device has finished executing the function, the appropriate response is sent, and the Control Agent waits to read the next line of input. It is important that the Control Agent does not read additional lines from the TCP socket until each command completes in turn. This will allow several commands that are pasted into a telnet window at once to be executed sequentially as expected. The communication between the Control Agent and the device should use an out-of-band mechanism because in-band communication such as using the wireless interface under test may not allow communication before the Device is associated.

The problem

While some of WFA-CA commands are requiring an operation that may take some time, some of the commands do not require that and may return immediately "COMPLETE" status, for example, see "DEV_GET_PARAMETER" command example on the Wifi Control TestSuit API specification. This means that we could not use two different messages for the response, one for the "RUNNING" and one for "COMPLETE", because only one may be received, but only one of them should release the BML blocking.

Solution

Create a WFA-CA module on the controller, that receives WFA-CA commands and parse it, and send the responses back to the BML.

Why the module which parses the command and replies it, have to be in the controller and not BML? Because only the controller has all the information it needs to validate the data in the command.

How could we use the same message to release BML blocking and return an additional reply that may come? Simply, the first reply will release the blocking and will be printed to the console, and the second reply if comes, will be routed to the callback function which was registered in the BML command and will be printed to console.

[tomereli]

Why not use a single callback which will accept the response buffer to be printed and call it twice? The CLI will register this callback using the same infrastructure that is used for network map updates. On init, the CLI will register the WFA-CA callback so it can receive responses. When a new WFA-CA command is received, will send the command to the controller via the BML and return. Every time the callback is called, it receives 2 arguments - one, an enum which marks the current status (RUNNING, COMPLETED, FAILED, etc.), and the second, a buffer with extra string, can be empty. The callback will print the status and the buffer each time it is called.

[arnout]

In general, there may be even more than two responses to a WFA CA command.

So I think it makes most sense to always use the "register event" approach, but never block on the event. In other words, the CLI just sends the WFA CA command without waiting for a response. The two responses come as events, and the CLI doesn't know if it's a RUNNING status which still needs to be continued, or one of the other statuses that "closes" the command. I also don't think the CLI should deal with the 120s timeout at all.

[arnout]

This was merged a long time ago.