Wow! That bug was insidious.
What if a six character call sign adds /R?
Longer and a special character.
Bob
On Sep 18, 2023, at 9:12 AM, Burns Fisher (AMSAT) via pacsat-dev pacsat-dev@amsat.org wrote:
Good catch! 73,
Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software
On Mon, Sep 18, 2023 at 10:09 AM Chris Thompson via pacsat-dev <pacsat-dev@amsat.orgmailto:pacsat-dev@amsat.org> wrote: I found a serious flaw in the upload code. I documented it in github but will paste the description below: https://github.com/AMSAT-NA/PacSatSW/issues/24
If the user of the ground station has a 6 digit (or longer) callsign and they upload a file then the PACSAT header is corrupted. Specifically the length byte of the upload_time field (number 0x12) is corrupted and likely all the bytes of the header from that point are wrong. The header is added successfully to the directory and can be downloaded. When the header is re-downloaded the ground station throws the header away as corrupted but then keeps requesting the "hole" in the directory.
If the IHU is reset then the header is found to be corrupt and is not re-loaded into the directory, but the directory at the ground station still has a hole and it does not resolve itself by requesting the hole from the spacecraft. There are no files in that date range to close the hole.
The bug appears to be in the spacecraft because the uploaded file saved at the ground station appears to have the correct header. The bug is likely because the upload_time field is updated at a fixed offset but we have a different length callsign. In fact the sender is in field (0x10) and can be up to 30 chars. Oops! All the other fields that are updated in place are in the fixed length initial header bytes. But not this one. It was later made mandatory and never moved into the mandatory header by the protocol designers.
There is also a second bug here. When the sat is rebooted and the corrupt file is rejected, then the ground station should be able to close its hole. It should request the directory and get an updated header for the header before the corrupted file, with the new and old dates that close out the hole. That requires the upload_time on the adjacent header to be changed otherwise it won't be broadcast. We already update at boot the new and old dates. We would have to see that there is a corrupt file and then update the upload_time on the adjacent header.
There is also a third bug here. When the header was updated with the upload_time we did not see that it was corrupted. We do run a check on uploaded file headers but apparently that runs before we update the upload_time. If it had run after the upload_time was updated then it would have rejected the header and the directory would not have been corrupted.
-- Chris E. Thompson chrisethompson@gmail.commailto:chrisethompson@gmail.com g0kla@arrl.netmailto:g0kla@arrl.net
-----------------------------------------------------------
pacsat-dev mailing list -- pacsat-dev@amsat.orgmailto:pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.orgmailto:pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
-----------------------------------------------------------
pacsat-dev mailing list -- pacsat-dev@amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave@amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org