<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I’m with Stephen on this one. I see this reverse ssh with port forwarding used as a pretty standard support tool. The only difference I would add is that the tunnel is initiated by the user on demand and one uses the site login to authenticate for the tunnel. <div><br></div><div>I expect this won’t be used on a wide scale for OVMS gear, but it is simple, useful, and widely used for hardware support. <br><br><div dir="ltr">Yada, yada,<div>S.</div><div>(via the iPad thingamajigg)</div></div><div dir="ltr"><br><blockquote type="cite">On 3 Feb 2020, at 14:06, Mark Webb-Johnson <mark@webb-johnson.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div class=""><br class=""></div><div class="">Seeking opinions (in particular Stephen, our ssh guru).</div><div class=""><br class=""></div><div class="">As I (and others) are doing more work remotely (OVMS modules in cars, and trying to connect in remotely to diagnose, test, or develop), I am seeing the same issue come up often. If the car is on your own home WiFi, it is simple and easy. But if the car is elsewhere, on someone else’s WiFi, then connecting _to_ the car becomes hard. Firewalls, port forwarding, and all that mess. Security also becomes an issue (once ports are opened and forwarded).</div><div class=""><br class=""></div><div class="">The core requirements seem to be:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">A way to get a proper shell. The ovms v2 protocol shell is ok, but quite painful to work with (especially as logs are not shown and there is no command expansion).<br class=""><br class=""></li><li class="">A way to get CAN dumps out of the car. Can save to sd card, but can’t copy in/out.</li></ul></div><div class=""><br class=""></div><div class="">Both of these are simple TCP connections.</div><div class=""><br class=""></div><div class="">The second issue (CAN dumps) is resolvable if the developer has a public address. Open the firewall, ’nc -l’ a port, and ‘can log start tcpclient …’ on the module. But a little kludgy, and doesn’t support SavvyCAN (which can only connect _to_ the module, not receive a connection _from_ the module).</div><div class=""><br class=""></div><div class="">I can see three possible approaches to this:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Extension of OVMS v2 protocol<br class=""><br class="">We could extend the OVMS v2 protocol to support a PIPE mode. Have it allow connections and data to be transferred over the v2 protocol link using simple messages. Then, the pipe could be used to tunnel SSH and CAN log connections. The same could be done with v3 over MQTT (the transport is different, but the console / port forwarding bits inside the ovms module are the same).<br class=""><br class="">The advantage here is that the OVMS v2 server becomes a man-in-the-middle broker. Both the car module and the developer connect to the OVMS v2 server to exchange data. No incoming connections, so everything can be dynamic.<br class=""><br class="">The disadvantage is security is fairly weak on that protocol. Very dated RC4 encryption and poor authentication.<br class=""><br class=""></li><li class="">Leverage SSH<br class=""><br class="">SSH has a port forwarding facility built in, that wolfssh seems to support. It is also possible to do a reverse ssh client.<br class=""><br class="">The advantage here is security (very strong encryption and authentication).<br class=""><br class="">The disadvantage is complexity and the fact that the developer end needs to poke a hole in their firewall (and possibly do NAT port forwarding, etc) to allow the incoming connections from the car.<br class=""><br class=""></li><li class="">STUNNEL / WireGuard / Mosh / VPN / etc<br class=""><br class="">Perhaps someone else knows of something suitable? The issues here are that the LWIP stack is not the easiest to work with.</li></ol></div><div class=""><br class=""></div><div class="">My initial preference is #1 or #2, but open to discussion…</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class="">P.S. To save you time, the reverse SSH (using normal Unix like systems) works like this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">Say developer at IP address A wants to connect to module at IP address B.<br class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">On the module: $ ssh -R 19999:localhost:22 <user-A>@<A></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">(And go through authentication for B to ssh to A)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">Then, on the developer’s workstation: $ ssh -p 19999 <user-B>@localhost</blockquote></blockquote><br class=""><span>_______________________________________________</span><br><span>OvmsDev mailing list</span><br><span>OvmsDev@lists.openvehicles.com</span><br><span>http://lists.openvehicles.com/mailman/listinfo/ovmsdev</span><br></div></blockquote></div></body></html>