Payloads at gateway level are still encrypted. You first need to decrypt them…
If you have data at the gateway and not the application you probably have issues with the counters. Try resetting the counter for the node in the console.
Payloads are AES-encrypted. You would need your app key to decode it and your network key to validate the crypto checksum.
For example you could use something like https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/ though that would mean sharing your keys with them. Or there are ways to do it locally.
One thing of note is that the frame count is very low; if this is not a new OTAA session then that indicates your node may have restarted its frame counter which could lead the network to reject packets unless you have disabled rollback protection.
1 Like
Dear Kersing
Try resetting the counter for the node in the console.
I did it this morning.
- I switch off node 4 (Ileave it off)
- I switch off/on the gateway
- I reseted the frame counter (Is what you means?) for all nodes
- I switch off/on nodes 1,2 and 3
Actually the ‘Frame up’ field are 0
For example, for node 1, I uncheck that
Dear cslorabox
I am using ABP, for now
though that would mean sharing your keys with them
What the real risk? I would prefer to do it on local (I am investigating)
Thank for helping!!!
PS: I just observed a second node in the gateway traffic
I would like to add a new comment.
Yesterday, I wrote, I can see traffic on my TTOG gateway, and I oberved two of my node because I the DEV ADDR number.
Then my nodes look like sent message to my gateway and my gateway show it in the traffic tab.
BUT, if I go to my devises, and then to the overbiew tab, the ‘status’ filed ‘3 days ago’ (See pictue in my prebious post)
The status is not updated while the gateway traffic show my nodes!! Funny no?
How can we explain that? The gateway see it, but the devise is not updated and the message is not “transfered” to my server
Either the sequence number is out of range, or the cryptographic checksum of the message indicates it is invalid, or the servers that would check this are not working.
There have been reports of server issues in the past few days.
If you could start up another node with temporary keys, you could share those with online decryption tool since you would delete and replace them anyway. It’s also quite possible that just starting with a fresh node will work, because the sequence really will start at the beginning and you’ll get to make sure the keys really match. That could be a hint as to what is wrong with the existing nodes. Or it could indicate that the system is not currently working.
Hello
Thanks a lot for following me. I have a spare node at home and I will create a new devise and try this.
The small private problem, my daughter is now on holiday with me 
and I will not be able to be proactive I will try to it this week, but for the following weeks she will prefer to go to the beach 
But I keep you up to date as soon I have a few moment.
Thank a lot and enjoy the summer!!!
Hello,
I am bit hopless.
If you could start up another node with temporary keys, you could share those with online decryption tool since you would delete and replace them anyway. It’s also quite possible that just starting with a fresh node will work, because the sequence really will start at the beginning and you’ll get to make sure the keys really match
I got a moment and I prepared a 4th node at home. I created a 4th devise from TTN console.
My home gateway could forward and record the message of my node with ABP and OTAA.
Then I went to the field and I first tried with ABP and then OTAA. In both case the message has not been save into my DB.
What was intersting to see: With ABP the devise was not seen (Status field from the 4th devise overview tab. However, with OTTA, it has been seen, but the measure was not record. Sadely, I have not saved the print of my terminal, but The message “EV_JOINING”, “EV_JOINED” and “EV_COMPLETED” was printed.
I also restarted the gateway, and I tried again without success.
Either the sequence number is out of range, or the cryptographic checksum of the message indicates it is invalid, or the servers that would check this are not working
May be I missunderstand the steps to do but I have no idea how to solve that issue, and I do not understand why the intteruption is so long and no idea how to solved that issue.
Should I create a new application with new devise?
Should reset the gateway?
I supposed both idea are not suitable. When a such issue happen, we should not create new application and devise for the same application. And of course I can not buy a new TTGO gateway.
There have been reports of server issues in the past few days.
Which keyword can use to find it?
Many many thank for your help
Restarting the gateway accomplishes absolutely nothing, because gateways have no stateful role, they just transparently proxy traffic between radio and Internet.
Stopping your node and restarting it could however be a problem, as you may now be re-using a previously used frame count value in the ABP case or join nonce in the OTAA case.
Lots of Join Requests going on there. Are any of those your nodes? That two second transmission on SF12 is an air hog! haha.
I am not convianced it the cause of the problem. I beleive a node could be stopped for maintenance or code update. In my today case, the frame is 0
Frames up 0 (reset frame counter)
Not unless you have persistent storage of its state, otherwise you will run into issues, which get worse the more a node has been previously used.
In my today case, the frame is 0
Rolling back to 0 will cause a spec-compliant LoRaWAN network to silently drop traffic, because it looks like a “replay attack”. There are ways to disable that check, but it is part of the specification of how LoRaWAN works.
Using OTAA does solve the frame count problem, because each new join sessions starts that from 0. But actually it only moves the problem, as you aren’t allowed to re-use join nonce numbers.
LoRaWAN fundamentally requires preservation of persistent state in the node.
Dear cslorabox
Thank for all of your replies (and sorry if I missunderstand you),
but what should I do now.
I am planning to use OTAA but I have to fix some developpment first and I will have no time before leaving for holiday. I already lost a lot of measure and it would be great if I can have measure from asap until I am back from holiday (2-3 weeks of measure).
How can I reset then the counter? Should I reset my TTOG?
Should I create a new gateway in TTN console and change the gateway key to my TTOG?
Should I create a new Application (in TTN console) with the 4 devises and modifying the keys to my nodes?
Should I power my TTOG with 220V? I actually power it with a 12V/90Ah battery through a PoE injector/adaptator 12V->48V.
Note, I have got the same problem with. a iC880A-SPI gateway. With that gateway, the problem desappear when I placed it at home, but the problem occured when I placed it on field.
Again, gateways do not have state.
State is only held on the nodes and servers
Figure out if packets are being sent and received
Figure out if those packets validly decrypt
Figure out if the frame count or join nonce are fresh and not re-used
Hello
Figure out if packets are being sent and received
Yes they are. I just see one of my node in my traffic tab.
Figure out if those packets validly decrypt
Yes, I juts decript it and the message is valid
Hex: 613136623935396336366431653835663130346731333568306932306B3431346C33353331
=>
String: a16b959c66d1e85f104g135h0i20k414l3531
The string is correct (the letter is a type a of mesure, the numbers are the value. With that paylod format, I store the value and save it into a DB (but it does not do it)
function Decoder(bytes, port) {
var str=String.fromCharCode.apply(null,bytes);
var astr = str.split(",");
var regex = /([a-z]+)(\d+)/g;
//var resultats = [];
var paire;
var decoded = {}
var te,pr,hu,lu,w1,w2,w3,da,ts,ga,ba,ar,an,it,wr;
while (null !== (paire = regex.exec(astr[0]))) {
//console.log(paire[1]);
switch(paire[1]){
case 'a':
//console.log("te",paire[2]);
te=paire[2];
break;
case 'b':
//console.log("pr",paire[2]);
pr=paire[2];
break;
case 'c':
//console.log("hu",paire[2]);
hu=paire[2];
break;
case 'd':
//console.log("lu",paire[2]);
lu=paire[2];
break;
case 'e':
//console.log("w1",paire[2]);
w1=paire[2];
break;
case 'f':
//console.log("w2",paire[2]);
w2=paire[2];
break;
case 'g':
//console.log("w3",paire[2]);
w3=paire[2];
break;
case 'h':
//console.log("da",paire[2]);
da=paire[2];
break;
case 'i':
//console.log("ts",paire[2]);
ts=paire[2];
break;
case 'j':
//console.log("ga",paire[2]);
ga=paire[2];
break;
case 'k':
//console.log("ba",paire[2]);
ba=paire[2];
break;
case 'l':
// console.log("ar",paire[2]);
ar=paire[2];
break;
case 'm':
// console.log("an",paire[2]);
an=paire[2];
break;
case 'n':
//console.log("it",paire[2]);
it=paire[2];
break;
case 'o':
//console.log("wr",paire[2]);
wr=paire[2];
break;
}
//resultats.push(paire);
}
return {
te:te,
pr:pr,
hu:hu,
lu:lu,
w1:w1,
w2:w2,
w3:w3,
da:da,
ts:ts,
ga:ga,
ba:ba,
ar:ar,
an:an,
it:it,
wr:wr,
}
}
Figure out if the frame count or join nonce are fresh and not re-used
This I do not understand how to do. How can I check if it’s re-used?
Thank for your patience 
Note, to decrypt, I past this in my terminal (with my app and nwk key)
lora-packet-decode --appkey XXXXX --nwkkey XXXXX --hex 40231F01268023010123D6297EB2EF162CB6692A46C393FADE238E5F57827180C79028A9BF0A8E8B3CF0501A866985013A88
it returned me a line like
Plaintext = 613136623935396336366431653835663130346731333568306932306B3431346C33353331 (‘a16b959c66d1e85f104g135h0i20k414l3531’)
Additional note:
-
As I wrote above, my nodes are seen in traffic tab of my gateway, but from TTN consol, under my devise, the field ‘status’ shows ‘13 days ago’, while the nodes was display in the traffic tab, today…
-
my TTOG gateway is seen each 3 minutes, which look long ( ‘Last Seen’ field), isn’t? Can it be a GSM (3G) network issue? (I am used to see the ‘Last Seen’ field to be update each 12-15 sec)
-
After I decript my message, from my devise in TTN console, I pasted the following
613135623935396331303064306538386631323867333068306931386B343038
in ’ Simulate Uplink’ section of my devise.
I pressed ‘sent’ and the message has been correctly recorded to my database and showed in my graph
That the messages are being received and seem to decrypt by other methods is a positive sign.
The frame count is part of the lorawan header, if I recall the 7th and 8th bytes. Look at your still-encrypted hex dumps and see if that is changing in your example the little-endian bytes in question are
40231F01268023010123D6297EB2EF162CB6692A46C393FADE238E5F57827180C79028A9BF0A8E8B3CF0501A866985013A88
Or 0x0123 = 291
You’d want to see that this number was greater than the frame count on the last packet accepted and decoded by TTN
(Technically these are only the low 16 bits of a 32 bit number; the wrapping to additional upper bits is supposed to be tracked by both ends. The MIC checksum calculation uses the full 32-bit value, so if an end guesses wrong about what the upper bits are, the MIC check will fail. If your command line tool validated the MIC without being given upper bits, then the upper bits are likely zero, but if TTN thinks they should be non-zero based on past history of having wrapped over, the packet will be rejected there)
Dear cslorabox
Thank again for your help and clarification.
By runing the following command
lora-packet-decode --appkey XXXXX --nwkkey XXXXX --hex 40231F01268023010123D6297EB2EF162CB6692A46C393FADE238E5F57827180C79028A9BF0A8E8B3CF0501A866985013A88
It display this line
decoding from Hex: 40F116012680230101666F7171F2F37BB57BB62B802EFD190C4823870417928F90EA4C260CAB6331F22D41FB06
Decoded packetMessage Type = Data
PHYPayload = 40F116012680230101666F7171F2F37BB57BB62B802EFD190C4823870417928F90EA4C260CAB6331F22D41FB06( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] ) MHDR = 40 MACPayload = F116012680230101666F7171F2F37BB57BB62B802EFD190C4823870417928F90EA4C260CAB6331F2 MIC = 2D41FB06 (OK) ( MACPayload = FHDR | FPort | FRMPayload ) FHDR = F1160126802301 FPort = 01 FRMPayload = 666F7171F2F37BB57BB62B802EFD190C4823870417928F90EA4C260CAB6331F2 Plaintext = 613135623935396331303064306538386631323867333068306931386B343038 ('a15b959c100d0e88f128g30h0i18k408') ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] ) DevAddr = 260116F1 (Big Endian) FCtrl = 80 FCnt = 0123 (Big Endian) FOpts = Message Type = Unconfirmed Data Up Direction = up FCnt = 291 FCtrl.ACK = false FCtrl.ADR = true
and I can observe
FCnt = 291
But this is the package sent.
You’d want to see that this number was greater than the frame count on the last packet accepted and decoded by TTN
I am sorry, but this is still not clear for me. Where can check the frame count (and how to reset)?
Is this ?
I suppose if I restart the node FCnt take the value of 0, so why it did not solve my problem?
How can I reset it?
(in any case when I restart my node, the first Tx is not recorded)
Today, I went to the field and I look at the gateway log. I got a such lines
GPS coordinates: latitude 46.21502, longitude 6.01250, altitude 464 m
Valid time reference (age: 2 sec)
[GPS]
SX1301 time (PPS): 2329427856
[JIT]
BEACON rejected: 0
BEACON sent so far: 0
BEACON queued: 0
TX rejected (too early): 0.00% (req:1, rej:0)
TX rejected (too late): 0.00% (req:1, rej:0)
TX rejected (collision beacon): 0.00% (req:1, rej:0)
TX rejected (collision packet): 0.00% (req:1, rej:0)
TX errors: 0
RF packets sent to concentrator: 0 (0 bytes)
PULL_RESP(onse) datagrams received: 0 (0 bytes)
PULL_DATA sent: 3 (100.00% acknowledged)
[DOWNSTREAM]
PUSH_DATA acknowledged: 100.00%
PUSH_DATA datagrams sent: 1 (155 bytes)
RF packets forwarded: 0 (0 bytes)
CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
RF packets received by concentrator: 0
[UPSTREAM]
2019-08-08 10:55:14 GMT
but unfortunately, I can make a relation with one of my node message
I suppose if I restart the node FCnt take the value of 0, so why it did not solve my problem?
Restarting the node doesn’t solve anything, on the contrary it can easily cause a problem, because then the node is using a frame count that the network has already seen.
Or trying to use a join nonce that the network has already seen.
Restarting a node is only safe if the node has persistent memory of what it has previously used, otherwise it needs to be avoided.
As repeatedly mentioned, gateways have no state - so going out in the field to check the gateway doesn’t really help debug a case where raw messages from the node are being passed up, but rejected by the server. Your stats message “RF packets forwarded: 0 (0 bytes)” means the gateway received nothing, but only during the period covered by that stats message, which is typically only 30 seconds to at most a few minutes.
Hello
Ok, that’s fine for me.
But I still have the same question:
what can I do to solve my problem?
How can reset the frame count?
- My nodes transmit the messages
- The nodes messages are seen in traffic tab of my gateway (the gateway has been restored and reconfigured yesterday)
- The packets are well decrypted (lora-packet-decode) and valid, and I can oberseve the FCnt number as well
- The devises (TTN console) are not seen (‘Status’ field)
- the log gateway show ‘Tx rejected’ messages
- Keep in mind, I already experience with a IC880A (see my first post) gateway, and as soon I replaced my IC880A gateway with the TTOG gateway, the problem was solved with the TTIG gateway until 25 of July.
Have. a nice day.
(I am leaving for 2 weeks holiday tomorrow)
No, it doesn’t. It shows that no transmissions requests were rejected.