JIT Error = 2 message can someone explain?

Hi there i had a gateway working fine now not so good.

I can see the join requests in the console but the device doesn’t actually join anymore

When i look at the gateway log i get this error bu cant find any information on it can someone point me in the right direction ? If i take the device near another gateway it connects fine and then works when i bring it back near this gateway.

ERROR: [down] Packet REJECTED (jit error=2 Too early to queue this packet)

More of the message

INFO: [status] TTN send status success
lgw_receive:1165: FIFO content: 1 31 1 5 17
lgw_receive:1184: [4 17]
Note: LoRa packet
INFO: [up] TTN lora packet send to server “bridge.asia-se.thethings.network”
INFO: [down] TTN received downlink with payload
INFO: [TTN] downlink 17 bytes
ERROR: [down] Packet REJECTED (jit error=2 Too early to queue this packet)

[UPSTREAM]

RF packets received by concentrator: 2

CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%

RF packets forwarded: 2 (46 bytes)

PUSH_DATA datagrams sent: 0 (0 bytes)

PUSH_DATA acknowledged: 0.00%

[DOWNSTREAM]

PULL_DATA sent: 0 (0.00% acknowledged)

PULL_RESP(onse) datagrams received: 0 (0 bytes)

RF packets sent to concentrator: 0 (0 bytes)

TX errors: 0

TX rejected (collision packet): 0.00% (req:2, rej:0)

TX rejected (collision beacon): 0.00% (req:2, rej:0)

TX rejected (too late): 0.00% (req:2, rej:0)

TX rejected (too early): 100.00% (req:2, rej:2)

BEACON IS DISABLED!

[JIT]

INFO: JIT queue contains 0 packets.

INFO: JIT queue contains 0 beacons.

[GPS]

The join reply messages TTN sends to the gateway are not accepted by the gateway for transmission because it considers the requested transmission timestamp invalid (window between current timestamp and requested timestamp is too large). I’ve only seen this issue once in the past 7 months and that was due to an error in the code which has been fixed 5-6 months ago.

You could try restarting the packet forwarder, if that does not solve the issue try rebooting the gateway.

Thanks for the reply - I tried a packet forwarder restart and also rebooted from the multitech device web admin portal and neither fixed it. A hard power cycle did fix it though so will keep an eye on it.

I’m seeing this currently too on a resin.io build. Did the restart, reboot and power cycle but the issues does persist. It was working fine until today though.

##### 2018-02-25 08:01:47 GMT #####
25.02.18 16:01:47 (+0800) ### [UPSTREAM] ###
25.02.18 16:01:47 (+0800) # RF packets received by concentrator: 0
25.02.18 16:01:47 (+0800) # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
25.02.18 16:01:47 (+0800) # RF packets forwarded: 0 (0 bytes)
25.02.18 16:01:47 (+0800) # PUSH_DATA datagrams sent: 0 (0 bytes)
25.02.18 16:01:47 (+0800) # PUSH_DATA acknowledged: 0.00%
25.02.18 16:01:47 (+0800) ### [DOWNSTREAM] ###
25.02.18 16:01:47 (+0800) # PULL_DATA sent: 0 (0.00% acknowledged)
25.02.18 16:01:47 (+0800) # PULL_RESP(onse) datagrams received: 0 (0 bytes)
25.02.18 16:01:47 (+0800) # RF packets sent to concentrator: 0 (0 bytes)
25.02.18 16:01:47 (+0800) # TX errors: 0
25.02.18 16:01:47 (+0800) # TX rejected (collision packet): 0.00% (req:3, rej:0)
25.02.18 16:01:47 (+0800) # TX rejected (collision beacon): 0.00% (req:3, rej:0)
25.02.18 16:01:47 (+0800) # TX rejected (too late): 0.00% (req:3, rej:0)
25.02.18 16:01:47 (+0800) # TX rejected (too early): 100.00% (req:3, rej:3)

Is there anything else I should look at?

You could try a build with DEBUG_JIT_ERROR set to 1 (defined in trace.h) for more details.

For resin.io you need to edit dev/build.sh, add

sed -i -e 's/#define DEBUG_JIT_ERROR .*$/#define DEBUG_JIT_ERROR 1/g' inc/trace.h

Between the following two lines:

cd $INSTALL_DIR/dev/packet_forwarder/mp_pkt_fwd/
make -j$(nproc)
1 Like

Thank you!

My build was few days ago. So, (before your reply, :smile:) I decided to update the software just now, that seems to solve the problem. But, I could only see the latest changes on the forwarder was on the on global_config, that couldn’t be the problem I guess.

Let me to add the debug information.

Hello,

Today on my multitech i see the jit error= 2. Here a copy of my log file :

10:14:02 INFO: [TTN] bridge.eu.thethings.network RTT 20
10:14:02 INFO: [TTN] send status success for bridge.eu.thethings.network
10:14:02 INFO: Disabling GPS mode for concentrator’s counter…
10:14:02 INFO: host/sx1301 time offset=(1521015962s:167851µs) - drift=-250µs
10:14:02 INFO: Enabling GPS mode for concentrator’s counter.

10:14:04 INFO: [down] TTN received downlink with payload
10:14:04 INFO: [TTN] downlink 12 bytes
src/jitqueue.c:323:jit_enqueue(): ERROR: Packet REJECTED, timestamp seems wrong, too much in advance (current=2882744870, packet=2561023292, type=0)
10:14:04 ERROR: [down] Packet REJECTED (jit error=2 Too early to queue this packet)
lgw_receive:1165: FIFO content: 1 8b 0 5 18
lgw_receive:1184: [7 17]
Note: LoRa packet
10:14:29 INFO: [up] TTN lora packet send to server “bridge.eu.thethings.network”

This error was here during 3 hours (7:30am to 10h15am). After this period of 3 hours,my system runs normally (without any reboot or restart lora_pk_fwd)

On my multitech, the pkt_fwd version is 3.0.0-r14. Do you know if version 3.0.20-r1 fix this error ?

This packet arrived far too late at the gateway. The current clock is 2882744870, the packet had to be transmitted at 2561023292. That is over 5 minutes late. The error message might be a bit confusing, the cause is clear.

It will not because this error is not in the packet forwarder. However 3.0.20 contains important fixes so please upgrade anyway.

Thanks!
That’s weird. Do you have an idea of what could explain packets arriving so late during a few hours then back to normal ?
BTW, we’ve now upgraded all our gateways to packet forwarder 3.0.20.

Sorry, nothing concrete as to what the cause might have been.