OTAA join request does not prompt gateway to respond

[JulianvDoorn]

Hi, I've been having issues for some while where the OTAA join request does not initiate a join accept. I've tested various things and at this point I'm uncertain what kind of parameters can be tweaked to get the gateway to respond. (E.g. I can see the transceiver sending a join-request, however the gateway which it's supposedly talking to does not send a join-accept)

I've got a similar setup in LMiC where all the parameters are correctly configured in order to join the network via OTAA (and this works, however the join mechanism increases the spreading factor until the join has been accepted, after a couple of trials it gets a response, as verified using an SDR, works at around SF11)

Note that I'm porting LoRaMAC to a SAM3X8E, I've verified that port is done correctly, as far as the following peripherals matter:

• True Random Number Generator (Generating a truly random nonce)
• Timer (A hardware timer is used to reduce the probability of an incorrect timer implementation written by me, it is partially tested by me however my assumption is that if the SX1276 is able send a correct join-request, a join-accept will be generated regardless of timings, which I will be able to see using my SDR, which I am able for the LMiC implementation)
• SPI driver (MCU talks to the SX1276 correctly)
• GPIO driver (Pins are set and read correctly)

Things I have considered which can be at fault:

• Message is not arrived at gateway (debunked: hardcoded SF11 for LMiC typically receives a join-accept, as it is seen using an SDR)
• SPI implementation is broken (debunked: logic analyzer, SX1276 does send a message)
• The SX1276 is broken (debunked: LMiC implementation does work with the same SX1762)
• Join request contents is incorrect (debunked: printed the buffer's contents to the serial monitor, showed the following format [MType 1 byte][AppEUI 8 bytes][DevEUI 8 bytes][DevNonce 2 bytes][MIC 4 bytes])

Now I understand that this is likely a complex issue, however I cannot seem to find any possible causes anymore, at this point I'm dumping all SX1276 configuration registers to my serial monitor and comparing it with LMiC's dump. I'n comparing them and manually adjusting the settings during the stand-by state before sending, yet I can't seem to find the issue nor get the transceiver to work.

Can you give me any pointers in the right direction? Is there something obvious I'm missing? Any help is appreciated.

[mluis1]

Could you please provide the following information?

1. Region being used
2. Network Server used

It looks like that the network server doesn't know your device. A network server only generates a JoinAccept in case all JoinReq parameters are correct.

Thus, the first thing to verify is that the JoinEui/AppEui and DevEui are set MSB first on the firmware and that they correspond to the ones setup on the network server. Then you need to verify that the keys being used are the same on both sides. Also you need to ensure that the DevNonce isn't repeated or has been used previously.

Up until you don't get the network server to answer with a JoinAccept there is nothing to verify on the firmware concerning the radio reception. If the JoinAccept isn't transmitted by the network server the end device can't receive it.

[JulianvDoorn]

Region used: EU868 Network server used: Undisclosed by network provider

I have played with the endianness of the keys, didn't matter. Except for one case where there was a weak response, which is different from the desired response, and is barely distinguished from the noise floor. Which is also the endianness required by LoRaMac-node.

I've found that the MIC was generated incorrectly, by generating it on my PC for the sent packages. The MIC was generated as if the AppKey was a buffer all containing '\x00's, meaning it was not initialized. I set the NwkKey to my supposed AppKey, as provided. Currently testing my device if this solves anything.

I've found that there's a very weak response from an LRR far away, I can't exactly tell whether the firmware is supposed to pick it up. As opposed to the nearby one which I normally communicate with (again, using the version using LMiC)

Now I've fixed the MIC being incorrect (NwkKey was not set, AppKey was set). I can validate that the MIC is correct using a script. But the same join accept is not sent from the gateway.

Got response:

Desired response (By LMiC):

Channels are the same. Spreading factor is the same. Now I've verified that MIC is the same for both. And a message is being sent. (And something is responding, but likely from further away, my assumption is a different LRR, likely also a different WAN)

[JulianvDoorn]

I'm porting LoRaMac-node to use an Arduino Due and a Dragino Shield v1.4, by the way. Transmitting messages works perfectly, however there must be subtle differences between LoRaMac-node and LMiC, since using LMiC on the Arduino stack (with some modifications) does work on the Arduino Due. LoRaMac-node does not, however it does transmit a similar message, as shown in the waterfalls above.

However I wish to step away from the Arduino stack and use a less opaque framework (or none at all). The issue I've described above is still persistent. I cannot find anymore clues in regards to configuring LoRaMac to work with the Dragino.

I've double checked everything you've told me @mluis1 in your previous message. I've configured all my variables as they should be, as a sanity check I've even flipped the endianness per variable. There's simply nothing to gain from there, as far as I'm concerned.

Could you tell me what LMiC is doing differently compared to LoRaMac-node? Otherwise I'm forced to switch back to LMiC to meet my deadlines.

[JulianvDoorn]

Dumping the sent packages to serial shows that the package is exactly the same as the working LMiC implementation. (Except for the randomly generated DevNonce). The MIC is correct since I've verified it using lora-package (NPM package).

Granted, I cannot concretely explain what's wrong, simply because if I knew what's wrong I could fix it. Any insights would be greatly appreciated.

[mluis1]

As far as I know the LoRaMac-node and LMIC should behave the same way.

As the network server doesn't generate the JoinAccept message it means that there is an issue with the provided parameters.

Maybe a potential issue that may arrive is related to the introduction of external secure-elemnts with latest release of this project. With this introduction we decided to support both 1.0.x and 1.1.x LoRaWAN versions of the specification through the APIs. We also decided to use the key names defined by the 1.1.x LoRaWAN version. In order to clarify these changes we added an additional comment to commisioning.h file indicating the equivalence between versions.

/*!
 ******************************************************************************
 ********************************** WARNING ***********************************
 ******************************************************************************
  The crypto-element implementation supports both 1.0.x and 1.1.x LoRaWAN 
  versions of the specification.
  Thus it has been decided to use the 1.1.x keys and EUI name definitions.
  The below table shows the names equivalence between versions:
               +---------------------+-------------------------+
               |       1.0.x         |          1.1.x          |
               +=====================+=========================+
               | LORAWAN_DEVICE_EUI  | LORAWAN_DEVICE_EUI      |
               +---------------------+-------------------------+
               | LORAWAN_APP_EUI     | LORAWAN_JOIN_EUI        |
               +---------------------+-------------------------+
               | LORAWAN_GEN_APP_KEY | LORAWAN_APP_KEY         |
               +---------------------+-------------------------+
               | LORAWAN_APP_KEY     | LORAWAN_NWK_KEY         |
               +---------------------+-------------------------+
               | LORAWAN_NWK_S_KEY   | LORAWAN_F_NWK_S_INT_KEY |
               +---------------------+-------------------------+
               | LORAWAN_NWK_S_KEY   | LORAWAN_S_NWK_S_INT_KEY |
               +---------------------+-------------------------+
               | LORAWAN_NWK_S_KEY   | LORAWAN_NWK_S_ENC_KEY   |
               +---------------------+-------------------------+
               | LORAWAN_APP_S_KEY   | LORAWAN_APP_S_KEY       |
               +---------------------+-------------------------+
 ******************************************************************************
 ******************************************************************************
 ******************************************************************************
 */

This means that when using 1.0.x network-servers the APP_KEY on the server corresponds to the LORAWAN_NWK_KEY on the end-device. The APP_EUI corresponds to LORAWAN_JOIN_EUI

[mluis1]

Also, Have you access to the gateway logs? Have you access to the server logs? Have you a way to verify if the network server accepts the JoinReq? Have you a way to verify if the network server generates the JoinAccept?

[mluis1]

Can we close this issue?

[JulianvDoorn]

Yes, that's okay