TTN Outdoor Gateway not sending data

Gateways TTOG - The Things Outdoor Gateway
1

We have two TTN Outdoor Gateways that have recently stopped sending data. They show as connected but get no data through. When we investigate the logson both devices the same received pkt log is recorded repeatedly.

Log snippet below. Any ideas appreciated.

INFO: Received pkt from mote: 11000003 (fcnt=9925)



JSON up: {"rxpk":[{"tmst":2747296972,"time":"2021-02-08T14:20:11.486143Z","tmms":1296829211486,"chan":7,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":0.8,"lsnr_min":-5.8,"lsnr_max":3.5,"rssi":-121,"size":23,"data"
:"AAMAABECxSYsyEQQ0KTVs3AJxkovtoE="}]}

INFO: [up] PUSH_ACK received in 11 ms



INFO: Received pkt from mote: 11000003 (fcnt=9925)



JSON up: {"rxpk":[{"tmst":2747329284,"time":"2021-02-08T14:20:11.518455Z","tmms":1296829211518,"chan":6,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","lsnr":-4.0,"lsnr_min":-5.8,"lsnr_max":1.5,"rssi":-113,"size":23,"data
":"AAMAABECxSYsZj8Q0KTVs3C8dUr4jNY="}]}

INFO: [up] PUSH_ACK received in 11 ms



INFO: Received pkt from mote: 11000003 (fcnt=9925)



JSON up: {"rxpk":[{"tmst":2747387732,"time":"2021-02-08T14:20:11.576903Z","tmms":1296829211576,"chan":6,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":-4.8,"lsnr_min":-7.0,"lsnr_max":-0.2,"rssi":-114,"size":23,"da
ta":"AAMAABECxSYsbUMQ0KTVs3BWIJBFG4Y="}]}

INFO: [up] PUSH_ACK received in 11 ms



INFO: Received pkt from mote: 11000003 (fcnt=9925)
2

The repeating fcnt indicates something in the node is broken.

Repeating an already used fcnt is illegal in LoRaWan, so these packets will be ignored by the network server.

see below, that’s not what these are

3

Appreciate the information, thanks. The nodes do appear to work on other Gateways though. Could it be a gateway fault?

4
  1. Those join requests not getting an answer might have nothing to do with the gateways. Have you checked those requests are visible in the application?
  2. Next time can you format the message for readability?
5

Oops, you’re right.

These are not repeating fcounts, rather than unsophistication of the packet forwarder’s debug prints in assuming it is looking at an ordinary in-session uplink, and so mis-interperting part of the join EUI as a frame count, is to blame for my mistaken post.

Lack of any apparent join-accept downlink through the gateway would seem to indicate that either another gateway is closer, the device isn’t registered, that some detail of the registration has been mis-entered, or that the join device nonce is being re-used. But the nonce seems to be random between the examples given, so that’s probably not it unless we’re seeing an insufficiently stirred pseudo random number generation do the same sequence over and over.