<div dir="ltr">Hi Min Xu,<div><br></div><div>I just sent you an e-mail a minute ago after finding this thread (<a href="https://lists.osmocom.org/pipermail/simtrace/2014-January/000621.html" target="_blank" style="font-size:12.8px">https://lists.<wbr>osmocom.org/pipermail/<wbr>simtrace/2014-January/000621.<wbr>html</a>).<br></div><div><br></div><div>I somehow missed that before - I will try to get the changes merged as Harald mentioned here (<a href="https://lists.osmocom.org/pipermail/simtrace/2014-October/000644.html">https://lists.osmocom.org/pipermail/simtrace/2014-October/000644.html</a>) in a way that will not break openocd.</div><div><br></div><div>Thanks for such quick response.</div><div>Lukas</div><div class="gmail-yj6qo gmail-ajU" style="margin:2px 0px 0px;font-size:12.8px"></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 1:37 AM, Min Xu <span dir="ltr"><<a href="mailto:min.xu@min-info.net" target="_blank">min.xu@min-info.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lukas<br>
<br>
I saw your email to my @<a href="http://sanjole.com" rel="noreferrer" target="_blank">sanjole.com</a> address but since this address is<br>
on the mailing list I'll just reply here so everyone can see.<br>
<br>
--- your email below ---<br>
Hi Min Xu,<br>
<br>
first of all thanks for all the work you put into simtrace.<br>
<br>
I’ve been testing your patches last couple days, they have not yet<br>
been in any release which I think is a shame, so I’d like to push the<br>
community to fix that so it can be even further tested (by testing,<br>
reporting back, fixing building the firmware with latest<br>
arm-none-eabi, etc.)<br>
<br>
I have found one bug for which I fail to identify the source .. The<br>
whole trace is fine except sometimes there are 4 bytes inside the data<br>
which seems to be the simtrace_hdr (first line is my debug):<br>
<br>
USB MSG: sh->cmd: 1, sh->flags: 0, sh->res[9, 5], payload: 00 a4 00 04<br>
02 a4 6f 07 61 2a 00 c0 00 00 2a c0 62 28 82 02 41 21 83 02 6f 07 a5<br>
0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06<br>
03 80 02 00 09 88 01 38 90 00 01 00 09 05 00 b0 00 00 09 b0 08 29 03<br>
30 10 66 03 91 12 90 00<br>
APDU: 00 a4 00 04 02 6f 07 61 2a<br>
APDU: 00 c0 00 00 2a 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0<br>
01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09<br>
88 01 38 90 00<br>
APDU: 01 00 09 05 00 b0 00<br>
APDU: 00 09 b0 08 29 03 30<br>
APDU: 10 66 03 91 12 90 00<br>
<br>
The 01 00 09 05 (which seems to be sh->cmd, sh->flags and Fi/Di (9/5)<br>
just randomly appear in APDU data every now and then. If those 4 bytes<br>
were not there apdu_split would split it fine .. like this it breaks<br>
this into nonsense pieces and breaks the trace.<br>
<br>
I’ve gone through your patches in the firmware, fiddled around with<br>
some of them but didn’t manage to find the root cause yet - seems like<br>
the simtrace_hdr is inserted in the middle (but that does not seem<br>
possible), so perhaps 2 USB messages somehow get merged into one?<br>
So I figured I’ll try to write you, maybe it will ring a bell - I have<br>
not fully verified the merge of your patches went correctly but from a<br>
fast compare it seems like it.<br>
<br>
If you’ll find a minute to give me a few tips I’ll appreciate that, in<br>
the meantime I’ll keep digging.<br>
<br>
PS: the version of FW I’m using is latest master in the git<br>
(<a href="https://git.osmocom.org/openpcd" rel="noreferrer" target="_blank">https://git.osmocom.org/<wbr>openpcd</a>).<br>
<br>
Thanks!<br>
Lukas<br>
--- END ---<br>
<br>
I believe the reason for this is actually in an email I sent to the<br>
list on Sep 10, 2013.<br>
<br>
Basically, the ATMEL chip can break up the req_ctx ( the usb response<br>
) and combine as it see fit (if there's a large burst etc). So you<br>
cannot rely on the "natural break" between the calls to transmit.<br>
Therefore, since it's a stream you'll get on receiving side, then a<br>
natural packet header that accounts of subsequent bytes must be added.<br>
<br>
So I added extra bytes into the simtrace_hdr header so that the actual<br>
data payload can be correctly accounted for.<br>
<br>
The changes are:<br>
<br>
struct simtrace_hdr {<br>
u_int8_t cmd;<br>
u_int8_t flags;<br>
u_int8_t res[2];<br>
+ u_int16_t seq_num;<br>
+ u_int16_t offset;<br>
+ u_int16_t tot_len;<br>
u_int8_t data[0];<br>
} __attribute__ ((packed));<br>
<br>
<br>
So the desktop client will have to have equivalent changes to account<br>
for these extra fields.<br>
<br>
Let me know if this answers your question. If not I can try send<br>
you the full code I have for the firmware and a sample of the desktop<br>
receiving / parsing code so you'll have a baseline.<br>
</blockquote></div><br></div>