ftp: use global sequence counter to prevent stale response loops#2760
Merged
ftp: use global sequence counter to prevent stale response loops#2760
Conversation
PX4's FTP server caches its last reply and uses seq+1 matching to detect retransmissions. When the client's seq counter reset to 0 for each new work item, PX4 would match against its cached reply and resend the old response instead of processing the new request. This caused sequential operations to time out. Move last_sent_seq_number from per-work-item to class-level so seq numbers increase monotonically. Also increment seq on retries so the client can escape stale cached replies from previous sessions.
d9272f4 to
7be02f9
Compare
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



PX4's FTP server caches its last reply and uses seq+1 matching to detect retransmissions. When the client's seq counter reset to 0 for each new work item, PX4 would match against its cached reply and resend the old response instead of processing the new request. This caused sequential operations to time out.
Move last_sent_seq_number from per-work-item to class-level so seq numbers increase monotonically. Also increment seq on retries so the client can escape stale cached replies from previous sessions.