Browser-based firmware generator
-
@Anticimex Thanks for the text fix. I've pushed an update with the device ID change.
General note about getting the latest version: You'll need to refresh once, wait for a bit and refresh a second time to see the latest changes. Alternatively, you can force a hard-refresh, usually by pressing Ctrl+F5 or Ctrl+R. I'll make this experience smoother in some time, but please bear with it for now. This extra refresh is because of the offline support.
I'm on Chrome 58 too. Very strange that you see empty zips. Did the example here https://stuk.github.io/jszip/ work for you?
@rakeshpai The example worked fine. I forced a reload. Then I trashed my old "project" and clicked "Create a network" followed immediately by the download button without touching any settings. Still an empty zip though.
-
@Anticimex Thanks for the text fix. I've pushed an update with the device ID change.
General note about getting the latest version: You'll need to refresh once, wait for a bit and refresh a second time to see the latest changes. Alternatively, you can force a hard-refresh, usually by pressing Ctrl+F5 or Ctrl+R. I'll make this experience smoother in some time, but please bear with it for now. This extra refresh is because of the offline support.
I'm on Chrome 58 too. Very strange that you see empty zips. Did the example here https://stuk.github.io/jszip/ work for you?
@rakeshpai I should mention that when I look at the zip, it is quite big (235KB) but when I open it from a explorer window it appear empty. If I try another tool like 7-zip, it opens. But the root folder is "_" and I suspect windows does not like that. Under that folder the gateway code is. So I think it is just a bug in the directory tree fabrication which is windows zip incompatible.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@rakeshpai I should mention that when I look at the zip, it is quite big (235KB) but when I open it from a explorer window it appear empty. If I try another tool like 7-zip, it opens. But the root folder is "_" and I suspect windows does not like that. Under that folder the gateway code is. So I think it is just a bug in the directory tree fabrication which is windows zip incompatible.
@Anticimex Ah, that makes sense. Based on this, I've rolled out an update. I don't have a Windows box to test, so I'd be awesome if you could have a look once again. Don't forget to do the double-refresh or the hard-refresh I mentioned above.
-
@Anticimex Ah, that makes sense. Based on this, I've rolled out an update. I don't have a Windows box to test, so I'd be awesome if you could have a look once again. Don't forget to do the double-refresh or the hard-refresh I mentioned above.
@rakeshpai Works just fine now. Great work! :+1:
-
Also, it looks like you generate the beta-personalizer, so just switching to PERSONALIZE_ATSHA204A instead of PERSONALIZE_SOFT should do the trick. If you decide to add the ATSHA "checkbox" option that is.
The only other change needed would be to set the appropriate signing flags and requirement flags. I could not see that you enable any such in the gateway it generated. Only encryption. So no signing functionality would be enabled. -
Yes, the browser downloads the SecurityPersonaliser from the development branch of GitHub. The choice of the development branch was accidental ;) but if that's the way things are headed, I'd rather stick with it.
There's very few modifications made to the personalizer. The changes are made here. Basically, the three keys are set, and PERSONALIZE_SOFT is defined. I say this just so that there are multiple eye-balls looking at the code. :)
I haven't worked with ATSHA, and I don't forsee myself doing so soon, so I'll need to understand the process before I make changes. If I understand correctly, I won't need to generate a device ID at all. The user will have to download and flash the personalizer on the arduino, and optionally (if they want whitelisting) read the generated key from the serial output. Is that correct?
I realise now that I haven't thought about adding whitelisting features to this yet. If you have any suggestions about how this can be made easy to use, preferably to the point of being an entirely transparent process, that would be awesome. Meanwhile I'll keep staring at your article on signing, hoping to soak more of it in. :)
Yes, I also haven't added any of the signing defines. That's why I have the huge disclaimers. :) Here's what I glean at the moment, please correct me if I'm wrong:
#define MY_SIGNING_SOFT // or MY_SIGNING_ATSHA204 #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // or MY_SIGNING_ATSHA204_PIN 4 #define MY_SIGNING_REQUEST_SIGNATURES // optional whitelisting #include <MySensors.h>Is this correct? Thanks for looking at this.
-
Yes, the browser downloads the SecurityPersonaliser from the development branch of GitHub. The choice of the development branch was accidental ;) but if that's the way things are headed, I'd rather stick with it.
There's very few modifications made to the personalizer. The changes are made here. Basically, the three keys are set, and PERSONALIZE_SOFT is defined. I say this just so that there are multiple eye-balls looking at the code. :)
I haven't worked with ATSHA, and I don't forsee myself doing so soon, so I'll need to understand the process before I make changes. If I understand correctly, I won't need to generate a device ID at all. The user will have to download and flash the personalizer on the arduino, and optionally (if they want whitelisting) read the generated key from the serial output. Is that correct?
I realise now that I haven't thought about adding whitelisting features to this yet. If you have any suggestions about how this can be made easy to use, preferably to the point of being an entirely transparent process, that would be awesome. Meanwhile I'll keep staring at your article on signing, hoping to soak more of it in. :)
Yes, I also haven't added any of the signing defines. That's why I have the huge disclaimers. :) Here's what I glean at the moment, please correct me if I'm wrong:
#define MY_SIGNING_SOFT // or MY_SIGNING_ATSHA204 #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // or MY_SIGNING_ATSHA204_PIN 4 #define MY_SIGNING_REQUEST_SIGNATURES // optional whitelisting #include <MySensors.h>Is this correct? Thanks for looking at this.
@rakeshpai
So far so good.
Yes, you don't need a device ID for atsha. It already has one.
The process of personalization is identical for the rest. Only the PERSONALIZE_SOFT flag has to be replaced.For whitelisting, you will have to somehow collect all nodes ID:s (therefore these should be statically set and not assigned during runtime) as well as the device ID of all nodes. Then you can fabricate a whitelist for the GW (or node) in question.
I think in addition to that, it would be prudent if the whitelist could be customized. So that you actually get a list of all the nodes from which you just can pick/check the nodes you want in the whitelist of a particular node (or GW).In it's simplest form, only the GW would have a whitelist, as the GW is "trusted", and the nodes are not.
It is only in very rare occasions that a node would need to speak signed messages directly to another node, and I also don't see a usecase for a node having to use a whitelist to trust a GW.
The message is already signed with a preshared key so a "rogue" GW should not be able to communicate as it wouldn't know the key. But in case someone stole a node, and turned it into a GW this might still be desired to have. But you would probably notice a second GW showing up and starting talking to your nodes :)The pins (random seed and atsha204) probably need to be customizable in the UI as it is HW dependent.
-
Yes, the browser downloads the SecurityPersonaliser from the development branch of GitHub. The choice of the development branch was accidental ;) but if that's the way things are headed, I'd rather stick with it.
There's very few modifications made to the personalizer. The changes are made here. Basically, the three keys are set, and PERSONALIZE_SOFT is defined. I say this just so that there are multiple eye-balls looking at the code. :)
I haven't worked with ATSHA, and I don't forsee myself doing so soon, so I'll need to understand the process before I make changes. If I understand correctly, I won't need to generate a device ID at all. The user will have to download and flash the personalizer on the arduino, and optionally (if they want whitelisting) read the generated key from the serial output. Is that correct?
I realise now that I haven't thought about adding whitelisting features to this yet. If you have any suggestions about how this can be made easy to use, preferably to the point of being an entirely transparent process, that would be awesome. Meanwhile I'll keep staring at your article on signing, hoping to soak more of it in. :)
Yes, I also haven't added any of the signing defines. That's why I have the huge disclaimers. :) Here's what I glean at the moment, please correct me if I'm wrong:
#define MY_SIGNING_SOFT // or MY_SIGNING_ATSHA204 #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 // or MY_SIGNING_ATSHA204_PIN 4 #define MY_SIGNING_REQUEST_SIGNATURES // optional whitelisting #include <MySensors.h>Is this correct? Thanks for looking at this.
Thanks for the comments, @Anticimex. I've now deployed a new build with the signing changes we discussed about, without the whitelisting. You can choose ATSHA or SoftSigning, and can specify the signing pin. You'll need to refresh and delete your existing network for the changes to take affect.
Sorry about the trouble with refreshing and deleting. I'll smooth out this experience once this has more users.
Regarding whitelists, I must add, if there's interest, I would like to develop a browser extension to flash the device directly from the site. If we have a browser extension that could talk to the device, we could read the key off serial. If we combine that with instructions to flash the gateway last, we might have simplified whitelist creation.
Also, I was hoping that if a user specifies that the node isn't battery operated, it would be configured to run as a repeater. I'm not sure how whitelists would work in such a scenario.
As an aside: The flash-directly-from-the-browser thing would require a server-side thing to do compilation - can't run avr-gcc in the browser yet. (Someone should port avr-gcc to llvm, so I can run it as WebAssembly in the browser! Very soon, I'm sure. :))
-
Nice but are you sure that "security signing" is enabled? In sources I've found only
#define MY_RF24_ENABLE_ENCRYPTIONnot
#define MY_SIGNING_ATSHA204
#define MY_SIGNING_REQUEST_SIGNATURES@bilbolodz I just updated the UI. Please do a hard-refresh (ctrl+r in chrome), delete your existing network, and try again.
In general, you shouldn't trust the output code yet. I haven't even run it on an arduino yet. The idea is just to give you a feel for the goals of the app, and find out if people find this useful/interesting.
Bugs reports are definitely welcome though. A comment on this thread works just fine.
-
Thanks for the comments, @Anticimex. I've now deployed a new build with the signing changes we discussed about, without the whitelisting. You can choose ATSHA or SoftSigning, and can specify the signing pin. You'll need to refresh and delete your existing network for the changes to take affect.
Sorry about the trouble with refreshing and deleting. I'll smooth out this experience once this has more users.
Regarding whitelists, I must add, if there's interest, I would like to develop a browser extension to flash the device directly from the site. If we have a browser extension that could talk to the device, we could read the key off serial. If we combine that with instructions to flash the gateway last, we might have simplified whitelist creation.
Also, I was hoping that if a user specifies that the node isn't battery operated, it would be configured to run as a repeater. I'm not sure how whitelists would work in such a scenario.
As an aside: The flash-directly-from-the-browser thing would require a server-side thing to do compilation - can't run avr-gcc in the browser yet. (Someone should port avr-gcc to llvm, so I can run it as WebAssembly in the browser! Very soon, I'm sure. :))
@rakeshpai Great!
Repeaters are completely signing agnostic. If they receive a signed message not addressed to them, they just forward it as is. So they don't need to carry whitelist entries to validate messages that are not directed directly to them. -
Thanks for the comments, @Anticimex. I've now deployed a new build with the signing changes we discussed about, without the whitelisting. You can choose ATSHA or SoftSigning, and can specify the signing pin. You'll need to refresh and delete your existing network for the changes to take affect.
Sorry about the trouble with refreshing and deleting. I'll smooth out this experience once this has more users.
Regarding whitelists, I must add, if there's interest, I would like to develop a browser extension to flash the device directly from the site. If we have a browser extension that could talk to the device, we could read the key off serial. If we combine that with instructions to flash the gateway last, we might have simplified whitelist creation.
Also, I was hoping that if a user specifies that the node isn't battery operated, it would be configured to run as a repeater. I'm not sure how whitelists would work in such a scenario.
As an aside: The flash-directly-from-the-browser thing would require a server-side thing to do compilation - can't run avr-gcc in the browser yet. (Someone should port avr-gcc to llvm, so I can run it as WebAssembly in the browser! Very soon, I'm sure. :))
@rakeshpai Looks good with the ATSHA option. One thing to consider is that we have "official" HW that comes predefined (the SenseBender GW for examples). Currently, it seem your tool (which is incomplete, I know) only seem to support AVR boards from looking at the pin options. At some point, you could perhams have a HW device list to pick from to specify what kind of HW the gw or node execute on. And in the case of the SenseBender GW (there could be others) the ATSHA pin is already set by the Arduino environment and should not be overridden by user config. Consider this just FYI right now. The tool looks really promising for people uncomfortable with modifying code.
-
Noted. Right now, the user will have to specify the ATSHA pin correctly for the SenseBender, so I guess it's not the end of the world, but I understand that it can be made easier.
There's actually a little bit of an understanding of the board already - if you choose an ESP8266 gateway and decide to add sensors to it, you'll see pin numbers matching the ESP8266's pinout. That's pin configuration in a different sense though. Let me think about how I can incorporate this.
Thanks for the kind words. :)
-
Noted. Right now, the user will have to specify the ATSHA pin correctly for the SenseBender, so I guess it's not the end of the world, but I understand that it can be made easier.
There's actually a little bit of an understanding of the board already - if you choose an ESP8266 gateway and decide to add sensors to it, you'll see pin numbers matching the ESP8266's pinout. That's pin configuration in a different sense though. Let me think about how I can incorporate this.
Thanks for the kind words. :)
@rakeshpai ah, ok. But the list of pins does not really make sense for the SenseBender gw since it is based on SAMD and not AVR.
-
@rakeshpai I personally think this is just amazing! When I wrote NodeManager I tried to make the world of MySensors just a step closed to a user who is not necessarily a programmer, this is doing the other 99 steps ;-) I'm sure there will be a lot of interest around this project
-
@rakeshpai I personally think this is just amazing! When I wrote NodeManager I tried to make the world of MySensors just a step closed to a user who is not necessarily a programmer, this is doing the other 99 steps ;-) I'm sure there will be a lot of interest around this project
Thanks, @user2684. @hek tells me that this is not the first attempt at making such a tool, but those attempts didn't end up succeeding. However, NodeManager might be changing that, making such a tool even possible. So, all compliments should be directed to you.
I'll need to bother you soon, because I'll need your help to validate the generated code, since it directly uses NodeManager. Still working on it - I'll keep you posted. -
Thanks, @user2684. @hek tells me that this is not the first attempt at making such a tool, but those attempts didn't end up succeeding. However, NodeManager might be changing that, making such a tool even possible. So, all compliments should be directed to you.
I'll need to bother you soon, because I'll need your help to validate the generated code, since it directly uses NodeManager. Still working on it - I'll keep you posted.@rakeshpai sure, I'll be more than happy to double check any code generated for NodeManager! And I'll do a better job documenting future changes to the API since may have an impact on your project as well.
-
Update: Not much has changed functionally, but I've now added a UI notification for when an update is available, so I don't have to tell you to do the double-refresh/hard-refresh ;) and people are always on the latest version.
I've also started writing some tests so that I can start to trust the generated code. I hope these tests are (at least somewhat) human-readable - they might be the easiest way to find out what the generated code is doing.
For eg. this file tests the NodeManager parts of config.h, and this file tests the sensor-specific code for NodeManager. The tests aren't exhaustive yet - still work in progress.
@user2684 Not sure if you'd prefer to read these tests. The alternative would be to change stuff on the UI, download zips, and verify the contents, which can get painful fast.
-
Update: Not much has changed functionally, but I've now added a UI notification for when an update is available, so I don't have to tell you to do the double-refresh/hard-refresh ;) and people are always on the latest version.
I've also started writing some tests so that I can start to trust the generated code. I hope these tests are (at least somewhat) human-readable - they might be the easiest way to find out what the generated code is doing.
For eg. this file tests the NodeManager parts of config.h, and this file tests the sensor-specific code for NodeManager. The tests aren't exhaustive yet - still work in progress.
@user2684 Not sure if you'd prefer to read these tests. The alternative would be to change stuff on the UI, download zips, and verify the contents, which can get painful fast.
@rakeshpai I like the idea of the tests but I'm just afraid it will take more for you to write tests for all the possible combinations more than the time it took already to write the entire sketch generator :-) I'm wondering, is it something easy by chance having in console.log() the resulting code or the change performed upon any action for troubleshooting purposes? If it is too much effort, since it would be for myself only probably, let's explore a better alternative :-)
