Project

General

Profile

Actions

Bug #5285

open

Multislot simultaneous acces sometimes fails with the CCID error 0xFE "Card absent or mute"

Added by rousseau about 1 month ago. Updated 11 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Start date:
10/29/2021
Due date:
% Done:

0%

Spec Reference:

Description

I am working on adding support of concurrent multi slot access in my CCID driver.
It is now possible to handle 2 APDUs on 2 slots at the same time.

I note that, sometimes, the sysmoOCTSIM reader reports the CCID error 0xFE "Card absent or mute".
My setup is 1 sysmoOCTSIM and 3 SIM cards in the first 3 reader slots.
The SIM cards are sysmoUSIM-SJS1.

I used the Python script usim_read.py presented in https://ludovicrousseau.blogspot.com/2021/02/reading-sim-card-phone-book-in-python.html
My test is to read the phone book from the SIM cards.
To preform parallel accesses I use the Makefile presented in https://ludovicrousseau.blogspot.com/2021/03/accessing-lot-of-smart-cards.html

The problem occurs for slot 1 or 2, never for slot 0.
So I exchanged the cards from slot 0 and 1. But the problem is still present only in slots 1 et 2. So the SIM card should not be the source of problem.
I then used slots 1, 2 and 3 and let the slot 0 empty. In this case the problem occurs in slot 2 and 3 and never in slot 1.
It looks like the first slot with a card has no problem. But the next slots may report this 0xFE error.

I do not have a hardware spy to know why the communication between the card and the reader fails.
My setup is easy to reproduce. I can configure it on your end if I have access to a computer connected to a sysmoOCTSIM and 2 sysmoUSIM-SJS1 SIM cards in the reader.

I attach 2 log files:
  • log.txt is a pcscd log with all debug messages
  • log_CCID.txt contains only the CCID frames

The error frame is:

000001 80 00 00 00 00 01 12 41 FE 00


Files

log.txt log.txt 139 KB rousseau, 10/29/2021 09:26 AM
log_CCID.txt log_CCID.txt 12.8 KB rousseau, 10/29/2021 09:26 AM
sysmoOCTSIM-0.2.71-ebfc-dirty.bin sysmoOCTSIM-0.2.71-ebfc-dirty.bin 70.2 KB fake setparameters response, no actual PSS exchange Hoernchen, 11/27/2021 11:42 AM
sysmoOCTSIM-0.2.71-ebfc-dirty.bin sysmoOCTSIM-0.2.71-ebfc-dirty.bin 70.2 KB fixed slot status irq msg Hoernchen, 11/27/2021 02:37 PM
Actions #1

Updated by rousseau about 1 month ago

I am using the latest firmware 0.2.67-30c2

Actions #2

Updated by laforge about 1 month ago

  • Assignee set to Hoernchen
Actions #3

Updated by laforge about 1 month ago

This is surprising as we did do a lot of parallel slot CCID stress testing of all the slots during R&D. We were using TTCN3 based tests, as far as I recall. Note that I'm not contesting your findings, I'm just surprised that we didn't see that in our CCID tests in the psat.

Actions #4

Updated by rousseau about 1 month ago

I am also surprised.
It is easy for me to reproduce with my sysmoOCTSIM.

I propose to configure a setup on your side so you can investigate what is happening between the reader and the card to generate the error. I do not have the hardware to spy the reader/card communication.

Actions #5

Updated by rousseau about 1 month ago

It is not always the first slot that does not fail and continue to work.
In a new test I used slots 0, 1 and 2. Slot 1 failed first, then slot 0.

I suspect a problem with the power supply of my sysmoOCTSIM.
I note that when I connect the power cable no LED blinks. I think it was the case before but I am not sure.
Also there is a 9th LED on the left of the first slot. This LED is never ON. I don't remember if the LED was ON before.
What is this LED used for?

I also got kernel errors and a non-responsive reader.
For example while disconnecting and reconnecting the reader I got

