Fast SIM cards loosing bytes

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.

Min Xu mxu at sanjole.com
Tue Feb 4 19:10:51 UTC 2014


Hi Dean

I believe that you are seeing incomplete or partial (maybe even) ATRs.  I
believe I experienced something similar when I see parity error in the
debug messages (from the debug port).  The first byte of the ATR must be 3F
or 3B.  I believe the firmware code I currently have should NOT break and
ATR into multiple segments.  Besides, ATRs are transmitted in a single
frame, so there would not be an idle time to push out the partial ATR into
the USB transmit buffer.

So I believe you are having similar problem that I experienced when the
ribbon cable is twisted, or bent close together like a U (which might have
caused interference... )

Try get a serial cable plugged into the simtrace board, and capture the
debug output to see if parity error were seen.

Best regards




On Sun, Feb 2, 2014 at 4:40 AM, Dean Chester <dean.g.chester at gmail.com>wrote:

> Hi Min,
>
> I've just been using the new firmware with a different type of sim card
> and noticed that the ATR is scrambled, at least for the header of the ATR.
> The ATR is the same length as the one I had great success with. The cards
> are running at the same speed according to the ATRs however the new card
> seems to send it's ATR over 3 commands not just one. Whats also interesting
> is the ATR scrambling is different. Here is an example with the Simtrace
> Header attached:
>
> 01 01 01 01 01 00 00 00 1a 00 e7 9a 03 1f c7 80 31 00 00 00 00 00 00 00 00
> 00
> 01 00 01 01 02 00 00 00 0f 00 00 00 00 00 00
> 01 00 01 01 03 00 00 00 12 00 00 00 00 00 00 00 00 00
>
> And the ATR should look like:
>
> 3B 9F 96 80 1F C7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> And with the same card from the same company I got:
>
> 01 01 01 01 01 00 00 00 16 00 9f 96 80 1f c7 80 31 00 00 00 00 00
> 01 00 01 01 02 00 00 00 13 00 67 42 70 02 10 00 00 01 f9
> 01 00 01 01 03 00 00 00 12 00 ff 10 96 79 ff 10 96 79
>
> With the card I had success with I got the following input in:
>
> 01 01 01 01 01 00 00 00 20 00 3b 9f 96 80 1f c7 80 31 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00
>
> And the ATR looks like:
> 3b 9f 96 80 1f c7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
> Any ideas where these errors are coming from in the firmware. I notice
> that the lengths in the failed are equal to 3B which is the start of the
> ATR if thats of any help. The tests were done with the same phone connected
> to the tracer just swapping the sim cards.
>
> Kind Regards,
>
> Dean Chester
>
>
> On 30 January 2014 21:47, Min Xu <mxu at sanjole.com> wrote:
>
>> That does make sense to me since I had issues where before I changed the
>> usb header, the host was sometimes merging multiple req_ctx into a single
>> usb read.
>>
>> I am attaching a tar.gz file containing all my changes as separate git
>> commits / format-patches and hopefully it will get committed to the
>> repository.  This includes the latest change to the usb header as well as a
>> change (as Peter suggested) to the bDeviceProtocol in
>> usb_descriptors_openpcd.h, setting the new value to 0.
>>
>> Best Regards
>>
>>
>> On Thu, Jan 30, 2014 at 6:21 AM, Dean Chester <dean.g.chester at gmail.com>wrote:
>>
>>> It was mostly the lost bytes/scrambled data with a variety of handsets
>>> that i'd tested with, compared with ubuntu running natively.
>>>
>>> Dean
>>>
>>>
>>> On 27 January 2014 18:37, Min Xu <mxu at sanjole.com> wrote:
>>>
>>>> P.S.  What problems were you experiencing of it running in a
>>>> virtualized system, can you elaborate?
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Mon, Jan 27, 2014 at 8:36 AM, Min Xu <mxu at sanjole.com> wrote:
>>>>
>>>>> I am contributing it to the project.  Once I incorporate Peter Stuge's
>>>>> suggestion, hopefully within the next few weeks I will submit another
>>>>> commit.
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>> On Mon, Jan 27, 2014 at 1:05 AM, Dean Chester <
>>>>> dean.g.chester at gmail.com> wrote:
>>>>>
>>>>>> Thanks Min it works a treat it also fixes the issues running in a
>>>>>> virtualised environment which I do for Ubuntu.
>>>>>>
>>>>>> Is your new firmware under the same licence as the original?
>>>>>>
>>>>>> Kind Regards,
>>>>>>
>>>>>> Dean Chester
>>>>>>
>>>>>>
>>>>>> On 24 January 2014 21:55, Peter Stuge <peter at stuge.se> wrote:
>>>>>>
>>>>>>> Min Xu wrote:
>>>>>>> > I would be happy to send them the USB protocol changes.  However,
>>>>>>> > it will be INCOMPATIBLE with earlier firmware based SIMTrace
>>>>>>> boards.
>>>>>>>
>>>>>>> There is a standardised way to deal with protocol changes in USB;
>>>>>>> change either the bDeviceProtocol field in the device descriptor or
>>>>>>> the bInterfaceProtocol field in the interface descriptor, and make
>>>>>>> host software do the appropriate thing based on the descriptors of
>>>>>>> the connected device.
>>>>>>>
>>>>>>> Of course only new host software will work with the new protocol, but
>>>>>>> this way new host software still continues to work with the old
>>>>>>> protocol.
>>>>>>>
>>>>>>>
>>>>>>> //Peter
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20140204/cef80701/attachment.htm>


More information about the simtrace mailing list