Gateway(s) Rejects Class-B package's, "Packet REJECTED, timestamp seems wrong, too much in advance"

Question

Hey,

I am trying to get Class-B working.
After converting from ChirpStack v3 to v4, this problem showed up.

When using Class-B (including multicast group Class-B or FUOTA Class-B), the messages fail to transmit correctly — they’re being rejected by the gateway.

The server is running NTP, and the gateways are connected via Ethernet (so there shouldn’t be any latency from 3G/4G).
I’ve seen several suggestions to set rx_delay to 1 or higher — I already tried that, but that’s only for Class-A receive windows, right?

Does anyone have suggestions on how to fix or debug this timing issue?

Versions:

Chirpstack: 4.13.0 (docker image)
Chirpstack MQTT Forwarder 4.4.0-r1_kona
Kona Macro, met v5.1.11
Tektelic packet forwarder 6.0.3

Oct  6 14:10:44 kona-macro-01A721 pkt_forwarder:
JSON down: {"txpk":{"imme":false,"rfch":0,"powe":29,"ant":0,"brd":0,"tmst":null,"tmms":1443795063390,"freq":869.525,"modu":"LORA","datr":"SF7BW125","codr":"4/5","fdev":null,"ncrc":null,"ipol":true,"prea":null,"size":255,"data":"..."}}
Oct  6 14:10:44 kona-macro-01A721 pkt_forwarder: Warning: Packet REJECTED, timestamp seems wrong, too much in advance (current=3123452581, packet=0, type=0)
Oct  6 14:10:44 kona-macro-01A721 pkt_forwarder: Warning: Packet REJECTED (jit error=2)

Jason Reiss · Answer

This message occurs due to tmst provided as null when coverted to json by mqtt forwarder.

tmst":null,"tmms":1443795063390

Warning: Packet REJECTED, timestamp seems wrong, too much in advance (current=3123452581, packet=0, type=0)

packet=0 is from "tmst": null, the packet tx time is not being derived from the "tmms" value.

Json parser will provide value 0 as shown in the debug message.
https://github.com/Lora-net/sx1302_hal/blob/4b42025d1751e04632c0b04160e0d29dbbb222a5/packet_forwarder/src/lora_pkt_fwd.c#L2906

Orne Brocaar · Answer

Looking at the timestamp in your log Oct 6 14:10:44 (I assume it is UTC), and the GPS epoch timestamp ("tmms": 1443795063390), I do not see any issue directly.

Note that tmms is in miliseconds (https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L134). Converted to seconds, 1443795063.39. If we enter 1443795063 in https://www.andrews.edu/~tzs/timeconv/timeconvert.php, we get Oct 06, 2025 14:10:45 UTC, which is 1 second in the future:

Please note that one of my clients reported in the past that they saw an incorrect tmms reporting by the gateway in the uplinks. If I remember correctly, it was reported in nanoseconds and not milliseconds as specified by the PROTOCOL.txt document. This might as well be related.

Gateway(s) Rejects Class-B package's, "Packet REJECTED, timestamp seems wrong, too much in advance"

2 Answers