This is a bug and should be fixed:
The smartcard insertion detection does not work if we uncomment
the check. But on the other hand, pcscd detects a lot of erroneous
smartcard insertion and removal events.
The select command mostly works when the blue sysmocom SIM card is inserted,
but with the white SuperSIM we always get timeouts and invalid answers.
Furthermore the white card takes much longer to answer the requests than the
blue one.
So probably there is a timing issue.
Currently this is the simtrace output for select and reading IMSI, etc:
(pcscd must be running as welil, otherwise we get:
$ ./simtrace.py -S
Exception: Failed to establish context : Service not available.)
$ ./simtrace.py -S
Context established!
PCSC Readers: ['ATMEL AT91SO CCID Smart Card Reader [SIMtraceCCID] 00 00']
Using reader: ATMEL AT91SO CCID Smart Card Reader [SIMtraceCCID] 00 00
Connected with active protocol 1
Select: 0x6E 0x00
Command: 0x6D 0x00
Disconnected
Released context.
==> Expected answer for Select: 0x6D 0x00
(based on trying to execute this command with gemalto usb smart card reader)
The command works only every now and then
$ ./simtrace.py -b
pcsc: wait_for_card
Reading ...
Traceback (most recent call last):
File "./simtrace.py", line 105, in <module>
main()
File "./simtrace.py", line 66, in main
ccid.pySim_read()
File "/home/chrysh/ba_thesis/sysmocom_repo/usb_application/ccid.py", line 22, in pySim_read
(res, sw) = scc.read_binary(['3f00', '2fe2'])
File "/home/chrysh/code/src/pysim/pySim/commands.py", line 42, in read_binary
r = self.select_file(ef)
File "/home/chrysh/code/src/pysim/pySim/commands.py", line 35, in select_file
data, sw = self._tp.send_apdu_checksw("a0a4000002" + i)
File "/home/chrysh/code/src/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
RuntimeError: SW match failed ! Expected 9000 and got 9404.
==> Error code 9404 does not exist, which suggests that we actually have a timing issue when
communicating with the smart cart
Switching to config 1 and 2 works, but to 3 and 4 usb_enum.py is
hanging for some reason. Switching the USB config from Sniffer to
CCID reader was not tested yet.
It is possible to use sniffer.py to sniff the phone-simcard-communication.
To be fixed: The buffer size read is fixed and the data is only send
over USB if the buffer max length is reached. which means we don not
get the last bytes of the transaction.
This should be changed in one of the next commits. Maybe the former
simtrace code can give some inspiration on this topic.
In the standard atmel lib only one configuration was possible.
On a GETDESCRIPTOR request the board would always return the full buffer
with both configurations.
The USB driver requests each configuration one after another, using the
configuration index number.
The atmel lib did not support more than one USB configuration.
But only when you program the chip. At some point it stops printing
the received bytes because the interrupt is not triggered anymore.
I do not know yet how and why this happens.
Even after restarting the board this state is maintained.
CLK_SIM, I/O_SIM, CLK_PHONE, I/O_PHONE: Each of these lines connect
two pins of the microcontroller. Therefore they should NEVER be
configured as output line simultaneously. Otherwise the uC might get
destroyed.
Serial smartcard reader sends data which should be processed.
In the USART1 IRQ a status variable is set to show that data has
arrived, which should be checked for in the main function.
The second argument for PIO_Configure is the list size,
which can be determined using the macro PIO_LISTSIZE.
You should pass the list (which is an array of pins) to it.
Refrain from passing the ADDRESS of the list to it, otherwise
the pin configuration is never applied and you find yourself
debugging for 3 days.
In other words:
It's working, don't touch it or it will break again!
For now the inttypes.h of the development computer is used.
Which is a bad state. The reason is
It should be fixed by creating a stdint.h in the Baselib, which
defines types like uint32_t, etc., or by entirely replacing the Baselibs
with the newlib.
This was an example of a compiler warning when the switch -Waddress was passed:
atmel_softpack_libraries/usb/device/core/USBD.c: In function 'USBD_RequestHandler':
atmel_softpack_libraries/usb/device/core/USBD.c:149:14: warning: the address of
'USBDCallbacks_RequestReceived' will always evaluate as 'true' [-Waddress]
else if (USBDCallbacks_RequestReceived) {
The test for existense of USBDCallbacks_RequestReceived is removed since there
is always a default implementation of these function.
This was an example of a compiler warning when the switch -Waddress was passed:
atmel_softpack_libraries/usb/device/core/USBD.c: In function 'USBD_RequestHandler':
atmel_softpack_libraries/usb/device/core/USBD.c:149:14: warning: the address of
'USBDCallbacks_RequestReceived' will always evaluate as 'true' [-Waddress]
else if (USBDCallbacks_RequestReceived) {
The test for existense of USBDCallbacks_RequestReceived is removed since there
is always a default implementation of these function.
When the SIM card adapter, which is usually plugged into a phone,
is plugged into a CCID reader instead, the CCID reader triggers
the reset line of the RST line and therefore a PIO interrupt.
The reader then waits for an ATR from the smartcard,
which should be send next.
The return value of ISO7816_GetChar is 0 in case of a timeout
when trying to retrieve values, and status of US_CSR otherwise.
Proper handling of this return value is not yet implemented though.
With the naive approach of just not sending the ATR if it could not
be read the simtrace firmware did not work together with pcsc_scan
AT ALL.
Before this change pcsc_scan would always receive garbage
from the stack when the reset button was pressed on the
simtrace board. Because the return value of ISO7816_GetChar
is never checked anywhere. If there is a timeout in this function,
the non-initialized local variable values which happen to be
lying around on the stack are inserted into the ATR message
and send to the host.
This only helps mitigating the symptoms but does not remove
the reason for the behavior. On the other hand, is it really
feasable to check the return value on EVERY call to
ISO7816_GetChar..?
Currently the smartcard insertion interrupt is always triggered,
but when checking in PIO_ISR which pin triggered the interrupt
often times DTXD is returned (the debug transmit line which is printing
debug messages at the moment..)
I originally took the library files from https://github.com/zwizwa/simtrace
for cciddriver, etc.
Then I notices some things changed and between the AT91Lib for SAM7
and SAM3S I am using. Therefore I took the original files from the AT91Lib
which I downloaded for the SAM3S. Most lines only differ in comment convention.
Christina Quast