TOO_EARLY when TOO_LATE

[gotthardp]

Hello. I am getting

src/jitqueue.c:251:jit_enqueue(): ERROR: Packet REJECTED,
timestamp seems wrong, too much in advance (current=1213920578, packet=1213631788, type=0)

which is kinda weird because packet->count_us - time_us = 1213631788-1213920578 = -288790, which is definitely not > TX_MAX_ADVANCE_DELAY. The error should be TOO_LATE, not TOO_EARLY.

I guess this is an overflow error.

[mcoracin]

Hello,

Here we handle a 32-bits rolling counter.
The rejection criteria are detailed in the jitqueue.c file:
https://github.com/Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/jitqueue.c#L224

TOO_LATE: happens when the packet time is before current time, but there is not enough time to program the downlink in the SX1301 buffer.

TOO_EARLY: the calculation on counter is unsigned arithmetic, so in your case (packet->count_us - time_us) does not equal -288790, but rather 4294678506. Which is definitely greater than TX_MAX_ADVANCE_DELAY. :)

It may be a bit confusing though. But anyway, the result is the same, downlink is rejected for a good reason.

[chrissnow]

Any reason not to just cast to int64 to fix this?

[mcoracin]

No, the main reason is the lack of time for all the testing necessary then when we change something in that part of the code. :)
But I keep that in mind to come back on this.
If you want to test it, don't hesitate to share a patch and your test results. :)

[rbaldwin13]

In an effort to improve our customer support experience and in recognition that our support backlog on GitHub has historically exceeded the capacity of our engineering team, we have taken the difficult decision to focus on the most contemporary issues reported and to close all others without confirmation of resolution.

Our belief is that issues which have remained unresolved and unaltered for extended periods of time are less likely to continue to pose a significant problem to the user than when they were originally filed. More contemporary issues however may still be relevant and hence are more appropriate to prioritize.

For those users who remain interested in resolution of a reported issue that was closed, we are encouraging usage of our developer portal forums [https://forum.lora-developers.semtech.com/] and commercial support portal [https://semtech.force.com/ldp/ldp_support?__hstc=212684107.579a13689e43099691e328c9248e6ecc.1623103335314.1624470656297.1624635514661.6&__hssc=212684107.6.1624635514661&__hsfp=4176385453] as the preferred avenues to receive support. We will continue to monitor the GitHub issue trackers as well, but want to encourage all users to take advantage of the increased community presence on the developer portal. For commercial customers, we highly recommend using the commercial support portal which is uniquely tailored to service such support requests.