30 Jan
2011
30 Jan
'11
11:05 p.m.
hi,
I'll be listing some issues I found in SIMtrace.
This is to warn future users.
I don't have time now, but I intend to work on this project in 1 or 2
weeks and correct these bugs.
1. when starting host program simtrace, the firmware will first return
ATR. This is an error if simtrace is started after the card has been
reseted. The program should use the state of the reset and vcc lines to
know the state.
2. when using a usb hub, having a lot of USB traffic, or poor USB signal
quality (I don't know exactly), bulk read timeouts can occur in host program
simtrace/at91sam7/host/main.c line 230:
rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000);
rc is -110 (REQUEST_TIMEOUT). I increased the timeout (100000) so to
have less errors (but they still occur), and I ignore this error instead
of exiting (tracing still works).
3. it seems simtrace can loose track of the I/O stream after some
traffic. see pcsc_apdu.log to see the original, and simtrace_apdu.log
for the captured traffic.
in the end, simtrace misses:
APDU: A0 C0 00 00 0F
and does a wrong following APDU parsing
The problem occurs when using a OmniKey CardMan 5321 and Alcor Micro
AU9520. Thus the reader should not be the origin.
Also, if only the command where the error occurs is sent, no bytes are
skipped. But another error occurs (see next bug)
4. when executing only the last commands, then it is wrongly interpreted
(as ATR), but no bytes are skipped
ATR (12): 3b 0a 41 00 3f 43 00 01 50 29 01 02
ATR (66): a0 a4 00 00 02 a4 7f 20 9f 17 a0 a4 00 00 02 a4 6f ad 9f 0f
a0 c0 00 00 0f c0 00 00 00 03 6f ad 04 00 04 f0 44 01 02 00 00 90 00 a0
b0 00 00 03 b0 00 00 00 90 00 3b 0a 41 00 3f 43 00 01 50 29 01 02
I already wrote a SIM traffic parser for the PC before simtrace
appeared. I used a logic analyzer to record the traffic.
I will integrate the ATR and APDU parsing/checking into the simtrace
firmware. Wrong recorded traffic will be discarded instead of affecting
the rest of the parsing.
thanks,
kevin
31 Jan
31 Jan
4:08 p.m.
Hi Kevin,
On Sun, Jan 30, 2011 at 11:05:59PM +0100, tsaitgaist wrote:
I'll be listing some issues I found in SIMtrace.
This is to warn future users.
I don't have time now, but I intend to work on this project in 1 or 2
weeks and correct these bugs.
1. when starting host program simtrace, the firmware will first return
ATR. This is an error if simtrace is started after the card has been
reseted. The program should use the state of the reset and vcc lines to
know the state.
this is unfortunately not possible. You _have_ to start your phone
after you have started simtrace. Otherwise we would not observe PPS
and thus not know which bit/baud rates to use.
2. when using a usb hub, having a lot of USB traffic,
or poor USB signal
quality (I don't know exactly), bulk read timeouts can occur in host program
simtrace/at91sam7/host/main.c line 230:
rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000);
ok, interesting. I think its not really something we need to care about,
if it works reliably using good cables/hubs.
I already wrote a SIM traffic parser for the PC before
simtrace
appeared. I used a logic analyzer to record the traffic.
I will integrate the ATR and APDU parsing/checking into the simtrace
firmware. Wrong recorded traffic will be discarded instead of affecting
the rest of the parsing.
ok, great. I'm looking forward to any contributions / bug fixes. Thanks
a lot!
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4:46 p.m.
Harald Welte wrote:
The issue is probably with the fact that bulk transfers are used for
the data.
Bulk transfers have no bound latency, they will be delivered "as soon
as possible" but this can very well mean indefinite delay on a loaded
bus. Interrupt transfers and isochronous transfer both have
guaranteed bus time, the latter are lossy (think UDP) so I'd suggest
using interrupt transfer if there's a choice.
Programmatically they work very much like bulk so switching over
should be simple.
Oh, and in host programs please don't use the old libusb-0.1 API with
usb_ functions as it has been deprecated and unmaintained for years,
please start using the libusb-1.0 API with libusb_ functions instead;
it fixes bugs, has better performance and is actually being worked
on. :)
//Peter
2. when using
a usb hub, having a lot of USB traffic, or poor USB
signal quality (I don't know exactly), bulk read timeouts can
occur in host program simtrace/at91sam7/host/main.c line 230:
rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000);
ok, interesting. I think its not really something we need to care
about, if it works reliably using good cables/hubs.
2 Feb
2 Feb
8:52 a.m.
Peter,
On Mon, Jan 31, 2011 at 04:46:32PM +0100, Peter Stuge wrote:
Harald Welte wrote:
The issue is probably with the fact that bulk transfers are used for
the data.
Bulk transfers have no bound latency, they will be delivered "as soon
as possible" but this can very well mean indefinite delay on a loaded
bus. Interrupt transfers and isochronous transfer both have
guaranteed bus time, the latter are lossy (think UDP) so I'd suggest
using interrupt transfer if there's a choice.
IIRC interrupt transfers had a size limit, though. The other issue I've
had in a number of projects is that libusb only provides a synchronous
interface, and it is impossible (without custom additional code) to
receive from both a bulk and and interrupt endpoint at the same time.
This is not really an issue with SIMTRACE, but it has made me avoid interrupt
endpoints at all cost when using libusb.
2. when
using a usb hub, having a lot of USB traffic, or poor USB
signal quality (I don't know exactly), bulk read timeouts can
occur in host program simtrace/at91sam7/host/main.c line 230:
rc = usb_bulk_read(udev, SIMTRACE_IN_EP, buf, sizeof(buf), 100000);
ok, interesting. I think its not really something we need to care
about, if it works reliably using good cables/hubs. Programmatically they work very much like bulk so
switching over
should be simple.
yes, it should be simple.
Oh, and in host programs please don't use the old
libusb-0.1 API with
usb_ functions as it has been deprecated and unmaintained for years,
please start using the libusb-1.0 API with libusb_ functions instead;
it fixes bugs, has better performance and is actually being worked
on. :)
I'm happy for anyone who has time to update the program. I'm only familiar
with the old API and have thus used it again to quickly get something going.
the entire simtrace stuff was just a quick hack to debug STK stuff, where the
latter being the 'real' work that needed to be done.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
4847
days inactive
4850
days old
baseband-devel@lists.osmocom.org
3 comments
3 participants
participants (3)
-
Harald Welte -
Peter Stuge -
tsaitgaist