[ 1150.312814] usb 1-1: new full-speed USB device number 34 using xhci_hcd
[ 1150.441087] usb 1-1: device descriptor read/64, error -71
[ 1150.676797] usb 1-1: device descriptor read/64, error -71
[ 1150.912863] usb 1-1: new full-speed USB device number 35 using xhci_hcd
[ 1151.041093] usb 1-1: device descriptor read/64, error -71
[ 1151.276807] usb 1-1: device descriptor read/64, error -71
[ 1151.384860] usb usb1-port1: attempt power cycle
[ 1151.796895] usb 1-1: new full-speed USB device number 36 using xhci_hcd
[ 1151.797145] usb 1-1: Device not responding to setup address.
[ 1152.004969] usb 1-1: Device not responding to setup address.
[ 1152.212893] usb 1-1: device not accepting address 36, error -71
[ 1152.341157] usb 1-1: new full-speed USB device number 37 using xhci_hcd
[ 1152.341382] usb 1-1: Device not responding to setup address.
[ 1152.549045] usb 1-1: Device not responding to setup address.
[ 1152.757106] usb 1-1: device not accepting address 37, error -71
[ 1152.757234] usb usb1-port1: unable to enumerate USB device
[ 1169.513165] usb 1-1: new full-speed USB device number 38 using xhci_hcd
[ 1184.917783] usb 1-1: device descriptor read/64, error -110
[ 1202.881847] usb 1-1: new full-speed USB device number 39 using xhci_hcd
[ 1218.458303] usb 1-1: device descriptor read/64, error -110
[ 1234.070537] usb 1-1: device descriptor read/64, error -110
[ 1234.306230] usb 1-1: new full-speed USB device number 40 using xhci_hcd
[ 1249.686428] usb 1-1: device descriptor read/64, error -110
[ 1262.558462] usb 1-1: new full-speed USB device number 41 using xhci_hcd
[ 1262.708678] usb 1-1: New USB device found, idVendor=1d50, idProduct=6141, bcdDevice= 0.00
[ 1262.708683] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[ 1262.708687] usb 1-1: Product: sysmoOCTSIM 0.2.67-30c2
[ 1262.708689] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[ 1262.708691] usb 1-1: SerialNumber: df4be7f03335355320202034433b15ff
[ 1262.711970] cdc_acm 1-1:1.1: ttyACM0: USB ACM device

I also note that I can use the reader if I connect only the USB cable but not the power cable.
I can communicate with 1 card with no problem.
If I try to use 2 cards it works and then I get the error I described above: the reader returns FE for one slot.
It is not surprising if the reader has not enough power to use 2 cards at the same time.

How can I check the power supply I use is working correctly?
I am not a electronic guy. I have no voltmeter for example. Sorry.

Actions #6

Updated by Hoernchen about 1 month ago

In practice the external PSU is not really required, it is only necessary in case you use all 8 slots with a worst case per-sim power draw of 120mA or something like that, but even in that case most host ports (not switchable OTG!) will silently deliver much more current and don't even complain about it. It mostly exists to be USB spec compliant. For 2 sim cards USB should be enough, there is no way that can exceed the 500mA, because even in short circuit conditions the sim driver chip will just switch off the slot power.

Actions #7

Updated by roh about 1 month ago

can you please replace the usb-cable and retry? i've seen similar issues with different boards which were only a broken cable.

Actions #8

Updated by laforge about 1 month ago

roh can you please check the expected LED behavior when only the PSU is connected?

We can certainly ship another power supply to Ludovic, if this is the problem.

rousseau, if you meanwhile have any other power supply with 5V and > 500mA with a matching connector (center plus, but this is standard these days), feel free to give it a try.

Actions #9

Updated by roh about 1 month ago

i just checked with firmware from today and latest bootloader:

with only the psu connected it doesn't matter at all and the led stays off. only a small green led on the pcb (not visible with case) is on.

when the button was kept pressed while power was plugged (usb or external) the device is in the dfu-loader. as soon as the usb gets enumerated the led goes green in case we are in the bootloader.

the behavior of this led is completely fw controlled, so i guess Hoernchen can tell us more details.

Actions #10

Updated by rousseau about 1 month ago

I have power supply units with the "possibly" good connector but they deliver 10V or 12V.
I don't think that is a good idea to connect them to the sysmoOCTSIM :-)

I have a PSU for 5V but the connector is miro-USB (I used it to power a Raspberry Pi).

I think I have other USB cables to replace the current one and make new tests. I will add my results here.

PS: sorry for the delay. I do not get any email notification when the ticket is updated. I don't know it that is expected.

Actions #11

Updated by laforge about 1 month ago

Dear Ludovic,

On Fri, Nov 05, 2021 at 03:19:24PM +0000, rousseau wrote:

I have power supply units with the "possibly" good connector but they deliver 10V or 12V.
I don't think that is a good idea to connect them to the sysmoOCTSIM :-)

no, that's not a good idea.

I think I have other USB cables to replace the current one and make new tests. I will add my results here.

I think it's best to wait with any further development activity until sysmocom has investigated
this further. We are extremely overloaded, but I would have expected Hoernchen to be
able to comment at least once on this issue within 7 days.

PS: sorry for the delay. I do not get any email notification when the ticket is updated. I don't know it that is expected.

Hi Ludovic,

it is because your ISP considers those notifications as spam and rejects them. See below
line from our mail server log.

Nov 5 15:19:25 lists postfix/smtp57415: 9F7E2216782: to=<>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.59, delays=0.27/0.01/0.22/0.1, dsn=5.0.0, status=bounced (host mx1.free.fr[212.27.48.7] said: 550 spam detected (in reply to end of DATA command))

