Add Remote Command Over WiFi #255
Conversation
|
It'd be cool if you could rebase this onto #256 |
|
pain^2 |
nekomona
force-pushed
the
rcmd_merge
branch
2 times, most recently
from
e3d2e80
to
758f8a1
Compare
|
IP check is added, so that remote command would only accept connection from the IP of connected SlimeVR Server. When the server is not connected, any IP could connect to the remote command, but will not receive any response, and only accept the |
|
commit history is a little broken on this and #262 😓 |
|
We squash it so it doesn't matter.. |
|
Rebased to main after v0.4.0 and tested on ESP32-S3, remote commands and server IP checks are looking good. |
| @@ -73,8 +74,8 @@ class FirmwareFeatures { | |||
| public: | |||
| enum EFirmwareFeatureFlags: uint32_t { | |||
| // EXAMPLE_FEATURE, | |||
| REMOTE_COMMAND = 0, | |||
There was a problem hiding this comment.
Should this really be 0? Is there a reason we started at 1?
There was a problem hiding this comment.
It's just from that the first version of remote command is written before WiFi scanning
| #if USE_REMOTE_COMMAND && ALLOW_REMOTE_WIFI_PROV | ||
| if (cmdFromRemote && !networkConnection.isConnected()) return; | ||
| #endif |
There was a problem hiding this comment.
This is used multiple times throughout this file, but it's not applied to every command? Why not just put it at the parser before the command functions are called? Also why is it on get and such? Isn't WiFi prov just for setting the WiFi?
There was a problem hiding this comment.
The idea here is to only allow SET and block other commands in the provisioning phase, before connected to a slime server. The repetition is from that the command is only known to be a SET after parsing, which is processed inside cmdParser.
|
As much as i would love this feature. There might be security concerns to think about. As sending commands over wifi would allow the usage of the reboot command remotely. Rebooting will make the OTA reset and allow for flashing new firmwares without the user interaction. As is, this PR is dangerous. If we could find a way to secure the connection when sending those commands it would be a super cool feature |
|
Can we just cut out the sending commands part and focus on the receiving bit for now instead? I think it would be interesting to handle sending but there are definitely considerations to be made about security there |
Co-authored-by: Butterscotch! <bscotchvanilla@gmail.com>
I think we could let the command part to be an define option disabled by default, and probably reject |
sounds good |
This PR add a remote command server running in parallel with the serial command, sharing the same command buffer, command lists, and logger outputs. All the data printed through
Loggerwill be forked to the remote when connected, while the ones usingSerialwon't be forked.The remote command server could be accessed through telnet clients. Would be easy to integrate into server since it use a simple TCP socket to transmit the same data as serial commands do.
Currently this remote command mostly benefits for checking TCAL status remotely, as other commands are mostly for debugging instead of functions. This could be used for future function commands which are too minor to occupy a packet type or doesn't fit well in a UDP packet like largely varying data length.