Fix the processing of apdus across multiple sources #451
Conversation
yrichard-ledger
force-pushed
the
fix_apdu_media
branch
from
10ce7f4
to
c704112
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #451 +/- ##
=======================================
Coverage 60.42% 60.42%
=======================================
Files 12 12
Lines 1660 1660
=======================================
Hits 1003 1003
Misses 657 657
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
@yrichard-ledger did you manage the case where we receive a new APDU (via BLE) when still processing the previous APDU (no answer provided) received also via BLE ? |
Yes, whatever the media, if we receive a new APDU while the previous apdu is still processing the SDK will reply with SWO_IOL_STA_02 (0x1302) |
When two apdus are received in parallel: * The first one is not impacted by the second one * The second one receives an error response SWO_IOL_STA_02 (0x1302)
yrichard-ledger
force-pushed
the
fix_apdu_media
branch
from
c704112
to
a89f7d0
Compare
Description
This PR fixes edge cases when several apdus are sent to the device from different media.
The expected behaviour when two apdus are received in parallel is now:
* The first apdu processing is not impacted by the second one
* The second apdu is not processed and the device replies with an error SWO_IOL_STA_02 (0x1302)
This PR also adds a set of functions so that an application can restrict the apdu source to a single media.
This is intended to lock the media during a complex flow of apdus. In particular during an app installation
we can now reject automatically apdus from other medias
Changes include