Hi Lukas
I saw your email to my @sanjole.com address but since this address is on the mailing list I'll just reply here so everyone can see.
--- your email below --- Hi Min Xu,
first of all thanks for all the work you put into simtrace.
I’ve been testing your patches last couple days, they have not yet been in any release which I think is a shame, so I’d like to push the community to fix that so it can be even further tested (by testing, reporting back, fixing building the firmware with latest arm-none-eabi, etc.)
I have found one bug for which I fail to identify the source .. The whole trace is fine except sometimes there are 4 bytes inside the data which seems to be the simtrace_hdr (first line is my debug):
USB MSG: sh->cmd: 1, sh->flags: 0, sh->res[9, 5], payload: 00 a4 00 04 02 a4 6f 07 61 2a 00 c0 00 00 2a c0 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 01 00 09 05 00 b0 00 00 09 b0 08 29 03 30 10 66 03 91 12 90 00 APDU: 00 a4 00 04 02 6f 07 61 2a APDU: 00 c0 00 00 2a 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 APDU: 01 00 09 05 00 b0 00 APDU: 00 09 b0 08 29 03 30 APDU: 10 66 03 91 12 90 00
The 01 00 09 05 (which seems to be sh->cmd, sh->flags and Fi/Di (9/5) just randomly appear in APDU data every now and then. If those 4 bytes were not there apdu_split would split it fine .. like this it breaks this into nonsense pieces and breaks the trace.
I’ve gone through your patches in the firmware, fiddled around with some of them but didn’t manage to find the root cause yet - seems like the simtrace_hdr is inserted in the middle (but that does not seem possible), so perhaps 2 USB messages somehow get merged into one? So I figured I’ll try to write you, maybe it will ring a bell - I have not fully verified the merge of your patches went correctly but from a fast compare it seems like it.
If you’ll find a minute to give me a few tips I’ll appreciate that, in the meantime I’ll keep digging.
PS: the version of FW I’m using is latest master in the git (https://git.osmocom.org/openpcd).
Thanks! Lukas --- END ---
I believe the reason for this is actually in an email I sent to the list on Sep 10, 2013.
Basically, the ATMEL chip can break up the req_ctx ( the usb response ) and combine as it see fit (if there's a large burst etc). So you cannot rely on the "natural break" between the calls to transmit. Therefore, since it's a stream you'll get on receiving side, then a natural packet header that accounts of subsequent bytes must be added.
So I added extra bytes into the simtrace_hdr header so that the actual data payload can be correctly accounted for.
The changes are:
struct simtrace_hdr { u_int8_t cmd; u_int8_t flags; u_int8_t res[2]; + u_int16_t seq_num; + u_int16_t offset; + u_int16_t tot_len; u_int8_t data[0]; } __attribute__ ((packed));
So the desktop client will have to have equivalent changes to account for these extra fields.
Let me know if this answers your question. If not I can try send you the full code I have for the firmware and a sample of the desktop receiving / parsing code so you'll have a baseline.
Hi Min Xu,
I just sent you an e-mail a minute ago after finding this thread ( https://lists.osmocom.org/pipermail/simtrace/2014-January/000621.html).
I somehow missed that before - I will try to get the changes merged as Harald mentioned here ( https://lists.osmocom.org/pipermail/simtrace/2014-October/000644.html) in a way that will not break openocd.
Thanks for such quick response. Lukas
On Fri, Nov 3, 2017 at 1:37 AM, Min Xu min.xu@min-info.net wrote:
Hi Lukas
I saw your email to my @sanjole.com address but since this address is on the mailing list I'll just reply here so everyone can see.
--- your email below --- Hi Min Xu,
first of all thanks for all the work you put into simtrace.
I’ve been testing your patches last couple days, they have not yet been in any release which I think is a shame, so I’d like to push the community to fix that so it can be even further tested (by testing, reporting back, fixing building the firmware with latest arm-none-eabi, etc.)
I have found one bug for which I fail to identify the source .. The whole trace is fine except sometimes there are 4 bytes inside the data which seems to be the simtrace_hdr (first line is my debug):
USB MSG: sh->cmd: 1, sh->flags: 0, sh->res[9, 5], payload: 00 a4 00 04 02 a4 6f 07 61 2a 00 c0 00 00 2a c0 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 01 00 09 05 00 b0 00 00 09 b0 08 29 03 30 10 66 03 91 12 90 00 APDU: 00 a4 00 04 02 6f 07 61 2a APDU: 00 c0 00 00 2a 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 APDU: 01 00 09 05 00 b0 00 APDU: 00 09 b0 08 29 03 30 APDU: 10 66 03 91 12 90 00
The 01 00 09 05 (which seems to be sh->cmd, sh->flags and Fi/Di (9/5) just randomly appear in APDU data every now and then. If those 4 bytes were not there apdu_split would split it fine .. like this it breaks this into nonsense pieces and breaks the trace.
I’ve gone through your patches in the firmware, fiddled around with some of them but didn’t manage to find the root cause yet - seems like the simtrace_hdr is inserted in the middle (but that does not seem possible), so perhaps 2 USB messages somehow get merged into one? So I figured I’ll try to write you, maybe it will ring a bell - I have not fully verified the merge of your patches went correctly but from a fast compare it seems like it.
If you’ll find a minute to give me a few tips I’ll appreciate that, in the meantime I’ll keep digging.
PS: the version of FW I’m using is latest master in the git (https://git.osmocom.org/openpcd).
Thanks! Lukas --- END ---
I believe the reason for this is actually in an email I sent to the list on Sep 10, 2013.
Basically, the ATMEL chip can break up the req_ctx ( the usb response ) and combine as it see fit (if there's a large burst etc). So you cannot rely on the "natural break" between the calls to transmit. Therefore, since it's a stream you'll get on receiving side, then a natural packet header that accounts of subsequent bytes must be added.
So I added extra bytes into the simtrace_hdr header so that the actual data payload can be correctly accounted for.
The changes are:
struct simtrace_hdr { u_int8_t cmd; u_int8_t flags; u_int8_t res[2];
u_int16_t seq_num;u_int16_t offset;u_int16_t tot_len; u_int8_t data[0];} __attribute__ ((packed));
So the desktop client will have to have equivalent changes to account for these extra fields.
Let me know if this answers your question. If not I can try send you the full code I have for the firmware and a sample of the desktop receiving / parsing code so you'll have a baseline.
Another follow up.
We did discover there is a difference in how to power sim card. The power should ALWAYS be coming from PHONE, not from the SIMtrace board. Otherwise, a 3.3V may be fed back into the phone and "may" cause damage to the phone/device. This means that ONLY PWR_PASS should be used.
Depending on the parts (BOM) used on the board (our board has a different part in FPF2108.pdf which I think had a different Active mode from the one used /shipped from osmocom) you may have to check the configuration when setting the PWR_PASS code. So be sure to check your call, and the best way to confirm this is by disconnecting the SIMtrace from the phone, then power up the SIMtrace (plug-in the USB) WHILE having a digital multimeter probe the PINs on the VCC/GND pad of the SIM PCB connected to the SIMTrace. THERE SHOULD NOT BE A VOLTAGE ACROSS THE PADS.
On Thu, Nov 2, 2017 at 10:37 PM, Min Xu min.xu@min-info.net wrote:
Hi Lukas
I saw your email to my @sanjole.com address but since this address is on the mailing list I'll just reply here so everyone can see.
--- your email below --- Hi Min Xu,
first of all thanks for all the work you put into simtrace.
I’ve been testing your patches last couple days, they have not yet been in any release which I think is a shame, so I’d like to push the community to fix that so it can be even further tested (by testing, reporting back, fixing building the firmware with latest arm-none-eabi, etc.)
I have found one bug for which I fail to identify the source .. The whole trace is fine except sometimes there are 4 bytes inside the data which seems to be the simtrace_hdr (first line is my debug):
USB MSG: sh->cmd: 1, sh->flags: 0, sh->res[9, 5], payload: 00 a4 00 04 02 a4 6f 07 61 2a 00 c0 00 00 2a c0 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 01 00 09 05 00 b0 00 00 09 b0 08 29 03 30 10 66 03 91 12 90 00 APDU: 00 a4 00 04 02 6f 07 61 2a APDU: 00 c0 00 00 2a 62 28 82 02 41 21 83 02 6f 07 a5 0f 80 01 71 c0 01 00 91 04 7f 20 6f 07 92 01 00 8a 01 05 8b 03 6f 06 03 80 02 00 09 88 01 38 90 00 APDU: 01 00 09 05 00 b0 00 APDU: 00 09 b0 08 29 03 30 APDU: 10 66 03 91 12 90 00
The 01 00 09 05 (which seems to be sh->cmd, sh->flags and Fi/Di (9/5) just randomly appear in APDU data every now and then. If those 4 bytes were not there apdu_split would split it fine .. like this it breaks this into nonsense pieces and breaks the trace.
I’ve gone through your patches in the firmware, fiddled around with some of them but didn’t manage to find the root cause yet - seems like the simtrace_hdr is inserted in the middle (but that does not seem possible), so perhaps 2 USB messages somehow get merged into one? So I figured I’ll try to write you, maybe it will ring a bell - I have not fully verified the merge of your patches went correctly but from a fast compare it seems like it.
If you’ll find a minute to give me a few tips I’ll appreciate that, in the meantime I’ll keep digging.
PS: the version of FW I’m using is latest master in the git (https://git.osmocom.org/openpcd).
Thanks! Lukas --- END ---
I believe the reason for this is actually in an email I sent to the list on Sep 10, 2013.
Basically, the ATMEL chip can break up the req_ctx ( the usb response ) and combine as it see fit (if there's a large burst etc). So you cannot rely on the "natural break" between the calls to transmit. Therefore, since it's a stream you'll get on receiving side, then a natural packet header that accounts of subsequent bytes must be added.
So I added extra bytes into the simtrace_hdr header so that the actual data payload can be correctly accounted for.
The changes are:
struct simtrace_hdr { u_int8_t cmd; u_int8_t flags; u_int8_t res[2];
u_int16_t seq_num;u_int16_t offset;u_int16_t tot_len; u_int8_t data[0];} __attribute__ ((packed));
So the desktop client will have to have equivalent changes to account for these extra fields.
Let me know if this answers your question. If not I can try send you the full code I have for the firmware and a sample of the desktop receiving / parsing code so you'll have a baseline.
-
Lukas Kuzmiak -
Min Xu