FCnt upper bytes are always all zeroes

[dennisg]

Hi Anthony, nice work building this node module!

I have some nodes that have been sending data for quite a while now. If I parse the raw data (using the correct NwkSKey / AppSKey I do not get the result I expect: e.g.:

Message Type = Data
  PHYPayload = 40232E012600711C06BE41598238

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 40
  MACPayload = 232E012600711C06BE
         MIC = 41598238

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = 232E012600711C
       FPort = 06
  FRMPayload = BE

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 26012E23 (Big Endian)
       FCtrl = 00
        FCnt = 1C71 (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Up
   Direction = up
        FCnt = 7281
   FCtrl.ACK = false
   FCtrl.ADR = false

All of the above is correct.

Of course, you are parsing the encrypted data exactly as per spec so that is not the problem, the thing is however that my FCnt has already rotated past 0xFFFF. So actually for the given message the FCnt that was used by the node to encrypt the message was 0x11C71 (notice the extra 0x1 in front, instead of 0x1C71). The fact that over the air only 2 FCnt bytes are sent means that there is an extra burden on the receiving side to remember the actual FCnt for each particular node.

This causes the 'decrypt' to fail; if I put in the correct higher two bytes in lib/crypt.js:88

 87       util.reverse(packet.getBuffers().FCnt),
 88       util.bufferFromUInt16LE(0x01), // upper 2 bytes of FCnt (zeroes, sometimes higher ;-) )

the decryption results in the data I expect.

Still investigating the best approach for a solution, if I find one I'll create a PR for you to review

[anthonykirby]

Hi Dennis, you're right - I didn't consider the 32-bit version of FCnt (looking at the spec #4.3.1.5, 16-bit & 32-bit frame counters). Apologies for the omission! I suppose the fix would be to add methods to the packet object, setter + getter for the upper 2 bytes - what do you think? A PR would be welcome, or I'll happily write it if you can test it :-) thanks Anthony

[dennisg]

No need for apologies! that's not the way open source works, right ;-)

Your suggestion for adding methods is one way of approaching it and would work fine.

I'm currently investigating an approach where we can supply a repository of sorts where you can ask for the appropriate 32bit FCnt based on the incoming 16bit FCnt and devAddr. Then you only have to configure it once, the codebase would stay the same and would even allow for automatic increments in upper bytes. But where to find the time?

[zhladik]

Hello, I got also to some problems. At first I believed that it is 16/32 bit counter problem, because I used long time running sensor. But I verified on GPS tracker with relaxed counter freshly switched on, that there must be some other issue:

I got partialy (?!) malformed data from decoding:

Payload monitored on GW (Kerlink iFemtocell): QEA1eBeAVQAC5DXowSedhwH5Mr0= 404035781780550002E435E8C1279D8701F932BD

NWSKey:73A65107BB2863FDB15F553EEE345467 APSkey:642B12054F4ACC153C9CF7C8C56E5ABC

correctly decoded payload via GW(veryfied on two different GW): 000e6402ee9f0900e4409c

wrongly decoded payload via DEMO1.js: 00 0E 64 02 EF BF BD EF BF BD 09

Crazy thing is correct beginning of decoded packet!

I dont know why this is screwed this way? May be console dump of base64 of wire formed payload have some info malformed? - may be MIC? But why is start of data not screwed up? Is it AES behaviour?

Here is dump from Kerling/Loriot logs: //JSON up: {"cmd":"gwmsgs","messages":[{"tmst":3224287156,"time":"2017-06-18T17:08:36.504520Z","freq":868100000,"rssi":-57,"snr":9.8,"sf":10,"bw":125,"cr":"4/5","mic":"DB004016","mt":2,"devaddr":"17783540","fctrl":128,"fcnt":85,"port":2,"toa":370,"len":24,"data":"QEA1eBeAVQAC5DXowSedhwH5Mr0="}]} //000DB53117783540 6/18/2017, 7:08:34 PM 85 2 000e6402ee9f0900e4409c

[anthonykirby]

(I'm scheduling time in September to work on this; apologies for the delay)

[dennisg]

thanks!