Remote update of a device running swupdate from the command line

[Philip Balister]

I'd like to update a remote device that is running the swupdate web server from the command line.

Has anyone tried this? Any other approaches I should consider.

I'd like to use something like curl to have swupdate get the file and update. I'm going to look in detail tomorrow, just hoping someone can get me going faster.

Thanks,

Philip

[Stefano Babic]

Hi Philip,

On 24/03/2016 02:01, Philip Balister wrote:
> I'd like to update a remote device that is running the swupdate web
> server from the command line.
>

I had not exactly this use case.

> Has anyone tried this? Any other approaches I should consider.

What I have already had is updating via an external tool (custom app),
letting the webserver running. This is done via the client library, that
is linked with the custom program. The webserver is really thought for
safe networks, as there is no authentication at all.

I used stunnel to encrypt the communication, and on the target the main
application communicates with swupdate via the client library to start a
new update and pass the .swu image.

>
> I'd like to use something like curl to have swupdate get the file and
> update. I'm going to look in detail tomorrow, just hoping someone can
> get me going faster.
>
> Thanks,

Regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Mike Williams]

Philip,

If you have a relatively recent version of swupdate curl downloading support may be built in. The '-d' flag will download the image from a URL you provide.

Mike

[Stefano Babic]

Hi Mike,

I think Philip want to use swupdate in push mode (target is the server
waiting for a connection) and not in pull mode (-d flag).

[Philip Balister]

On Thursday, March 24, 2016 at 7:58:37 AM UTC-7, Stefano Babic wrote:

Hi Mike,

On 24/03/2016 14:42, Mike Williams wrote:
> Philip,
>
> On Wed, Mar 23, 2016 at 9:01 PM, Philip Balister
> <philip....@gmail.com <mailto:philip....@gmail.com>> wrote:
>
>     I'd like to update a remote device that is running the swupdate web
>     server from the command line.
>
>     Has anyone tried this? Any other approaches I should consider.
>
>     I'd like to use something like curl to have swupdate get the file
>     and update. I'm going to look in detail tomorrow, just hoping
>     someone can get me going faster.
>
>
> If you have a relatively recent version of swupdate curl downloading
> support may be built in. The '-d' flag will download the image from a
> URL you provide.

I think Philip want to use swupdate in push mode (target is the server
waiting for a connection) and not in pull mode (-d flag).

Yep, for this case, the network is very private, so web server access is under complete control. We have a few options, and I am looking for something that doesn't require us to carry homegrown code.

Philip

[Philip Balister]

On Thursday, March 24, 2016 at 10:19:04 AM UTC-7, Philip Balister wrote:

On Thursday, March 24, 2016 at 7:58:37 AM UTC-7, Stefano Babic wrote:

Hi Mike,

On 24/03/2016 14:42, Mike Williams wrote:
> Philip,
>
> On Wed, Mar 23, 2016 at 9:01 PM, Philip Balister
> <philip....@gmail.com <mailto:philip....@gmail.com>> wrote:
>
>     I'd like to update a remote device that is running the swupdate web
>     server from the command line.
>
>     Has anyone tried this? Any other approaches I should consider.
>
>     I'd like to use something like curl to have swupdate get the file
>     and update. I'm going to look in detail tomorrow, just hoping
>     someone can get me going faster.
>
>
> If you have a relatively recent version of swupdate curl downloading
> support may be built in. The '-d' flag will download the image from a
> URL you provide.

I think Philip want to use swupdate in push mode (target is the server
waiting for a connection) and not in pull mode (-d flag).

Yep, for this case, the network is very private, so web server access is under complete control. We have a few options, and I am looking for something that doesn't require us to carry homegrown code.

$ curl -H "X_FILENAME: foo.swu"  --data-binary @foo.swu http://10.16.32.183:8080/handle_post_request

seems to do what I want. Any ideas on how to get success/failure status from the device?

Philip

[Stefano Babic]

Hi Philip,

Nice trick :-)

> seems to do what I want. Any ideas on how to get success/failure status
> from the device?

Maybe it is enough something like wget://<ip>/getstatus.json.

Regards,

[Philip Balister]

Like this:

[balister@mini ~]$ cat getstatus.json 

{

"Status" : "1",

"Msg" : "Software Update started !",

"Error" : "0",

"LastResult" : "3"

}

Looks like a get a line per request. But I should be able to use this. (also works with curl)

Philip

[giz...@gmail.com]

Hi!

I'm also experimenting with such a use case and this works for me from command line:

curl -F name=@foo.swu http://10.200.8.1:8080/handle_post_request

The HTTP status code you get just tells you the upload (HTTP POST) was ok, but says nothing about how/if your update get applied. More status info, as suggested, can be obtained by "polling" the webserver with:

curl http://wsn.asp.teamware.it:8080/getstatus.json

And yes, you get one json object per request from a queue that swupdate populates with status update and notification objects. This approach is useful i.e. to implement any sort of progress notification at the client side, the way the provided web frontend does.

This turned out being a problem for us on very slow connections (still need to support some 2G connected devices), where polling the status gets very unreliable (timeouts) or at least heavily delayed by the file upload process.

