From mailman at riseup.net  Tue Mar  6 20:06:22 2012
From: mailman at riseup.net (=?ISO-8859-1?Q?Florian_Borggr=E4fe?=)
Date: Tue, 06 Mar 2012 21:06:22 +0100
Subject: What can be logged?
Message-ID: <4F566E3E.60905@riseup.net>

Hello,

i have a question about the functionality of the Osmoscon SimTrace
hardware system.
Can I log everything, also packets like silent SMS
(https://en.wikipedia.org/wiki/SMS#Silent_SMS)?

Thank you for your request.

Flo



From lukash at backstep.net  Tue Mar  6 20:50:24 2012
From: lukash at backstep.net (Lukas Kuzmiak)
Date: Tue, 6 Mar 2012 21:50:24 +0100
Subject: What can be logged?
In-Reply-To: <4F566E3E.60905@riseup.net>
References: <4F566E3E.60905@riseup.net>
Message-ID: <CABV5EtFboz7qJwoT3K7GMKZ=0iKocMy66_fCZKt7ohdUV0DA5Q@mail.gmail.com>

Hi Florian,

purely from my personal knowledge and experience (I'm not saying this is a
way it works in general), but phone may drop the SMS before it reaches the
SIM, if it's corrupted in a way or strictly addresses a phone rather than a
SIM card, so.. you may see some of them, you may miss some of them, this
really depends .. it's a case-by-case problem.

Cheers,
Lukas

2012/3/6 Florian Borggr?fe <mailman at riseup.net>

> Hello,
>
> i have a question about the functionality of the Osmoscon SimTrace
> hardware system.
> Can I log everything, also packets like silent SMS
> (https://en.wikipedia.org/wiki/SMS#Silent_SMS)?
>
> Thank you for your request.
>
> Flo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20120306/481c0544/attachment.htm>

From laforge at gnumonks.org  Tue Mar  6 22:02:09 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 6 Mar 2012 23:02:09 +0100
Subject: What can be logged?
In-Reply-To: <4F566E3E.60905@riseup.net>
References: <4F566E3E.60905@riseup.net>
Message-ID: <20120306220209.GB10454@prithivi.gnumonks.org>

On Tue, Mar 06, 2012 at 09:06:22PM +0100, Florian Borggr?fe wrote:

> i have a question about the functionality of the Osmoscon SimTrace
> hardware system.
> Can I log everything, also packets like silent SMS
> (https://en.wikipedia.org/wiki/SMS#Silent_SMS)?

I can only follow up to what Lukas wrote.  We can trace anything that
ever hits the ME - SIM interface.  But which phones might or might not
forward silent messages to the SIM remains an open question.

My personal educated guess would be that it is probably not sent to the
sim in the majority of the cases/phones.  SMS on the SIM is an ancient
relic, and then in the case of silent SMS, if the phone knows it shall
discard it, why first push it to the SIM...

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From lukash at backstep.net  Tue Mar  6 22:05:47 2012
From: lukash at backstep.net (Lukas Kuzmiak)
Date: Tue, 6 Mar 2012 23:05:47 +0100
Subject: What can be logged?
In-Reply-To: <20120306220209.GB10454@prithivi.gnumonks.org>
References: <4F566E3E.60905@riseup.net>
	<20120306220209.GB10454@prithivi.gnumonks.org>
Message-ID: <CABV5EtFHzmrdMUud0Z4AP8SWb8TmBQKLYANR95+3Dfo+EDTuBg@mail.gmail.com>

one more thing that crossed my mind - it really depends on what you call a
"silent sms", it may also be SMS sent to update some parameters of a SIM
card (like (F)PLMN list), that is still a silent sms - most phones will not
show anything about this being received .. and that will reach the SIM
obviously.

however i have no knowledge what authorities/hackers actually use as a
silent SMS.

2012/3/6 Harald Welte <laforge at gnumonks.org>

> On Tue, Mar 06, 2012 at 09:06:22PM +0100, Florian Borggr?fe wrote:
>
> > i have a question about the functionality of the Osmoscon SimTrace
> > hardware system.
> > Can I log everything, also packets like silent SMS
> > (https://en.wikipedia.org/wiki/SMS#Silent_SMS)?
>
> I can only follow up to what Lukas wrote.  We can trace anything that
> ever hits the ME - SIM interface.  But which phones might or might not
> forward silent messages to the SIM remains an open question.
>
> My personal educated guess would be that it is probably not sent to the
> sim in the majority of the cases/phones.  SMS on the SIM is an ancient
> relic, and then in the case of silent SMS, if the phone knows it shall
> discard it, why first push it to the SIM...
>
> Regards,
>        Harald
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20120306/19aa3b77/attachment.htm>

From smit.arjen at gmail.com  Wed Mar  7 23:11:15 2012
From: smit.arjen at gmail.com (Arjen Smit)
Date: Thu, 8 Mar 2012 00:11:15 +0100
Subject: sysmosim - Greencard
Message-ID: <CABtLHnWZSf2WtzUchYmyYDo7bxM02vM-+6BduDvRDJVxX5EO4g@mail.gmail.com>

Dear all,

Hopefully this is the right list for some questions on the SysmoSIM (aka
Greencard).

I have set the PIN1, PUK1, PIN1, PUK1, ADM1, AUK1, ADM2, AUK2 using the
non-standard APDU (80 D4 ..) successfully using the  cyberflex-shell.
Verification of CHV1 and CHV2 are fine as well. (A0 20 00 01 08  ...)

However verification of ADM2 (which I need because I want to change the
Authentication algorithm)
A0 20 00 0B 08 30 30 30 30 30 30 30 30
returns status : 98 02 (no chv initialized).

It looks like  I use the wrong APDU sequence for verifying ADM2 (I tried
some other sequences as well (e.g A0 20 00 0A .. to A0 20 00 0D ..) but no
luck.

My main question is : What APDU sequence is needed to verify ADM2  ?

Secondary less important questions:
-When thinking about AUK1, AUK2, what are these used for ?
-Do the cards support 03.48 OTA specs (if yes, can the Kic, Kid be set ?)
-Are there actually any specs of these cards available ?
(google gives www.elektroda.pl/rtvforum/download.php?id=351846 which
matches the ATR of the card, however this spec is of little use though).



Thanks in advance for your help.
/Arjen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20120308/13195f5e/attachment.htm>

From smit.arjen at gmail.com  Fri Mar  9 15:39:23 2012
From: smit.arjen at gmail.com (Arjen Smit)
Date: Fri, 9 Mar 2012 16:39:23 +0100
Subject: sysmosim - Greencard
In-Reply-To: <CABtLHnWZSf2WtzUchYmyYDo7bxM02vM-+6BduDvRDJVxX5EO4g@mail.gmail.com>
References: <CABtLHnWZSf2WtzUchYmyYDo7bxM02vM-+6BduDvRDJVxX5EO4g@mail.gmail.com>
Message-ID: <CABtLHnX+Jo=YKSTU_KFZ0M6Nit3_4oSoeMmnRsxbD-XUX9JeCg@mail.gmail.com>

For anyone interested:
A0 20 00 05 08  44 44 44 44 44 44 44 44 unlocks the card to allow update
e.g the authentication Algorithm.

http://openbsc.osmocom.org/trac/wiki/GrcardSIM describes that ADM2 key
security level is associated to several EFs.
I doubt if it is the ADM2 key associated to these files, when I modify the
ADM2 key and try that key using the A0 20 00 05 08 .. sequence it locks
this key. Thus allowing no further changes.

If any spec available on the sysmosim/Greencard card it would be
appreciated.

BR
/Arjen





On Thu, Mar 8, 2012 at 12:11 AM, Arjen Smit <smit.arjen at gmail.com> wrote:

> Dear all,
>
> Hopefully this is the right list for some questions on the SysmoSIM (aka
> Greencard).
>
> I have set the PIN1, PUK1, PIN1, PUK1, ADM1, AUK1, ADM2, AUK2 using the
> non-standard APDU (80 D4 ..) successfully using the  cyberflex-shell.
> Verification of CHV1 and CHV2 are fine as well. (A0 20 00 01 08  ...)
>
> However verification of ADM2 (which I need because I want to change the
> Authentication algorithm)
> A0 20 00 0B 08 30 30 30 30 30 30 30 30
> returns status : 98 02 (no chv initialized).
>
> It looks like  I use the wrong APDU sequence for verifying ADM2 (I tried
> some other sequences as well (e.g A0 20 00 0A .. to A0 20 00 0D ..) but no
> luck.
>
> My main question is : What APDU sequence is needed to verify ADM2  ?
>
> Secondary less important questions:
> -When thinking about AUK1, AUK2, what are these used for ?
> -Do the cards support 03.48 OTA specs (if yes, can the Kic, Kid be set ?)
> -Are there actually any specs of these cards available ?
> (google gives www.elektroda.pl/rtvforum/download.php?id=351846 which
> matches the ATR of the card, however this spec is of little use though).
>
>
>
> Thanks in advance for your help.
> /Arjen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20120309/e2dcddc1/attachment.htm>

From laforge at gnumonks.org  Fri Mar  9 20:27:56 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 9 Mar 2012 21:27:56 +0100
Subject: sysmosim - Greencard
In-Reply-To: <CABtLHnX+Jo=YKSTU_KFZ0M6Nit3_4oSoeMmnRsxbD-XUX9JeCg@mail.gmail.com>
References: <CABtLHnWZSf2WtzUchYmyYDo7bxM02vM-+6BduDvRDJVxX5EO4g@mail.gmail.com>
	<CABtLHnX+Jo=YKSTU_KFZ0M6Nit3_4oSoeMmnRsxbD-XUX9JeCg@mail.gmail.com>
Message-ID: <20120309202756.GC24882@prithivi.gnumonks.org>

Hi Arjen,

On Fri, Mar 09, 2012 at 04:39:23PM +0100, Arjen Smit wrote:
> For anyone interested:
> A0 20 00 05 08  44 44 44 44 44 44 44 44 unlocks the card to allow update
> e.g the authentication Algorithm.

thanks a lot for informing the list about your progress.

> If any spec available on the sysmosim/Greencard card it would be
> appreciated.

There is no specification, sorry.  All information we know about that
card and its programming had to be reverse engineered from an
uncommented list of APDU sequences for pre-personalization and
personalization that we received from our supplier.

It would be great if you could find some time to improve the wiki page
with your findings.  Unless the community collaborates on creating a
better spec/document, there will not be one :/

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From lexington1776 at gmail.com  Wed Mar 14 22:10:35 2012
From: lexington1776 at gmail.com (Jonathan Thomas)
Date: Wed, 14 Mar 2012 17:10:35 -0500
Subject: SIM Trace Appears to Stop Processing APDUs
Message-ID: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>

Environment:

We have tested on three systems with both Ubuntu and OpenSUSE.
Additionally, we have tested with both VMs and as a core system
install.

Software Installed:
Installed the latest using the instructions from the user manual.

Issue:

With testing against all three of the SIMTrace modules we purchased we
have found the trace appears to lock-up or freeze randomly through
processing of the APDUs.  Since the phone still functions properly I
am assuming that the communication between the SIM and the phone are
still intact, it is just an issue with the output to screen/file
output.  Has anyone else experienced this issue?

We will try and flash the firmware, but since we saw this issue with
all of the hardware we purchased we assumed there might be some other
issue.

Thank you.
Jonathan



From laforge at gnumonks.org  Sun Mar 18 11:30:33 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 18 Mar 2012 12:30:33 +0100
Subject: SIM Trace Appears to Stop Processing APDUs
In-Reply-To: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
References: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
Message-ID: <20120318113033.GG10684@prithivi.gnumonks.org>

Hi Jonathan,

sorry to hear you are having trouble.

On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:

> With testing against all three of the SIMTrace modules we purchased we
> have found the trace appears to lock-up or freeze randomly through
> processing of the APDUs.  

Can you please indicate what exactly seems to trigger those freezes?
Is there any particular phone model or sim card (or combination
thereof)?

What can you see on the simtrace UART at the time of the freeze?

Does the USB device re-enumerate (USB reset) when you observe the freeze?

Does the simtrace program keep running or does it stop?

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From lexington1776 at gmail.com  Tue Mar 20 14:49:18 2012
From: lexington1776 at gmail.com (Jonathan Thomas)
Date: Tue, 20 Mar 2012 09:49:18 -0500
Subject: SIM Trace Appears to Stop Processing APDUs
In-Reply-To: <20120318113033.GG10684@prithivi.gnumonks.org>
References: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
	<20120318113033.GG10684@prithivi.gnumonks.org>
Message-ID: <CAERN135nPQRVj2Kcym2178Fqzh23JvcTpQ+qfQPPxmG0PRqacw@mail.gmail.com>

Harald,

Thank you for your response.  I will try and summarize what we are
seeing based on your questions below.

The word 'freeze' is probably not accurate as the the simtrace
application is still running/executing without receiving a termination
signal, etc.  What we are experiencing is that the output, both with
Wireshark and stdout, stops displaying any APDU traffic.

For instance, when I boot up the phone for this first time, the
simtrace application will appear to work correctly, but at some point
during the reset it will stop displaying APDU traffic.  For instance
on this run it stops after a response from the SIM:

APDU: (183):  03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4
6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06
01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23
c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a
00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e
9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00
00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00
00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00
00 02 a4
APDU: (7):  6f 07 9f 13 a0 c0 00
APDU: (7):  00 13 c0 00 00 00 09
APDU: (7):  6f 07 04 00 14 00 44
APDU: (7):  01 06 00 00 00 6f 06
APDU: (7):  03 90 00 a0 a4 00 00
APDU: (7):  02 a4 6f 07 9f 13 a0
APDU: (199):  c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00
00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00
a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4
6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06
00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02
a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01
06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02
a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01
06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff

After this point it will no longer display (Wireshark or stdout) any
APDU traffic.  The board itself shows no indication that there are any
issues and the process 'simtrace' is still running.  If I restart the
phone the only APDU I see is the ATR APDU.

If I now stop the simtrace application and restart the application I
will get the same result on boot up of the phone.  If I restart the
application after the phone has been completely booted then I will see
the status messages between the phone and the SIM for some period of
time before that traffic also stops displaying to the screen.

After a while I will see this error from the simtrace application:
"Error submitting BULK IN urb: No error".

An alternative phone will stop displaying APDUs, but at a different
location from the first (this doesn't seem to be consistent):

APDU: (7):  32 05 83 02 6f 42 a5
APDU: (7):  03 80 01 71 8a 01 05
APDU: (7):  8b 03 6f 06 07 80 02
APDU: (7):  00 fa 88 00 90 00 00
APDU: (7):  b2 01 04 32 b2 ff ff

Please let me know if I can clarify/focus these issues.

Thanks,
Jonathan

On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi Jonathan,
>
> sorry to hear you are having trouble.
>
> On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
>
>> With testing against all three of the SIMTrace modules we purchased we
>> have found the trace appears to lock-up or freeze randomly through
>> processing of the APDUs.
>
> Can you please indicate what exactly seems to trigger those freezes?
> Is there any particular phone model or sim card (or combination
> thereof)?
>
> What can you see on the simtrace UART at the time of the freeze?
>
> Does the USB device re-enumerate (USB reset) when you observe the freeze?
>
> Does the simtrace program keep running or does it stop?
>
> Regards,
> ? ? ? ?Harald
> --
> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)



From martin at martinpaljak.net  Wed Mar 21 19:44:47 2012
From: martin at martinpaljak.net (Martin Paljak)
Date: Wed, 21 Mar 2012 21:44:47 +0200
Subject: SIM Trace Appears to Stop Processing APDUs
In-Reply-To: <CAERN135nPQRVj2Kcym2178Fqzh23JvcTpQ+qfQPPxmG0PRqacw@mail.gmail.com>
References: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
	<20120318113033.GG10684@prithivi.gnumonks.org>
	<CAERN135nPQRVj2Kcym2178Fqzh23JvcTpQ+qfQPPxmG0PRqacw@mail.gmail.com>
Message-ID: <CACsm3DV7Lm6L_A-s-uFjaLaeE=c5Qb_6VsSJXabOyyyutseF=Q@mail.gmail.com>

Hello,

Your APDU output is garbage because it seems you have broken your host
side software or reset the board after you powered up your phone.

I experienced similar issues but it usually worked after fixing a
small apdu parsing bug in simtrace tool after following this:

1. phone off
2. reset simtrace board
3. start simtrace application
4. power up phone

Martin
On Tue, Mar 20, 2012 at 16:49, Jonathan Thomas <lexington1776 at gmail.com> wrote:
> Harald,
>
> Thank you for your response. ?I will try and summarize what we are
> seeing based on your questions below.
>
> The word 'freeze' is probably not accurate as the the simtrace
> application is still running/executing without receiving a termination
> signal, etc. ?What we are experiencing is that the output, both with
> Wireshark and stdout, stops displaying any APDU traffic.
>
> For instance, when I boot up the phone for this first time, the
> simtrace application will appear to work correctly, but at some point
> during the reset it will stop displaying APDU traffic. ?For instance
> on this run it stops after a response from the SIM:
>
> APDU: (183): ?03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4
> 6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06
> 01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23
> c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a
> 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e
> 9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00
> 00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00
> 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00
> 00 02 a4
> APDU: (7): ?6f 07 9f 13 a0 c0 00
> APDU: (7): ?00 13 c0 00 00 00 09
> APDU: (7): ?6f 07 04 00 14 00 44
> APDU: (7): ?01 06 00 00 00 6f 06
> APDU: (7): ?03 90 00 a0 a4 00 00
> APDU: (7): ?02 a4 6f 07 9f 13 a0
> APDU: (199): ?c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00
> 00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00
> a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4
> 6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06
> 00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02
> a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01
> 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02
> a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01
> 06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff
>
> After this point it will no longer display (Wireshark or stdout) any
> APDU traffic. ?The board itself shows no indication that there are any
> issues and the process 'simtrace' is still running. ?If I restart the
> phone the only APDU I see is the ATR APDU.
>
> If I now stop the simtrace application and restart the application I
> will get the same result on boot up of the phone. ?If I restart the
> application after the phone has been completely booted then I will see
> the status messages between the phone and the SIM for some period of
> time before that traffic also stops displaying to the screen.
>
> After a while I will see this error from the simtrace application:
> "Error submitting BULK IN urb: No error".
>
> An alternative phone will stop displaying APDUs, but at a different
> location from the first (this doesn't seem to be consistent):
>
> APDU: (7): ?32 05 83 02 6f 42 a5
> APDU: (7): ?03 80 01 71 8a 01 05
> APDU: (7): ?8b 03 6f 06 07 80 02
> APDU: (7): ?00 fa 88 00 90 00 00
> APDU: (7): ?b2 01 04 32 b2 ff ff
>
> Please let me know if I can clarify/focus these issues.
>
> Thanks,
> Jonathan
>
> On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte <laforge at gnumonks.org> wrote:
>> Hi Jonathan,
>>
>> sorry to hear you are having trouble.
>>
>> On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
>>
>>> With testing against all three of the SIMTrace modules we purchased we
>>> have found the trace appears to lock-up or freeze randomly through
>>> processing of the APDUs.
>>
>> Can you please indicate what exactly seems to trigger those freezes?
>> Is there any particular phone model or sim card (or combination
>> thereof)?
>>
>> What can you see on the simtrace UART at the time of the freeze?
>>
>> Does the USB device re-enumerate (USB reset) when you observe the freeze?
>>
>> Does the simtrace program keep running or does it stop?
>>
>> Regards,
>> ? ? ? ?Harald
>> --
>> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
>> ============================================================================
>> "Privacy in residential applications is a desirable marketing option."
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
>



From martin at martinpaljak.net  Wed Mar 21 20:03:03 2012
From: martin at martinpaljak.net (Martin Paljak)
Date: Wed, 21 Mar 2012 22:03:03 +0200
Subject: SIM Trace Appears to Stop Processing APDUs
In-Reply-To: <CAERN136xtO75ot=YYPvOdfAnzU9wrB1Nc__jQozdrv+QUUBA_Q@mail.gmail.com>
References: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
	<20120318113033.GG10684@prithivi.gnumonks.org>
	<CAERN135nPQRVj2Kcym2178Fqzh23JvcTpQ+qfQPPxmG0PRqacw@mail.gmail.com>
	<CACsm3DV7Lm6L_A-s-uFjaLaeE=c5Qb_6VsSJXabOyyyutseF=Q@mail.gmail.com>
	<CAERN136xtO75ot=YYPvOdfAnzU9wrB1Nc__jQozdrv+QUUBA_Q@mail.gmail.com>
Message-ID: <CACsm3DVNbTnCrUJ47eLe9NYMa+K-ENkg874Ca-_nGZYBpXaf-g@mail.gmail.com>

On Wed, Mar 21, 2012 at 21:52, Jonathan Thomas <lexington1776 at gmail.com> wrote:
> Martin,
>
> Thank you for your response. ?It doesn't appear that following those
> steps fixes what does appear to be a APDU parsing issue. ?Take a look
> at this set of APDUs and notice that the last APDU should have been:
>
> a0 b2 04 04 26 b2 ff ff
>
> but the a0 was appended to the previous line.

> APDU: (45): ?a0 b2 03 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 90 00 a0
> APDU: (7): ?b2 04 04 26 b2 ff ff


Lc is 0x26 which is 38 (dec) yet there are 37 ff-s.

Either your phone/card are OK with faulty APDU-s or the simtrace board
"lost" a byte (if that is possible, I don't know)

Best,

Martin

> When you say 'reset' I assume you mean that you physically press the
> 'Reset' button on the board.
Yes.

> Any other helpful hints that might fix/bypass this parsing issue?
>
> Thank you,
> Jonathan
>
> On Wed, Mar 21, 2012 at 2:44 PM, Martin Paljak <martin at martinpaljak.net> wrote:
>> Hello,
>>
>> Your APDU output is garbage because it seems you have broken your host
>> side software or reset the board after you powered up your phone.
>>
>> I experienced similar issues but it usually worked after fixing a
>> small apdu parsing bug in simtrace tool after following this:
>>
>> 1. phone off
>> 2. reset simtrace board
>> 3. start simtrace application
>> 4. power up phone
>>
>> Martin
>> On Tue, Mar 20, 2012 at 16:49, Jonathan Thomas <lexington1776 at gmail.com> wrote:
>>> Harald,
>>>
>>> Thank you for your response. ?I will try and summarize what we are
>>> seeing based on your questions below.
>>>
>>> The word 'freeze' is probably not accurate as the the simtrace
>>> application is still running/executing without receiving a termination
>>> signal, etc. ?What we are experiencing is that the output, both with
>>> Wireshark and stdout, stops displaying any APDU traffic.
>>>
>>> For instance, when I boot up the phone for this first time, the
>>> simtrace application will appear to work correctly, but at some point
>>> during the reset it will stop displaying APDU traffic. ?For instance
>>> on this run it stops after a response from the SIM:
>>>
>>> APDU: (183): ?03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4
>>> 6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06
>>> 01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23
>>> c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a
>>> 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e
>>> 9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00
>>> 00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00
>>> 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00
>>> 00 02 a4
>>> APDU: (7): ?6f 07 9f 13 a0 c0 00
>>> APDU: (7): ?00 13 c0 00 00 00 09
>>> APDU: (7): ?6f 07 04 00 14 00 44
>>> APDU: (7): ?01 06 00 00 00 6f 06
>>> APDU: (7): ?03 90 00 a0 a4 00 00
>>> APDU: (7): ?02 a4 6f 07 9f 13 a0
>>> APDU: (199): ?c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00
>>> 00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00
>>> a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4
>>> 6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06
>>> 00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02
>>> a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01
>>> 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02
>>> a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01
>>> 06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff
>>>
>>> After this point it will no longer display (Wireshark or stdout) any
>>> APDU traffic. ?The board itself shows no indication that there are any
>>> issues and the process 'simtrace' is still running. ?If I restart the
>>> phone the only APDU I see is the ATR APDU.
>>>
>>> If I now stop the simtrace application and restart the application I
>>> will get the same result on boot up of the phone. ?If I restart the
>>> application after the phone has been completely booted then I will see
>>> the status messages between the phone and the SIM for some period of
>>> time before that traffic also stops displaying to the screen.
>>>
>>> After a while I will see this error from the simtrace application:
>>> "Error submitting BULK IN urb: No error".
>>>
>>> An alternative phone will stop displaying APDUs, but at a different
>>> location from the first (this doesn't seem to be consistent):
>>>
>>> APDU: (7): ?32 05 83 02 6f 42 a5
>>> APDU: (7): ?03 80 01 71 8a 01 05
>>> APDU: (7): ?8b 03 6f 06 07 80 02
>>> APDU: (7): ?00 fa 88 00 90 00 00
>>> APDU: (7): ?b2 01 04 32 b2 ff ff
>>>
>>> Please let me know if I can clarify/focus these issues.
>>>
>>> Thanks,
>>> Jonathan
>>>
>>> On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte <laforge at gnumonks.org> wrote:
>>>> Hi Jonathan,
>>>>
>>>> sorry to hear you are having trouble.
>>>>
>>>> On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
>>>>
>>>>> With testing against all three of the SIMTrace modules we purchased we
>>>>> have found the trace appears to lock-up or freeze randomly through
>>>>> processing of the APDUs.
>>>>
>>>> Can you please indicate what exactly seems to trigger those freezes?
>>>> Is there any particular phone model or sim card (or combination
>>>> thereof)?
>>>>
>>>> What can you see on the simtrace UART at the time of the freeze?
>>>>
>>>> Does the USB device re-enumerate (USB reset) when you observe the freeze?
>>>>
>>>> Does the simtrace program keep running or does it stop?
>>>>
>>>> Regards,
>>>> ? ? ? ?Harald
>>>> --
>>>> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
>>>> ============================================================================
>>>> "Privacy in residential applications is a desirable marketing option."
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
>>>



From lexington1776 at gmail.com  Wed Mar 21 19:52:40 2012
From: lexington1776 at gmail.com (Jonathan Thomas)
Date: Wed, 21 Mar 2012 14:52:40 -0500
Subject: SIM Trace Appears to Stop Processing APDUs
In-Reply-To: <CACsm3DV7Lm6L_A-s-uFjaLaeE=c5Qb_6VsSJXabOyyyutseF=Q@mail.gmail.com>
References: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
	<20120318113033.GG10684@prithivi.gnumonks.org>
	<CAERN135nPQRVj2Kcym2178Fqzh23JvcTpQ+qfQPPxmG0PRqacw@mail.gmail.com>
	<CACsm3DV7Lm6L_A-s-uFjaLaeE=c5Qb_6VsSJXabOyyyutseF=Q@mail.gmail.com>
Message-ID: <CAERN136xtO75ot=YYPvOdfAnzU9wrB1Nc__jQozdrv+QUUBA_Q@mail.gmail.com>

Martin,

Thank you for your response.  It doesn't appear that following those
steps fixes what does appear to be a APDU parsing issue.  Take a look
at this set of APDUs and notice that the last APDU should have been:

a0 b2 04 04 26 b2 ff ff

but the a0 was appended to the previous line.

APDU: (9):  a0 a4 00 00 02 7f 20 9f 23
APDU: (42):  a0 c0 00 00 23 00 00 00 00 7f 20 02 00 00 00 00 00 16 b3
02 37 04 00 83 8a 83 8a 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00
APDU: (9):  a0 a4 00 00 02 6f c7 9f 13
APDU: (26):  a0 c0 00 00 13 00 00 00 98 6f c7 04 00 11 00 44 01 06 01
26 00 6f 06 04 90 00
APDU: (45):  a0 b2 01 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff 90 00
APDU: (45):  a0 b2 02 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff 90 00
APDU: (45):  a0 b2 03 04 26 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90 00 a0
APDU: (7):  b2 04 04 26 b2 ff ff


When you say 'reset' I assume you mean that you physically press the
'Reset' button on the board.  Any other helpful hints that might
fix/bypass this parsing issue?

Thank you,
Jonathan

On Wed, Mar 21, 2012 at 2:44 PM, Martin Paljak <martin at martinpaljak.net> wrote:
> Hello,
>
> Your APDU output is garbage because it seems you have broken your host
> side software or reset the board after you powered up your phone.
>
> I experienced similar issues but it usually worked after fixing a
> small apdu parsing bug in simtrace tool after following this:
>
> 1. phone off
> 2. reset simtrace board
> 3. start simtrace application
> 4. power up phone
>
> Martin
> On Tue, Mar 20, 2012 at 16:49, Jonathan Thomas <lexington1776 at gmail.com> wrote:
>> Harald,
>>
>> Thank you for your response. ?I will try and summarize what we are
>> seeing based on your questions below.
>>
>> The word 'freeze' is probably not accurate as the the simtrace
>> application is still running/executing without receiving a termination
>> signal, etc. ?What we are experiencing is that the output, both with
>> Wireshark and stdout, stops displaying any APDU traffic.
>>
>> For instance, when I boot up the phone for this first time, the
>> simtrace application will appear to work correctly, but at some point
>> during the reset it will stop displaying APDU traffic. ?For instance
>> on this run it stops after a response from the SIM:
>>
>> APDU: (183): ?03 00 00 fa b0 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4
>> 6f 3a 9f 13 a0 c0 00 00 13 c0 00 00 0d 48 6f 3a 04 00 11 00 22 01 06
>> 01 22 00 6f 06 03 90 00 a0 a4 00 00 02 a4 7f 20 9f 23 a0 c0 00 00 23
>> c0 00 00 00 00 7f 20 02 00 00 00 00 00 16 33 02 37 04 00 83 8a 83 8a
>> 00 03 00 00 fa b0 00 00 00 00 2f 06 06 90 00 a0 a4 00 00 02 a4 6f 7e
>> 9f 13 a0 c0 00 00 13 c0 00 00 00 0b 6f 7e 04 00 11 00 44 01 06 00 00
>> 00 6f 06 06 90 00 a0 a4 00 00 02 a4 6f 07 9f 13 a0 c0 00 00 13 c0 00
>> 00 00 09 6f 07 04 00 14 00 44 01 06 00 00 00 6f 06 03 90 00 a0 a4 00
>> 00 02 a4
>> APDU: (7): ?6f 07 9f 13 a0 c0 00
>> APDU: (7): ?00 13 c0 00 00 00 09
>> APDU: (7): ?6f 07 04 00 14 00 44
>> APDU: (7): ?01 06 00 00 00 6f 06
>> APDU: (7): ?03 90 00 a0 a4 00 00
>> APDU: (7): ?02 a4 6f 07 9f 13 a0
>> APDU: (199): ?c0 00 00 13 c0 00 00 09 6f 07 04 00 14 00 44 01 06 00 00
>> 00 6f 06 03 90 00 a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00
>> a0 b0 00 00 09 b0 08 09 10 10 10 32 54 76 98 90 00 a0 a4 00 00 02 a4
>> 6f 78 9f 13 a0 c0 00 00 13 c0 00 00 00 02 6f 78 04 00 14 00 44 01 06
>> 00 00 00 6f 06 05 90 00 a0 b0 00 00 02 b0 00 01 90 00 a0 a4 00 00 02
>> a4 6f 31 9f 13 a0 c0 00 00 13 c0 00 00 00 01 6f 31 04 00 14 00 44 01
>> 06 00 00 00 6f 06 05 90 00 a0 b0 00 00 01 b0 00 90 00 a0 a4 00 00 02
>> a4 6f 30 9f 13 a0 c0 00 00 13 c0 00 00 96 96 6f 30 04 00 11 00 44 01
>> 06 00 00 00 6f 06 04 90 00 a0 b0 00 00 96 b0 ff ff ff ff
>>
>> After this point it will no longer display (Wireshark or stdout) any
>> APDU traffic. ?The board itself shows no indication that there are any
>> issues and the process 'simtrace' is still running. ?If I restart the
>> phone the only APDU I see is the ATR APDU.
>>
>> If I now stop the simtrace application and restart the application I
>> will get the same result on boot up of the phone. ?If I restart the
>> application after the phone has been completely booted then I will see
>> the status messages between the phone and the SIM for some period of
>> time before that traffic also stops displaying to the screen.
>>
>> After a while I will see this error from the simtrace application:
>> "Error submitting BULK IN urb: No error".
>>
>> An alternative phone will stop displaying APDUs, but at a different
>> location from the first (this doesn't seem to be consistent):
>>
>> APDU: (7): ?32 05 83 02 6f 42 a5
>> APDU: (7): ?03 80 01 71 8a 01 05
>> APDU: (7): ?8b 03 6f 06 07 80 02
>> APDU: (7): ?00 fa 88 00 90 00 00
>> APDU: (7): ?b2 01 04 32 b2 ff ff
>>
>> Please let me know if I can clarify/focus these issues.
>>
>> Thanks,
>> Jonathan
>>
>> On Sun, Mar 18, 2012 at 6:30 AM, Harald Welte <laforge at gnumonks.org> wrote:
>>> Hi Jonathan,
>>>
>>> sorry to hear you are having trouble.
>>>
>>> On Wed, Mar 14, 2012 at 05:10:35PM -0500, Jonathan Thomas wrote:
>>>
>>>> With testing against all three of the SIMTrace modules we purchased we
>>>> have found the trace appears to lock-up or freeze randomly through
>>>> processing of the APDUs.
>>>
>>> Can you please indicate what exactly seems to trigger those freezes?
>>> Is there any particular phone model or sim card (or combination
>>> thereof)?
>>>
>>> What can you see on the simtrace UART at the time of the freeze?
>>>
>>> Does the USB device re-enumerate (USB reset) when you observe the freeze?
>>>
>>> Does the simtrace program keep running or does it stop?
>>>
>>> Regards,
>>> ? ? ? ?Harald
>>> --
>>> - Harald Welte <laforge at gnumonks.org> ? ? ? ? ? http://laforge.gnumonks.org/
>>> ============================================================================
>>> "Privacy in residential applications is a desirable marketing option."
>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6)
>>



From 246tnt at gmail.com  Wed Mar 21 20:17:22 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 21 Mar 2012 21:17:22 +0100
Subject: SIM Trace Appears to Stop Processing APDUs
In-Reply-To: <CACsm3DVNbTnCrUJ47eLe9NYMa+K-ENkg874Ca-_nGZYBpXaf-g@mail.gmail.com>
References: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
	<20120318113033.GG10684@prithivi.gnumonks.org>
	<CAERN135nPQRVj2Kcym2178Fqzh23JvcTpQ+qfQPPxmG0PRqacw@mail.gmail.com>
	<CACsm3DV7Lm6L_A-s-uFjaLaeE=c5Qb_6VsSJXabOyyyutseF=Q@mail.gmail.com>
	<CAERN136xtO75ot=YYPvOdfAnzU9wrB1Nc__jQozdrv+QUUBA_Q@mail.gmail.com>
	<CACsm3DVNbTnCrUJ47eLe9NYMa+K-ENkg874Ca-_nGZYBpXaf-g@mail.gmail.com>
Message-ID: <CAHL+j099v4jkHKad_W_0xWzEHsqNQgDZcp_dKF4uGB67bHBu6w@mail.gmail.com>

> Either your phone/card are OK with faulty APDU-s or the simtrace board
> "lost" a byte (if that is possible, I don't know)

Yes, it happens ... the simtrace can loose byte which is really annoying.

Cheers,

    Sylvain



From laforge at gnumonks.org  Wed Mar 21 21:02:02 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 21 Mar 2012 22:02:02 +0100
Subject: SIM Trace Appears to Stop Processing APDUs
In-Reply-To: <CAHL+j099v4jkHKad_W_0xWzEHsqNQgDZcp_dKF4uGB67bHBu6w@mail.gmail.com>
References: <CAERN1367_2fjX9yO5a+oLZWDEZ3ixpdu2A8gGDCQ0h7X=8TWqw@mail.gmail.com>
	<20120318113033.GG10684@prithivi.gnumonks.org>
	<CAERN135nPQRVj2Kcym2178Fqzh23JvcTpQ+qfQPPxmG0PRqacw@mail.gmail.com>
	<CACsm3DV7Lm6L_A-s-uFjaLaeE=c5Qb_6VsSJXabOyyyutseF=Q@mail.gmail.com>
	<CAERN136xtO75ot=YYPvOdfAnzU9wrB1Nc__jQozdrv+QUUBA_Q@mail.gmail.com>
	<CACsm3DVNbTnCrUJ47eLe9NYMa+K-ENkg874Ca-_nGZYBpXaf-g@mail.gmail.com>
	<CAHL+j099v4jkHKad_W_0xWzEHsqNQgDZcp_dKF4uGB67bHBu6w@mail.gmail.com>
Message-ID: <11516e8f-c8eb-4639-8a56-bb669d422e13@email.android.com>

Just to clarify: Lost bytes have recently been identified and are now a known firmware problem.

It seems however that nobody has yet found the time to properly fix it.  The problem seems to be extended periods of disabled interrupts in the USB code.

Several solutions have been proposed.

I always want to look at it, but then this is only one of way too many issues on my apparently ever-growing todo list.  But then, it shouldn't even require me to get it solved anyway ;)
-- 
Sent from my mobile phone. Please excuse my brevity.



From laforge at gnumonks.org  Wed Mar 21 22:48:13 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 21 Mar 2012 23:48:13 +0100
Subject: lost bytes in ISO7816 UART receive
In-Reply-To: <20120218191833.17427.qmail@stuge.se>
References: <20120212100456.GX1898@prithivi.gnumonks.org>
	<C1A7C004-889C-45DE-9FBB-7F8874699756@gmail.com>
	<20120212142241.GG1898@prithivi.gnumonks.org>
	<20120212144204.GH1898@prithivi.gnumonks.org>
	<CDF1296D-5B40-4D73-B3BD-67935DDC8D95@gmail.com>
	<4F3B856D.1050409@freyther.de>
	<EBE37E8B-C4D0-4744-BE15-8B085A3F434B@gmail.com>
	<20120216231114.3219.qmail@stuge.se>
	<5434FE82-9A42-4876-94BC-1D1B6DF49C69@gmail.com>
	<20120218191833.17427.qmail@stuge.se>
Message-ID: <20120321224813.GS27124@prithivi.gnumonks.org>

Hi Peter and others,

On Sat, Feb 18, 2012 at 08:18:33PM +0100, Peter Stuge wrote:
> I note that all data to be transmitted is copied byte for byte from
> the rctx data buffer into the USB peripheral memory. I had expected
> zero copy. During copying, interrupts are disabled.

I'm actually not sure on the latter part:

* the hardware and IRQ handler code supports nested interrupts
* the core IRQ handler assembly code re-enables interrupts immediately
  even before calling the USB driver
* the endpoint re-fill code called from the irq handler
  __udp_refill_ep() doesn't contain any explicit local_irq_disable()
* the USART interrupt priority (4) is higher than the USB prio (2)

So based on all this, the USART interrupt should happily be served as a
nested IRQ even while the USB driver is re-filling the end-point FIFO.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Thu Mar 22 23:12:23 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 23 Mar 2012 00:12:23 +0100
Subject: New v0.5 simtrace firmware release
Message-ID: <20120322231223.GO17351@prithivi.gnumonks.org>

Hi all!

Just in time before OsmoDevCon, I managed to releaes a new version of
the SIMtrace firmware.

The list of changes is quite extensive and should address a number of
the reliability problems that people have experienced.

The changes include:
* don't activate pass-through and LDO supply for the sim card at
  the same time, leading in power leaking from simtrace into phones
* fix a watchdog timer misconfiguration leading to occasional watchdog
  resets
* fix detection of sim insert/removal
* better VCC_PHONE detection
* reduce the amount of debug logging on the serial console and replace
  it by statistics (count of bytes, overruns, parity errors, etc)
* statistics can be read from the UART by pressing 't'.
* no longer crash the simtrace firmware if no simtrace host program is
  running

Using this v0.5 firmware and a pretty aggressiv program causing lots of
traffic (hunz' simdump) on a cm3121 reader at card Fi(9) Di(4) ratio 64
didn't cause any lost bytes or SIMtrace resets for me anymore.

Any feedback is appreciated.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main_simtrace_v05.bin
Type: application/octet-stream
Size: 21420 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20120323/e26d6d83/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main_simtrace_v05.samba
Type: application/octet-stream
Size: 59224 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20120323/e26d6d83/attachment.obj>

From myonium at gmail.com  Sun Mar 25 09:16:10 2012
From: myonium at gmail.com (Myonium)
Date: Sun, 25 Mar 2012 11:16:10 +0200
Subject: New v0.5 simtrace firmware release
In-Reply-To: <20120322231223.GO17351@prithivi.gnumonks.org>
References: <20120322231223.GO17351@prithivi.gnumonks.org>
Message-ID: <33BED984-DEBF-496F-BD6E-8966232A3B4F@gmail.com>

Hi Harald

Thank you for the new release.

So far everything works fine for me except for the lost byte issue for fast communication such as for the ?Gemalto .NET v2.0? card. (Issue: bytes get lost between UART chunks.)

However this is easily fixed just by reducing the rctx buffer size (same as in the last release). I set the buffer size ?rctx->size? to 16 Byte.

A quick and dirty fix is:
diff --git a/firmware/src/simtrace/iso7816_uart.c b/firmware/src/simtrace/iso7816_uart.c
index 4169ab9..f1db406 100644
--- a/firmware/src/simtrace/iso7816_uart.c
+++ b/firmware/src/simtrace/iso7816_uart.c
@@ -536,7 +536,8 @@ static void process_byte(struct iso7816_3_handle *ih, u_int8_t byte)
       rctx->data[rctx->tot_len] = byte;
       rctx->tot_len++;

-       if (rctx->tot_len >= rctx->size || ih->rctx_must_be_sent) {
+       /* if (rctx->tot_len >= rctx->size || ih->rctx_must_be_sent) { */
+       if (rctx->tot_len >= 16 || ih->rctx_must_be_sent) {
               ih->rctx_must_be_sent = 0;
               send_rctx(ih);
       }

Regards,

Ben
On Mar 23, 2012, at 12:12 AM, Harald Welte wrote:

> Hi all!
> 
> Just in time before OsmoDevCon, I managed to releaes a new version of
> the SIMtrace firmware.
> 
> The list of changes is quite extensive and should address a number of
> the reliability problems that people have experienced.
> 
> The changes include:
> * don't activate pass-through and LDO supply for the sim card at
>  the same time, leading in power leaking from simtrace into phones
> * fix a watchdog timer misconfiguration leading to occasional watchdog
>  resets
> * fix detection of sim insert/removal
> * better VCC_PHONE detection
> * reduce the amount of debug logging on the serial console and replace
>  it by statistics (count of bytes, overruns, parity errors, etc)
> * statistics can be read from the UART by pressing 't'.
> * no longer crash the simtrace firmware if no simtrace host program is
>  running
> 
> Using this v0.5 firmware and a pretty aggressiv program causing lots of
> traffic (hunz' simdump) on a cm3121 reader at card Fi(9) Di(4) ratio 64
> didn't cause any lost bytes or SIMtrace resets for me anymore.
> 
> Any feedback is appreciated.
> 
> Regards,
> 	Harald
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
> <main_simtrace_v05.bin><main_simtrace_v05.samba>




From krzysztof.zajac at exset.com  Mon Mar 26 06:51:06 2012
From: krzysztof.zajac at exset.com (Krzysztof Zajac)
Date: Mon, 26 Mar 2012 08:51:06 +0200
Subject: question
Message-ID: <4F7011DA.5000204@exset.com>

Hello,

I'm interesting of this device to sniff APDUs. Can we talk a bit more
details?

BR
Krzysztof Z.




From laforge at gnumonks.org  Mon Mar 26 08:39:50 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 26 Mar 2012 10:39:50 +0200
Subject: question
In-Reply-To: <4F7011DA.5000204@exset.com>
References: <4F7011DA.5000204@exset.com>
Message-ID: <20120326083949.GL19032@prithivi.gnumonks.org>

Hi Krysztof,

On Mon, Mar 26, 2012 at 08:51:06AM +0200, Krzysztof Zajac wrote:

> I'm interesting of this device to sniff APDUs. Can we talk a bit more
> details?

First of all: This is a public mailing list of an open source / open
hardware project.

You are happy to send your requirements by e-mail and we can discuss how
SIMtrace might fit your application.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Mon Mar 26 08:43:37 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 26 Mar 2012 10:43:37 +0200
Subject: New v0.5 simtrace firmware release
In-Reply-To: <33BED984-DEBF-496F-BD6E-8966232A3B4F@gmail.com>
References: <20120322231223.GO17351@prithivi.gnumonks.org>
	<33BED984-DEBF-496F-BD6E-8966232A3B4F@gmail.com>
Message-ID: <20120326084337.GM19032@prithivi.gnumonks.org>

On Sun, Mar 25, 2012 at 11:16:10AM +0200, Myonium wrote:
> So far everything works fine for me except for the lost byte issue for
> fast communication such as for the ?Gemalto .NET v2.0? card. (Issue:
> bytes get lost between UART chunks.)

It's quite funny.  What Fi/Di value is your card using?  Any idea what
the frequency on CLK is?

I have used a card with Fi/Di ratio of 64 on an Omnikey Cardman 3121 and
was unable to trigger the problem.  So in order to reproduce it, the CLK
frequency and Fi/Di values would help.

Also, when you look at the output of the statistics command on the
serial line, do you actually see the overrun counter increasing?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From myonium at gmail.com  Mon Mar 26 19:06:21 2012
From: myonium at gmail.com (Myonium)
Date: Mon, 26 Mar 2012 21:06:21 +0200
Subject: New v0.5 simtrace firmware release
In-Reply-To: <20120326084337.GM19032@prithivi.gnumonks.org>
References: <20120322231223.GO17351@prithivi.gnumonks.org>
	<33BED984-DEBF-496F-BD6E-8966232A3B4F@gmail.com>
	<20120326084337.GM19032@prithivi.gnumonks.org>
Message-ID: <831E3F9D-A1C3-4FDB-8C5D-6CE17BDCECDA@gmail.com>

The output from the serial console is:

nRST                                                 
LEN > BYTES_LEFT                                     
CC_PHONE off                                         
VCC_PHONE off
VCC_PHONE off                                                                   
....
VCC_PHONE off                                                                   
VCC_PHONE off                                                                   
VCC_PHONE off                                                                   
VCC_PHONE off                                                                   
WRAP DURING APPEND                                                              
VVCC_PHONE off                                                                  
RST                                                                             
computed Fi(1) Di(1) ratio: 372                                                 
VCC_PHONE on                                                                    
found Fi=9 Di=6                                                                 
computed Fi(9) Di(6) ratio: 16

I?m using also an Omnikey Cardman 3121.
?Gemalto .NET V2.0? supports baud rates up to 223Kbps. If you want me, I can sent you such a card for testing. Do you feel like testing such a card?


On Mar 26, 2012, at 10:43 AM, Harald Welte wrote:

> It's quite funny.  What Fi/Di value is your card using?  Any idea what
> the frequency on CLK is?
> 
> I have used a card with Fi/Di ratio of 64 on an Omnikey Cardman 3121 and
> was unable to trigger the problem.  So in order to reproduce it, the CLK
> frequency and Fi/Di values would help.
> 
> Also, when you look at the output of the statistics command on the
> serial line, do you actually see the overrun counter increasing?




From peter at stuge.se  Mon Mar 26 19:21:20 2012
From: peter at stuge.se (Peter Stuge)
Date: Mon, 26 Mar 2012 21:21:20 +0200
Subject: New v0.5 simtrace firmware release
In-Reply-To: <831E3F9D-A1C3-4FDB-8C5D-6CE17BDCECDA@gmail.com>
References: <20120322231223.GO17351@prithivi.gnumonks.org>
	<33BED984-DEBF-496F-BD6E-8966232A3B4F@gmail.com>
	<20120326084337.GM19032@prithivi.gnumonks.org>
	<831E3F9D-A1C3-4FDB-8C5D-6CE17BDCECDA@gmail.com>
Message-ID: <20120326192120.5764.qmail@stuge.se>

Myonium wrote:
> RST                                                                             
> computed Fi(1) Di(1) ratio: 372                                                 
> VCC_PHONE on                                                                    
> found Fi=9 Di=6                                                                 
> computed Fi(9) Di(6) ratio: 16

Does this mean that phone and SIM are communicating at different
speeds?


//Peter



From myonium at gmail.com  Mon Mar 26 20:17:11 2012
From: myonium at gmail.com (Myonium)
Date: Mon, 26 Mar 2012 22:17:11 +0200
Subject: New v0.5 simtrace firmware release
In-Reply-To: <20120326192120.5764.qmail@stuge.se>
References: <20120322231223.GO17351@prithivi.gnumonks.org>
	<33BED984-DEBF-496F-BD6E-8966232A3B4F@gmail.com>
	<20120326084337.GM19032@prithivi.gnumonks.org>
	<831E3F9D-A1C3-4FDB-8C5D-6CE17BDCECDA@gmail.com>
	<20120326192120.5764.qmail@stuge.se>
Message-ID: <EFD4B0A8-0778-4C13-9F3A-D5AFDB028357@gmail.com>

It's a smart card in an Omnikey 3121 reader. I think it is normal that the reader is switching speed e.g. after the ATR or a card reset.
I thought, that is what we see, isn't it?
Ben 
On Mar 26, 2012, at 9:21 PM, Peter Stuge wrote:

> Myonium wrote:
>> RST                                                                             
>> computed Fi(1) Di(1) ratio: 372                                                 
>> VCC_PHONE on                                                                    
>> found Fi=9 Di=6                                                                 
>> computed Fi(9) Di(6) ratio: 16
> 
> Does this mean that phone and SIM are communicating at different
> speeds?
> 
> 
> //Peter
> 




From laforge at gnumonks.org  Mon Mar 26 19:29:59 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 26 Mar 2012 21:29:59 +0200
Subject: New v0.5 simtrace firmware release
In-Reply-To: <831E3F9D-A1C3-4FDB-8C5D-6CE17BDCECDA@gmail.com>
References: <20120322231223.GO17351@prithivi.gnumonks.org>
	<33BED984-DEBF-496F-BD6E-8966232A3B4F@gmail.com>
	<20120326084337.GM19032@prithivi.gnumonks.org>
	<831E3F9D-A1C3-4FDB-8C5D-6CE17BDCECDA@gmail.com>
Message-ID: <20120326192959.GF23817@prithivi.gnumonks.org>

Hi!

On Mon, Mar 26, 2012 at 09:06:21PM +0200, Myonium wrote:
> The output from the serial console is:

if you type 't' you get the statistics.

> found Fi=9 Di=6
> computed Fi(9) Di(6) ratio: 16

Ok, that explains.  I have never seen any card with a ratio < 64.  Your
ratio of 16 means four times the speed that I am used to here.

> I?m using also an Omnikey Cardman 3121.  ?Gemalto .NET V2.0? supports
> baud rates up to 223Kbps. If you want me, I can sent you such a card
> for testing. Do you feel like testing such a card?

yes, that would be appreciated.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



From myonium at gmail.com  Mon Mar 26 20:50:45 2012
From: myonium at gmail.com (Myonium)
Date: Mon, 26 Mar 2012 22:50:45 +0200
Subject: Fwd: New v0.5 simtrace firmware release
References: <831E3F9D-A1C3-4FDB-8C5D-6CE17BDCECDA@gmail.com>
Message-ID: <72463E4B-D5DD-4EAA-B454-C21EE02463FB@gmail.com>


For completeness:
With the un-patched v0.5 version (with byte lost) I get the following serial console output (switching back and forth):
WRAP DURING APPEND                                   
ff                                                   
VCC_PHONE off                                        
...                                                                                  
VCC_PHONE off                                                                   
VCC_PHONE off                                                                   
VCC_PHONE on                                                                    
RST                                                                             
computed Fi(1) Di(1) ratio: 372                                                 
nRST                                                                            
VCC_PHONE on                                                                    
RST                                                                             
computed Fi(1) Di(1) ratio: 372                                                 
VCC_PHONE on                                                                    
RST                                                                             
computed Fi(1) Di(1) ratio: 372                                                 
VCC_PHONE off                                                                   
VCC_PHONE on                                                                    
nRST                                                                            
VCC_PHONE off                                                                   
VCC_PHONE on                                                                    
RST                                                                             
computed Fi(1) Di(1) ratio: 372                                                 
found Fi=9 Di=6                                                                 
computed Fi(9) Di(6) ratio: 16                                                  
RST                                                                             
computed Fi(1) Di(1) ratio: 372                                                 
RST                                                                             
computed Fi(1) Di(1) ratio: 372                                                 
nRST


Begin forwarded message:

> From: Myonium <myonium at gmail.com>
> Subject: Re: New v0.5 simtrace firmware release
> Date: March 26, 2012 9:06:21 PM GMT+02:00
> To: Harald Welte <laforge at gnumonks.org>
> Cc: simtrace at lists.osmocom.org
> 
> The output from the serial console is:
> 
> nRST                                                 
> LEN > BYTES_LEFT                                     
> CC_PHONE off                                         
> VCC_PHONE off
> VCC_PHONE off                                                                   
> ....
> VCC_PHONE off                                                                   
> VCC_PHONE off                                                                   
> VCC_PHONE off                                                                   
> VCC_PHONE off                                                                   
> WRAP DURING APPEND                                                              
> VVCC_PHONE off                                                                  
> RST                                                                             
> computed Fi(1) Di(1) ratio: 372                                                 
> VCC_PHONE on                                                                    
> found Fi=9 Di=6                                                                 
> computed Fi(9) Di(6) ratio: 16
> 
> I?m using also an Omnikey Cardman 3121.
> ?Gemalto .NET V2.0? supports baud rates up to 223Kbps. If you want me, I can sent you such a card for testing. Do you feel like testing such a card?
> 
> 
> On Mar 26, 2012, at 10:43 AM, Harald Welte wrote:
> 
>> It's quite funny.  What Fi/Di value is your card using?  Any idea what
>> the frequency on CLK is?
>> 
>> I have used a card with Fi/Di ratio of 64 on an Omnikey Cardman 3121 and
>> was unable to trigger the problem.  So in order to reproduce it, the CLK
>> frequency and Fi/Di values would help.
>> 
>> Also, when you look at the output of the statistics command on the
>> serial line, do you actually see the overrun counter increasing?
>