Hello all,
I have an application running for more than a year, where a Spider mainboard writes sensor data to Azure Storage Table service every 10 minutes using BuildInEthernet and https protocol.
I let the board reboot regulary when memory goes low (because of the known memory leak) and I have a watchdog implemented. The application usually runs fine for longer periods up to more than 2 months. The forced reboots usually work as expected.
But occasionally the app stops sending data to the Cloud. When I connect the running board to the PC and log in with MFDeploy I can see that the application is running but throws the same exception as when no ssl-seed was entered. When I update the ssl-seed on the running app the following https transmissions are successful and the app runs flawlessly again. Rebooting the board through power off and on doesn’t help. I have to assign a new ssl-seed to get the https transmissions work.
I have no eyplanation for this behavior. It seems that the board occasionally forgets its ssl-seed. Did anybody experience such a behavior too? Is there a way that the application can update the ssl-seed itself when the exception (https access failed) is thrown?
Thanks in advance
Roland
Do you write configuration at all? That can be indirectly when you store the display config it network? Do you do that I on every power up?
No, I do not write the configuration. The App uses no display. Before I use the board I write the ssl-seed and the MAC one time but nothing else. The last time the issue happened it was not in the cycle of a programmatically induced reboot. However it may be that the board rebooted unexpected because an iteration counter that I use the monitor how things go on was reset (the reboot could however also be happened when I plugged in the USB cable). Can it be that an application “gets wild” e.g. through a power issue and overwrites the stored ssl-seed?
If you are not writing then I do not see how a reset would corrupt the data.
I do not know it either. Is there a way to read/write the ssl-seed from program code. If yes, I could evt. compare “before and after” or could write a new one if the old no longer works.
Configuration is one of those things that needed to be completely redone. This is why it is not in TinyCLR OS.
Short answer, there isn’t much you can do.
Long answer, it has been a few years so I am not 100% sure but I think we exposed a way to access configuration and if you knew the internal name of the “seed” then you could in theory read it. This is undocumented so you will need to review the NETMF source code to try to figure it out.
Thanks for your answers though, I hoped there was an easier way.
To expand a bit on what Gus said, to read/write the config entry, take a look at GHI.Processor.Configuration, methods ReadEntry(string, byte[]) and WriteEntry(string, byte[]), in the GHI.Hardware assembly. You’ll still need to look at the NETMF source to figure out how SSL seed is stored in config and what format it is in. Keep in mind it’s an implementation detail. This only works in the latest NETMF SDKs.
Thanks, I’ll have look, but perhaps it will be too time consuming. Perhaps we better wait on ethernet in TinyCLR 