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
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@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>
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?
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?
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
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.
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@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@gnumonks.org Cc: simtrace@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?
-
Harald Welte -
Myonium -
Peter Stuge