Incomplete trace (due to high-speed SIM?)

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
Thu Sep 5 05:47:46 UTC 2013


Hi Harald

I made a bunch of changes that significantly improved my test scenario:

Before the changes, the LTE SIM card being traced on a USB modem would
fairly consistently "restart" the simtrace board (I later found out that
the WDT was kicking in).  And the same sim card on a Galaxy SII phone would
get corrupted data (ie., wireshark would no longer be able to follow the
conversation)

The changes are as follow:

1) The req_ctx are loaded into a double-linked list for consistency (FIFO
manner).  Previously, in the old code when multiple req_ctx are ready for
transmit to USB, the lowered numbered (which may be the most recently
filled req_ctx) would always be transmitted first.  Additionally, to
simplify the queue, there is only a single sized req_ctx now,   1 kb.
There are 19 of them allocated.

2) The debug ring buffer is now transmitted using Peripheral DMA.  Receive
is left alone.  Also, the append/flush and AT..._PrintFrame is written to
allow for re-entrance (via Interrupt handler).  Additionally, debugp will
always prefix a line number to help / assist in debugging.

3) The watch dog (wdt.c) is modified so I can see when the watch dog is
activated (which it no longer does in my current test, so you can comment
out the #define WDT_DEBUG line...)

4) Both the usb interrupt and the uart interrupt handlers first enable core
interrupt so that the AIC can do interrupt nesting (I observed at least 1
uart overrun per DEBUGPCR prior to these changes)

5) Minor additional debugpcr in req_ctx_init and in udp_refill_ep to
indicate where the req_ctx are and containing what data to assist debug

Please review and comment

Issues I will work on further:

1) The first APDU after the ATR is almost always broken up (I don't think
it's due to my changes).  And occasionally, the length byte (p3?) sometimes
is missing (ONLY on this LTE sim card / MODEM).

2) I need the simtrace to transmit a complete APDU as soon as possible.  It
seems not consistent on when it sends out received data to the USB.
Sometimes, I would see GSM AUTHENTICATE apdu without a response for quiet a
while...

----

I would like to have an additional field (2 byte short) in the simtrace
header (the beginning of the req_ctx to indicate the position of the first
byte of an APDU, so that in the event the synchronization is lost, the pc
side can recover, because it appears the firmware code tracks the state of
the APDU so it should be able to indicate it.

Thanks

Best Regards



On Sat, Aug 24, 2013 at 4:05 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Min Xu,
>
> On Fri, Aug 09, 2013 at 10:54:28AM -1000, Min Xu wrote:
> > Thanks for getting back to me.  After analyzing the issue, I believe the
> > issue is the overrun error the USART reports.  The issue appear to stem
> > from the fact that each byte received by the USART is handled in the
> > interrupt handler, but the USB sending code locks out the interrupt for
> the
> > entirety of its call.
>
> Thanks again for analyzing the problem.  I was pondering to apply your
> patch, but think a different approach might be better:  Use the USART
> DMA mode.  Thiss way we don't get one interrupt per character, but one
> interrupt every 'dma buffer size' characters.  Using double buffering we
> should be able to always process one particular dma buffer, while the
> other buffer is being filled by the hardware without interrupts.
>
> Processing of the DMA buffer could happen either in an interrupt handler
> of the PDC (dma controller) or even in the main loop.
>
> Unfortunately the SAM7S USB controller does not support DMA, so it is
> impossible to improve on that side.
>
> I will give this some more thought.  If I'm unable to implement this
> within short time, I might merge your patch anyway as a interim fix.
>
> 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/20130904/127e7b02/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simtrace.diff
Type: application/octet-stream
Size: 36201 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20130904/127e7b02/attachment.obj>


More information about the simtrace mailing list