Hello Chris,
On Thu, 18 Mar 2010 08:34:18 +0100, "Christian Vogel" <vogelchr(a)vogel.cx> wrote:
>
> Maxim alone has about a dozen variations of the MAX232 (max3232 for 3v3, e.g).
>
> It's much easier to directly go from USB to TTL/3v3 serial ports, the
> basic breakout boards from Sparkfun (e.g.
> http://www.watterott.com/de/FTDI-Basic-Breakout-33V) seem to be fine
> and sell for ?12. Haven't used them on a C123-phone, though.
Thanks for the info. I am a bit old-fashioned when it comes to
serial communication, I prefer to use "real" RS-232 because its
much more predictable with regards to timing. For the USB serial
adpaters it depends on the used interface chip. Of course for
"standard" serial communication where the timing is not critical
an USB serial adapter is just fine.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sebastien,
On Thu, 18 Mar 2010 08:07:23 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> You can now be sure: the 3.3v part is the MAX 3232.
> Other parts exists that need smaller capacitors (100nF) instead of 1-10uF
> required by the "grand father" MAX232 :)
Thanks for the update.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Lubomir,
On Thu, 18 Mar 2010 01:00:44 +0100, "Lubomir Schmidt" <gentoo.lubomir(a)googlemail.com> wrote:
>
> How can i change the cable to get it working? What is a
> level-converter and where can i get such?
The level of the RS-232 interface is specified to be -3V..-15V for a
logic one and +3V..+15V for a logic zero, typically -12V and +12V is
used. The phone uses 0V and 3.2V. So you need a level-converter between
the RS-232 port of a PC and the phone.
The simple solution is to use a ready-made data cable with a built-in
level-converter, they cost around 9.00 EUR on ebay Germany including
shipping, either as USB or RS-232 variant. If you really want to build
your own level-converter, you can for example use the MAX232 IC. The
MAX232 is for TTL level (0V and 5V), I think there is a variant for
3.2V available, however I am not 100% sure.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
Hello Sebastien,
On Tue, 16 Mar 2010 10:04:07 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> I know that smart card EEPROMS are rated for 100k writes, but I would not
> rely on that. In fact, this depends on how often is the EF.Kc file written,
> which was my original question. Every 30 seconds or every day? Every day is
> of course OK.
It is only written if an AUTHENTICATION REQUEST from the network is
performed. This usually happens when the phone is turned on and
does a location update. The network can also perform an AUTHENTICATION
REQUEST when doing a call or similar things, however usually this is
not done every time and the previous Kc stored on the SIM is reused
as Sylvain explained it. For OpenBSC and OpenBTS the default is that
there is no AUTHENTICATION REQUEST at all, so no Kc is written (I am
not 100% sure if this is true for OpenBTS, but I guess so).
> Additionally, how often are these other files written (LOCI, BCCH) ?
They are written when a location update is done or the cell changes.
However it depends on the phone if the data is really written to the
SIM every time, sometimes the phone caches those data and writes them
to the SIM only when the phone is turned off. For OpenBSC and OpenBTS
writing should not happen that often because there is usually only one
cell with fixed parameters. And I guess you will probably not actually
write to the EEPROM if the same data is already stored (or a least
the Card OS should do it this way).
> SmartCardFocus has a ID0 cutting service, that can turn any card into a SIM
> sized module:
> http://www.smartcardfocus.com/shop/ilp/id~82/p/index.shtml
> This is the best option I know so far.
Thanks, I did not know that. It would be interesting to know what tool
they use and if it is available for a reasonable price.
> However for devel purposes, as layer 2-3 will be developed on a PC, most
> people will need/use a PCSC reader and a normal sized card. Any javacard
> will do, even dual interface cards such as JCOP31 or Cosmo or older
> Cyberflex. my applet will have no specific requirement on javacard support,
> JC 2.1.x or 2.2.x will do.
Yes, sure.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
I'm trying to run the layer1 firmware and the layer23 program
with an C123, however as soon as the firmware reports a layer 1
reset and a L1CTL_NEW_CCCH_REQ message is sent to the phone,
it appears to crash and sends a new PROMPT1, causing an endless
cycle of firmware uploads and following crashes.
Bisection failed due to compiler errors, using trial-and-error
I found that the last instructions successfully executed are in
l1a_l23_rx_cb(), case L1CTL_NEW_CCCH_REQ, just before the
tpu_end_scenario() call. tpu_end_scenario() is what appears to
be triggering the crash, more specifically its the tpu_enable()
call in tpu_end_scenario().
Any hints how to debug this further?
For reference, this is the output of osmocon:
$ ./osmocon -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/compal_e88/layer1.bin
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.bin):
file_size=35848, hdr_len=4, dnload_len=35855
...
handle_write(): finished
Received DOWNLOAD ACK from phone, your code is running now!
Hello World from apps/layer1/main.c program code
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Dropping sample '~'
===
THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
hdlc_send_to_phone(dlci=5): 01 00 00 00 00 00 14 00
Received PROMPT1 from phone, responding with CMD
read_file(../../target/firmware/board/compal_e88/layer1.bin):
file_size=35848, hdr_len=4, dnload_len=35855
...
Received PROMPT2 from phone, starting download
and so on.
Hello Sebastien,
On Tue, 16 Mar 2010 00:09:46 +0100, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote:
>
> Sylvain, if I evolve your algorithm, then I think we don't need to store
> anything in EEPROM. Just keep that in RAM and force a renegociation at MS
> boot. What do you think of that?
Just a question: Why do you want to avoid writing Kc to the EEPROM ? The
cards I know have a quite huge number of EPPROM write cycles, e.g. for a
certain MULTOS card the number is specified to be 500.000. I don't know
the number for the card you use, but I expect it to be at least 100.000.
For our purpose this should be really good enough, I would expect more
writes to EF LOCI and EF BCCH than to EF KC.
A question to the list: does anyone know where to get a tool to
cut out a SIM from a standard smart card ? I don't prefer doing this
with a knife or similar, this might only be OK for one or two pieces
and the result also does not look too good.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
(sorry dexter , this was intended for the list - someone has to fix the
reply-to address of this group)
Hi all,
Tonight I worked on the sim implementation with javacard. I will update this
thread with my progress.
A few minutes ago, I completed the most important parts selection and
creation code, that allows me to create any directory structure on the card.
There is no security yet, only the highway to what is necessary. Side roads
will be added later.
My implementation has a Master File (MF) and the possibility to create
directories (Dedicated Files, DF) like in any unix file system. File
identifiers are 2 bytes long (Long identifier or LID). The MF is the tree
root, with LID 0x3F00, and DFs can be nested to "any" level.
I have a command to select directories, then create directories inside. this
is the equivalence of :
cd / (select MF)
cd .. (select parent DF)
cd <dir> (select a file with its LID, be it the parent, a brother or a
child)
mkdir <dir> (create DF)
Everything related to this is described in ISO7816-4 (creation in
ISO7816-9).
You'll be happy (or not) to find BER-TLV encoded data here, too.
I'm now focusing on having a ISO7816-4 compliant card applet whose code is
separated from the filesystem implementation. This way, I'll be able to
quickly switch from the ISO7816-4 commands to the TS 11.11 apdu commands.
This is only a matter of what information is returned from the SELECT FILE
apdu, and what selection modes are supported.
In the coming day I'll focus on data file (EF) implementation, along with
the READ and UPDATE commands.
Select commands allowing content browsing are planned too (select first/next
child)
The current code is not in the global git yet, I prefer keeping it in my
personal SVN until the first release. However if anyone is interested in
looking at the code, I can provide access to it.
Let me say this is quite specific code that will not be usable by everyone.
You need skills in javacard, globalplatform and smart cards in general.
Regards
Sebastien
PS: Guess the format of the current "Card FAT" :-)
idx ty sf lid fch nxt par
0000: 01 00 3F00 0001 FFFF FFFF
0001: 01 00 2000 0002 0003 0000
0002: 01 00 3000 FFFF 0004 0001
0003: 01 00 4000 FFFF FFFF 0000
0004: 01 00 5000 FFFF FFFF 0001
OK, that was easy, just a list of entries forming a tree with "next" "child"
and "parent" links. data files have a corresponding data block at the same
index in another list.
I can nest just everything I want, and create any number of files (well, atm
256, that is configurable, and the max file size is 32kB, that is fixed by
the max array size in javacard - signed short ) until the card is full.
tree corresponding to the list (index:file id):
0000:3F00
+--- 0001:2000
| +--- 0002:3000
| +--- 0004:5000
+--- 0003:4000
Hello Nathan,
On Sun, 14 Mar 2010 17:54:29 +0000, "Nathan Fain" <nat(a)fains.com> wrote:
>
> because i was on the python route I went ahead and wrote code all the way
> through uploading. I was expecting I would get a NACK but instead I get
> neither a NACK nor ACK but the following response after uploading hello
> world. Just curious if anyone has ever seen this before:
What you see looks like the strings inside the binary you send
to the phone. So your download code either echoes back what you
send or there is a problem with the cable (e.g. shortcut between
RX and TX). The phone usually does not echo back what it receives,
at least I never saw that.
Best regards,
Dieter
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
