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 35.76% 35.76%
=======================================
Files 13 13
Lines 1591 1591
=======================================
Hits 569 569
Misses 1022 1022
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) |
yrichard-ledger
force-pushed
the
fix_apdu_media
branch
from
c704112
to
a89f7d0
Compare
|
@yrichard-ledger as discussed, could we revisit this topic? I realize that we had already encountered some problematic cases with the BT here. |
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
a89f7d0
to
af90253
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