GetKISS+ 1.4.2: HTTP 400 when forwarding CUBEBEL-2 telemetry, but manual resubmission returns 201

Generic
1

Hi everyone,

I am using GetKISS+ v1.4.2 on Windows to forward CUBEBEL-2 telemetry (NORAD 57175) to the SatNOGS DB telemetry endpoint:

https://db.satnogs.org/api/telemetry/

The station source is CITEDEF, and GetKISS+ receives packets through a local TCP connection at 127.0.0.1:8100.

During the September 10 pass, I received these responses:

Submission time (UTC) Frame length HTTP response
11:59:40.450 216 bytes 201 Created
12:00:00.400 216 bytes 400 Bad Request
12:00:21.370 207 bytes 400 Bad Request
12:00:40.390 216 bytes 400 Bad Request

The 400 responses include Content-Type: application/json and Content-Length: 50, but I cannot see the JSON response body in the GetKISS+ logs. The Debug tab only shows the received frames.

I subsequently resubmitted the 12:00:00.400 frame using PowerShell, with the same original timestamp and form fields, and received 201 Created.

Windows uses Argentina local time (UTC−3), and the submitted timestamps are correctly converted to UTC, with a trailing Z. Clock synchronization accuracy has not yet been verified.

Does the API reject timestamps that are slightly ahead of server time? If so, what tolerance does it allow? Could this explain why a frame is rejected during live forwarding but accepted when resubmitted later?

Also, is there a way to view the complete HTTP error response in GetKISS+? Its display reports “HTTP POST OK: 4” while also showing three failures, so I am relying on the actual HTTP status codes.

I can provide the full request payloads and logs if useful.

Thanks for your help!

2

Thanks for the detailed report, from the logs indeed I can see that the frames were rejected, but unfortunately I’m not able to see why this happened.

The only recent change was checking if the timestamp is in the future, so maybe this is what triggers this response.

Currently there isn’t any tolerance, so whatever comes with a future timestamp it is rejected. However we may need to add some as it seems it creates some issues.

Let me check it and I’ll update you as soon as I have something.

3

:upside_down_face: Future, Just like what happens to me

4

I’ve added a setting in DB software, so now we will be able to tune tolerance for how far in future a frame timestamp should be in order to be acceptable. For now it is set to 1 second, so this should be enough for ntp synced servers/clients that have some minor networking issues.

The changes will be deployed in the next minutes, please continue to check if this will solve the issues.

Thanks again for reporting and the help for debugging this issue.

2 Likes
5

@LW2DTZ @LW2DYB

Is everything works fine now? Any other incidence?

6

All works fine! Thanks for your help.

7

All works fine! Thanks.