Failed to make encryption work on a barebone ATMEGA328P
-
Hello everyone!
First of all, thank you for building MySensors, it's really an awesome project!
I had been searching a few months ago for a low-cost (and DIY) alternative to Zigbee / ZWave / Enocean... I'm glad I found it!This is my first post here ; I'm currently struggling to make encryption and signing work on a barebone ATMEGA328P, using the internal 8MHz clock.
First, a bit of context:
I am working on a project to control my heaters via MySensors and HomeAssistant.
Basically, the idea is to send a (part) of the mains signal to the heater so that it enters the right mode: Comfort, Eco, Frost protection or Off mode.
The circuit behind that is really simple to build: a 3.3V power adapter, two optotriacs, two diodes, a microcontroller, a few resistors and a radio basically.On the gateway side, HomeAssistant is running on a Raspberry Pi 1 and I attached to that board an RFM69W radio in the "serial gateway" configuration.
It has been built with the right configuration options: encryption enabled, rmf69w radio defined, etc.
I also defined a random AES and HMAC key in the configuration file used by the gateway.On the "actuator" side if I can say so, I first tested the setup I'm trying to build with an Arduino Uno, another RFM69W, the right level converter between the radio and the Arduino Uno, and finally the controlling circuit.
I followed the procedure to make signing work: run the SecurityPersonalizer sketch with the keys defined and then uploaded my pilot wire code.This first prototype using the Arduino Uno worked well: I could see nonces being exchanged in the debug view of the gateway, the commands sent / received and the state changing on the Arduino side (thanks to diodes). I am now planning to make a second more "realistic" prototype.
My goal is to produce PCBs with the minimum number of components ; I'll therefore replace the Arduino Uno by an ATMEGA328P with the internal 8MHz clock, two capacitors between (A)Vin and GND, and a resistor near the "not RESET" pin.An important note before talking about the issue: I bought the ATMEGAs directly from Microchip (RIP Atmel :P) and the RFM69W radios directly from HopeRF.
So, these are genuine components!Now, the issue:
I uploaded the SecurityPersonalizer sketch to the ATMEGA328P, made sure it was executed correctly and then I pushed my "pilot wire" sketch.
For an unknown reason, the node fails to register and I can't see any message on the gateway side.
Here are the "actuator" logs:__ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.3.1 16 MCO:BGN:INIT NODE,CP=RPNNAS-X,REL=255,VER=2.3.1 63 TSM:INIT 63 TSF:WUR:MS=0 67 TSM:INIT:TSP OK 67 TSM:FPAR 75 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 2390 TSF:MSG:READ,51-180-176,s=199,c=3,t=129,pt=3,l=23,sg=1:0 2398 !TSF:MSG:LEN=7,EXP=32 2400 !TSM:FPAR:NO REPLY 2402 TSM:FPAR 2410 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 4278 TSF:MSG:READ,51-180-176,s=199,c=3,t=129,pt=3,l=23,sg=1:0 4286 !TSF:MSG:LEN=7,EXP=32 4419 !TSM:FPAR:NO REPLY 4421 TSM:FPAR 4427 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 6436 !TSM:FPAR:NO REPLY 6438 TSM:FPAR 6445 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 8454 !TSM:FPAR:FAIL 8456 TSM:FAIL:CNT=1 8458 TSM:FAIL:DIS 8460 TSF:TDI:TSL 18462 TSM:FAIL:RE-INIT 18464 TSM:INIT 18466 TSM:INIT:TSP OK 18468 TSM:FPAR 18477 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 20486 !TSM:FPAR:NO REPLY 20488 TSM:FPAR 20494 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 22503 !TSM:FPAR:NO REPLY 22505 TSM:FPAR 22511 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 24520 !TSM:FPAR:NO REPLY 24522 TSM:FPAR 24528 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 26540 !TSM:FPAR:FAIL 26542 TSM:FAIL:CNT=2 26544 TSM:FAIL:DIS 26546 TSF:TDI:TSL 36550 TSM:FAIL:RE-INIT (etc)
When this problem appeared, I followed the pieces of advice given on this forum: I ran the "clear EEPROM" sketch, re-run the SecurityPersonalizer sketch and re-pushed my pilot wire sketch. Still no luck
I started to believe the problem could be at the hardware level.
I disabled encryption on the gateway (after rebuilding it) and in my sketch... and the actuator managed to register:__ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.3.1 16 MCO:BGN:INIT NODE,CP=RPNNA---,REL=255,VER=2.3.1 28 TSM:INIT 28 TSF:WUR:MS=0 30 TSM:INIT:TSP OK 32 TSM:FPAR 38 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 440 TSF:MSG:READ,0-0-255,s=255,c=3,t=8,pt=1,l=1,sg=0:0 446 TSF:MSG:FPAR OK,ID=0,D=1 2048 TSM:FPAR:OK 2048 TSM:ID 2050 TSM:ID:REQ 2066 TSF:MSG:SEND,255-255-0-0,s=2,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=OK: 2574 TSF:MSG:READ,0-0-255,s=2,c=3,t=4,pt=0,l=1,sg=0:1 2580 TSF:SID:OK,ID=1 2584 TSM:ID:OK 2584 TSM:UPL 2600 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1 2820 TSF:MSG:READ,0-0-1,s=255,c=3,t=25,pt=1,l=1,sg=0:1 2824 TSF:MSG:PONG RECV,HP=1 2828 TSM:UPL:OK 2830 TSM:READY:ID=1,PAR=0,DIS=1 2844 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100 3055 TSF:MSG:READ,0-0-1,s=255,c=3,t=15,pt=6,l=2,sg=0:0100 3080 TSF:MSG:SEND,1-1-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.3.1 3602 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0 3649 TSF:MSG:READ,0-0-1,s=255,c=3,t=6,pt=0,l=1,sg=0:M 3674 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=11,pt=0,l=10,sg=0,ft=0,st=OK:Fil pilote 4196 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0 4229 TSF:MSG:SEND,1-1-0-0,s=0,c=0,t=4,pt=0,l=0,sg=0,ft=0,st=OK: 4237 MCO:REG:REQ 4751 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2 4968 TSF:MSG:READ,0-0-1,s=255,c=3,t=27,pt=1,l=1,sg=0:1 4974 MCO:PIM:NODE REG=1 4978 MCO:BGN:STP 4978 MCO:BGN:INIT OK,TSP=1 4995 TSF:MSG:SEND,1-1-0-0,s=0,c=1,t=2,pt=2,l=2,sg=0,ft=0,st=OK:1 5521 TSF:MSG:SEND,1-1-0-0,s=0,c=1,t=3,pt=2,l=2,sg=0,ft=0,st=OK:2 589813 TSF:MSG:READ,0-0-1,s=0,c=1,t=3,pt=0,l=1,sg=0:6 599988 TSF:MSG:READ,0-0-1,s=0,c=1,t=3,pt=0,l=1,sg=0:1 611840 TSF:MSG:READ,0-0-1,s=0,c=1,t=3,pt=0,l=1,sg=0:3
I could of course see messages being received / send on the gateway side too.
To sum up
Communication is successfully working between an Arduino Uno and the Serial Gateway with encryption + signing enabled but fails to work on a barebone ATMEGA328P.Here are a few questions / ideas I have regarding the issue:
- Could the problem be the bootloader I used to flash the ATMEGA328P? I used the " breadboard-1-6-x.zip" found on the official Arduino website: https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard. Maybe the fuses / EEPROM address it set / uses conflicts with what the SecurityPersonalizer sketch does?
- It seems the encrypted packet is just ignored with encryption enabled since I can't see any logs on the gateway side. I was wondering: are the messages dropped at the radio level or at the software level?
Thanks in advance for your help!
Appendix -- Pilot wire code
#define MY_DEBUG // MySensors configuration #define MY_RADIO_RFM69 #define MY_RFM69_NEW_DRIVER #define MY_SIGNING_SOFT #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7 #define MY_SIGNING_REQUEST_SIGNATURES #define MY_RFM69_ENABLE_ENCRYPTION // Include the libraries #include <MySensors.h> // Global settings #define CHILD_ID 0 #define INITIAL_MODE 2 #define MOC_P 3 #define MOC_N 4 // Global variables bool first_msg_sent = false; MyMessage status_msg(CHILD_ID, V_STATUS); MyMessage mode_msg(CHILD_ID, V_PERCENTAGE); void set_mode(int16_t mode) { digitalWrite(MOC_N, mode & 1); digitalWrite(MOC_P, mode & 2); } void presentation() { sendSketchInfo("Fil pilote", "1.0"); present(CHILD_ID, S_DIMMER); } void setup() { // Make the MOC pins outputs pinMode(MOC_P, OUTPUT); pinMode(MOC_N, OUTPUT); // Set the initial mode (2 = OFF) set_mode(INITIAL_MODE); } void loop() { if (!first_msg_sent) { send(status_msg.set((int16_t) 1)); send(mode_msg.set((int16_t) INITIAL_MODE)); first_msg_sent = true; } } void receive(const MyMessage &message) { if(message.type == V_PERCENTAGE) { set_mode(message.getInt()); } }
-
Nice work @encrypt
Does the gateway startup CP=... line match the settings for the node?
-
Hello @mfalkvidd, thanks for trying to help me
I've just run the gateway compiled with encryption + signing enabled and here are the logs:
Apr 20 16:26:01 INFO Starting gateway... Apr 20 16:26:01 INFO Protocol version - 2.3.1 Apr 20 16:26:01 DEBUG Serial port /dev/ttyMySensorsGateway (115200 baud) created Apr 20 16:26:01 DEBUG MCO:BGN:INIT GW,CP=RPNGLS-X,REL=255,VER=2.3.1 Apr 20 16:26:01 DEBUG TSF:LRT:OK Apr 20 16:26:01 DEBUG TSM:INIT Apr 20 16:26:01 DEBUG TSF:WUR:MS=0 Apr 20 16:26:01 DEBUG TSM:INIT:TSP OK Apr 20 16:26:01 DEBUG TSM:INIT:GW MODE Apr 20 16:26:01 DEBUG TSM:READY:ID=0,PAR=0,DIS=0 Apr 20 16:26:01 DEBUG MCO:REG:NOT NEEDED Apr 20 16:26:01 DEBUG MCO:BGN:STP Apr 20 16:26:01 DEBUG MCO:BGN:INIT OK,TSP=1 Apr 20 16:26:01 DEBUG TSM:READY:NWD REQ Apr 20 16:26:01 DEBUG TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
So I get
CP=RPNGLS-X
on the gateway side and I gotCP=RPNNAS-X
previously on the node side.
Is that correct?
-
@encrypt yes they look good
-
I tried again pushing my pilot wire code to the ATMEGA328P with encryption and signing enabled... same issue
I really don't know what is wrong here...
-
@encrypt what is your memory utilization?
-
@Anticimex: According to my Arduino 1.8.7 IDE -- with the DEBUG mode, encryption and signign enabled -- the sketch uses 18830 bytes (61%) of program storage space and 953 bytes of dynamic memory.
Also, for an unknown reason, the SerialGateway stopped working 10 minutes ago when I re-launched the mysgw binary. I now get "!TSM:INIT:TSP FAIL" messages
-
@encrypt hm, usage is not alarmingly high. The only thing that comes to my mind is if your sketch for the bare atmega328p is compiled with the correct frequency specified. Some timing specific code rely on the CPU_FREQ define (note, I am not sure if that name is the correct one) and if that does not reflect the actual clock rate things might not work as expected.
-
Hmm... I haven't specified the frequency anywhere in a #define...
@Anticimex: What should I add in my sketch if that is necessary? (I've posted the code of my sketch in the first post)
-
@encrypt
I do not see encryption kye for RFM69 in your code...
-
@encrypt normally when using the arduino IDE it is automatically added when you pick board variant. F_CPU or something like that.
-
@kimot all security secrets are stored in eeprom or in an atsha204a device. Never in the sketch unless you use the simple security option.
Exception being the personalizer sketch for obvious reasons
-
@kimot: I used the SecurityPersonalizer sketch with the keys defined in it.
Here is the beginning of the sketch:/* * The MySensors Arduino library handles the wireless radio link and protocol * between your home built sensors/actuators and HA controller of choice. * The sensors forms a self healing radio network with optional repeaters. Each * repeater and gateway builds a routing tables in EEPROM which keeps track of the * network topology allowing messages to be routed to nodes. * * Created by Henrik Ekblad <henrik.ekblad@mysensors.org> * Copyright (C) 2013-2018 Sensnology AB * Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors * * Documentation: http://www.mysensors.org * Support Forum: http://forum.mysensors.org * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * version 2 as published by the Free Software Foundation. * */ /** * @ingroup MySigninggrp * @{ * @file SecurityPersonalizer.ino * @brief Security personalization sketch * * REVISION HISTORY * - See git log (git log libraries/MySensors/examples/SecurityPersonalizer/SecurityPersonalizer.ino) */ /** * @example SecurityPersonalizer.ino * This sketch will personalize either none-volatile memory or ATSHA204A for security functions * available in the MySensors library.<br> * Details on personalization procedure is given in @ref personalization.<br> * This sketch will when executed without modifications also print a guided workflow on the UART. */ #include "sha204_library.h" #include "sha204_lib_return_codes.h" /** @brief Make use of the MySensors framework without invoking the entire system */ #define MY_CORE_ONLY #include <MySensors.h> /************************************ User defined key data ***************************************/ /** @brief The user-defined HMAC key to use unless @ref GENERATE_HMAC_KEY is set */ #define MY_HMAC_KEY 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x01,0x02,0x03,0x04,0x05 /** @brief The user-defined AES key to store in EEPROM unless @ref GENERATE_AES_KEY is set */ #define MY_AES_KEY 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x01,0x02,0x03,0x04,0x05,0x06,0x07 /** @brief The user-defined soft serial to use for soft signing unless @ref GENERATE_SOFT_SERIAL is set */ #define MY_SOFT_SERIAL 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF /***************************** Flags for guided personalization flow ******************************/ /** * @def GENERATE_KEYS_ATSHA204A * @brief Default settings for generating keys using ATSHA204A * * @note The generated keys displayed in the serial log with this setting needs to be written down * and transferred to all nodes this gateway will communicate with. This is mandatory for ALL * nodes for encryption (AES key). For signing (HMAC key) it is only required for nodes that * use signing. Typically you set the values for @ref MY_HMAC_KEY and @ref MY_AES_KEY. */ //#define GENERATE_KEYS_ATSHA204A /** * @def GENERATE_KEYS_SOFT * @brief Default settings for generating keys using software * * @b Important<br> * You will need to ensure @ref MY_SIGNING_SOFT_RANDOMSEED_PIN is set to an unconnected analog pin * in order to provide entropy to the software RNG if your hardware has no HWRNG. * * @note The generated keys displayed in the serial log with this setting needs to be written down * and transferred to all nodes this gateway will communicate with. This is mandatory for ALL * nodes for encryption (AES key). For signing (HMAC key) it is only required for nodes that * use signing. Typically you set the values for @ref MY_HMAC_KEY and @ref MY_AES_KEY. */ //#define GENERATE_KEYS_SOFT /** * @def PERSONALIZE_ATSHA204A * @brief Default settings for personalizing an ATSHA204A * * It is assumed that you have updated @ref MY_HMAC_KEY and @ref MY_AES_KEY with the keys displayed * when executing this sketch with @ref GENERATE_KEYS_ATSHA204A or @ref GENERATE_KEYS_SOFT defined. */ //#define PERSONALIZE_ATSHA204A /** * @def PERSONALIZE_SOFT * @brief Default settings for personalizing EEPROM for software signing * * It is assumed that you have updated @ref MY_HMAC_KEY and @ref MY_AES_KEY with the keys displayed * when executing this sketch with @ref GENERATE_KEYS_ATSHA204A or @ref GENERATE_KEYS_SOFT defined. */ #define PERSONALIZE_SOFT /** * @def PERSONALIZE_SOFT_RANDOM_SERIAL * @brief This is an alternative to @ref PERSONALIZE_SOFT which will also store a randomly generated * serial to EEPROM in addition to the actions performed by @ref PERSONALIZE_SOFT. Take note of the * generated soft serial as it will be needed if you plan to use whitelisting. It should be * unique for each node. * * @note This is only needed for targets that lack unique device IDs. The sketch will inform you if * there is a need for generating a random serial or not. Check the "Hardware security * peripherals" listing. If a target has a unique device ID and a serial in EEPROM, the serial * in EEPROM will be used. If erased (replaced with FF:es) the unique device ID will be used * instead. */ //#define PERSONALIZE_SOFT_RANDOM_SERIAL /*************************** The settings below are for advanced users ****************************/ /** * @def USE_SOFT_SIGNING * @brief Uncomment this to generate keys by software and store them to EEPROM instead of ATSHA204A */ //#define USE_SOFT_SIGNING /** * @def LOCK_ATSHA204A_CONFIGURATION * @brief Uncomment this to enable locking the ATSHA204A configuration zone * * It is still possible to change the key, and this also enable random key generation. * @warning BE AWARE THAT THIS PREVENTS ANY FUTURE CONFIGURATION CHANGE TO THE CHIP */ //#define LOCK_ATSHA204A_CONFIGURATION /** * @def SKIP_UART_CONFIRMATION * @brief Uncomment this for boards that lack UART * * This will disable additional confirmation for actions that are non-reversible. * * @b Important<br> For ATSHA204A, no confirmation will be required for locking any zones with this * configuration! Also, if you generate keys on a board without UART, you have no way of determining * what the key is unless it is stored in EEPROM. */ //#define SKIP_UART_CONFIRMATION /** * @def GENERATE_HMAC_KEY * @brief Uncomment this to generate a random HMAC key using ATSHA204A or software depending on * @ref USE_SOFT_SIGNING * @note If not enabled, key defined by @ref MY_HMAC_KEY will be used instead. */ //#define GENERATE_HMAC_KEY /** * @def STORE_HMAC_KEY * @brief Uncomment this to store HMAC key to ATSHA204A or EEPROM depending on @ref USE_SOFT_SIGNING */ //#define STORE_HMAC_KEY /** * @def GENERATE_AES_KEY * @brief Uncomment this to generate a random AES key using ATSHA204A or software depending on * @ref USE_SOFT_SIGNING * @note If not enabled, key defined by @ref MY_AES_KEY will be used instead. */ //#define GENERATE_AES_KEY /** * @def STORE_AES_KEY * @brief Uncomment this to store AES key to EEPROM */ //#define STORE_AES_KEY /** * @def GENERATE_SOFT_SERIAL * @brief Uncomment this to generate a random serial number for software signing * @note If not enabled, serial defined by @ref MY_SOFT_SERIAL will be used instead. */ #define GENERATE_SOFT_SERIAL /** * @def STORE_SOFT_SERIAL * @brief Uncomment this to store the serial number to EEPROM */ //#define STORE_SOFT_SERIAL /** * @def PRINT_DETAILED_ATSHA204A_CONFIG * @brief Uncomment to print the detailed ATSHA204A configuration */ //#define PRINT_DETAILED_ATSHA204A_CONFIG /** * @def RESET_EEPROM_PERSONALIZATION * @brief Uncomment to reset the personalization data in EEPROM to 0xFF:es */ //#define RESET_EEPROM_PERSONALIZATION /********************* Guided mode flag configurations (don't change these) ***********************/ #ifdef GENERATE_KEYS_ATSHA204A #define LOCK_ATSHA204A_CONFIGURATION // We have to lock configuration to enable random number generation #define GENERATE_HMAC_KEY // Generate random HMAC key #define GENERATE_AES_KEY // Generate random AES key #define SKIP_UART_CONFIRMATION // This is an automated mode #endif #ifdef GENERATE_KEYS_SOFT #define USE_SOFT_SIGNING // Use software backend #define GENERATE_HMAC_KEY // Generate random HMAC key #define GENERATE_AES_KEY // Generate random AES key #define SKIP_UART_CONFIRMATION // This is an automated mode #endif #ifdef PERSONALIZE_ATSHA204A #define LOCK_ATSHA204A_CONFIGURATION // We have to lock configuration to enable random number generation #define STORE_HMAC_KEY // Store the HMAC key #define STORE_AES_KEY // Store the AES key #define SKIP_UART_CONFIRMATION // This is an automated mode #endif #ifdef PERSONALIZE_SOFT_RANDOM_SERIAL #define GENERATE_SOFT_SERIAL // Generate a soft serial number #define PERSONALIZE_SOFT // Do the rest as PERSONALIZE_SOFT #endif #ifdef PERSONALIZE_SOFT #define USE_SOFT_SIGNING // Use software backend #define STORE_HMAC_KEY // Store the HMAC key #define STORE_AES_KEY // Store the AES key #define STORE_SOFT_SERIAL // Store the soft serial number #define SKIP_UART_CONFIRMATION // This is an automated mode #endif #if defined(GENERATE_HMAC_KEY) || defined(GENERATE_AES_KEY) || defined(GENERATE_SOFT_SERIAL) #define GENERATE_SOMETHING #endif #if defined(MY_LOCK_MCU) #undefine MY_LOCK_MCU // The Sketch after SecurityPersonaliter should lock the MCU #endif /********************************** Preprocessor sanitychecks *************************************/
Note that the values of MY_HMAC_KEY and MY_AES_KEY in the text above are not the ones I'm currently using.
I re-checked that the AES and HMAC keys are indeed the same on the gateway and that's correct.I don't use the MY_SOFT_SERIAL key yet, so I let the sketch generate a random one.
@Anticimex: I could indeed see in the file
~/Arduino/hardware/breadboard/avr/boards.txt
thatatmega328bb.build.f_cpu=8000000L
is defined.
-
@encrypt then I am fresh out of alternatives. Have you tried the verbose flag for signing just to see if it is signing/encryption that is causing the problems? Or try using signing / encryption one at a time.
Signing can be set up on a per device/gw basis but encryption has to be configured for all devices (that need to communicate).
-
I've enabled
MY_DEBUG_VERBOSE_SIGNING
andMY_DEBUG_VERBOSE_RFM69
, here is what I get:__ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.3.1 16 MCO:BGN:INIT NODE,CP=RPNNAS-X,REL=255,VER=2.3.1 40 !SGN:PER:TAMPERED 77 SGN:INI:BND OK 79 TSM:INIT 81 TSF:WUR:MS=0 83 RFM69:INIT 83 RFM69:INIT:PIN,CS=10,IQP=2,IQN=0 90 RFM69:PTX:LEVEL=5 dBm 92 TSM:INIT:TSP OK 94 TSM:FPAR 96 SGN:SGN:NREQ=255 98 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0 102 RFM69:CSMA:RSSI=-108 108 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 2117 !TSM:FPAR:NO REPLY 2119 TSM:FPAR 2121 SGN:SGN:NREQ=255 2123 RFM69:SWR:SEND,TO=255,SEQ=1,RETRY=0 2127 RFM69:CSMA:RSSI=-108 2136 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 4145 !TSM:FPAR:NO REPLY 4147 TSM:FPAR 4149 SGN:SGN:NREQ=255 4151 RFM69:SWR:SEND,TO=255,SEQ=2,RETRY=0 4155 RFM69:CSMA:RSSI=-107 4163 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 6172 !TSM:FPAR:NO REPLY 6174 TSM:FPAR 6176 SGN:SGN:NREQ=255 6178 RFM69:SWR:SEND,TO=255,SEQ=3,RETRY=0 6182 RFM69:CSMA:RSSI=-108 6191 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 8200 !TSM:FPAR:FAIL 8202 TSM:FAIL:CNT=1 8204 TSM:FAIL:DIS 8206 TSF:TDI:TSL 8206 RFM69:RSL
I'm wondering: maybe I should try to dump the EEPROM memory to be sure the keys were properly set?
Also, regarding my question in the first post, do you know where messages are dropped if the AES key isn't correct? Is it at the radio or software level?
-
@encrypt
I am not sure, if we speak about the same AES key.
I mean encryption key for RFM69 chip, because you select using encryption by this radio in your network.
But I am on my mobile only, so it is dificult study source codes Now.
-
@kimot AES key is stored in eeprom for all radios. It is fetched and loaded to the radio in runtime. Not compiletime.
-
@encrypt
The key here is "!SGN:PER:Tampered".
The security backend checks a checksum of the eeprom data used for security. If it is not valid, it considers data tampered and will not use it. So your eeprom has been corrupted one way or another. Or you use either a really old personalizer or a really old library version.
Edit: not old library. And old library would not care about checksum.
-
Hello again,
I don't know why I'm getting that "!SGN:PER:Tampered" message...
I've run the SecurityPersonalizer sketch again and it reported that everything went as expected:+------------------------------------------------------------------------------------+ | MySensors security personalizer | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Configuration settings | +------------------------------------------------------------------------------------+ | * Guided personalization/storage of keys in EEPROM | | * Software based personalization (no ATSHA204A usage whatsoever) | | * Will not require any UART confirmations | | * Will store HMAC key to EEPROM | | * Will store AES key to EEPROM | | * Will generate soft serial using software | | * Will store soft serial to EEPROM | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Hardware security peripherals | +--------------+--------------+--------------+------------------------------+--------+ | Device | Status | Revision | Serial number | Locked | +--------------+--------------+--------------+------------------------------+--------+ | AVR | DETECTED | N/A | N/A (generation required) | N/A | +--------------+--------------+--------------+------------------------------+--------+ +------------------------------------------------------------------------------------+ | Key generation | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | SERIAL | OK | 2DFECBDAE05BB8414C | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Key copy section | +------------------------------------------------------------------------------------+ #define MY_SOFT_SERIAL 0x2D,0xFE,0xCB,0xDA,0xE0,0x5B,0xB8,0x41,0x4C +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Key storage | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | HMAC | OK | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | AES | OK | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | SERIAL | OK | 2DFECBDAE05BB8414C | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | EEPROM | +--------+--------+------------------------------------------------------------------+ | Key ID | Status | Key | +--------+--------+------------------------------------------------------------------+ | HMAC | OK | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | AES | OK | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | SERIAL | OK | 2DFECBDAE05BB8414C | +--------+--------+------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | This nodes whitelist entry on other nodes | +------------------------------------------------------------------------------------+ {.nodeId = <ID of this node>,.serial = {0x2D,0xFE,0xCB,0xDA,0xE0,0x5B,0xB8,0x41,0x4C}} +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | WHAT TO DO NEXT? | +------------------------------------------------------------------------------------+ | This device has now been personalized. Run this sketch with its current settings | | on all the devices in your network that have security enabled. | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Execution result | +------------------------------------------------------------------------------------+ | SUCCESS | +------------------------------------------------------------------------------------+
Also, note I'm running the latest version of the SecurityPersonalizer sketch, which can be found here: https://github.com/mysensors/MySensors/blob/development/examples/SecurityPersonalizer/SecurityPersonalizer.ino
I really don't know what can be wrong here...
Could the 8MHz internal clock be the faulty part? Maybe it fails to correctly read the EEPROM data due to a misconfigured clock?Here is what avrdude shows in the debug view of the Arduino IDE ; using the Arduino Uno as a programmer:
/opt/arduino-1.8.7/hardware/tools/avr/bin/avrdude -C/opt/arduino-1.8.7/hardware/tools/avr/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyACM0 -b19200 -Uflash:w:/tmp/arduino_build_879921/fil_pilote.ino.hex:i avrdude: Version 6.3-20171130 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "/opt/arduino-1.8.7/hardware/tools/avr/etc/avrdude.conf" User configuration file is "/home/encrypt/.avrduderc" User configuration file does not exist or is not a regular file, skipping Using Port : /dev/ttyACM0 Using Programmer : arduino Overriding Baud Rate : 19200 AVR Part : ATmega328P Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PC2 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Arduino Description : Arduino Hardware Version: 2 Firmware Version: 1.18 Topcard : Unknown Vtarget : 0.0 V Varef : 0.0 V Oscillator : Off SCK period : 0.1 us avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e950f (probably m328p) avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "/tmp/arduino_build_879921/fil_pilote.ino.hex" avrdude: writing flash (21394 bytes): Writing | ################################################## | 100% 23.60s avrdude: 21394 bytes of flash written avrdude: verifying flash memory against /tmp/arduino_build_879921/fil_pilote.ino.hex: avrdude: load data flash data from input file /tmp/arduino_build_879921/fil_pilote.ino.hex: avrdude: input file /tmp/arduino_build_879921/fil_pilote.ino.hex contains 21394 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 13.37s avrdude: verifying ... avrdude: 21394 bytes of flash verified avrdude done. Thank you.
-
@encrypt normally when this happens, it is the main sketch that writes something to eeprom without taking into consideration what parts of the eeprom the MySensors library reserves for internal use.
Could you try to run the personalizer to write the eeprom, then your main sketch, and after that the personalizer again, but this time, configured to not write any data, just print out what is already there?
Sara should be identical but I strongly suspect it will not be (as the main sketch consider data "tampered").
-
I've run the Arduino IDE in "debug" mode to be sure the F_CPU variable was taken into account and it seems it is indeed:
/opt/arduino-1.8.7/arduino-builder -dump-prefs -logger=machine -hardware /opt/arduino-1.8.7/hardware -hardware /home/encrypt/Arduino/hardware -tools /opt/arduino-1.8.7/tools-builder -tools /opt/arduino-1.8.7/hardware/tools/avr -built-in-libraries /opt/arduino-1.8.7/libraries -libraries /home/encrypt/Arduino/libraries -fqbn=breadboard:avr:atmega328bb -vid-pid=0X2341_0X0043 -ide-version=10807 -build-path /tmp/arduino_build_879921 -warnings=none -build-cache /tmp/arduino_cache_286732 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.avr-gcc-5.4.0-atmel3.6.1-arduino2.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.avrdude.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.avrdude-6.3.0-arduino14.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.arduinoOTA.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.arduinoOTA-1.2.1.path=/opt/arduino-1.8.7/hardware/tools/avr -verbose /home/encrypt/Documents/Projets/Domotique/Fil_pilote/fil_pilote/fil_pilote.ino /opt/arduino-1.8.7/arduino-builder -compile -logger=machine -hardware /opt/arduino-1.8.7/hardware -hardware /home/encrypt/Arduino/hardware -tools /opt/arduino-1.8.7/tools-builder -tools /opt/arduino-1.8.7/hardware/tools/avr -built-in-libraries /opt/arduino-1.8.7/libraries -libraries /home/encrypt/Arduino/libraries -fqbn=breadboard:avr:atmega328bb -vid-pid=0X2341_0X0043 -ide-version=10807 -build-path /tmp/arduino_build_879921 -warnings=none -build-cache /tmp/arduino_cache_286732 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.avr-gcc.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.avr-gcc-5.4.0-atmel3.6.1-arduino2.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.avrdude.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.avrdude-6.3.0-arduino14.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.arduinoOTA.path=/opt/arduino-1.8.7/hardware/tools/avr -prefs=runtime.tools.arduinoOTA-1.2.1.path=/opt/arduino-1.8.7/hardware/tools/avr -verbose /home/encrypt/Documents/Projets/Domotique/Fil_pilote/fil_pilote/fil_pilote.ino Using board 'atmega328bb' from platform in folder: /home/encrypt/Arduino/hardware/breadboard/avr Using core 'arduino' from platform in folder: /opt/arduino-1.8.7/hardware/arduino/avr Detecting libraries used... /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10807 -DARDUINO_AVR_ATMEGA328BB -DARDUINO_ARCH_AVR -I/opt/arduino-1.8.7/hardware/arduino/avr/cores/arduino -I/opt/arduino-1.8.7/hardware/arduino/avr/variants/standard /tmp/arduino_build_879921/sketch/fil_pilote.ino.cpp -o /dev/null /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10807 -DARDUINO_AVR_ATMEGA328BB -DARDUINO_ARCH_AVR -I/opt/arduino-1.8.7/hardware/arduino/avr/cores/arduino -I/opt/arduino-1.8.7/hardware/arduino/avr/variants/standard -I/home/encrypt/Arduino/libraries/MySensors /tmp/arduino_build_879921/sketch/fil_pilote.ino.cpp -o /dev/null /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10807 -DARDUINO_AVR_ATMEGA328BB -DARDUINO_ARCH_AVR -I/opt/arduino-1.8.7/hardware/arduino/avr/cores/arduino -I/opt/arduino-1.8.7/hardware/arduino/avr/variants/standard -I/home/encrypt/Arduino/libraries/MySensors -I/opt/arduino-1.8.7/hardware/arduino/avr/libraries/SPI/src /tmp/arduino_build_879921/sketch/fil_pilote.ino.cpp -o /dev/null Using cached library dependencies for file: /home/encrypt/Arduino/libraries/MySensors/MyASM.S Using cached library dependencies for file: /opt/arduino-1.8.7/hardware/arduino/avr/libraries/SPI/src/SPI.cpp Generating function prototypes... /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10807 -DARDUINO_AVR_ATMEGA328BB -DARDUINO_ARCH_AVR -I/opt/arduino-1.8.7/hardware/arduino/avr/cores/arduino -I/opt/arduino-1.8.7/hardware/arduino/avr/variants/standard -I/home/encrypt/Arduino/libraries/MySensors -I/opt/arduino-1.8.7/hardware/arduino/avr/libraries/SPI/src /tmp/arduino_build_879921/sketch/fil_pilote.ino.cpp -o /tmp/arduino_build_879921/preproc/ctags_target_for_gcc_minus_e.cpp /opt/arduino-1.8.7/tools-builder/ctags/5.8-arduino11/ctags -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives /tmp/arduino_build_879921/preproc/ctags_target_for_gcc_minus_e.cpp Compilation du croquis... /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=atmega328p -DF_CPU=8000000L -DARDUINO=10807 -DARDUINO_AVR_ATMEGA328BB -DARDUINO_ARCH_AVR -I/opt/arduino-1.8.7/hardware/arduino/avr/cores/arduino -I/opt/arduino-1.8.7/hardware/arduino/avr/variants/standard -I/home/encrypt/Arduino/libraries/MySensors -I/opt/arduino-1.8.7/hardware/arduino/avr/libraries/SPI/src /tmp/arduino_build_879921/sketch/fil_pilote.ino.cpp -o /tmp/arduino_build_879921/sketch/fil_pilote.ino.cpp.o Compiling libraries... Compiling library "MySensors" Utilisation du fichier déjà compilé : /tmp/arduino_build_879921/libraries/MySensors/MyASM.S.o Compiling library "SPI" Utilisation du fichier déjà compilé : /tmp/arduino_build_879921/libraries/SPI/SPI.cpp.o Compiling core... Using precompiled core: /tmp/arduino_cache_286732/core/core_breadboard_avr_atmega328bb_8bcbb10bb0e7a5b614c24d1e9ac07d80.a Linking everything together... /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-gcc -w -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections -mmcu=atmega328p -o /tmp/arduino_build_879921/fil_pilote.ino.elf /tmp/arduino_build_879921/sketch/fil_pilote.ino.cpp.o /tmp/arduino_build_879921/libraries/MySensors/MyASM.S.o /tmp/arduino_build_879921/libraries/SPI/SPI.cpp.o /tmp/arduino_build_879921/../arduino_cache_286732/core/core_breadboard_avr_atmega328bb_8bcbb10bb0e7a5b614c24d1e9ac07d80.a -L/tmp/arduino_build_879921 -lm /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/arduino_build_879921/fil_pilote.ino.elf /tmp/arduino_build_879921/fil_pilote.ino.eep /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom /tmp/arduino_build_879921/fil_pilote.ino.elf /tmp/arduino_build_879921/fil_pilote.ino.hex Utilisation de la bibliothèque MySensors version 2.3.1 dans le dossier: /home/encrypt/Arduino/libraries/MySensors Utilisation de la bibliothèque SPI version 1.0 dans le dossier: /opt/arduino-1.8.7/hardware/arduino/avr/libraries/SPI /opt/arduino-1.8.7/hardware/tools/avr/bin/avr-size -A /tmp/arduino_build_879921/fil_pilote.ino.elf Le croquis utilise 21394 octets (69%) de l'espace de stockage de programmes. Le maximum est de 30720 octets. Les variables globales utilisent 1022 octets de mémoire dynamique.
Now, to answer your question @Anticimex, how do you run the SecurityPersonalizer sketch to only print the content of the EEPROM and not do any write? I've commented out all options but now it reports that no #define has been set
-
@encrypt you should be able to run it without any local modifications to get it to print the data.
-
Maybe I've missed something but any #define set will make the code write to the EEPROM.
I ran the SecurityPersonalizer again, it reset the EEPROM to FF's.
I enabled thePERSONALIZE_SOFT_RANDOM_SERIAL
flag ran it again and finally re-uploaded my pilot wire code.I still have that "tempered" message in the logs, I really don't know what I can do...
I may just end up disabling encryption I guess...
-
@encrypt that sounds very strange to me. The sketch is written to do nothing when left unchanged from git. Just output the current status.
-
Here is what I get with the SecurityPersonalizer sketch directly from GitHub:
+------------------------------------------------------------------------------------+ | MySensors security personalizer | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | You are running without any configuration flags set. | | No changes will be made to ATSHA204A or EEPROM except for the EEPROM checksum | | which will be updated. | | | | If you want to personalize your device, you have two options. | | | | 1. a. Enable either GENERATE_KEYS_ATSHA204A or GENERATE_KEYS_SOFT | | This will generate keys for ATSHA204A or software signing. | | b. Execute the sketch. You will be guided through the steps below under | | WHAT TO DO NEXT? | | c. Copy the generated keys and replace the topmost definitions in this file. | | d. Save the sketch and then disable the flag you just enabled. | | e. Enable PERSONALIZE_ATSHA204A to personalize the ATSHA204A device. | | or | | Enable PERSONALIZE_SOFT to personalize the EEPROM for software signing. | | If you want to use whitelisting you need to pick a unique serial number | | for each device you run the sketch on and fill in MY_SOFT_SERIAL. | | or | | Enable PERSONALIZE_SOFT_RANDOM_SERIAL to personalzie the EEPROM and | | include a new random serial number every time the sketch is executed. | | Take note of each saved serial number if you plan to use whitelisting. | | f. Execute the sketch on each device you want to personalize that is supposed | | to communicate securely. | | | | 2. Enable any configuration flag as you see fit. | | It is assumed that you know what you are doing. | +------------------------------------------------------------------------------------+ +------------------------------------------------------------------------------------+ | Hardware security peripherals | +--------------+--------------+--------------+------------------------------+--------+ | Device | Status | Revision | Serial number | Locked | +--------------+--------------+--------------+------------------------------+--------+ | AVR | DETECTED | N/A | N/A (generation required) | N/A | +--------------+--------------+--------------+------------------------------+--------+ | ATSHA204A | NOT DETECTED | N/A | N/A | N/A | +--------------+--------------+--------------+------------------------------+--------+ +------------------------------------------------------------------------------------+ | Execution result | +------------------------------------------------------------------------------------+ | FAILURE (last ATSHA204A return code: 0xE7) | +------------------------------------------------------------------------------------+
-
@encrypt hm ok. Try to enable the MY_SIGNING_SOFT flag. I am on cell phone so I have a hard time reading the logic flow of the code.
-
Hmmm... I'm starting to believe that the bootloader i used could be the problem.
Someone using an "alternative" bootloader got problems with signing a few years ago: https://forum.mysensors.org/topic/4991/mysbootloader-1-3pre2-testing/2
-
According to that post, it seems there is a high correlation between the fuses value and the fact that security may or may not work.
Here is the boards.txt file I got from the official "Arduino on a breadboard with internal 8MHz clock" bootloader:
############################################################## atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock) atmega328bb.upload.protocol=arduino atmega328bb.upload.maximum_size=30720 atmega328bb.upload.speed=57600 atmega328bb.bootloader.low_fuses=0xE2 atmega328bb.bootloader.high_fuses=0xDA atmega328bb.bootloader.extended_fuses=0x05 atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex atmega328bb.bootloader.unlock_bits=0x3F atmega328bb.bootloader.lock_bits=0x0F atmega328bb.build.board=AVR_ATMEGA328BB atmega328bb.build.mcu=atmega328p atmega328bb.build.f_cpu=8000000L atmega328bb.build.core=arduino:arduino atmega328bb.build.variant=arduino:standard atmega328bb.bootloader.tool=arduino:avrdude atmega328bb.upload.tool=arduino:avrdude
Do you have any clue @Anticimex / @mfalkvidd?
-
@encrypt sorry no. There is no direct dependency between the security functionality and avr fuses. Atsha communications and some timeouts do expect the clocks to be working at expected rates though so the concept of time is valid. If the core clock is not matching what the preprocessor flags specify (F_CPU) then there could be problems.
Perhaps your device is not really running @8Mhz?Perhaps you could test running a simple sketch that prints something at a specific pace and match that with a "real" clock. For example printing something every 10s specified by some delay or wait function and measure that that is reasonably accurate.
I would expect that if the MCU is not executing at the speed F_CPU specifies, a thing like delay(10s) would not really delay for 10s.
-
@encrypt but I still do not get how the bootloader could cause you to get tampered eeprom data.
Unless the fuses also affect eeprom writes of course.
-
@Anticimex: I have just found that there is an EESAVE fuse on the ATMEGA328P which prevents the EEPROM from being erased whenever a new sketch is pushed to the microcontroller.
It seems to be the root cause of the issue since I've found references in other posts of the MySensors forum to that problem.
I'll test that now and let you know.
-
@encrypt ah, that would indeed explain a lot and especially the tampered indication.
If true, I'll see if I can add that to the troubleshooting section to the documentation.
I was not aware of this fuse.
-
IT WORKS @Anticimex !!!
The issue was indeed the EESAVE fuse not set, which caused the EEPROM to be erased after each sketch upload.
Here is my modified boards.txt file:
############################################################## atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock) atmega328bb.upload.protocol=arduino atmega328bb.upload.maximum_size=30720 atmega328bb.upload.speed=57600 atmega328bb.bootloader.low_fuses=0xE2 atmega328bb.bootloader.high_fuses=0xD2 atmega328bb.bootloader.extended_fuses=0x05 atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex atmega328bb.bootloader.unlock_bits=0x3F atmega328bb.bootloader.lock_bits=0x0F atmega328bb.build.board=AVR_ATMEGA328BB atmega328bb.build.mcu=atmega328p atmega328bb.build.f_cpu=8000000L atmega328bb.build.core=arduino:arduino atmega328bb.build.variant=arduino:standard atmega328bb.bootloader.tool=arduino:avrdude atmega328bb.upload.tool=arduino:avrdude
So, basically, for people coming here in the future:
Follow the tutorial https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard to flash the bootloader of your ATMEGA328P but replace the given boards.txt file (in the breadboard-1-6-x.zip archive) by the one above.A useful link to calculate the fuses values: http://www.engbedded.com/fusecalc/
Thanks for your help @Anticimex, @mfalkvidd and @kimot
-
@encrypt great news! Thanks for joining the community and for your troubleshooting. This information will be compiled into the docs for future reference. Happy signing
-
@anticimex @Encrypt That's a bit odd and certainly specific to the bootloader you're using (ATmegaBoot): AVRdude does (at least with optiboot) a page erase (vs. chip erase where EESAVE has an effect). I do not have the EESAVE fuse bit set and no issues with erased eeprom when loading a new sketch, also see below:
Arduino Uno with optiboot:
uno.bootloader.tool=avrdude uno.bootloader.low_fuses=0xFF uno.bootloader.high_fuses=0xDE uno.bootloader.extended_fuses=0xFD uno.bootloader.unlock_bits=0x3F uno.bootloader.lock_bits=0x0F uno.bootloader.file=optiboot/optiboot_atmega328.hex
High fuse (0xDE) does not enable EESAVE.
-
Hello @tekka and thank you for your remarks!
Your input makes questions come to my mind:
-
What is the difference between Optiboot and the bootloader given in the Arduino tutorial? I am quite new to the world of microcontrollers and I don't know much for the moment, I simply use what is working, eh eh
-
The configuration you gave here doesn't use the internal 8MHz clock, therefore it doesn't fit my needs here, eh eh. Could I just use the "regular" Arduino Uno bootloader and set the proper fuses values in the boards.txt file to use the internal 8MHz clock?
-
You are saying that it's actually optiboot which does the page erase and not avrdude? I believed there the "chip erase" instruction is the only instruction possible to erase the flash, handled by avrdude. And according to the ATMEGA328P datasheet (page 297), I have understood that any "chip erase" instruction will also erase the EEPROM if the EESAVE fuse isn't set. That operation seems to be mandatory too as they say: « A Chip Erase must be performed before the Flash and/or EEPROM are reprogrammed ». So, how does Optiboot / avrdude handle that in such a configuration?
Finally, it seems there is no tutorial in the MySensors documentation explaining how to build a project using a standalone ATMEGA328P and which bootloader to choose (there are a few discussions though). It could be worth creating a tutorial / post about that and I could contribute to it of course
-
-
@encrypt I may have an idea what's going on here: Are you programming a new sketch to your barebone AT328p via ArduinoISP or any other means of serial (=SPI) programming? Programming via bootloader (ATmegaboot or optiboot) requires a FTDI adapter and will only do page erases while leaving the eeprom untouched.
-
Hi @tekka!
I'm indeed programming the ATMEGA328P using an Arduino Uno transformed as ISP with the ArduinoISP sketch.
I've wired the circuit exactly as shown on the first picture of the tutorial here: https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard. I used the same circuit to burn the bootloader and to upload my sketches.
Your remark makes me wonder: do I really need a bootloader at the end?
-
@encrypt Ok, this explains your issue: programming via ISP will do a chip erase and hence the EESAVE fuse setting is critical for e2p persistance. The most common use case is programming via serial bootloader (e.g. optiboot, atmegaboot, etc.) which only does page erases and leaves the rest untouched. To answer your question: If you're using an ISP programmer you do not need a bootloader.
-
I thought the bootloader is overwritten when using ISP? So "you don't need a bootlader" is slightly incorrect, you can not have a bootloader when using isp?
-
@mfalkvidd The Arduino builder generates two .hex files, one of which contains the bootloader as specified in boards.txt. Depending on the flashing settings you may burn the sketch only or the sketch + bootloader, however, the bootloader is not needed for ISP programming.
-
@tekka I see. Thanks for explaining.
Suggested Topics
-
💬 Capacitive Soil Moisture Sensor
OpenHardware.io • 14 Mar 2021, 23:14 • openhardware.io 14 Jan 2022, 15:42 -
Anti-theft Entrance Guard Alarm System Based on Arduino
My Project • 28 Jan 2015, 08:36 • Yeager Cade 28 Jan 2015, 08:36 -
Removing pro mini led bricked the board
Hardware • 29 Feb 2016, 20:40 • tripy 29 Oct 2017, 20:45 -
💬 Radio Node
OpenHardware.io • 30 May 2019, 08:13 • openhardware.io 30 May 2019, 11:37 -
[SOLVED]Atmega 328P reset to start
Troubleshooting • 11 Apr 2021, 11:35 • barrydou 14 Apr 2021, 20:18 -
Novice requesting PCB review and advice for a window / door sensor
Hardware • 22 Nov 2018, 12:04 • BearWithBeard 7 Mar 2020, 10:59 -
💬 Wireless Touch Switch: Triac Model - (For Livolo crystals)
OpenHardware.io • 30 Jan 2018, 21:04 • openhardware.io 3 Mar 2018, 17:03