23 Mar
2012
23 Mar
'12
12:12 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
25 Mar
25 Mar
11:16 a.m.
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(a)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>
26 Mar
26 Mar
10:43 a.m.
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?
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9:06 p.m.
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?
10:17 p.m.
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
9:29 p.m.
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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:50 p.m.
New subject: Fwd: New v0.5 simtrace firmware release
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(a)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(a)gnumonks.org>
Cc: simtrace(a)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?
4425
days inactive
4429
days old
7 comments
3 participants
participants (3)
-
Harald Welte -
Myonium -
Peter Stuge