Closed h0bb3 closed 7 months ago
Seems to be working with the dual mining firmware and the rpi4 compose files.
DIY Dual mining FW 0.8.0
Rpi4 compose running on DIY Rak v2
For that machine the crypto chip seems to be wonky:
I will try a reboot of it...
remote reboot did not help - possibly a power cykle...
Seems to be linked to #132
After an unrelated docker rebuild on my Rak i suddenlty got this:
{"deviceName": "ATECC608", "serialNumber": "0123748154192e58ee", "publicKey": "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
correct serial but wonky pubkey?
Restarting containers did nothing but power cycling the device removed the problem....
One idea could be to upgrade the cryptolib to some newer version. But it would be good with some repeatable scenario that triggers this. It seems to be connected to deploying new images, and/or restarting the containers?
It would be interesting to know if the Nebra/Helium code can handle this situation. So it would be interesting to check this in the dual mining scenario.
In the new threaded queue I tried reloading the first page that show the cryptochip info... got some really strange behavior in some cases it was ok, other we got the serial, other nothing, and also apparent crash and restart of the service:
will continue investigation....
moha ha ha ha this was indeed a threading issue and the library needed to be protected by thread locks.
This could potentially/probably be fixd by now. So I will close this as we will see in the next firmware release if the problem was removed.
This looks odd - a plain RAK v2 should work out of the box or (i.e. no dual mining)?