Logmein.com smart device behavior replication

Question

I have several smart devices that run Windows CE5 with our application written in .NETCF 3.5. Smart devices are connected to the Internet with built-in GPRS modems. My clients would like to use the remote support option, but VNC and similar tools do not seem to be able to do the job. I found several issues with VNC to get it working. Firstly, it has serious performance problems when working on a smart device. The second problem is that the ISP has a firewall that blocks all incoming requests if they do not come from the smart device itself. Therefore, I cannot initiate a remote desktop session using smart devices because the request did not originate from the smart device.

We can get our own APN, but they are too expensive, and the monthly cost is too high for the number of smart devices that we deployed. This is more economical for us if we could add development costs to the initial cost of the product, because our customers do not like the high monthly costs and instead pay a large amount. The remote support solution will also allow us to minimize our on-site support.

That's why we more or less decided to knock over our own remote desktop solution. We have a code to capture images on a smart device and receive only data that has been changed since the last cycle. We need to make a communication solution, such as logmein.com (does not support WinCE5), where smart devices connect to a server from which we can transfer data to our customer support services. Basically, the smart device initiates a connection to our server and begins to provide screen data when the server requests it. The support client connects to the server and receives a list of available threads, and then selects one to listen to.

Any suggestions on how to do this, given that we have to execute the solution in .NETCF 3.5 on smart devices? We have limited communication experience outside of simple soap web services.

Answer 1

Since you are asking for a suggestion, I suggest the following:

Do not invent. Reuse your best. You can perform tunneling using SSH, so make an SSH connection (for example, PuTTY or plink inside the loop) via GPRS on your smart device; redirect remote ports to local ports bound to the local SSH server address (127.0.0.1 (sshd): 4567 => localhost (smart_device_01): 4567). Your clients connect to your SSH server and gain access to the designated port for each device.

Having said that, perhaps this is not the answer you are looking for. Below is the answer you're probably looking for.

---

Based on my analysis of LogMeIn, you will want to create an HTTPS or TLS server where your smart devices will transmit data. Let me call it your tunnel server.

You probably want to create a new thread that repeatedly tries to connect to the tunnel server ( outgoing connections from the smart device to the server in accordance with the requirement you specify). Using the BEEP / BXXP protocol, you can encapsulate and multiplex message-oriented or streaming sessions. Wrap BXXP / BEEP in TLS and go through the tunnel server. BEEP allows you to multiplex threads onto a single connection - if you want to use all the features of LogMeIn's own solution, you will want to use something like this.

Once the connection is established, start a new BEEP session. With a new session, tell the tunnel server information about your system (device name, device authentication signature). Record heart rate data (timestamp) periodically in this new session.

Set up a callback (or other thread) that interacts with your BEEP management session. Keep track of the message request. When such a request arrives, create the necessary streams to copy the data from your user remote display protocol and move this data through the same channel.

This sets the basic premise for your Smart Device program. You can add functionality to this as you wish, say, according to what the LMI IT Reach subscription provides (remote registry, secure tunneled Telnet, remote file system, remote printing, remote sound ... you get the idea)

I will make some assumptions that you know how to properly protect all these things for authentication and authorization for your clients (is foo allowed to allow access to the panel of smart devices?).

On your tunnel server, start a server socket (listening for incoming connections or from the point of view of smart devices, smart devices, outgoing connections ) that demultiplex connections and sessions. Once the connection is open, start BEEP and register a callback / start the stream to wait for the authentication session / heart rate. Perform the necessary checks for AAA on smart devices - are these devices allowed, as far as they are known, how much it costs, etc. Your tunnel server sends data on behalf of your smart devices. For each BEEP session, attach the name (device name) to the BEEP session after a successful AAA procedure; if it fails, close the connection and let the AAA mechanism know (to block intruders). Your tunnel server should also configure what is required to interact with the interface, that is, it must have code to interact with BEEP to demultiplex the stream for your remote display data.

On your external server (it may be the same flag as the tunnel server), set the procedure for AAA - check if the user is known, if the user is allowed, how much the user must pay, etc. all checks pass, make a secure connection from an external server to the tunnel server. Get the device names that the tunnel server knows that the user is allowed to access. At this point, you should be able to receive a "plaintext" stream based on the device name from the tunnel server. Send this stream back to the user (via TLS, for example, or via BEEP via TLS), or send the required configuration for your remote mapping client to connect to your tunnel server with the required parameters to access the remote mapping protocol stream.