seems to be much shorter than usual ATR I've seen, but _all_ o2-cz and o2-sk, postpaid, prepaid have that same ATR (since like 2-3 yrs old till few months ago - meaning bought from o2).

wasn't so sure where to stick the hex-dump so I've put it into main.c, process_usb_msg, diff is below just in case you need to be sure about the exact location.

trace i got is attached, it seems some of the APDU data are getting marked as part of ATR with SIMTRACE_FLAG_ATR flag and since then all the data don't make sense to the parser anymore (imho).

diff --git a/host/main.c b/host/main.c

index 4fbac8d..377868a 100644

--- a/host/main.c

+++ b/host/main.c

@@ -92,6 +92,7 @@ static int process_usb_msg(uint8_t *buf, int len)

switch (sh->cmd) {

case SIMTRACE_MSGT_DATA:

+ printf("dump: %s\n", osmo_hexdump(payload, payload_len));

/* special treatment for ATR */

if (sh->flags & SIMTRACE_FLAG_ATR) {

printf("ATR ");

On Thu, Dec 15, 2011 at 10:48 PM, Holger Hans Peter Freyther <holger@freyther.de> wrote:

On 12/15/2011 10:24 PM, Lukas Kuzmiak wrote:

>
> - I've put one printf() into the apdu_split_in method, it seems the buffer is
> somehow getting scrambled from the beginning, it shows something like:

Hi,
so let me claim the issue is in our split method... could you generate the
hexdump of the bytes added? we could then feed APDU split ourselves. The other
part would be, do you have a PCSC Card reader? you could send us the ATR as
reportede by pcsc_scan.