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
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.
- 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.
- 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 wrote:
- 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.
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
Peter,
On Mon, Jan 31, 2011 at 04:46:32PM +0100, Peter Stuge wrote:
Harald Welte wrote:
- 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.
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.
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
baseband-devel@lists.osmocom.org
-
Harald Welte -
Peter Stuge -
tsaitgaist