Harald Welte
38d990b0be
I can occasionally see osmo-remsim-client-st2 get stuck when the Modem (in this case a Quectel EC20) is performing PTS with the card. In the log of osmo-remsim-client-st2 I can see: SIMtrace => PTS req: ff 10 94 7b 00 00 SIMtrace -> 01 07 00 00 00 00 15 00 04 ff 10 94 7b 00 00 ff 10 94 7b SIMtrace => PTS req: ff 10 94 7b 00 00 SIMtrace IRQ 01 04 00 00 00 00 15 00 13 00 00 00 00 00 09 04 0a 80 25 00 00 after which the communication doesn't proceed. After a long time, the modem seems to retry without PTS and then proceeds with normal SIM card communication. Interestingly, both the firmware and a usbmon trace agree that the first APDU header after the PTS is actually sent in an USB IN transfer: -I- 0: computed Fi(1) Di(1) ratio: 372 -I- 0: computed Fi(9) Di(4) ratio: 64 -I- 0: send_tpdu_header: 00 a4 00 04 02 -I- 0: flush_rx_buffer (5) usbmon shows 010600000000130001000000050000a4000402 It's unclear why the host program doesn't get the data from the IN transfer. However, if multiple asynchronous IN EP URB are submited, the problem can be reproducibly avoided. Let's do that. Change-Id: I2fa5f71869b124b73e0c312befce1ca268e9a9a2 Closes: OS#4409 |
||
|---|---|---|
| .. | ||
| bankd | ||
| client | ||
| rspro | ||
| server | ||
| Makefile.am | ||
| asn1c_helpers.c | ||
| asn1c_helpers.h | ||
| debug.c | ||
| debug.h | ||
| rspro_client_fsm.c | ||
| rspro_client_fsm.h | ||
| rspro_util.c | ||
| rspro_util.h | ||
| slotmap.c | ||
| slotmap.h | ||