Does this package support cooking-hacks RN2483?

[Yaoshicn]

Hi, Brocaar,

I am wondering whether this package support RN2483 chip because the encryption algorithm at gateway seems not same as the one at node. Please follow my thought below.

For example, assuming that we have a string data "longtest" needs to be sent to a node. And we have network session key and app session key go like this:

char NWK_SESSION_KEY[] = "01020304050607080910111213141516";
char APP_SESSION_KEY[] = "000102030405060708090A0B0C0D0E0F";

The downlink packet sent by your lorawan system (lora-gateway-bridge/ lorawan-server/ lorawan-app-server) goes like this:

Assuming base64-encoded packet
YOLyEQYgAgAK68z9jEUZBpOUYg==

Message Type = Data
  PHYPayload = 60E2F211062002000AEBCCFD8C451906939462

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 60
  MACPayload = E2F211062002000AEBCCFD8C4519
         MIC = 06939462

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = E2F21106200200
       FPort = 0A
  FRMPayload = EBCCFD8C4519

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 0611F2E2 (Big Endian)
       FCtrl = 20
        FCnt = 0002 (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Down
   Direction = down
        FCnt = 2
   FCtrl.ACK = true
   FCtrl.ADR = false

When my RN2483 node receive this downlink, the decrypted buffer is not the ASCII for string "longtest".

9689e0b5eb2d

Later, I found another tool for encrypting/decrypting LoRa packets here: https://github.com/anthonykirby/lora-packet/

And I write a script (test.js) to illustrate the problem:

var lora_packet = require('lora-packet');

//-----------------
// packet decoding
// decode a packet
// Base64 Downlink Packet: YOLyEQYgbAEKW0lk2KCLHg==
//var packet = lora_packet.fromWire(new Buffer('60e2f2110620020001112a735eda5127e74afea1f7', 'hex'));  // right encrypted packet
var packet = lora_packet.fromWire(new Buffer('60E2F211062002000AEBCCFD8C451906939462', 'hex'));  // the gateway tx encrypted packet

// debug: prints out contents
// - contents depend on packet type
// - contents are named based on LoRa spec
console.log("packet.toString()=\n" + packet);

// e.g. retrieve payload elements
console.log("packet MIC=" + packet.getBuffers().MIC.toString('hex'));
console.log("FRMPayload=" + packet.getBuffers().FRMPayload.toString('hex'));

// check MIC
var NwkSKey = new Buffer('01020304050607080910111213141516', 'hex');
console.log("MIC check=" + (lora_packet.verifyMIC(packet, NwkSKey) ? "OK" : "fail"));

// calculate MIC based on contents
console.log("calculated MIC=" + lora_packet.calculateMIC(packet, NwkSKey).toString('hex'));

// decrypt payload
var AppSKey = new Buffer('000102030405060708090A0B0C0D0E0F', 'hex');
console.log("Decrypted='" + lora_packet.decrypt(packet, AppSKey, NwkSKey).toString('hex') + "'");
console.log("Decrypted='" + lora_packet.decrypt(packet, AppSKey, NwkSKey).toString('') + "'");



var constructedPacket = lora_packet.fromFields({
        MType: 'Unconfirmed Data Down',   // (default)
        DevAddr: new Buffer('0611F2E2', 'hex'), // big-endian
        FCtrl: {
            ADR: false,       // default = false
            ACK: true,        // default = false
            ADRACKReq: false, // default = false
            FPending: false   // default = false
        },
        FCnt: new Buffer('0002', 'hex'), // can supply a buffer or a number
        payload: 'longtest'
    }
    , new Buffer("000102030405060708090A0B0C0D0E0F", 'hex') // AppSKey
    , new Buffer("01020304050607080910111213141516", 'hex') // NwkSKey
);
console.log("constructedPacket.toString()=\n" + constructedPacket);
var wireFormatPacket = constructedPacket.getPHYPayload();
console.log("wireFormatPacket.toString()=\n" + wireFormatPacket.toString('hex'));

The output shows that the encryption algorithm of this package is not same as that running on cooking-hacks RN2483. (The encryption algorithm running in the RN2483 nodes is same as the one in JavaScript repo I mentioned before.) Would you please give me some help on this issue? Thank you.

Best Regards,
Xuanliang

[brocaar]

I've been testing a lot with the RN2483 myself and I don't have any issues with receiving the correct data. Although I don't know exactly what you mean with cooking-hacks RN2483? There shouldn't be any difference in how nodes encrypt as the encrypting meganism is defined by the specs.

Ae you sure that you did set your AppSKey correctly in both LoRa App Server and your node? Please note that in some scripts / for some nodes you need to enter it LSB, in some others MSB. This makes a difference in what you will receive 😉 In case you have doubts, start testing with a key that is equal to its reverse byte order (e.g. 01010101010101010101010101010101).

[Yaoshicn]

@brocaar
Thank you for your reply. The cooking-hacks RN2483 means : https://www.cooking-hacks.com/lorawan-shield-for-raspberry-pi-868-mhz-xbee-socket . We use this chip since we need to integrate some other codes on a Raspberry Pi. The cooking-hacks provide a library so that we can operate RN2483 by C++ program directly.

I double checked the setting and have tested a key that is equal to its reverse byte order. It still not work. If you have time, would you please run the JavaScript I mentioned before to get a better understanding? Thanks again.

[Yaoshicn]

Hi, @brocaar,

Problem solved. I apologize for my carelessness. I did not encode the data with base 64.

apiEnqueueDownlinkQueueItemRequest {
confirmed (boolean, optional): Is an ACK required from the node. ,
data (string, optional): **Base64 encoded data**. ,
devEUI (string, optional): Hex encoded DevEUI of the node. ,
fPort (integer, optional): FPort used (must be >0) ,
reference (string, optional): Random reference (used on ack notification).
}

Thank you for your help and patience.

Best Regards,
Xuanliang