Only send Prompt Naks if were in UNACKNOWLEDGED and send EOF every time we send missing segments

[Firedorange717]

No description provided.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.86%. Comparing base (f162e44) to head (7b94038).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #68      +/-   ##
==========================================
+ Coverage   92.54%   92.86%   +0.32%     
==========================================
  Files          17       17              
  Lines        4613     4600      -13     
==========================================
+ Hits         4269     4272       +3     
+ Misses        344      328      -16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mkolopanis]

Hey I'm actually a bit confused by the changes that are being requested here. Prompt PDUs are explicitly for acknowledged mode transmissions in the cfdp standard.

Additionally what is the motivation for re-sending EoF after the Nak is drained? I cannot find a place in the standard definition that requests this (though it's not forbidden too).

[Firedorange717]

Hey Matt, This is aimed at fixing a issue that has been plaguing SPARCS PLP -> XB1 transfers where they would not complete on the BUS. As you are aware the BCT/XB1 CFDP implementation does not exactly follow the CFDP standard, BCT based the BUS CFDP engine off of CCSDS CFDP Book 4, but it very loosely follows and only partially implements things, as well as their own "Tailoring" as they call them. I cant share it here but if you still have access to it Please have a look at the BCT CFDP Manual for the BUS 01DOC0100_BCT_CFDP_manual_rev_e.pdf

Transfers from the PLP to the XB1 are done in Acknowledged mode if you look at page 23 section 5.6.2 it explains the payload to BUS (PLP -> XB1) Handshake that the BUS is expecting.

The CURRENT way this transfer was going is incorrect and like so.

1. Ground Sends Proxy Put for a PLP -> XB1 transfer
2. PLP creates a new transaction for the PLP -> XB1 transfer and sends Metadata PDU, then FileData PDU's, then EOF PDU
3. The XB1 when it receives the EOF PDU attempts to finish the file and if so Sends a Empty NAK signaling its Done(One of the BCT Tailorings)
4. IF SEGMENTS ARE MISSING in BCT Acknowledge mode, the XB1 will send a NAK with missing segments automatically to the PLP
5. PLP then sends missing FileData PDU's back to the XB1
6. PLP then sends a Prompt NAK to XB1 (THIS IS THE PROBLEMATIC STEP) (IN BCT ACKNOWLEDGED MODE WE NEED TO SEND MISSING SEGMENTS THEN A EOF PDU AGAIN) (NOT A PROMPT NAK)
7. If the XB1 has all the pieces after getting the PROMPT NAK it sends the PLP a Empty NAK and the PLP sees this and signals itself its complete.
8. The XB1 is still waiting for the EOF and the transaction never finishes on the BUS

The PROPER BCT WAY (And yes this goes against the standard)

1. Ground Sends Proxy Put for a PLP -> XB1 transfer
2. PLP creates a new transaction for the PLP -> XB1 transfer and sends Metadata PDU, then FileData PDU's, then EOF PDU
3. The XB1 when it receives the EOF PDU attempts to finish the file and if so Sends a Empty NAK signaling its Done(One of the BCT Tailorings)
4. IF SEGMENTS ARE MISSING in BCT Acknowledge mode, the XB1 will send a NAK with missing segments automatically to the PLP
5. PLP then sends missing FileData PDU's back to the XB1
6. PLP then sends a EOF PDU again after retransmitting the missing pieces
7. If the XB1 has all the pieces after getting the EOF it will Automatically Send back a EMPTY NAK
8. The PLP gets the Empty NAK and finishes the transaction on its side and the XB1 automatically closes the transaction on the BUS side and everything is good.

So what i have done is change the behavior from the standard to work with the BCT implementation. In BCT CFDP prompts are only for UNACKNOWLEDGED Mode as the BUS will not send NAKs automatically. as well as making the PLP CFDP engine send the EOF again after retransmitting Missing segments.

I am aware that this CFDP-RS is used for both the ground and the PLP, perhaps instead of merging this into MAIN we make a new PLP branch only for the PLP CFDP Engine, and leave the Ground CFDP implementation alone since the Ground -> PLP Follow the standard CFDP implementation, but the PLP->XB1 CFDP transfers have to have special cases.

This is something that i woud like your insight @mkolopanis would be very helpful in since you wrote most of it.

[Firedorange717]

Actually this change is needed to even upload the new CFDP Binary to the XB1 because the ground CFDP engine has the same as the PLP so this should go into main so they both pull the fix.

[mkolopanis]

Sorry been a bit swamped with work over here. I can definitely understand the need to make things work with the custom cfdp implementation from bct. Maybe it is finally the time for sparcs to have it's own branch of this repo or fork. So we can differentiate the standard implementation with a mission specific tailoring

…

-------- Original Message --------

On Wednesday, 05/13/26 at 21:20 Joshua Kantarges ***@***.***> wrote: Firedorange717 left a comment [(ASU-cubesat/cfdp-rs#68)](#68 (comment)) Actually this change is needed to even upload the new CFDP Binary to the XB1 because the ground CFDP engine has the same as the PLP so this should go into main so they both pull the fix. — Reply to this email directly, [view it on GitHub](#68 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ACB7BLMSJMI5W4RBAG7R2ID42TKHHAVCNFSM6AAAAACYZORCSKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DINBUHA4TOOBQHA). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub). You are receiving this because you were mentioned.Message ID: ***@***.***>