Why my gateway receive only twice data

Gateways TTKG - The Things Kickstarter Gateway
41

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:

  1. 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…

  2. 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)

  3. After I decript my message, from my devise in TTN console, I pasted the following

613135623935396331303064306538386631323867333068306931386B343038

in ’ Simulate Uplink’ section of my devise.

05
052242×660 28.5 KB

I pressed ‘sent’ and the message has been correctly recorded to my database and showed in my graph

05
051138×500 28.7 KB

42

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)

43

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 packet

Message 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 ?
29

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

44

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.

45

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?

  1. My nodes transmit the messages
  2. The nodes messages are seen in traffic tab of my gateway (the gateway has been restored and reconfigured yesterday)
  3. The packets are well decrypted (lora-packet-decode) and valid, and I can oberseve the FCnt number as well
  4. The devises (TTN console) are not seen (‘Status’ field)
  5. the log gateway show ‘Tx rejected’ messages
  6. 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)

46

No, it doesn’t. It shows that no transmissions requests were rejected.

47

Hello,
I am back from my holiday and before elaving, I leave my infrastructure running, even if the gateway do not trnasmit.
Suddently, on the 13 of august, two nodes transmit and it still tranmitting today.
The node 4, were switch off and for the node 1, I badely inserted the SD card and I devloped the code to not continue if the SD card is not inserted. On saturday, as soon as I inserted the SD card, the data were received successfully.

I am a bit surprised that from the 13 of August, from the same moment, the message from the node could be transmit, while I was on holiday (far away from my codes, infrastructure and PC). In other, word, I did nothing.

I suggest a issue with TTN infrastructure and not with my nodes and gateway.

What do you things?

Actually, the node1 stop transmitting this night. This evening, I will go to my orchard and I will switch on the node 4. I will check node 1, but I beleive it a local issue. (this week, I will make all my nodes working with OTAA instead of ABP)

Cheers