osmo_apdu_segment_in() doesn't have the context of the previous APDU,
for nearly all calls this is fine, except for GP GET DATA, which can be
a case 2 or case 4 APDU.
GP GET DATA defines the Le field as 0x00 which is used by osmo_apdu_segment_in
to detect if it is a case 2 or case 4.
However a card can respond with the SW 6cXX, which means the previous
command must be resend with a Le field XX, which got misinterpreted by
the osmo_apdu_segment_in() as a case 4 resulting in a timeout waiting for
more data.
Modem <-> Card
81cadf2000 ->
<- 6c0b
81cadf200b ->
-- Simtrace waits for more data because it wrongly decodes it as APDU case 4
instead of case 2.
Related: SYS#8147
Change-Id: Ie238662e7e6a10dd4283ede0c8d8d73bc375c247
Add api call osmo_st2_cardem_request_config2(struct cardemu_usb_msg_config *)
which contains a full cardemu_usb_msg_config.
Related: SYS#6946
Change-Id: Iacde63e667472a85a5f18cb4ca99dcfa1a84dd59
The sim presence pin allows the simtrace2 to inform the modem
about the presence of the simcard. On a generic simcard slot a
button is pressed by the simcard which generate a high or low voltage level.
Even though there are specifications of minipcie or ngff defining this signal, certain
modems behave different.
Certain modems require different signals from the specification.
Extend the usb protocol to set the behaviour at runtime.
Related: SYS#6946
Change-Id: I77118114ba873fdf0778137402888b40f2442456
libosmo-simtrace2 traditionally had only supported blocking, synchronous
I/O, while other osmocom programs such as remsim-client used
asynchronous USB I/O.
Using async USB I/O for IRQ + IN transfers while using blocking I/O for
OUT transfers doesn't seem to work reliably, so we have to offer a way
to perform the OUT transfers generated within libosmo-simtrace2 in async
mode.
Change-Id: Ib8939bdb7f533cd20a34a30a97f12b782b9816c2
Alexander Couzens