Current RPC interface design for USB settings
P4wnP1_service stores a temporary state of USB settings (not yet deployed settings).
The clients are meant to issue gRPC calls to manipulate this temporary settings and ,once all changes are applied, to deploy these settings.
The idea behind dividing the change of USB settings into multiple steps, was to allow incremental changes of settings before deployment (relative settings change).
Example:
Even if the current gadget settings are unknown, a gRPC call could be issued, which enables HID keyboard. It doesn't matter which settings have been applied so far, as they are preserved and the keyboard is switched to on, additionally. But these settings aren't ultimately deployed , as this would involve rebuilding the whole USB stack and kill all depending services (Network gadgets, applied DHCP server, clients, already running HID scripts etc..). So deploying new settings is some kind of critical task.
In pseudo code, configuration with the CLI client could have looked like this:
// current USB state unknown, maybe USB mass storage/serial/mouse etc. is on, maybe not
P4wnP1_cli USB set --cdc-ecm 1 //enable CDC ECM
P4wnP1_cli USB set --hid-keyboard 1 //enable HID keyboard
P4wnP1_cli USB set deploy //deploy the new settings to kernel
// --> we know for sure HID keyboard and CDC ECM are on, other USB settings still unknown
To avoid the overhead of running a deploy command, the CLI behavior was changed to "autodeploy" new settings if not suppressed with an additional --no-deploy
flag (short -n
)
Same script after no-deploy flag addition
// current USB state unknown, maybe USB mass storage/serial/mouse etc. is on, maybe not
P4wnP1_cli USB set --cdc-ecm 1 -n //enable CDC ECM, but don't deploy
P4wnP1_cli USB set --hid-keyboard 1 //enable HID keyboard and deploy
// P4wnP1_cli USB set deploy //<-- not neded anymore
// --> we know for sure HID keyboard and CDC ECM are on, other USB settings still unknown
The script from above with short flags:
P4wnP1_cli USB set -e 1 -n //enable CDC ECM
P4wnP1_cli USB set -k 1 //enable HID keyboard and deploy
Wrapping both settings changes in a one-liner
P4wnP1_cli USB set -e 1 -k 1 //enable CDC ECM, enable HID keyboard and deploy (don't suppress deployment)
Simplification for redesign
As the last version of the script shows, the whole USB settings can be fit into a one-line using the CLI client. Toggling single settings, using multiple commands without deploying isn't a very natural approach in scripting, it would be more interesting to use this in interactive sessions.
By introducing a webclient, an additional layer of temporary USB settings state was introduced (the webpage keeps an own USB settings state, till they are send to the gRPC service - which doesn't happen on every single change).
To keep a long story short:
The approach of changing setting incremental (only providing settings which have to be changed, not all settings). The step of storing temporary settings before deployment could be removed, as isn't to useful but requires managing and synchronizing various unneeded states.