On Mon, 10 Feb 2020, Mark Webb-Johnson wrote:
I am curious, @Steve, if you implemented any controls for restriction of engineer access? For example, in this OVMS requirement, say a developer configured his module to SSH tunnel back to the central control server, then he can SSH to that control server to tunnel into his module. But what is stopping other developers also connecting to his module? Presumably everybody is just connecting to 127.0.0.1 on the central controls server?
That wasn't a requirement for our implementation. Access to the phone-home server was restricted to the set of support staff and engineers responsible for supporting the systems that phone home, but all of those support staff and engineers were allowed to access any of the connected remote devices. For OVMS, you are envisioning a much more general problem where a large number of developers would want independent remote access to their OVMS devices. Trying to provide that through one shared call-back server would be more complicated. But the only reason for the shared call-back server would be to free those developers from needing to set up a globally addressable server of their own. I'm not sure we need to do that. I was thinking about a scenario much more like the one I had in my job. The server would only be accessed by a small set of core developers -- those, like you, who are willing and able to help diagnose user problems. Those developers would have access through the server to any of the OVMS units whose owners have chosen to grant that access by enabling the callback. Those owners would do so because they trust the developers and want their assistance.
I am also concerned about performance. For console access, that shouldn’t matter - but for can bus dumps we need every bps of speed we can get.
Assuming some reasonable server machine, I would not expect that to be the bottleneck. My guess is the limiting factor would be the networking software in OVMS. -- Steve