One more problem we faced with the webserver based approach is that we need it set up to serve only one request than go away. The reason is a limitation on the port we can reach on our device. Only an application port which is normally owned by another daemon can indeed be used. While integrating swupdate client-side library (which I did not have time to look at yet) into such a deamon sounds like the best approach for us, we initially looked for a more immediate integration path for swupdate functionality. At the moment this is done with a slightly patched swupdate daemon. Unfortunately, the issues on slow connection I mentioned before, render this approach quite unreliable for a production environment.

As a consequence of these results, I decided to investigate the different approach of running swupdate via ssh against a previously uploaded file. This doesn't provide you as easily consumable informations on the upgrade progress (unless you parse the swupdate stdout), but gives you a more reliable success/failure global information through the process' return value. Of course this also requires another port (ssh) to be accessible, but this seems something we can discuss about with the customer...

Sorry for this lengthy reply but I'm trying to share as much as possible about my experience with swupdate. I believe this is one of the best options available today for implementing a good upgrade strategy for embedded devices. I'm greedy to hear of as many usecases as possible and learn the best approach from others' experience.

[giz...@gmail.com]

Hi Stefano,

On Thursday, March 24, 2016 at 10:53:48 AM UTC+1, Stefano Babic wrote:
> Hi Philip,
>
> On 24/03/2016 02:01, Philip Balister wrote:
> > I'd like to update a remote device that is running the swupdate web
> > server from the command line.
> >
>
> I had not exactly this use case.
>
> > Has anyone tried this? Any other approaches I should consider.
>
> What I have already had is updating via an external tool (custom app),
> letting the webserver running. This is done via the client library, that
> is linked with the custom program. The webserver is really thought for
> safe networks, as there is no authentication at all.
>
> I used stunnel to encrypt the communication, and on the target the main
> application communicates with swupdate via the client library to start a
> new update and pass the .swu image.

Do you know of any opensource project available that integrates swupdate client library this way? I'd be very interested in looking at an example to use as starting point.

regards

[Stefano Babic]

Hi Andrea,

The client library is thought to let people to link their custom and
proprietary application. You won't find an open source project.

I have provide an example using it with examples/client. This is small
and easy example how to use the library.

Best regards,
Stefano Babic

[Stefano Babic]

Hi Andrea,

On 08/04/2016 15:10, giz...@gmail.com wrote:

>
> I'm also experimenting with such a use case and this works for me
> from command line:
>
> curl -F name=@foo.swu http://10.200.8.1:8080/handle_post_request
>
> The HTTP status code you get just tells you the upload (HTTP POST)
> was ok, but says nothing about how/if your update get applied. More
> status info, as suggested, can be obtained by "polling" the webserver
> with:
>
> curl http://wsn.asp.teamware.it:8080/getstatus.json
>
> And yes, you get one json object per request from a queue that
> swupdate populates with status update and notification objects. This
> approach is useful i.e. to implement any sort of progress
> notification at the client side, the way the provided web frontend
> does.

Exactly.

>
> This turned out being a problem for us on very slow connections
> (still need to support some 2G connected devices), where polling the
> status gets very unreliable (timeouts) or at least heavily delayed by
> the file upload process.
>
> One more problem we faced with the webserver based approach is that
> we need it set up to serve only one request than go away. The reason
> is a limitation on the port we can reach on our device. Only an
> application port which is normally owned by another daemon can indeed
> be used. While integrating swupdate client-side library (which I did
> not have time to look at yet) into such a deamon sounds like the best
> approach for us,

It looks to me, too, that you should use the library. You have already
an application to communicate with the world, and the IP port must be
shared. Driving swupdate from your app can solve several headaches.

> we initially looked for a more immediate integration
> path for swupdate functionality. At the moment this is done with a
> slightly patched swupdate daemon. Unfortunately, the issues on slow
> connection I mentioned before, render this approach quite unreliable
> for a production environment.

There is an overhead due to the connection is reopened at each query. It
could be avoided in some ways maintaining the connection, or the answer
could be filtered by sending only status changes.

>
> As a consequence of these results, I decided to investigate the
> different approach of running swupdate via ssh against a previously
> uploaded file. This doesn't provide you as easily consumable
> informations on the upgrade progress (unless you parse the swupdate
> stdout), but gives you a more reliable success/failure global
> information through the process' return value. Of course this also
> requires another port (ssh) to be accessible, but this seems
> something we can discuss about with the customer...

This is generally not practicable in most cases, because the .swu image
must be completed loaded on the target. It is also not very efficient,
because swupdate can load and install at the same time.

>
> Sorry for this lengthy reply but I'm trying to share as much as
> possible about my experience with swupdate.

Thanks for that, I appreciate it.

> I believe this is one of
> the best options available today for implementing a good upgrade
> strategy for embedded devices. I'm greedy to hear of as many usecases
> as possible and learn the best approach from others' experience.

I will glad, too. I hope some other users will want to share their
experience, both positive or negative - the best way to learn from
errors how to improve the project.

Best regards,
Stefano Babic