maybe you can configure something in the user interface of this ISP to prevent it from
treating osmocom redmine notifications as spam.

Actions #12

Updated by Hoernchen about 1 month ago

Sorry about the lack of a response, I was left with the impression that there were weird PSU issues that obviously need to be solved first before we take a closer look.

Actions #13

Updated by laforge about 1 month ago

  • Status changed from New to Stalled
  • Assignee changed from Hoernchen to rousseau

to exclude any power supply related porblems, sysmocom will send you another power supply and also a USB miniB-A cable. The shipment should leave sysmocom tuedsay next week, so it will probably arrive at the end of next week.

Feel free to postpone any furthe work related to the sysmOCTSIM until then.

Actions #14

Updated by rousseau about 1 month ago

I tried with a different USB cable and I have the same problem.

I modified the CCID driver to disable the support of simultaneous CCID commands. In this case I do NOT reproduce the problem. I used 3 cards and run my program to access the 3 cards at the "same time". pcscd uses a lock to serialize the accesses so the performances are not good but I do not have the "Card absent or mute" error from the sysmoOCTSIM reader.

I think it would help if you could configure a setup with one sysmoOCTSIM and 2 or 3 cards on your side.
If I can reproduce the problem then my PSU or USB cable is not at fault. And you will have everything you need to analyze the problem on your side.

Actions #15

Updated by rousseau about 1 month ago

Just to be sure I also tried to connect the sysmoOCTSIM to a desktop computer instead of a laptop.
The desktop should provide enough power to the USB interface.

I can still reproduce the problem.
Connecting or not the PSU to the sysmoOCTSIM does not change the result.

Actions #16

Updated by rousseau 23 days ago

I received the new USB cable and PSU.
I tried with the new USB cable (and no PSU connected) and I have the same problem.
I tried with the new USB cable and the new PSU and I also have the same problem.

It looks like the USB cable and the PSU are NOT the cause of the problem.

I really think it would help if it is possible to reproduce the problem on your side. You will then have everything to work on the issue.

Actions #17

Updated by Hoernchen 21 days ago

Oh, sorry, I missed your update because I was for some reason not added as a watcher..
It's fine, I'll take a look at it now - I've debugged plenty of "weird" issues recently, so it was important to make sure that it was not the PSU/cable first.

Actions #18

Updated by rousseau 20 days ago

  • Assignee changed from rousseau to Hoernchen

Hoernchen, do not hesitate to ask me to test new firmware versions if you think you found and fixed the problem.

Actions #19

Updated by Hoernchen 20 days ago

  • Status changed from Stalled to In Progress

I've managed to reproduce the issue, and I'm now trying to figure out what's wrong.

Actions #20

Updated by Hoernchen 11 days ago

Hi Ludovic,
I've built a firmware that bypasses the issue by secretly "ignoring" the ccid parameters, so it will respond and pretend that everyhing is ok, but not actually do a PPS exchange with the card and will not apply those settings. That should be enough to allow you to continue working on it. I think I've also fixed a rare usb issue upon start.

Actions #21

Updated by rousseau 11 days ago

Good news. I can't reproduce the problem with this new firmware.
I checked with 3 SIMs at the same time and the total time to dump 1, 2 or 3 SIM is always 24 seconds. So the driver is really talking to the 3 slots at the same time (in parallel).

I don't know why you modified the PPS handling. Now the communication is very slow. We moved from 5 seconds to 24 seconds to dump a SIM card.

Actions #22

Updated by Hoernchen 11 days ago

This is a workaround for you, so you can look at concurrent access - the problem was related to higher baud rates, and this obviously is not a proper fix, just something that allows you to keep working on the pcscd concurrency topic for now without any weird errors.
In practice the baud rate is not that important anyway, because the long running commands like "run gsm algo"/response keep a slot busy for quite some time, and that is not related to the baud rate at all.

By the way, does the new pcscd allow accessing slots that are powered while other slots are still unpowered/trying different voltages (might be unresponsive, broken, empty sim card holder, ...)?

Actions #23

Updated by rousseau 11 days ago

The new firmware sysmoOCTSIM-0.2.71-ebfc-dirty.bin reports a card present with PC_to_RDR_GetSlotStatus even if no card is inserted in the slot.
This was not the case with the previous firmware.
It is a regression. I don't know if you did it on purpose.

To answer your question: every slot is independent. So yes, it is possible to access a slot while another one is doing something else like power on or power off, etc.

Actions #24

Updated by Hoernchen 11 days ago

You're right, I just broke that because I was eager to give you a working version and didn't even test it with less than 8 cards, I've fixed it in the attached fw version.

Actions #25

Updated by rousseau 11 days ago

The card presence is now working as expected with the latest firmware.

Now improve the communication speed as it was before and I am happy :-)

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)