Software signing suddenly stop working


  • Hardware Contributor

    Hi to all,
    I have a RPI2 as Controller, with an UNO as Gateway connected via USB, version 2.1.1, with a NRF amplified.

    I have 3 nodes in home.

    2 are temp / hum battery, no signing at all.

    1 is the heater control, with a relay attached for the heater.

    This node is feeded with a Samsung 5V/2A.

    All network did work for last 6 month. Tonight, suddenly, the heater node lost communication, or better, did not receive command for the relay.

    I did attach a FT232 and I did see on serial "SIGN FAIL". A quick research on forum, I did comment the MY_SIGNING_REQUEST_SIGNATURES

    #define MY_SIGNING_SOFT
    #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
    //#define MY_SIGNING_REQUEST_SIGNATURES
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0x3B,0xF4,0xF4,0xDF,0x1E,0x97,0xB1,0x2D,0xEC}}}
    

    on both gateway and nodes and.... all work like a charme.

    The node is an Atmega328 on breadboard @8MHZ, with amplified NRF, + screen + relay, as I did say.

    Now, for the moment it will be without security, but, just to understand, if someone on the neighborhood would "play" with my node, he could do it?

    I don't need security for a heater, but I would like only to have the WHITELISTING feature.

    IN next days I will investigate what could have done this issues, after about 6 month of small others issues but, of sure, no issues about the signing.

    Another question, I did update several time ago the library from Arduino update. Do you hint to delete totally from the folder, re-download and reinstall? Or the library on the official repository is the same?

    Thank you for your effort.


  • Contest Winner

    @sineverba Hi, it is hard to tell what has gone wrong with the signed messages without any logs to look at. My best guess would be that you have a NACK problem.
    As for the whitelisting feature, no, you cannot "only" have whitelisting. It is based on the signing feature and need it enabled in order to work.



  • @sineverba said in Software signing suddenly stop working:

    MY_SIGNING_REQUEST_SIG

    Interestingly I'm working through a very similar issue myself just now. The garage door opener just stopped working a few days ago.

    I've pulled the Pro Mini out and onto a breadboard and have been doing the following this evening:

    • Updated it to 2.1.1 from 2.0.0 beta (no improvements)
    • Re applied the Security Personalizer / soft HMAC Key with the 2.1.1 core (no difference, nor was I expecting that)
    • Added #define MY_DEBUG_VERBOSE_SIGNING
    • Added #define MY_SIGNING_SOFT_RANDOMSEED_PIN A0 (I never had this line, but it made no difference)
    • Added a capacitor across the NRF24 (no difference)
    • Added additional debug statements to MyTransport.cpp but haven't discovered anything yet.
    • Disabled MY_SIGNING_SOFT (immediately fixes it, but I don't want that)

    My experience is that the messages either never get received (no trace output) or the output ends at "Transmitted nonce". Randomly, it will work.

    It used to work just fine and I'm reluctant to drop the signing. So I'm definitely interested in how you get along and I'll update too if I get my end sorted.

    Cheers


  • Hardware Contributor

    @brendanl as PHP developer, It is INCREDIBLE that a perfect working software, WITHOUT updates, suddenly crash. But It is. For now, I did disable the signing. Do you have inserted other nodes in the network? Changed some radio? I don know whats the failure. I did redownload library from github and tonight I Will reinstallare. I Will update the thread ASAP.


  • Contest Winner

    Signing has an absolute requirement that the radio link works flawlessly. It will trow away or fail messages if any part of the exchange fails to reach the destination. So if you get any NACKs in the log, then those NACKs have to be resolved before signing can be expected to work.


  • Hardware Contributor

    @Anticimex I did see Your similar answer on another thread. I am in accord with you, but my / our nodes was working flawless from month.... I Will try also swapping radios, maybe a power failure that has broken them? But no Power failure in about 6 month in my home....


  • Contest Winner

    @sineverba The log will show if your messages come through or not (you need them from both the node and the GW to verify that). It can be a power issue, or a noise issue, or a neighbour buying some radio equipment that disturb your comms, or birds just crossing at a bad time. Hard to say, but I am inclined to blame RF for this problem and not signing (for this very reason).
    And as I have said, in many threads (and also in the documentation) the fact that it "works without signing" does not automatically mean signing is not working. It is normally just because with signing enabled, the RF link is put on stress due to the messages being much bigger.


  • Hardware Contributor

    @Anticimex ok, I Will investigate more and more.

    Question: if I leave the Heather without signing, or a generic relay, someone "malicious" how could "play" with my relay? Need to have a portable controller and gateway and sniff when I poweron or poweroff the relay itself tto have the node in his controller?


  • Contest Winner

    @sineverba With enough knowledge, only a gateway is needed. You can just use a terminal to send commands to the gateway. If your node ID is known and your radio address, then anyone could just send commands to it. They will need to know what command your node reacts to, but that can be obtained from sniffing the traffic (assuming you don't encrypt your communications).


  • Hardware Contributor

    @Anticimex If i live at 4th floor of a Palace and the family at 3rd use MySensor, on same Channel also (!), Is there the possibility that their Heather commands could be read and interpretated from mine ? (Or viceversa).... Thank you!


  • Contest Winner

    @sineverba That is up to you and how you validate the sender of the messages you receive and accept in your node. If you accept everything, then you accept everything 😉


  • Hardware Contributor

    @Anticimex so, we return to the whitelisting 😞 ...


  • Contest Winner

    @sineverba Not necessarily. You can validate that the message is from "some gateway", and that it is specifically of the type you accept.
    You can also enable encryption.

    But essentially, if you want "security" you need signing. That is kind of the point of that feature 😉


  • Hardware Contributor

    @Anticimex
    I'm re-studying the API and specifically the signature / signing section.

    I did not understand something. I don't want open a new thread, ask here. If necessary, I will open a new one.

    My questions (and thank you in advance for your time and time for all readers!)

    From this page: https://www.mysensors.org/apidocs-beta/group__SigningSettingGrpPub.html#gaf75e26bdb90edd1230100ef160786e78

    1. MY_SIGNING_REQUEST_SIGNATURES
      It says "If used for a gateway, gateway will by default require signatures from ALL nodes[...]".
      I did enable this on the gateway (Arduino UNO).
      Q: In my network I have 2 nodes that transmit temp, hum and battery (atmega328). No signing at all in the sketch(es). Why they works without the SIGNING?

    2. MY_SIGNING_NODE_WHITELISTING
      I do not understand the explain. In effect, in my relay node (the only one of 3 nodes that did have the signing software enabled) I did have also:

    #define MY_SIGNING_SOFT
    #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
    //#define MY_SIGNING_REQUEST_SIGNATURES
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0x3B,0xF4,0xF4,0xDF,0x1E,0x97,0xB1,0x2D,0xEC}}}
    

    What's a verifyng node cited on the explain? Another one node of my network is acting as a bridge beetween both?

    1. You did mention that I could sniff the address of trasmitting (of the gateway). I did not find nothing on the library... Could you help me to perform this "sniff"? This is my receive function atm:
    /**
     * Receive function from gateway
     * 
     * @since 1.0
     */
    void receive(const MyMessage &message) {
    
      if ( !message.isAck() ) {
    
        if ( message.type == V_STATUS) {
      
          if (  message.getCommand() == 1 ) {
      
            bool received_state = message.getBool();
            Serial.print("We did receive a new value. Received_state value is ");
            Serial.println(received_state);
      
            if ( received_state == 1) {
      
              digitalWrite(PIN_RELAY , RELAY_ON);
              
            } else {
      
              digitalWrite(PIN_RELAY , RELAY_OFF);
              
            }
            
          }
          
        }
    
      }
    
    }
    

  • Contest Winner

    @sineverba

    1. I am not sure. I assume you run the 2.2.0-rc.1 version on all nodes and gw? The documentation you read is for that branch (development branch).

    2. The verifying node is the node that verifies the signatures. That is, the node that require signatures. It can be both ends if both require signatures (node and GW)

    3. No, I meant "someone" could sniff. The library itself does not offer sniffing APIs.


  • Contest Winner

    @sineverba actually, reading your first post, it would appear that you run the official release (2.1.1). The signing requirements work differently there, and the documentation is also different as you can see here: https://www.mysensors.org/apidocs/index.html as opposed to here: https://www.mysensors.org/apidocs-beta/index.html


  • Hardware Contributor

    @Anticimex No, I'm running the 2.1.1 on all nodes and gw.

    In this moment I did re-enable the signature and signing software section on the gateway (but not in nodes, no nodes have signing enabled). All works. I can confirm.

    For the 2 (whitelisting) I did enable only on the node that require signature, i.e. the relay node. Not in gw, not in no others nodes.

    For the 3, maybe I was not clear. I did mean if I did have the possibility, on receive function, as following pseudo code:

    if (message.getSenderSerial() == 0X01,0XAA, 0XBB) {
    
        Serial.println("We did receive this message from our gateway... we can proceed");
       
    }
    

  • Contest Winner

    This post is deleted!

  • Contest Winner

    @sineverba your config seem correct.


  • Hardware Contributor

    A small update.
    1 - I did delete the library and re-downloaded from Github
    2 - I did clear the EEPROM of gateway
    3 - I did clear the EEPROM of a new Atmega328 (for relay / actuactor)
    4 - I did reinstall the Gateway sketch and the sketch for the relay heater, with signing.

    ..... it works......

    Yes, too many changes all together..... And fortunately I did receive today the PCBs for it, so in next days I will solder it on a firm base and not on breadboard.....

    After 30 min, no working anymore...... 😞 😞 Fake alarm.... maybe some trouble with breadboard, maybe oxyde.... I will test in some day on PCB.


  • Contest Winner

    @sineverba uhm, if you cleared the eeprom, you have erased your personalization data. So now you run without a signing key. So your signatures are worthless.
    You also still run 2.1.1 because that would not work on 2.2.0,iy has checks for such things.
    You will need to redo personalization if you erase the eeprom.


  • Hardware Contributor

    @Anticimex I did forget a step. I did reinstall the personalization also, but after 20/30 mins, all stop works.

    I could try also the 2.2.0rc. Do I need every node and gw on same release or can I mix nodes and gw between 2.1.1 and 2.2.0 ?


  • Contest Winner

    @sineverba ok, I strongly suggest you instead just post your logs (or read them yourself). If you get NACKs, you can reflash and re-personalize all you want. Signing will never work as long as you get NACKs. You have to fix that problem by either tuning your rf settings, checking your rf environment or power supplies.



  • Well I've just got mine working again. I'm putting it down to the birds not just crossing, but circulating for the last couple of weeks!

    After the work last night, I moved my Gateway into the same room as my node on the breadboard in order to swap radios and it instantly became more responsive (much less NACKs & much less randomness on signed communication). I continued swapping radios etc to at least demonstrate consistency/working radios, but the location improvement alone was a Big Clue!

    I have a NRF24L with the external aerial on the gateway, so was always expecting it to continue performing well regardless of what was around it. In my case though it was sitting above a metal 19" network patch panel & right next to a running laptop. Inside the patch panel as well as numerous runs of Cat6, is a 24port switch and a 8 port POE switch. Fair enough, plenty of interference potential, but I don't recall changing any of that recently (for it to just drop out).

    Anyway, whether it's a combination of things, wriggling some wires, resetting some radios in their sockets etc or just now positioning the Gateway further from all the metal, we're back in business.

    I agree, nothing wrong with the software, but perhaps somewhat sensitive on the environmental factors.

    Thanks guys and good luck with the remainder of yours @sineverba


  • Hardware Contributor

    @Anticimex

    I'm looking and investigating for this issue.

    My network of sensors is located at channel 125, by the way I did notice new troubles when Wifi of ADSL is under heavy load.

    I did use two different scanner, and this is the output.

    alt text

    And other scanner

    alt text

    I don't know if my choice to move the radio to channel 125 is ok. In effect, on the node with relay/actuactor, I have also the traffic light. When wifi is under heavy load, I can see the red led blinking. No red when no wifi is used.

    On another website (http://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo) I did read the hint to move the radios to channel 108.

    What do you think about?


  • Contest Winner

    @sineverba I'd suggest that if you can analyze the traffic, pick a channel with low "competing" traffic. Wifi and nrf work in the same band, so it would also to some extent depend on your (and your surroundings) use of various wifi channels. It's difficult to give any recommendations. Just try various and see which have the fewest failed transmissions.


  • Hardware Contributor

    @Anticimex

    I'm investigating on this issue.

    1. I'm on channel 125 (last one, the more free channel on my house).

    2. I have a node on a custom printed pcb with atmega328@8MHZ and an Amplified Antenna. This node is feeded via a LM11173v3 from a 5V 2A samsung charger. This node also has a 100uF near the VCC/GND of antenna.

    3. I have a PI2 + Arduino UNO (genuine!) with an amplified antenna with socket module. The amplified antenna is feeded via the socket module from 5V of PI.

    4. I did clear the EEPROM of Gateway, reloaded the personalization sketch and the Gateway Sketch.

    5. I did load the range finder sketch test from @Boots33 located here: https://forum.mysensors.org/topic/4567/repeater-node-problems/17

    RESULT WITHOUT THE SIGNING ENABLED:

    0 MCO:BGN:INIT NODE,C⸮=RNNNA--,VER=2.1.1
    4 TSM:INIT
    4 TSF:WUR:MS=0
    12 TSM:INIT:TSP OK
    14 TSF:SID:OK,ID=6
    16 TSM:FPAR
    51 TSF:MSG:SEND,6-6-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    712 TSF:MSG:READ,0-0-6,s=255,c=3,t=8,pt=1,l=1,sg=0:0
    718 TSF:MSG:FPAR OK,ID=0,D=1
    2060 TSM:FPAR:OK
    2060 TSM:ID
    2062 TSM:ID:OK
    2064 TSM:UPL
    2068 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    2084 TSF:MSG:READ,0-0-6,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    2088 TSF:MSG:PONG RECV,HP=1
    2093 TSM:UPL:OK
    2095 TSM:READY:ID=6,PAR=0,DIS=1
    2099 TSF:MSG:SEND,6-6-0-0,⸮=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    2107 Waiting for GW to send signing preferences...
    2138 TSF:MSG:READ,0-0-6,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    2144 Received signing presentation, but signing is not supported (message ignored)
    2154 TSF:MSG:SEND,6-6-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
    2164 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
    2185 TSF:MSG:READ,0-0-6,s=255,c=3,t=6,pt=0,l=1,sg=0:M
    2195 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=11,pt=0,l=12,sg=0,ft=0,st=OK:Range Finder
    2207 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
    2217 TSF:MSG:SEND,6-6-0-0,s=0,c=0,t=16,pt=0,l=0,sg=0,ft=0,st=OK:
    2224 MCO:REG:REQ
    2230 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=26,⸮t=1,l=1,sg=0,ft=0,st=OK:2
    2244 TSF:MSG:READ,0-0-6,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    2248 MCO:PIM:NODE REG=1
    2252 MCO:BGN:INIT OK,TSP=1
    2256 TSF:MSG:SEND,6-6-0-0,s=0,c=1,t=23,pt=2,l=2,sg=0,ft=0,st=OK:0
    0
    3266 TSF:MSG:SEND,6-6-0-0,s=0,c=1,t=23,pt=2,l=2,sg=0,ft=0,st=OK:1
    1
    

    And it goes to "infinity" to 20 and restart. NO missing 1 send in about 30 minutes.. Very happy with this.
    After, I did enable the Signing Personalization:

    /**
     * rangeTester
     */
    
    // Enable debug prints to serial monitor
    #define MY_DEBUG
    #define MY_DEBUG_VERBOSE_SIGNING
    
    // Enable and select radio type attached
    #define MY_RADIO_NRF24
    
    #define MY_SIGNING_SOFT
    #define MY_SIGNING_SOFT_RANDOMSEED_PIN 7
    #define MY_SIGNING_REQUEST_SIGNATURES
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0x3B,0xF4,0xDD,0xDF,0x1E,0x97,0xB1,0xFB,0xEC}}}
    
    #define MY_RF24_CHANNEL 125
    
    #include <SPI.h>
    #include <MySensors.h>  
    
    #define CHILD_ID_LIGHT 0
    
    unsigned long WAIT_TIME = 1000; //  time between reads (in milliseconds)
    
    MyMessage msg(CHILD_ID_LIGHT, V_LIGHT_LEVEL);
    
    void presentation()  {
    
      // Send the sketch version information to the gateway and Controller
      sendSketchInfo("Range Finder", "1.0");
    
      // Register all sensors to gateway (they will be created as child devices)
      present(CHILD_ID_LIGHT, S_LIGHT_LEVEL);
      
    }
    
    void loop() {
      
     for (int i=0; i<20; i++) {
       send(msg.set(i));
       Serial.println(i);
       wait(WAIT_TIME);
     }
      
    }
    

    It is a disaster... This is the LOG:

    ⸮0 MCO:BGN:INIT NODE,CP=RNNNAS-,VER=2.1.1
    4 TSM:INIT
    4 TSF:WUR:MS=0
    12 TSM:INIT:TSP OK
    14 TSF:SID:OK,ID=6
    16 TSM:FPAR
    16 Will not sign message for destination 255 as it does not require it
    59 TSF:MSG:SEND,6-6-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    1032 TSF:MSG:READ,0-0-6,s=255,c=3,t=8,pt=1,l=1,sg=0:0
    1038 Skipping security for command 3 type 8
    1042 TSF:MSG:FPAR OK,ID=0,D=1
    2068 TSM:FPAR:OK
    2068 TSM:ID
    2070 TSM:ID:OK
    2072 TSM:UPL
    2074 Skipping security for command 3 type 24
    2080 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    2097 TSF:MSG:READ,0-0-6,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    2103 Skipping security for command 3 type 25
    2107 TSF:MSG:PONG RECV,HP=1
    2109 TSM:UPL:OK
    2111 TSM:READY:ID=6,PAR=0,DIS=1
    2115 Signing required
    2117 Whitelisting required
    2119 Skipping security for command 3 type 15
    2127 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0103
    2134 Waiting for GW to send signing preferences...
    2162 TSF:MSG:READ,0-0-6,s=255,c=3,t=15,pt=6,l=2,sg=0:0101
    2168 Skipping security for command 3 type 15
    2172 Mark node 0 as one that require signed messages
    2179 Mark node 0 as one that do not require whitelisting
    2185 Skipping security for command 3 type 16
    2191 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=16,pt=0,l=0,sg=0,ft=0,st=OK:
    2197 Nonce requested from 0. Waiting...
    7202 Timeout waiting for nonce!
    7204 !TSF:MSG:SIGN FAIL
    7206 Skipping security for command 3 type 16
    7213 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=16,pt=0,l=0,sg=0,ft=1,st=OK:
    7221 Nonce requested from 0. Waiting...
    12226 Timeout waiting for nonce!
    12228 !TSF:MSG:SIGN FAIL
    14231 Skipping security for command 3 type 16
    14239 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=16,pt=0,l=0,sg=0,ft=1,st=OK:
    14245 Nonce requested from 0. Waiting...
    14282 TSF:MSG:READ,0-0-6,s=255,c=3,t=17,pt=6,l=25,sg=0:CDD8E3A6EF6862ABE47C625626385D9C43B17DF5EED6C19A8C
    14295 Skipping security for command 3 type 17
    14299 Nonce received from 0.
    14303 Proceeding with signing...
    Message to process: 060066030BFF52616E67652046696E646572
    Current nonce: CDD8E3A6EF6862ABE47C625626385D9C43B17DF5EED6C19A8CAAAAAAAAAAAAAA
    HMAC: 2FBD5D7E220EB6B33DDC59893EE33081AB9C3A6069BA1DBB0DBC9C52B354AE9D
    Signature in message: 01BD5D7E220EB6B33DDC59893E
    14477 Message ⸮igned
    14485 Message to send has been signed
    14491 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=11,pt=0,l=12,sg=1,ft=0,st=OK:Range Finder
    14499 Skipping security for command 3 type 16
    14510 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
    14518 Nonce requested from 0. Waiting...
    19523 Timeout waiting for nonce!
    19525 !TSF:MSG:SIGN FAIL
    19529 Skipping security for command 3 type 16
    19535 TSF:MSG:SEND,6-6-0-0,s=0,c=3,t=16,pt=0,l=0,sg=1,ft=1,st=OK:
    19544 Nonce requested from 0. Waiting...
    24549 Timeout waiting for nonce!
    24551 !TSF:MSG:SIGN FAIL
    24553 MCO:REG:REQ
    24555 Skipping security for command 3 type 26
    24563 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=26,pt=1,l=1,sg=1,ft=1,st=OK:2
    24592 TSF:MSG:READ,0-0-6,s=255,c=3,t=16,pt=0,l=0,sg=1:
    24598 Skipping security for command 3 type 16
    SHA256: C88B09B24FEE7C0C5CA06C1C70DB958B075D545BCED7A42C4E00000000000000
    24633 Skipping security for command 3 type 17
    24647 TSF:MSG:SEND,6-6-0-0,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:C88B09B24FEE7C0C5CA06C1C70DB958B075D545BCED7A42C4E
    24659 Transmitted nonce
    24788 TSF:MSG:READ,0-0-6,s=255,c=3,t=27,pt=1,l=1,sg=1:1
    Signature in message: 01C615639AAE6055592C7394379A9FD7A448D9BAAE6D8057
    Message to process: 00060E231BFF01
    Current nonce: C88B09B24FEE7C0C5CA06C1C70DB958B075D545BCED7A42C4EAAAAAAAAAAAAAA
    HMAC: 955CF8A12B90E36B4D42B321FFD79586AFEED8566A0162025D1DD3A826393EDD
    SHA256: 80C615639AAE6055592C7394379A9FD7A448D9BAAE6D80572ADFBC1FA45A61E3
    24993 MCO:PIM:NODE REG=1
    24999 MCO:BGN:INIT OK,TSP=1
    25004 Skipping security for command 3 type 16
    25012 TSF:MSG:SEND,6-6-0-0,s=0,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
    25018 Nonce requested from 0. Waiting...
    25083 TSF:MSG:READ,0-0-6,s=255,c=3,t=17,pt=6,l=25,sg=1:098D99FFD443EF2C0D37320ACE0BC0E4B57FFAF6A5705FC2EC
    25096 Skipping security for command 3 type 17
    25100 Nonce received from 0.
    25102 Proceeding with signing...
    Message to process: 0600164117000000
    Current nonce: 098D99FFD443EF2C0D37320ACE0BC0E4B57FFAF6A5705FC2ECAAAAAAAAAAAAAA
    HMAC: A7147AC2A73D5C389A437078A9F2D022528FED7B2431DA3226B05C3C616039B7
    Signature in message: 01147AC2A73D5C389A437078A9F2D022528FED7B2431DA
    25278 Message signed
    25284 Message to send has been signed
    25292 TSF:MSG:SEND,6-6-0-0,s=0,c=1,t=23,pt=2,l=2,sg=1,ft=0,st=OK:0
    0
    26298 Skipping security for command 3 type 16
    26316 TSF:MSG:SEND,6-6-0-0,s=0,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
    26322 Nonce requested from 0. Waiting...
    26378 TSF:MSG:READ,0-0-6,s=255,c=3,t=17,pt=6,l=25,sg=1:79101C63451593B1924BD221797435507AB7AC59C55558D365
    26388 Skipping security for command 3 type 17
    26394 Nonce received from 0.
    26396 Proceeding with signing...
    Message to process: 0600164117000100
    Current nonce: 79101C63451593B1924BD221797435507AB7AC59C55558D365AAAAAAAAAAAAAA
    HMAC: 11D124CC8BA9369358F58569ACBC78ABE57B21C64FA46FCA9E4DCEAEF4042933
    Signature in message: 01D124CC8BA9369358F58569ACBC78ABE57B21C64FA46F
    26570 Message signed
    26578 Message to send has been signed
    26589 TSF:MSG:SEND,6-6-0-0,s=0,c=1,t=23,pt=2,l=2,sg=1,ft=0,st=OK:1
    1
    27596 Skipping security for command 3 type 16
    27602 TSF:MSG:SEND,6-6-0-0,s=0,c=3,t=16,pt=0,l=0,sg=1,ft=0,st=OK:
    27611 Nonce requested from 0. Waiting...
    32616 Timeout waiting for nonce!
    32618 !TSF:MSG:SIGN FAIL
    2
    33622 Skipping security for command 3 type 16
    33632 TSF:MSG:SEND,6-6-0-0,s=0,c=3,t=16,pt=0,l=0,sg=1,ft=1,st=OK:
    33638 Nonce requested from 0. Waiting...
    38643 Timeout waiting for nonce!
    38645 !TSF:MSG:SIGN FAIL
    3
    39649 Skipping security for command 3 type 16
    39659 TSF:MSG:SEND,6-6-0-0,s=0,c=3,t=16,pt=0,l=0,sg=1,ft=1,st=OK:
    39665 Nonce requested from 0. Waiting...
    

    Sometimes it signs, often no. Could be that ACK // timeout for nonce is too fast?

    =================== UPDATE ?======================================

    I did just swap from this radio

    alt text

    To this << edited >> radio.... with plastic and aluminium to shield it...

    alt text

    I would say victory.... now nonce is coming istantly.....

    ================= NEW UPDATE ============================

    I did swap the radio from node and gateway. Gateway with black and node with shielded. No issue, no issue. Probabily the shielded doesn't like Arduino or simply doesn't love the jumpers and works like a charme with a pcb.... don't know, in aliexpress they have so many positive feedback.....


  • Contest Winner

    @sineverba great that you got it working. Yes, signing require a solid radio link. It is not so much a matter of "signing is not working" but rather "radio is not working".


 

318
Online

7.8k
Users

8.7k
Topics

93.1k
Posts