Change in osmo-remsim[master]: client: Work around "stock on PTS" problem

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

laforge gerrit-no-reply at lists.osmocom.org
Fri Feb 21 21:11:56 UTC 2020


laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-remsim/+/17243 )


Change subject: client: Work around "stock on PTS" problem
......................................................................

client: Work around "stock on PTS" problem

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
---
M src/client/simtrace2-remsim_client.c
1 file changed, 4 insertions(+), 2 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-remsim refs/changes/43/17243/1

diff --git a/src/client/simtrace2-remsim_client.c b/src/client/simtrace2-remsim_client.c
index 2929574..e495f10 100644
--- a/src/client/simtrace2-remsim_client.c
+++ b/src/client/simtrace2-remsim_client.c
@@ -1062,7 +1062,7 @@
 {
 	struct st_transport *transp = ci->slot->transp;
 	struct usb_interface_match _ifm, *ifm = &_ifm;
-	int rc;
+	int rc, i;
 
 	ifm->vendor = cfg->usb.vendor_id;
 	ifm->product = cfg->usb.product_id;
@@ -1163,7 +1163,9 @@
 	printf("Entering main loop\n");
 
 	allocate_and_submit_irq(ci);
-	allocate_and_submit_in(ci);
+	/* submit multiple IN URB in order to work around OS#4409 */
+	for (i = 0; i < 4; i++)
+		allocate_and_submit_in(ci);
 
 	while (!g_leave_main) {
 		osmo_select_main(false);

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-remsim/+/17243
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-remsim
Gerrit-Branch: master
Gerrit-Change-Id: I2fa5f71869b124b73e0c312befce1ca268e9a9a2
Gerrit-Change-Number: 17243
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge at osmocom.org>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200221/fbdbbf73/attachment.htm>


More information about the gerrit-log mailing list