baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

Re: Regarding the cable from Dealextreme
by Dieter Spaar 18 Mar '10

18 Mar '10

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

1 0

Re: Regarding the cable from Dealextreme
by Dieter Spaar 18 Mar '10

18 Mar '10

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

1 0

Re: Regarding the cable from Dealextreme
by Dieter Spaar 18 Mar '10

18 Mar '10

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

3 2

jtag voltage
by Nathan Fain 18 Mar '10

18 Mar '10

I'm starting to look at the JTAG of the c155. does anyone know the VCC level the IC's are running at. JTAG lines will likely be the same. thanks

4 3

Re: Sim
by Dieter Spaar 18 Mar '10

18 Mar '10

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

7 11

C123 crashing (?)
by Patrick McHardy 17 Mar '10

17 Mar '10

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.

4 8

Re: Sim
by Dieter Spaar 16 Mar '10

16 Mar '10

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

3 2

Sim
by Sébastien Lorquet 16 Mar '10

16 Mar '10

(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

5 8

GSM overview
by Andreas.Eversberg 15 Mar '10

15 Mar '10

hi, i just found some valuable information this weekend at www.informatik.hu-berlin.de/~goeller/isdn/ an introduction into gsm tracing in german http://www.informatik.hu-berlin.de/~goeller/isdn/DieGSMDmKanaele.pdf and the same in english http://www.informatik.hu-berlin.de/~goeller/isdn/GSMDmChannels.pdf it gives a rough history of GSM development, GSM network structure, framing, encryption, coding, and services - in just 100 pages. for me it is usefull to verify my parsing of SYSTEM INFORMATION messages. it describes traces of the most importaint messages. andreas

1 0

Re: sercomm/osmocon cant send CMD after PROMPT1
by Dieter Spaar 15 Mar '10

15 Mar '10

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

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel