Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix #3347 by implementing a read loop until all file bytes are read. #3349

Closed
wants to merge 4 commits into from

Conversation

ke6jjj
Copy link
Contributor

@ke6jjj ke6jjj commented Jan 8, 2024

What's new

This fixes #3347 by implementing a read loop which reads the file bit by bit until completed.

Verification

Tested with a Mifare DESFire card which exhibited the initial issue.

Checklist (For Reviewer)

  • PR has description of feature/bug or link to Confluence/Jira task
  • Description contains actions to verify feature/bugfix
  • I've built this code, uploaded it to the device and verified feature/bugfix

@ke6jjj
Copy link
Contributor Author

ke6jjj commented Jan 8, 2024

This issue likely also exists in the "read file value" and "read file records" code paths. I've only fixed the "read normal file" path.

@gornekich gornekich self-assigned this Jan 9, 2024
@gornekich gornekich added the NFC NFC-related label Jan 9, 2024
Fix an off-by-one bug which drops DESFire responses which are
actually perfectly fine. The bug occurs due to the fact that the
response handling code forgets to discount the "MF_DESFIRE_FLAG_HAS_NEXT"
byte at the front of all continued reponses, and thus, determines
that the reponse is too big (by one byte).
Update the file read loop to size its read requests perfectly for
the receive buffer, rather than banging its head repeatedly against
the wall in the receive handler by dropping incoming responses.
@ke6jjj
Copy link
Contributor Author

ke6jjj commented Jan 10, 2024

As noted in #3347, I've pushed in some more fixes to this PR.

One fixes an off-by-one counting bug which was causing received responses to be thrown away when they actually were perfectly fine.

The other is a change to the file read polling loop such that it requests no more bytes than can actually fit into the receive buffer.

@@ -301,24 +303,35 @@ MfDesfireError mf_desfire_poller_read_file_data(
size_t size,
MfDesfireFileData* data) {
furi_assert(instance);
size_t cur_offset, read_size, num_read;
MfDesfireError error;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compiler thinks that we might not get into for loop, where we update error variable. Please, initialize this variable here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem. I'll look at it this week.

@skotopes skotopes marked this pull request as draft January 16, 2024 06:32
@skotopes
Copy link
Member

Un-draft when ready

@gornekich
Copy link
Member

Fixed arrive in dev

@gornekich gornekich closed this May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NFC NFC-related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

NFC: Files from DESFire cards appear truncated; more reads may be necessary
3 participants