remote.it is available on a whole new platform! Enjoy all the things you love about remote.it on OpenWrt!
Use it as a jumpbox to connect to devices for a private network at home or at your work.
Enjoy a GLiNet router using OpenWrt, it’s small and great for when you’re traveling.
It’s a whole new device package that doesn’t need nodes or bloated libraries - better for embedded devices.
Useful documents:
Installation Instructions
We’d love to know what you think and how you’re using it!
Hello All
I have done an integration of Remote.it on an embedded product based on Armbian/Debian running on H3 ARM chipset. I used the Remote.it CLI package and the integration was straightforward and it all works very well.
Kudos on a nice product!
The idea of the integration is that when a user is deploying the device in the field, they can set up the various operational parameters for the device including registering the device to a Remote.it account which will be used by the ops team to administer the device. The administration is done via a series of web screens running on the embedded device and accessible initially via a local WiFi connection.
Now I would like to do the same integration on an OpenWRT based product, but it seems that the CLI package is not available for the OpenWRT platform.
Or have I missed something?
The OpenWRT offering shown here:
Overview & Installation - remote.it
appears to operate quite differently to the CLI package.
The user has to install the package from the command line, retrieve a Claim Code and then enter the code into the Remote.it system web page.
This does not integrate well into our web based admin screen, which was almost trivially easy with the CLI package. And the product can be shipped with the CLI module pre-installed.
Obviously we would like to be able to do the Remote.it integration in a uniform way across the product range.
So have I completely misunderstood something about the OpenWRT offering, or is there some technical reason why the CLI package can not be used on the OpenWRT platform?
Thanks in advance for any help with this.
T
Hello Tgillett!
First, we’re so happy to hear that you’re enjoying remote.it! I have passed your question on to the Engineering team, so I can get you an answer reqarding your OpenWrt request. We’ll get back to you as soon as I hear back.
Many thanks!!
Kei
Hello @tgillett!
I looped-back with our engineering team and please see their suggestion below:
You can set-up and easy registration process using the same process that you’ve been using:
Please let us know how that goes and please don’t hesitate to get back to us with any questions you have. You can also write directly to Support@remote.it.
Thanks so much!
Kei
Hi Kei
Many thanks for your response.
That sounds like a good solution.
I will try it out and get back to you over the next couple of days.
Regards
Terry
Hi Terry,
Fantastic, do let us know how it goes!
All the best,
Kei
Hi Kei
I followed the process for installation on a clean install of my product build based on
OpenWrt 19.07.3.
I was able to get to Step 3. as follows:
# mkdir /etc/remoteit
# touch /etc/remoteit/registration
# opkg update
...
# opkg install curl
...
# opkg install jq
...
# opkg install /tmp/remoteit_4.13.5.ipk
Installing remoteit (4.13.5) to root...
Configuring remoteit.
So far so good.
Step 3 says to write the ‘registration code’ into the ‘registration’ file.
What is the ‘registration code’ please?
I thought it may have been the Account ID, but that didn’t seem to work.
Can you enlighten me please?
Also, once I have successfully registered the device, what is the process for adding services - HTTP, SSH etc?
Thanks
Terry
Hi Terry,
I’m a Sr. DevOps Engineer at remote.it. Are these devices going to be used internally by your company or is it an embedded product you sell and want the customer to enter the license key? If internally you can go to the latest Desktop → More → Licensing and you will see a License Key listed there. Put that into the /etc/remoteit/registration file and then refresh.sh. If you have an “ops” remoteit account that you register all your devices too then make sure you are logged into the Desktop as that “ops” user to get the right License Key.
As for services they are now added to the device via the Desktop since there is no longer a CLI installed. This makes the remote.it device package more like a lightweight agent. Once it is registered just log into the Desktop as the owner of the device and you can add services right there.
Hope this helps,
robo
Hi Robo
Thanks for your reply.
Some background…
The company I am working for produces a range of embedded system ‘appliances’; for example the current project is around a range of LoRaWAN gateway devices that are based on either ARM/Debian or OpenWRT platforms. They share a common web based administration interface across the range.
There is a requirement to be able to remotely access the devices once they are deployed in the field. All the usual remote access approaches are provided for in the design, but as you know, they all involve potentially compromising security by opening ports, and, probably more importantly, they are dependent on significant levels of end user knowledge to ensure security is maintained.
What we would like to be able to do is the ship the product with no open ports and the appropriate Remote.it module installed, so that one of the options the end user has for remote access is to use Remote.it, thereby making it easy to implement a secure solution, if for no other reason than it is so simple to activate without having to worry about open ports etc.
So I did an implementation using the CLI module on the ARM/Debian platform. It turns out to be a very neat solution.
The user decides that they want to use the Remote.it option for remote access, so the first thing they do is open a Remote.it account.
The user then has a relationship with Remote.it and can work out with you whatever licencing model is appropriate.
On the device we have a screen where the user enters the details of Remote.it account which the device will be associated with, the Device Name that will be displayed, and selects the services (HTTP, SSH) that are to be enabled. Click the Register button, and the job is done.
Log in to the Remote.it page (app.remote.it/#devices) and the device is there in the Device List waiting to be used.
The process is very simple for the user to navigate for the first time, and the chances of needing to contact technical support are pretty small.
Users who have trialled it love it. Sweet!
So, now having sold this approach to the management, we want to do the same thing on the OpenWRT based devices.
Ooops! Curiously, there is no CLI module option for OpenWrt. Why???
OK, so now we start playing around with the other remoteit module that would normally run interactively from the command line and generate a Claim Code that is used to register the device.
In the workaround approach as you have described, the end user has to install a Remote.it Desktop application in order to get a Licence key that is then entered into the administration screen on the device, and the registration process proceeds.
Somehow we seem to have lost the elegant simplicity of the CLI based approach.
Asking the first time user to install a Desktop application just to get a Licence key is not something I would be prepared to do, and I am sure that this level of complication will certainly result in support calls to you and us.
The obvious question is why is the CLI module not available for OpenWRT?
And the next question is whether the CLI module is going to be supported in the long term for any platform?
I think Remote.it is an excellent solution for secure remote access, and I am sure it will be widely taken up as a premium remote access solution.
Unfortunately for us, there is just one small piece of the puzzle missing for OpenWRT platforms.
Look forward to hearing your thoughts.
Terry
Hi Terry,
The CLI version of the remoteit installer was developed for the Raspberry Pi initially and requires node and jqgrid to be installed. For OpenWrt we removed that requirement and simplified installation for many people. But your deployment scenario isn’t one we considered.
I’ve heard engineering say they are going to add CLI back into the Device Package, but given the above constraint I don’t know what they have in mind.
The “License Key” is currently only visible in the Desktop application, however I’m informed that it will be displayed in the web portal in an upcoming release. (When? I am not sure.)
The Device Package also supports “Auto Registration” - please review this section of our documentation.
With this method, the device automatically registers to your account when it is first enabled and connected to the internet. It’s not obvious to me at this moment how you would go about figuring out which customer enabled which device (as you could then transfer it to them). I’ll have to give it more thought.
Thanks,
Gary W.
remote.it Support
Update, you can get your license key by logging in here:
Hi Gary
Thanks for the reply.
Getting a Licence Key from the web portal sounds like it might fit the process ok.
And if CLI is going to be made available on all OS types as a long term facility, then that would work as well.
Obviously we want to use one process across the product range, and use a registration facility that is going to be available/stable in the long term.
I will look into your other suggestions also to see if there is something that we might use.
Regards
Terry
Hi Gary
I tested the process outlined by Robo using the Licence Key from the web site as you suggested, and it all works ok.
So now I have my new OpenWrt based device registered and appearing on my Portal page, but obviously without any services.
So what options are there for adding the services?
Is it only possible from the Desktop App?
Also, the process has picked up the hostname from OpenWrt and used that as the Device name in the web portal presentation.
Is there any alternative ?
I notice there is a file “/etc/remoteit/config.json” on the OpenWrt box after the registration process has completed.
It contains various fields including “id”, “name”, and an entry for “services”.
Is it possible to update these values in some way in order to e.g. set the Device Name and add services perhaps?
Thanks
Terry
Hi Terry,
You can add services using the Desktop application, or if you would like to configure devices in such a way that they will automatically configure a predetermined set of services, please see:
As far as configuring the name to be something other than the hostname, that’s not currently possible, although of course you can edit the name using the desktop application. We don’t suggest that you edit the config.json.
Hi Gary
Thanks for your response.
For our use case, I think we have to install the remoteit OpenWrt module and leave the registration file blank in the firmware, since the user will want to use their own Remote.it account.
When the user configures the device to use Remote.it for remote access, they can enter the Licence code corresponding to their account, and this will be put into the registration file before the registration process is completed.
This will result in a registered device with no Services, and these can be added from the Desktop app.
Alternatively, as per your suggestion, the user can set up a Product profile in their account, which includes the default services for the device type, and get the Bulk Identification Code for the Product.
Then when it comes time to register a device, this code can be used instead of the Licence code, which will result in the device being registered including the default services defined for the Product.
If there is a special case of a device that requires a change to the default services, this can be done from the Desktop app.
At least that is how I think it will work from reading the reference you provided.
If that all works out in testing, then I think we have a viable process that can be used for any platform.
One improvement over the CLI approach is that the device registration will use a code rather than the account credentials.
I will test the approach over the next few days and post the outcome.
Regards
Terry
Hi Gary
Just to confirm, testing with the BI Code went well, so I think we now have a viable solution.
Thanks to all for your help.
Regards
Terry
Great, thanks for the update.
Hi Gary
Just hit a speed bump trying to translate the solution back to H3 ARM board.
See post in Troubleshooting.
Thanks for all your help to date.
Terry
OK Got the issue ARM / Debian sorted out. Many thanks.
Next issue…
I have been testing the deployment of Remoteit to some different hardware device types running OpenWrt that we use across various projects. All are running the current stable release 19.07.8 for testing.
So far all but one device type has behaved perfectly. The odd one out returns the error message below when I attempt to install the .ipk file.
The device in question is based on the Qualcomm Atheros QCA9531 SoC, but I have another board type that uses the same SoC and it works fine.
So I am just wondering if you can throw any light on what might cause this error message?
I suspect I have just missed something basic in the build for this board type…
Regards
Terry
# opkg install /root/remoteit*.ipk
Installing remoteit (4.13.5) to root...
Configuring remoteit.
remoteit: Error: Unknown architecture "mips_24kc".
Collected errors:
* pkg_run_script: package "remoteit" postinst script returned status 1.
* opkg_configure: remoteit.postinst returned 1.
This architecture exists, maybe the installer could not download it for some other reason, if you still have the issues, you can download the binaries from https://downloads.remote.it/openwrt/latest/mips_24kc/binaries.tgz
This contains the actual connectd binaries, you can add them in the /usr/share/remoteit/ folder and install again, it will detect the binaries are there
Let me know if you still have an issue