We're experimenting with software called yalertunnel (yaler.net). It causes embedded devices to maintain a connection to a relay server through which they can be accessed. We are using a 3g broadband dongle with no static ip or port forwarding and results have been quite good. We have been using it only for accessing our web-interface but they also support ssh.
Regards, Mark On Fri, Mar 7, 2014 at 1:41 PM, Bryan Evenson <beven...@melinkcorp.com>wrote: > Alex, > > > -----Original Message----- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Alex J Lennon > > Sent: Friday, March 07, 2014 7:30 AM > > To: yocto@yoctoproject.org > > Subject: [yocto] Remote management of embedded devices > > > > Hi, > > > > I'm looking into remote management solutions for an upcoming headless > > mesh edge router running Poky. I think, at least in the initial rollout > we're > > going to need something more than, say, a cron-based package update > > facility. > > > > I'm currently thinking of going down the route of a cloud based server > > providing SSH port forwarding to the embedded devices, and then perhaps > > putting some scripting together on top of that to enable monitoring, > > configuration, and control. > > This is similar to what we have running. We're using opkg for the package > management system and allow firmware upgrade through the USB stick or > through remote access. We have an SSH server for remote access, and each > device has its own private key for access into the server. If the device > is in the middle of an SSH session with the remote access server, we can > then SSH into the device from our server if we want to do some deeper > diagnostics on an issue with a device. We have separate HTTP server which > each device queries to see if it needs to check in. So instead of having > to do an ssh login each time to check if there's a firmware upgrade > available, it just needs to do a HTTP GET to see if there's firmware > available or if we want to check on its status. > > The biggest issues we've had have been due to our network setup and > handling upgrade both through the network and the USB stick. We are using > "opkg upgrade --download-only" as the first step of the upgrade process to > make sure that we don't do a partial upgrade. opkg-0.1.8 doesn't do > --download-only for file:// sources; why download a file that is already on > the filesystem? So I had to add a patch so it would download files from > the USB stick. We also had an issue with DNS names because the server has > a different name when the device finds it locally on our intranet then when > it connects remotely, so we had to setup separate mirrors. Other than that > it's been working pretty well. > > I'd also love to hear other people's solutions to see if they have done > something similar or came up with a different solution. > > Regards, > Bryan > > > > > I was wondering if there are better solutions already supported by the > Yocto > > project which people might be using to good effect in production systems > ? > > > > Thanks, > > > > Alex > > > > _______________________________________________ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto >
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto