when the emulator has received some data, don't just check that
we see it coming up on teh USB side, but actually also check
the content of those messages
We don't want the tc_etu to call into card_emu at all times,
e.g. while clock is applied, but RST is not yet present.
Rather, we want to explicitly enable it once RST is released
we cannot first chage the state and then transmit the byte
asynchronously later, this introduces race conditions. Do it
in-line by explicit calls to the UART Tx function.
* don't enter a state we are already in
* enable the UART receiver not only when waiting for CLA, but also
generally when we're waiting for more data from the reader
When the USB host software sets this flag, we terminate the
TPDU transmission after the last character in this frame and
transition again to the WAIT_TPDU state.
I couldn't help but to spend my sunday on working towards card
emulation, including
* various state machines in the target about ISO7816 states
* tc_etu timer import from simtrace1
* req_ctx import from simtrace1 (needs renaming and simplifiation)
* USB protocol description as cardemu_prot.h
* some host-based testing code to test the state machines
The code seems to work fine throughout card reset, sending ATR and
receiving the TPDU header of the first APDU, up to the point where it
marks the TPDU header as to-be-transmitted over th bulk-in endpoint.
Sending the ATR must be done inside the firmware for timing
requirements.
From that point onwards, the host needs to respond at the very least
with a procedure byte, and some indication whether or not the card
emulator should continue to transmit data (card->reader), or receive
data (reader->card).
The code is intentionally not hooked up yet with the USB logic nor with
the UART. I want host-based testing completed before doing that.
we shouldn't re-use the vendor/device ID usd by simtrace1, as the
protocol is incompatible and applications for simtrace 1 don't work with
simtrace2. Also, there's a different processor architecutre in the
hardware.
The host got stuck sometimes when large data frames had to be send
from the host program to SIMtrace. The printouts would just stop
if many large packets were received from the SIM card and needed
to be transferred to the mobile phone.
Increasing the buffer length removed the problem.
When the timeout was too small, the main function would infinitely
loop around, restarting the board and waiting for the USB interface
to get configured. But since configuration seems to take more than
one second, it rarely succeeded.
Increasing the timeout makes the USB configuration finish in the
first try.
Wait time extension commands are not implemented yet.
They are a nice-to-have for the future, since they would enable
the board to work with phones that expect a higher frequency.
With a wait time extension request towards the phone, SIMtrace could
signal the phone to wait for a longer time period while SIMtrace is
still waiting for a response from the SIM card.
Atmel library mixes up the value for two different messages.
Explanation can be found here:
http://permalink.gmane.org/gmane.comp.mobile.osmocom.simtrace/29
Actually, a better fix for this problem would be to go through the
Atmel code and replace ICC_INSERTED_EVENT with ICC_BS_PRESENT_NOTACTIVATED
where appropriate and in accordance with the Smart Card CCID standard
(and libccid, for this matter).
The code used a vendor and product id taken from Atmel example code.
Now it is changed to the vendor and product id, which was also previously
used in the original SIMtrace code.
Since the host side does the parsing of the packets, (not the firmware,
as it was in the old simtrace version), we do not need to check for expired
max waiting time.
Instead, every byte received from the phone is filled into a ring buffer.
As soon as the USB endpoint to the host is not busy anymore, it is sent
to the host over the respective USB endpoint.
