Lan Firmware Updating, the conclusion

I have not been following GHI for some time now. Waiting for things in the .netmf world to mature a bit more for me.
If i do run with .netmf in the future, there is one feature that is a must have to make it client friendly, which is updating the firmware via LAN.
I know you have that now, but last i knew it was for static only. Which is just not good enough.
It needs to be more feature driven and i dont know if this a GHI or MS situation.

This is what it needs to do. boot static, but id its thrown on a different LAN segment, then switch to DHCP and acquire an IP…
then on the PC side there needs to be a way to bang the network and find all .netmf boards out there. Show them in a list along with their mac addresses and what version of firmware they are currently running. Then select the device you want from the list and click upload firmware.

Dont get me wrong, the updates via USB are great, and work well. But IMHO when it comes to designing a industrial or commercial product for release to the wild there must be a more robust LAN update capabilities.

Is GHI and or MS seriously looking into doing this ?

Hi jdal,

You can actually managed to do this on your own…
I believe NetMF 4.2 includes an infield updates so this can be done on OSH board… and here is how you would do it…

First you create a central Web Site call it Version Control site… Or better yet a Web Service …

all your board upon network activity can report to this Web Service… with their IP and firmware and all info you need…
all your board would implement the infield update feature either using the current way of doing it (Pixys way) or using the one introduced in 4.2

Next you can develop an application that can ping the web service and get the list of all devices on network… get their info…
in this application you select the device you want to upload and send it the file either directly using the local IP if it is on local network. or through the web service if it on WAN.

once done the new board will update the web service with the new firmware…

another way if you are working locally… you can use DPWS on all of your board and create a desktop application that can communicate with them and update them as you wish…
Possibilities are endless…

DPWS would be best for local network because it features broadcasting and so on…

Hope this helps.

You can update GHI premium devices anyway you like, including network.

We have had in field update for years :slight_smile:

[quote]You can update GHI premium devices anyway you like, including network.

We have had in field update for years Smiley[/quote]

Correct me if i am wrong but to do that don’t you need to know the devices IP number to update it ?
.

Not if you implement the proper service. In field update is 100% independent from anything else. You just need to fetch the file somehow and IFU does the rest.

Ah, i think that is where the rub is. There cannot be a server set up somewhere just to handle any update requests from devices.
IMHO it needs to be user driven. If i have 100 devices on the LAN, and some need to run version 1.2 and other need 1.6 because of say something like some have old sensors and some have newer. I want the user to be able to run some app, that will bang the network find all the modules out there and then can choose who get what.
Much like how Netburner does it.

[quote=“jdal”]If i have 100 devices on the LAN, and some need to run version 1.2 and other need 1.6 because of say something like some have old sensors and some have newer. I want the user to be able to run some app, that will bang the network find all the modules out there and then can choose who get what.
[/quote]

There’s no reason you can’t do that… You’d need to design the “bang the network” code, though. Does the network stack not support UDP broadcast packets?

@ godefroi, that is my point… No one should have to write anything. It should already be there. Updating the firmware via USB is already good and well. Nothing really to improve upon there. The network updates is seriously lacking. A tool like i described in the first post should have been wrote from the early onset of .netmf.

I’m not sure that that’s something that ought to be built into the framework. That could all be implemented in managed code, though, so it doesn’t really depend on anything from MS or GHI, post-4.2 anyway.

If i have to guess i think he wants this to be done from Visual Studio directly, or am i wrong?

even if that’s the case you should be able to do it… by using the POST Build feature and call your program to take over to do what you want.

you can even check into creating a VS2010 Plugin to do the job from inside visual studio…

I think most of the ground work is already here, it just a matter of someone taking the time to create something useful out of it.

and btw don’t forget the fact that you can use MFDeploy DLL to do the actual network deployment… for you…so all your application will do is scan the network get the connected devices and pick the device you want to deploy, give the IP to MFDeploy dll and let it do the work. at least in theory …

Hope this helps.

It would be nice, but not necessary. I would prefer a stand alone app that i can give to the customer. So if an when an update is needed i can e-mail him the file and he can update the devices at his leisure.

I hope i am not coming off sarcastic or anything like that in this thread. I just think that these sort of tools should have been out long ago. If a device plugs in on a LAN then it should be very easy to update it that way.

In that case all you have to do is create an Application that would scan the network for all connected devices (You will have to design how to achieve this, can be easily done in DPWS or UDP) and than once the users selects a device, you would pass it’s IP and the file to the MFDeployEngine.dll to do the update for you.

I assume most companies would like a custom update mechanism, or at least the detection of the devices. This to prevent bricking / hacking of devices by using general tools. Some kind of security measurements should be implemented to achieve a robust and trustworthful update mechanism.

its nice to know there is a way out of this. But this should already available by either GHI or MS.
I can be the only one who is thinking commercially.

Think about it, most routers, and other LAN enabled devices the company who makes it provides a simple way for the customer to update the device. Even with very limited knowledge of anything computer related. .netmf should have the same.

The GHI products are development boards and/or partial products. Not a complete device. There are mechanisms for updating available. Just not a complete package…

That does not matter. The purpose of say the new G120 is to make a device with it. That being said the end user will need a easy way to update it.
Quite a few other companies like Netburner, Lantronix, DiGi, and so on also sell modules that have easy way to update the firmware from a end users perspective.

Correct. Through IFU, you can create any update mechanism you like. Some may want to use network, other USB stock. Maybe the file is encrypted, maybe the network is SSL. We let you take this as far as you wish. There is no “one size fits all” in commercial applications.

It is already available … you basically sign your Developed application using MFDeploy… and no one can update it unless they have the Private KEY or a signed package…

I agree, and remember if GHI makes gives you the size fits all, how would you differentiate your product from the competition (talking about other NetMF companies in the same line of business as you are).

I agree that there is no one size fits all. But at the very least there should be what i have been talking about as far as a stand alone app for the end user to update.
I am not trying to beat a dead horse here. I understand that you all are telling me it can be done via the developer writes it.
Though that is not my point here. There should already be in place a no install app that would do this. IF someone wants more features like you describe then they can code that in themselves spring boarding from the original app as a common base to start with.

I am willing to bet anything that as .nermf evolves into the huge thing that i feel it will, this issue will become one of the major requests from users.