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
If the server sends us ConfigClientBankReq with bankd_port == 0, then
this means that we shall disconnect from the bankd. Translate this to
the SRVC_E_DISCONNECT event towards the RSPRO connection FSM.
Change-Id: Idbfbfa0e84fa14dcb913b4dcbd943bc80ec175ac
Related: OS#4399
This is a remsim-client with an interactive 'shell', where the user
can type in C-APDUs in hex formats, which will be sent to the bankd /
SIM-card. Responses received from SIM Card via bankd will be printed
in return.
Change-Id: I636505fd9741833ccf5cbd1bcac30f7b9aa94425
There are some situations where remsim-client would want to make its
surrounding system aware of, e.g. to take specific action.
This is particularly important on platforms where the simtrace2 firmware
doesn't have direct control over modem reset/poweron or the like.
Change-Id: I61cf4d93c669db137de801f8b147dcffaa6f3abd
Depends: libosmocore.git Ib24ac8a083db32e55402ce496a5eabd8749cc888
Closes: OS#4332
While the user may have specified a USB path at the command line
(or not), let's make sure we obtain the actual path after opening
the respective USB device.
Change-Id: I7e707c74647f4c5db06d495d369b2e69e2fc7c97
Rather, pass it around between functions and attach it to other state.
Also, make it a talloc contxt so other objects can be allocated off it.
Change-Id: I25f592581382238d5640c1f6326dec745f8d1d40
When introducing asynchronous USB support in Change-Id
Ic18690b3c2cbc5e99de0665c0b68b7555433b3cd, we accidentially
broke the --keep-running behavior, where even a disappearing USB
device will not terminate the remsim-client process.
Change-Id: I19cca9f7953d61058a36856b2fc4c97a3b93e15d
As both the bankd and the server already are in src/bankd and
src/server, respectively: Let's unify this and have the client
also in its own sub-directory.
Change-Id: I67a3a5941434f09f7099c2cdb19c126cea305a73
Harald Welte