From ml at mail.tsaitgaist.info Thu Dec 2 17:24:42 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Thu, 02 Dec 2010 18:24:42 +0100 Subject: simtrac hw In-Reply-To: <4CECCA23.1080802@mail.tsaitgaist.info> References: <20101121195349.GE26868@prithivi.gnumonks.org> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195644.10439.qmail@stuge.se> <4CE9BBAB.7020005@mail.tsaitgaist.info> <20101121222910.GJ26868@prithivi.gnumonks.org> <20101122024909.5149.qmail@stuge.se> <20101122112911.GY26868@prithivi.gnumonks.org> <6fbd9ccd-1145-4403-927b-08fa0d2fdd62@email.android.com> <4CECCA23.1080802@mail.tsaitgaist.info> Message-ID: <4CF7D65A.6050600@mail.tsaitgaist.info> I continued the hardware design I added : - a switch, to choose between SIMtrace and normal SC reader. the USB CCID profile could be loaded during boot. VCC can be supplied to power the SC. - switches for the SC presence, included in the sockets - LEDs to show the current mode (green=reader,yellow=emulator,blue=sniffer,red=MitM) - transistor array to control the LEDs, SC connections, and I/O line - line names - .... as I'm not an electrician, could someone check if this could work, resistors/capacitors are missing, .... here the schema : https://gsm.tsaitgaist.info/SIMtrac/v0.4/SIMtrac.ps Kevin On 24.11.2010 09:17, ml at mail.tsaitgaist.info wrote: > To be able to choose between 1.8v (class c) or 3.3v (class b), there is > a manual switch. The other solution would be to use logic level shifter. > > here the drawing : https://gsm.tsaitgaist.info/SIMtrac/v0.3/SIMtrac.ps > > kevin > From peter at stuge.se Sun Dec 12 21:27:21 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 12 Dec 2010 22:27:21 +0100 Subject: Sciphone's Versions and European Shops In-Reply-To: <415561.21392.qm@web29618.mail.ird.yahoo.com> References: <415561.21392.qm@web29618.mail.ird.yahoo.com> Message-ID: <20101212212721.6377.qmail@stuge.se> luca bongiorni wrote: > How i could ask to sellers for the best version? > (TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM) You basicall can't. You have to either find some metric that even sales droids can understand (a revision number on a sticker in the battery compartment maybe) or you just have to take your chances and buy something that may or may not work. //Peter From gndz.ali at gmail.com Thu Dec 2 15:49:15 2010 From: gndz.ali at gmail.com (=?ISO-8859-1?Q?Ali_G=FCnd=FCz?=) Date: Thu, 2 Dec 2010 16:49:15 +0100 Subject: Free Software GSM Talk in Berlin on Dec. 9th Message-ID: Hello all, I'm going to be giving a presentation about free software GSM implementations at the FSFE's Berlin meeting on December 9th, 2010. It will be very elementary and newcomer-friendly. I'm planning to go over OsmocomBB, OpenBTS and OpenBSC, and discuss their security and practical implications. The talk will start at 19:30 in Newthinking Store Tucholskystr. 48, 10117 Berlin. You can find more about it on http://aligunduz.org/blog/free_gsm_talk_next_week.html Considering I'm not an expert on GSM myself, it would be nice to have people more familiar with it in attendance. Ali G?nd?z From Marcin.Mielczarczyk at tieto.com Fri Dec 3 17:53:19 2010 From: Marcin.Mielczarczyk at tieto.com (Marcin.Mielczarczyk at tieto.com) Date: Fri, 3 Dec 2010 19:53:19 +0200 Subject: Sciphone G2 (MT6235) status Message-ID: <8716C48654180249A0941A44457B907508FFE7BE22@EXMB02.eu.tieto.com> Hi list, Last days I was focused on getting self-built code running from NAND memory and finally I got it working. You can find short demo which actually covers all the functionality which is currently working on Sciphone: http://www.youtube.com/watch?v=w_Iwsckm7Ko Here is the list of functionalities which are already working: * NAND memory driver with HW ECC control and MTK's ECC layout (ECC layout is important for loading SPL, creating dumps of firmware and restoring it). NAND driver also supports all the NAND memories found so far on Sciphone G2 (small page and large page). * SD/MMC card support * LCD driver (automatically detects LCD controller, so far identified two different LCD controllers mounted in G2: ILI9331 and ILI9325) * tool for creating bootable image from given binary file (should work on all MT62xx chips). It doesn't need to be SPL (from U-Boot), it can be self-built binary which will be run by IPL on the phone (not bigger than 64kB). * automatic detection of RAM memory in SPL (two configurations checked) - this will be added by Steve to osmocon loader as well * BBT and ENV can be saved in NAND (BBT in NAND is disabled by default, as deletes last two NAND blocks, and most people are running from RAM) I also updated wiki with informations about new features added: http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 Open issues: * LCD controller is using the same data lines as NFI (NAND) controller. Currently it's not possible to use NAND when LCD is enabled. * vibrator in SPL code - vibrator will be turned on in SPL when it'll start reading NAND and turned off when it'll finish, thanks to that user will know that SPL code has started (short code which doesn't change SPL size). * boot process from NAND has been tested only on small page NAND device - I'll create dump of my second phone and try this process on large page NAND device as well I recommend to create full NAND dump before playing with new software. There is already driver for NAND running and you can erase/write NAND easily by mistake. I turned on define CONFIG_ENV_IS_IN_NAND, which will not erase/write NAND at start, but when you execute "saveenv" command it'll do so. Please, make NAND dump first. The problem with NAND dump is that I haven't found built-in functionality in U-Boot that sends dump of RAM memory (where NAND will be read) to PC/SD card. Dump also has to be created in chunks, as there is less RAM memory than NAND. I'm planning to create dump/restore commands which will save/restore dumps using SD card, but I didn't start it yet. Currently the easiest way is to create dump in FlashTool. I checked that restoring of phone using dump created in FlashTool works, so going back to previous firmware is possible. Unfortunatelly code for LCD driver is not yet in git as my coleague didn't manage to finish it today. Hopefully it'll be available during weekend or beginning next week. Now I'm going to switch to Linux kernel side and start writing drivers there... Other good new is that Andrew has reported last week that he successfully run our code on E1000 chinese phone which is also based on MT6235. There was no need to make any changes. Here is how E1000 phone looks like: http://triray.en.made-in-china.com/product/kbYJeomynHhs/China-N97-WiFi-Java-TV-Quad-Band-Sliding-Phone-E1000-.html BR, Marcin From aifiltr0 at invyl.ath.cx Fri Dec 3 20:01:07 2010 From: aifiltr0 at invyl.ath.cx (Andrew) Date: Fri, 03 Dec 2010 23:01:07 +0300 Subject: Sciphone G2 (MT6235) status In-Reply-To: <8716C48654180249A0941A44457B907508FFE7BE22@EXMB02.eu.tieto.com> References: <8716C48654180249A0941A44457B907508FFE7BE22@EXMB02.eu.tieto.com> Message-ID: On Fri, 3 Dec 2010 19:53:19 +0200, wrote: > Hi list, > Hi Marcin, thanks for the update. I have been working recently on 3 things with my E1000: As you suggested, I have tried to make a nand backup, which was of no good: the nand just doesn't want to be read past 256 KiB (2 sectors) and UART is still acting weird on 52 Mhz AHBx4. 26Mhz seem to fix the issue, but I have not yet managed to make RAM work on that frequency yet. I still have that weird uart bug, that makes dumping via uart impossible, but I guess that dumping to an SD card can be a solution. USB loader is still work in progress - I'm not very familiar with USB (No more than implementing USB devices with vusb stack on AVRs), so it takes time to read the specs. I have also looked into the keypad driver and even made a more or less working draft - keypad driver should be working some time next week - I'll send the patch to the list. Regards, Andrew. > BR, > Marcin From laforge at gnumonks.org Sat Dec 4 13:27:42 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 4 Dec 2010 21:27:42 +0800 Subject: Sciphone G2 (MT6235) status In-Reply-To: <8716C48654180249A0941A44457B907508FFE7BE22@EXMB02.eu.tieto.com> References: <8716C48654180249A0941A44457B907508FFE7BE22@EXMB02.eu.tieto.com> Message-ID: <20101204132742.GA31879@prithivi.gnumonks.org> Marcin, once again congratulations on your progress, and thanks for the update. I wish I could actually jump in and also do some work on the non-GSM related Linux drivers, but I'm currently too busy with other projects. However, I still intend to work on the GSM part of the MTK chipsets, probably from January 2011 onwards. I've already spent quite some time reading thorugh the various MT623x and MT6139/6140 data sheets and other documentation that we found, and I believe I have a pretty good idea how everything works - with the exception of the details of the DSP/ARM interface that is not documented anywhere. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From libosmocore-2010 at mrq1.org Tue Dec 7 18:31:06 2010 From: libosmocore-2010 at mrq1.org (Hermann Gausterer) Date: Tue, 7 Dec 2010 19:31:06 +0100 Subject: [PATCH] protocol: typofix for gsm_03_41.h In-Reply-To: <4CFE79E6.3060807@gmail.com> References: <20101207163627.GA4003@mrq1.org> <4CFE79E6.3060807@gmail.com> Message-ID: <20101207183106.GA5519@mrq1.org> On Tue, Dec 07, 2010 at 08:16:06PM +0200, Alex Badea wrote: > On 12/07/2010 06:36 PM, Hermann Gausterer wrote: > >Small typo in the second Serial Number Octet > > > >Signed-off-by: Hermann Gausterer > > Good catch, thanks! > > You should send this patch to baseband-devel at lists.osmocom.org such > that one of the maintainers can apply it. > > Thanks, > Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-protocol-typofix-for-gsm_03_41.h.patch Type: text/x-diff Size: 870 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From duanelew at gmail.com Wed Dec 8 14:17:38 2010 From: duanelew at gmail.com (Duane Lew) Date: Wed, 8 Dec 2010 09:17:38 -0500 Subject: MT6235/6140 and MT6516? Message-ID: Dear Members, I incidentally see your development of linux drivers for MT6235/6140 chipset(the sciphone G2), and wanna share my 50 cents: The year 2009 released AP+BB monolithic chip MT6156 from mediatek is an ARM9 AP + ARM7 BB (the old MT6235 is ARM9 AP, MT6140 is ARM7 BB), considering the timeline of mediatek processors, it should be conjectured that MT6516 is a combination of these two chips. They already have Windows mobile 6.5 drivers mature for MT6516, and they have android drivers (not only driver but the whole system image), which might be an important referenece for developing MT6235 linux drivers. So I believe it's a good idea to ask MTK for its MT6516 linux driver and see what can be ported. Best for all, Duane From Marcin.Mielczarczyk at tieto.com Wed Dec 8 20:03:21 2010 From: Marcin.Mielczarczyk at tieto.com (Marcin.Mielczarczyk at tieto.com) Date: Wed, 8 Dec 2010 22:03:21 +0200 Subject: MT6235/6140 and MT6516? In-Reply-To: References: Message-ID: <8716C48654180249A0941A44457B907508FFF09A6E@EXMB02.eu.tieto.com> Hi Duane, > They already have Windows mobile 6.5 drivers mature for MT6516, and they > have android drivers (not only driver but the whole system image), > which might be an important referenece for developing MT6235 linux > drivers. So I believe it's a good idea to ask MTK for its MT6516 > linux driver and see what can be ported. Thanks for pointing out MT6516 which is pretty interesting as it's ARM926EJ-S running at 416MHz (twice bigger frequency than MT6235). I just looked through MT6516 datasheet and it seems that basic peripherals like GPIO, IRQ controller, keypad controller, timers, UARTs are the same (just amount of some of these peripherals is different). For these peripherals we already have Linux drivers. If it comes to more complex peripherals, like NAND controller or LCD controller, they are different on MT6516. Seems that they are redesigned and improved when comparing to MT62xx (in case of NAND there is new ECC block). Differences between peripherals of MT6235 and MT622x are really small and in case of MT6516 these differences are fundamental. Of course I looked just at some of the peripherals I already know, didn't go through whole datasheet. From dw at botanicus.net Thu Dec 9 03:33:02 2010 From: dw at botanicus.net (David Wilson) Date: Thu, 9 Dec 2010 03:33:02 +0000 Subject: [PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X. Message-ID: <20101209033302.GA92863@eldil.flat> --- src/host/layer23/src/common/l1l2_interface.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/host/layer23/src/common/l1l2_interface.c b/src/host/layer23/src/common/l1l2_interface.c index e72b86e..08ef7be 100644 --- a/src/host/layer23/src/common/l1l2_interface.c +++ b/src/host/layer23/src/common/l1l2_interface.c @@ -118,9 +118,10 @@ int layer2_open(struct osmocom_ms *ms, const char *socket_path) local.sun_path[sizeof(local.sun_path) - 1] = '\0'; rc = connect(ms->l2_wq.bfd.fd, (struct sockaddr *) &local, - sizeof(local.sun_family) + strlen(local.sun_path)); + sizeof(local)); if (rc < 0) { - fprintf(stderr, "Failed to connect to '%s'.\n", local.sun_path); + fprintf(stderr, "Failed to connect to '%s': %s\n", local.sun_path, + strerror(errno)); close(ms->l2_wq.bfd.fd); return rc; } -- 1.7.3.2 -- Computers are useless. They can only give you answers. -- Pablo Picasso From holger at freyther.de Thu Dec 9 07:05:41 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 09 Dec 2010 08:05:41 +0100 Subject: [PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X. In-Reply-To: <20101209033302.GA92863@eldil.flat> References: <20101209033302.GA92863@eldil.flat> Message-ID: <4D007FC5.7050008@freyther.de> On 12/09/2010 04:33 AM, David Wilson wrote: any more verbose commit message? What issue did you face? What is your reference? From laforge at gnumonks.org Thu Dec 9 13:23:26 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 9 Dec 2010 21:23:26 +0800 Subject: [PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X. In-Reply-To: <4D007FC5.7050008@freyther.de> References: <20101209033302.GA92863@eldil.flat> <4D007FC5.7050008@freyther.de> Message-ID: <20101209132326.GT10791@prithivi.gnumonks.org> Hi Zecke, On Thu, Dec 09, 2010 at 08:05:41AM +0100, Holger Hans Peter Freyther wrote: > On 12/09/2010 04:33 AM, David Wilson wrote: > > any more verbose commit message? What issue did you face? What is your > reference? my suggestion is that he was using a non-linux platform (specifically MacOS) which has slightly different layout of the socket address structure. In any case, sizeof() the entire structure is correct, not size of the two members (which is ignoring any padding, etc.) nonetheless, a more detailed description would be helpful so we don't have to guess... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dw at botanicus.net Thu Dec 9 13:35:27 2010 From: dw at botanicus.net (David Wilson) Date: Thu, 9 Dec 2010 13:35:27 +0000 Subject: [PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X. In-Reply-To: <20101209132326.GT10791@prithivi.gnumonks.org> References: <20101209033302.GA92863@eldil.flat> <4D007FC5.7050008@freyther.de> <20101209132326.GT10791@prithivi.gnumonks.org> Message-ID: That's indeed the case, on OS X connect() will fail with ENOENT unless the correct size is used. I just noticed I've changed the formatting in that patch. Is there a particular code style adhered to? With this patch, the pl2303 driver from http://www.prolific.com.tw/eng/downloads.asp?id=31 , /dev/tty.usbserial , MacPorts arm-elf-gcc and RANLIB=arm-elf-ranlib, things appear to just work on OS X. I will try to send another patch for the ranlib change (system ranlib on OS X is Mach O). Finally is there a good default set of git format-patch flags to use? That was my first ever attempt, and in particular the git log message didn't make it into the body at all. David On 9 December 2010 13:23, Harald Welte wrote: > Hi Zecke, > > On Thu, Dec 09, 2010 at 08:05:41AM +0100, Holger Hans Peter Freyther wrote: >> On 12/09/2010 04:33 AM, David Wilson wrote: >> >> any more verbose commit message? What issue did you face? What is your >> reference? > > my suggestion is that he was using a non-linux platform (specifically MacOS) > which has slightly different layout of the socket address structure. > > In any case, sizeof() the entire structure is correct, not size of the two > members (which is ignoring any padding, etc.) > > nonetheless, a more detailed description would be helpful so we don't have > to guess... > > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) > > From 246tnt at gmail.com Thu Dec 9 16:36:42 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 9 Dec 2010 17:36:42 +0100 Subject: [PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X. In-Reply-To: References: <20101209033302.GA92863@eldil.flat> <4D007FC5.7050008@freyther.de> <20101209132326.GT10791@prithivi.gnumonks.org> Message-ID: > I just noticed I've changed the formatting > in that patch. Is there a particular code style adhered to? Linux Kernel style ( Documentation/CodingStyle in the kernel sources ) From peter at stuge.se Thu Dec 9 22:55:33 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 9 Dec 2010 23:55:33 +0100 Subject: [PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X. In-Reply-To: References: <20101209033302.GA92863@eldil.flat> <4D007FC5.7050008@freyther.de> <20101209132326.GT10791@prithivi.gnumonks.org> Message-ID: <20101209225533.18102.qmail@stuge.se> David Wilson wrote: > Finally is there a good default set of git format-patch flags to use? See also git send-email. //Peter From laforge at gnumonks.org Sat Dec 11 03:32:41 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 11 Dec 2010 11:32:41 +0800 Subject: [PATCH] connect's addrlen should be sizeof(local), not the contained path's length. Permits layer23 to work on OS X. In-Reply-To: References: <20101209033302.GA92863@eldil.flat> <4D007FC5.7050008@freyther.de> <20101209132326.GT10791@prithivi.gnumonks.org> Message-ID: <20101211033241.GD26844@prithivi.gnumonks.org> Thanks David, I've applied your patch, fixed the formatting change and committed it to my local tree. Will push to master soon. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From n6vale at googlemail.com Thu Dec 9 12:27:25 2010 From: n6vale at googlemail.com (Simon Barnett) Date: Thu, 9 Dec 2010 12:27:25 +0000 Subject: Osmocom SIMtrace Message-ID: Hi All, I'm not 100% sure this is the right place to post this really, maybe someone can point me in the right direction if I'm in the wrong place. I'm trying to build the Osmocom SIMtrace firmware, but so far I'm not having much luck When I try to make it I get the following output: - make -f Makefile.dfu BOARD=OLIMEX -------- begin (mode: RUN_FROM_ROM) -------- arm-elf-gcc (GCC) 4.0.2 Copyright ? 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. scripts/mkcompile_h > include/compile.h svn: '.' is not a working copy svn: warning: '.' is not a working copy make: *** No rule to make target `src/simtrace/usb_strings_dfu.txt', needed by `src/simtrace/usb_strings_dfu.h'. Stop. Has anyone got any ideas how I might be able to fix this? Thanks, Simon From laforge at gnumonks.org Thu Dec 9 16:02:45 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 10 Dec 2010 00:02:45 +0800 Subject: Osmocom SIMtrace In-Reply-To: References: Message-ID: <20101209160245.GH13457@prithivi.gnumonks.org> On Thu, Dec 09, 2010 at 12:27:25PM +0000, Simon Barnett wrote: > I'm trying to build the Osmocom SIMtrace firmware, but so far I'm not > having much luck As indicted in private mail: There was one file missing from the git tree, it has been fixed. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From n6vale at googlemail.com Sun Dec 12 22:52:19 2010 From: n6vale at googlemail.com (Simon Barnett) Date: Sun, 12 Dec 2010 22:52:19 +0000 Subject: Osmocom SIMtrace In-Reply-To: <20101209160245.GH13457@prithivi.gnumonks.org> References: <20101209160245.GH13457@prithivi.gnumonks.org> Message-ID: Thanks for this, its much appreciated - it builds now. I've got an AT91SAM7S64 board with an Olimex ARM-USB-OCD JTAG debugger, however, I'm having trouble figuring out how to flash the board with your firmware. I've done quite a bit of research looking into how to flash the device, but haven't found anything yet that I can get to work. How do you suggest that I flash the firmware? Thanks for your help, Simon On 9 December 2010 16:02, Harald Welte wrote: > On Thu, Dec 09, 2010 at 12:27:25PM +0000, Simon Barnett wrote: > >> I'm trying to build the Osmocom SIMtrace firmware, but so far I'm not >> having much luck > > As indicted in private mail: ?There was one file missing from the git > tree, it has been fixed. > > -- > - Harald Welte ? ? ? ? ? http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(ETSI EN 300 175-7 Ch. A6) > From laforge at gnumonks.org Mon Dec 13 07:06:22 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 13 Dec 2010 08:06:22 +0100 Subject: Osmocom SIMtrace In-Reply-To: References: <20101209160245.GH13457@prithivi.gnumonks.org> Message-ID: <20101213070622.GI26844@prithivi.gnumonks.org> On Sun, Dec 12, 2010 at 10:52:19PM +0000, Simon Barnett wrote: > Thanks for this, its much appreciated - it builds now. > > I've got an AT91SAM7S64 board with an Olimex ARM-USB-OCD JTAG > debugger, however, I'm having trouble figuring out how to flash the > board with your firmware. I've done quite a bit of research looking > into how to flash the device, but haven't found anything yet that I > can get to work. > > How do you suggest that I flash the firmware? http://www.openpcd.org/Firmware#Flashing_a_complete_flash_image_.28using_SAM-BA.29 i.e. you first 'cat dfu.bin main_simtrace.bin > main_simtrace.samba' and then follow the SAM-BA flashing sequence for flashing the first time (bootloader + simtrace firmware). All this happens over USB, no need for a debugger. From stefan at datenfreihafen.org Mon Dec 13 15:40:25 2010 From: stefan at datenfreihafen.org (Stefan Schmidt) Date: Mon, 13 Dec 2010 16:40:25 +0100 Subject: Osmocom SIMtrace In-Reply-To: <20101213070622.GI26844@prithivi.gnumonks.org> References: <20101209160245.GH13457@prithivi.gnumonks.org> <20101213070622.GI26844@prithivi.gnumonks.org> Message-ID: <20101213154025.GF31742@excalibur.local> Hello. On Mon, 2010-12-13 at 08:06, Harald Welte wrote: > > From the first time on, you can then use the DFU method to simply flash > main_simtrace.bin, using dfu-util from http://dfu-util.gnumonks.org And please use the version from git here as the 0.2 release has a bug that prevents it from working with sam7dfu. I should bring out a new release for this sometime soon... regards Stefan Schmidt From bouchtaoui at gmail.com Mon Dec 13 08:49:28 2010 From: bouchtaoui at gmail.com (Nordin) Date: Mon, 13 Dec 2010 09:49:28 +0100 Subject: Osmocom SIMtrace In-Reply-To: References: <20101209160245.GH13457@prithivi.gnumonks.org> Message-ID: <4D05DE18.8040407@gmail.com> I've done some sam7A3 and sam7s256 development a few years ago, but normally you have tools for that. I was using a commercial one IAR, but there are opensource alternatives, you can google for it. Have you ever tried flashing sam7S64 microntroller? Cause you don't really need to figure out how flash work, you just need the right tool which loads the firmware into the uC. On 12-12-2010 23:52, Simon Barnett wrote: > Thanks for this, its much appreciated - it builds now. > > I've got an AT91SAM7S64 board with an Olimex ARM-USB-OCD JTAG > debugger, however, I'm having trouble figuring out how to flash the > board with your firmware. I've done quite a bit of research looking > into how to flash the device, but haven't found anything yet that I > can get to work. > > How do you suggest that I flash the firmware? > > Thanks for your help, > > Simon > > > On 9 December 2010 16:02, Harald Welte wrote: >> On Thu, Dec 09, 2010 at 12:27:25PM +0000, Simon Barnett wrote: >> >>> I'm trying to build the Osmocom SIMtrace firmware, but so far I'm not >>> having much luck >> As indicted in private mail: There was one file missing from the git >> tree, it has been fixed. >> >> -- >> - Harald Welte http://laforge.gnumonks.org/ >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. A6) >> > From laforge at gnumonks.org Sat Dec 11 03:28:12 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 11 Dec 2010 11:28:12 +0800 Subject: [ADM] Please try to avoid merges in the git tree Message-ID: <20101211032812.GC26844@prithivi.gnumonks.org> Hi all, this is just a general request to everyone with git commit access on the OpenBSC / Osmocom repositories. I would appreciate to restrict the use of 'git merge' to the absolute minimum neccessarry, as it makes the commitlog and timeline much harder to understand. If you're working on some private branch on a particular feature, please rebase that private branch on current master before pushing the changes. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Sat Dec 11 20:55:49 2010 From: peter at stuge.se (Peter Stuge) Date: Sat, 11 Dec 2010 21:55:49 +0100 Subject: [ADM] Please try to avoid merges in the git tree In-Reply-To: <20101211032812.GC26844@prithivi.gnumonks.org> References: <20101211032812.GC26844@prithivi.gnumonks.org> Message-ID: <20101211205549.21419.qmail@stuge.se> Harald Welte wrote: > If you're working on some private branch on a particular feature, please > rebase that private branch on current master before pushing the changes. Avoid automatic merges by setting rebase=true on branches. (Equivalent of git pull --rebase) //Peter From andreas at galauner.de Mon Dec 13 05:56:13 2010 From: andreas at galauner.de (Andreas Galauner) Date: Mon, 13 Dec 2010 06:56:13 +0100 Subject: Qualcomm documentation Message-ID: <4D05B57D.8050909@galauner.de> Hello everybody, last year I stumbled upon a PDF which describes all registers inside the Qualcomm MSM7200 series chipset. I now got a new mobile phone and remembered about that document because wanted to play a bit with my old one (HTC Magic/Sapphire/G2/Ion). I googled a few hours now and found several documents from Qualcomm, but I just found a whole svn repository full of Documentation [1]. Those Qualcomm chipsets are particularly interesting, because, due to Android, there already is a Linux kernel for the ARM11 core available. The missing part is a free implementation of the ARM9 baseband. My next goal is, as soon as I managed to solder cables to the JTAG pins covered in epoxy, to get own code running on the ARM9. I don't know how hard this will get, because this chipset has several security features like signature checking of code, fusebits for security configuration etc., but I will give it a try. JTAG definitely is still activated, because several people developed a method to unbrick their phones in case they have a bad ARM11 bootloader. And even if there is no chance to get own code running right away, I'm pretty certain that there somewhere is a buffer overflow which is exploitable. Either inside the baseband itself or in the serial console command parser of the early bootloaders provided by the OEM (OEMSBL). Time will tell. I hope I've got something to show you at the 27C3. My problem is that I don't have enough experience and knowledge about GSM yet to estimate if all this documentation is sufficient to implement a real baseband software on this chipset. If it's not, I think it's pointless to invest several days/nights of work to get own code running. Maybe somebody of you can have a quick look over the repository and the documents? Thanks, Andy [1]: http://code.google.com/p/ptwcdma/source/browse/ From frank at hvitehus.no Mon Dec 13 07:22:29 2010 From: frank at hvitehus.no (Frank A. Stevenson) Date: Mon, 13 Dec 2010 08:22:29 +0100 (CET) Subject: Qualcomm documentation In-Reply-To: <4D05B57D.8050909@galauner.de> References: <4D05B57D.8050909@galauner.de> Message-ID: <64207.178.74.36.49.1292224949.squirrel@mail1.webfaction.com> My advice to you would be to nip this idea in the bud so to speak. I have extensive knowledge of the Qualcomm platform. You will find that the low level radio stuff is handled at the DSP level, and there is some good layer1,2,3 code that interfaces with the DSP. However above this level code quality quickly goes south. (Making it very hard to work with) On the Android devices, I suspect that Linux is running in user space under the L4 microkernel that now powers all Qualcomm devices. And they layer123 API will be inaccessible from Linux, which can only communicate to the legacy code through supplied APIs & L4 intraprocess communication. Even if you could build from source, what you suggest would be a daunting task :-o regards, Frank > Hello everybody, > last year I stumbled upon a PDF which describes all registers inside the > Qualcomm MSM7200 series chipset. I now got a new mobile phone and > remembered about that document because wanted to play a bit with my old > one (HTC Magic/Sapphire/G2/Ion). > I googled a few hours now and found several documents from Qualcomm, but > I just found a whole svn repository full of Documentation [1]. > ... > My problem is that I don't have enough experience and knowledge about > GSM yet to estimate if all this documentation is sufficient to implement > a real baseband software on this chipset. If it's not, I think it's > pointless to invest several days/nights of work to get own code running. > Maybe somebody of you can have a quick look over the repository and the > documents? > > Thanks, > Andy > > [1]: http://code.google.com/p/ptwcdma/source/browse/ > From laforge at gnumonks.org Mon Dec 13 16:15:27 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 13 Dec 2010 17:15:27 +0100 Subject: Qualcomm documentation In-Reply-To: <64207.178.74.36.49.1292224949.squirrel@mail1.webfaction.com> References: <4D05B57D.8050909@galauner.de> <64207.178.74.36.49.1292224949.squirrel@mail1.webfaction.com> Message-ID: <20101213161527.GP26844@prithivi.gnumonks.org> Hi Frank, On Mon, Dec 13, 2010 at 08:22:29AM +0100, Frank A. Stevenson wrote: > On the Android devices, I suspect that Linux is running in user space > under the L4 microkernel that now powers all Qualcomm devices. You are wrong. All Android smartphones (with the exception of some legacy ST-Ericsson devices) contain an independent ARM processor for the Baseband and Application side. The BP (in the QC case) runs L4 + AMSS (their stack), the AP runs Linux natively without any hypervisor. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From drasko.draskovic at gmail.com Mon Dec 13 16:33:58 2010 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Mon, 13 Dec 2010 17:33:58 +0100 Subject: Qualcomm documentation In-Reply-To: <20101213161527.GP26844@prithivi.gnumonks.org> References: <4D05B57D.8050909@galauner.de> <64207.178.74.36.49.1292224949.squirrel@mail1.webfaction.com> <20101213161527.GP26844@prithivi.gnumonks.org> Message-ID: On Mon, Dec 13, 2010 at 5:15 PM, Harald Welte wrote: > You are wrong. ?All Android smartphones (with the exception of some legacy > ST-Ericsson devices) contain an independent ARM processor for the Baseband > and Application side. ?The BP (in the QC case) runs L4 + AMSS (their stack), > the AP runs Linux natively without any hypervisor. Why do they need L4 if they are running just one container with AMSS ? Is there something else running on BP in L4 apart from AMSS (some other OS or RT apps) ? BR, Drasko From laforge at gnumonks.org Mon Dec 13 17:03:52 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 13 Dec 2010 18:03:52 +0100 Subject: Qualcomm documentation In-Reply-To: References: <4D05B57D.8050909@galauner.de> <64207.178.74.36.49.1292224949.squirrel@mail1.webfaction.com> <20101213161527.GP26844@prithivi.gnumonks.org> Message-ID: <20101213170352.GU26844@prithivi.gnumonks.org> Hi Drasko, On Mon, Dec 13, 2010 at 05:33:58PM +0100, Drasko DRASKOVIC wrote: > On Mon, Dec 13, 2010 at 5:15 PM, Harald Welte wrote: > > You are wrong. ?All Android smartphones (with the exception of some legacy > > ST-Ericsson devices) contain an independent ARM processor for the Baseband > > and Application side. ?The BP (in the QC case) runs L4 + AMSS (their stack), > > the AP runs Linux natively without any hypervisor. > > Why do they need L4 if they are running just one container with AMSS ? > Is there something else running on BP in L4 apart from AMSS (some > other OS or RT apps) ? not in the smartphone (dual-core) designs like the MSM7200A or the Snapdragon. Of course, there are feature phones which only have a single core, e.g. built around the MSM6275 or MSM6280, which then run BREW and various BREW applications on top of the same L4. you can compare the baseband processor part in a smart phoen more like the USB GSM/3G Modem case: No UI and no application software on the BP. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 775725965 at qq.com Tue Dec 14 08:50:15 2010 From: 775725965 at qq.com (=?gbk?B?wvPM78rYzfs=?=) Date: Tue, 14 Dec 2010 16:50:15 +0800 Subject: MTK chip for GSM USRP Message-ID: Hello everybody I want to develop USB Interface USRP Use MTK 6218 chip, But no Firmware Source Code 6218 is ARM Core 'USE it is a GSM Way of USRP .Friends if you Have to know Please contact me -------------- next part -------------- An HTML attachment was scrubbed... URL: From 775725965 at qq.com Wed Dec 15 06:18:50 2010 From: 775725965 at qq.com (=?gbk?B?wvPM78rYzfs=?=) Date: Wed, 15 Dec 2010 14:18:50 +0800 Subject: Price Cheap of USRP for openbts and GSM Message-ID: Hello everybody you may have USRP ???????????????????????????????????? ????Simple?????Practical?????????Development???Contact??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahuemer at cosy.sbg.ac.at Thu Dec 16 22:06:49 2010 From: ahuemer at cosy.sbg.ac.at (Alexander Huemer) Date: Thu, 16 Dec 2010 23:06:49 +0100 Subject: sciphone g2 connector Message-ID: <4D0A8D79.6000900@cosy.sbg.ac.at> hi, i want to make a cable for the sciphone g2 that provides serial communication and charging with one connector. unfortunately the pictures at [1] aren't clear enough for me. i don't want to kill my phone. actually i count 15 pins in the picture, where mine has only 12. that's weird. i guess that 2 are just for aligning the case, but that still makes 13 vs. 12. i tried to ascii draw the connector from the back (soldering) side. the rounded half of the connector on the upper side. The pins i found described elsewhere on the internet are already marked. -------------------------- ( ) ( ) | ( ) | +-------------------------+ | | | | | | | | | / | | | | | | | | / +-------------------------+/ ^ ^ ^ ^ | | | | | | | +--- GND | | +----- GND | +----------- RX (PC -> Phone) +--------------- TX (Phone -> PC) could someone please mark the pins that have to be connected for charging ? i guess one of the two GND pins is involved. kind regards and thanks for your time -Alex [1] http://en.qi-hardware.com/wiki/Sciphone_Dream_G2 From laforge at gnumonks.org Fri Dec 17 08:44:04 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 17 Dec 2010 09:44:04 +0100 Subject: sciphone g2 connector In-Reply-To: <4D0A8D79.6000900@cosy.sbg.ac.at> References: <4D0A8D79.6000900@cosy.sbg.ac.at> Message-ID: <20101217084404.GR25200@prithivi.gnumonks.org> Hi Alexander, On Thu, Dec 16, 2010 at 11:06:49PM +0100, Alexander Huemer wrote: > i tried to ascii draw the connector from the back (soldering) side. the > rounded half of the connector on the upper side. The pins i found described > elsewhere on the internet are already marked. As you can read from the Schematics page 8 (I/O connector), Pin 9 is the Charger/USB Power. As you have already marked, 6+8 are UART and 10+12 is ground. So you have to connect the ground of your power supply to 10 and/or 12, and the +5V to pin number 9. I've added the pin numbers to your ASCII-ART: > -------------------------- > ( ) > ( ) | > ( 1 2 3 4 5 6 7 8 9 0 1012 ) > +-------------------------+ | > | | | | | | | | / > | | | | | | | | / > +-------------------------+/ > ^ ^ ^ ^ > | | | | > | | | +--- GND > | | +----- GND > | +----------- RX (PC -> Phone) > +--------------- TX (Phone -> PC) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ste7an at gmail.com Thu Dec 16 23:03:35 2010 From: ste7an at gmail.com (ste7an) Date: Fri, 17 Dec 2010 00:03:35 +0100 Subject: got Simtrace to compile Message-ID: I ordered a SAM7-P64 board for running Simtrace (received board today, but still waiting for the REBELSIm connectors). When compiling the code (using Gnuarm3.4.3) I got two errors: 1) the --g($DEBUGF) option was not understood; omitting this, made the Makefile (for dfu and main) working 2) in /lib/vsprintf.c I had to add #include in order to prevent errors related to MAX_INT etc. Are there any ideas for making a man-in-the-middle SIM device? One master interface to a real SIM, another slave interface providing a SIM interface towards a phone with the possibility to filter certain APDU's or to add files or commands on top of the real SIM. This would need an additional SIM master interface (to send and receive APDU's to the real SIM) on top of what already is in SIMtrace and the slave interface should be capable of sending messaged back to the real SIM master. I will look into it, first starting with implementing a simple SIM card master on the other UART. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Dec 17 07:12:32 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 17 Dec 2010 08:12:32 +0100 Subject: got Simtrace to compile In-Reply-To: References: Message-ID: <20101217071232.GO25200@prithivi.gnumonks.org> Hi Ste7an, good to see there are multiple pepole with interest in SIMtrace. On Fri, Dec 17, 2010 at 12:03:35AM +0100, ste7an wrote: > I ordered a SAM7-P64 board for running Simtrace (received board today, but > still waiting for the REBELSIm connectors). When compiling the code (using > Gnuarm3.4.3) I got two errors: > 1) the --g($DEBUGF) option was not understood; omitting this, made the > Makefile (for dfu and main) working > 2) in /lib/vsprintf.c I had to add #include in order to prevent > errors related to MAX_INT etc. those are probably all related to the fact that > Are there any ideas for making a man-in-the-middle SIM device? One master > interface to a real SIM, another slave interface providing a SIM interface > towards a phone with the possibility to filter certain APDU's or to add > files or commands on top of the real SIM. sure, there are ideas for this. The easiest way is to implement transmit support in the SIMtrace firmware + host software and use that implementation as the 'card emulation' part. You can then use any pcsc-lite supported card reader to actually talk to the card, and write some PC software that passes and filters or even manipulates the APDUs. > This would need an additional SIM master interface (to send and receive > APDU's to the real SIM) on top of what already is in SIMtrace and the slave > interface should be capable of sending messaged back to the real SIM master. > I will look into it, first starting with implementing a simple SIM card > master on the other UART. Implementing the reader side inside the SAM7S (on the other UART) will work, too - but at the expense of having to write your own card reader firmware. Depending on where you want to go, simply using an existing USB card reader for the SIM will be the quicker road to success. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Dec 17 08:45:02 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 17 Dec 2010 09:45:02 +0100 Subject: got Simtrace to compile In-Reply-To: <20101217071232.GO25200@prithivi.gnumonks.org> References: <20101217071232.GO25200@prithivi.gnumonks.org> Message-ID: <20101217084502.GS25200@prithivi.gnumonks.org> Sorry, I was missing the second half of one sentence: On Fri, Dec 17, 2010 at 08:12:32AM +0100, Harald Welte wrote: > On Fri, Dec 17, 2010 at 12:03:35AM +0100, ste7an wrote: > > I ordered a SAM7-P64 board for running Simtrace (received board today, but > > still waiting for the REBELSIm connectors). When compiling the code (using > > Gnuarm3.4.3) I got two errors: > > 1) the --g($DEBUGF) option was not understood; omitting this, made the > > Makefile (for dfu and main) working > > 2) in /lib/vsprintf.c I had to add #include in order to prevent > > errors related to MAX_INT etc. > > those are probably all related to the fact that ... you are using a different toolchain than the gnuarm-4.0.2 that we use for OsmocomBB as well as OpenPCD and SIMtrace cross-compilation. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ste7an at gmail.com Fri Dec 24 12:09:23 2010 From: ste7an at gmail.com (ste7an) Date: Fri, 24 Dec 2010 13:09:23 +0100 Subject: got Simtrace to compile In-Reply-To: <20101217084502.GS25200@prithivi.gnumonks.org> References: <20101217071232.GO25200@prithivi.gnumonks.org> <20101217084502.GS25200@prithivi.gnumonks.org> Message-ID: SimTrace compiles, I got the P64 board to load the main program. Connected the RebelSim flatcable+SIM. Without connecting the P64 board, the phione can use the SIm without a problem. When connecting the I/O and clk to the PA6+PA1 and PA2+PA4 pins the phone shows a SIM error. Is there a need for a resistor between the SIM signals and the P64 pins? Is there a need for a resistor between the input and output ports on the P64, or can they be directly connected? In some cases I got the ATR sniffed. The value was consistent with other readings. So, part of it i working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at mail.tsaitgaist.info Fri Dec 17 09:21:35 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Fri, 17 Dec 2010 10:21:35 +0100 Subject: got Simtrace to compile In-Reply-To: References: Message-ID: <4D0B2B9F.9070404@mail.tsaitgaist.info> I am using the toolchain provided by the summon-arm-toolchain script from esden. it uses binutils 2.20, newlib 1.18.0, and gcc 4.5.1 > 1) the --g($DEBUGF) option was not understood; omitting this, made the > Makefile (for dfu and main) working I do not get this error > 2) in /lib/vsprintf.c I had to add #include in order to > prevent errors related to MAX_INT etc. I also get this error and solve it the same way Additionally, I get : error : uses hardware FP, whereas main_simtrace.elf uses software FP which I could not get rid off yet. > > Are there any ideas for making a man-in-the-middle SIM device? I am designing some SIMtrace hardware. I think the schema is almost finished. I will publish it in the next days and begin with the board if no one finds an error. I already ordered most of the parts to build the PCB. Kevin From ml at mail.tsaitgaist.info Sat Dec 18 13:13:58 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Sat, 18 Dec 2010 14:13:58 +0100 Subject: SIMtrace hardware Message-ID: <4D0CB396.7060607@mail.tsaitgaist.info> Hi, I made a lot of changes to the SIMtrace hardware schema. Here my v0.5 : https://gsm.tsaitgaist.info/SIMtrace/v0.5/SIMtrace.ps Some important point that are unclear, where I would like to have some comments : - I do not use USB_DP_PUP which I found in several at91sam7s design (and openPCD). I don't know if it will be useful or required. - I use npn transistor as switches (2 for I/O because bidirectional). Maybe (N/P/C)MOS is a better solution. I already bought most of the parts and would like to start drawing the PCB. Please tell me if you find some errors or have any advices. kevin From zecke at selfish.org Mon Dec 20 19:15:13 2010 From: zecke at selfish.org (Holger Freyther) Date: Mon, 20 Dec 2010 20:15:13 +0100 Subject: Working on the documentation... Message-ID: <4D0FAB41.2040402@selfish.org> Hi all, I have started a GettingStarted[1] page to cover the topics of getting the code, getting an ARM toolchain and pointing to the osmocon and layer23 pages for the details. I was also going through the search to update the names of the firmware binaries. The CalypsoRomloader[2] page deserves an update as well. It is referring to the GTA0X but then tries to flash a nonexistent E88 binary. I am not sure what to turn this page into. Do we also have a list of Milestones we want to accomplish (besides merging the sending code to master)? Do we have junior tasks for people that would like to get started on target and host firmware? regards z. [1] http://bb.osmocom.org/trac/wiki/GettingStarted [2] http://bb.osmocom.org/trac/wiki/CalypsoRomloader From stefan at opdebeek.net Mon Dec 20 23:47:22 2010 From: stefan at opdebeek.net (Stefan Op de Beek) Date: Tue, 21 Dec 2010 00:47:22 +0100 Subject: can't get SAM7-p64 board into SAM-BA Message-ID: I tried to load the dfu.bin+main.bin (=samba) onto the Olimex SAM7-P64 board. I connected jumper TEST for >10s, disconnected power, reconnected power. I assume that it is possible now to upload firmware using sam-ba (i tried both linux and windows) over the USB port. Even trying to connect through the dbg serial port failed. Is there something wrong with the board or in the procedure I follow. Should I see a USB-CDC serial port when the SAM7 is running the SAM-BA bootloader? Any comments would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Dec 21 08:15:07 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 21 Dec 2010 09:15:07 +0100 Subject: can't get SAM7-p64 board into SAM-BA In-Reply-To: References: Message-ID: <20101221081507.GV6578@prithivi.gnumonks.org> Hi Stefan, On Tue, Dec 21, 2010 at 12:47:22AM +0100, Stefan Op de Beek wrote: > I tried to load the dfu.bin+main.bin (=samba) onto the Olimex SAM7-P64 > board. I connected jumper TEST for >10s, disconnected power, reconnected > power. I assume that it is possible now to upload firmware using sam-ba (i > tried both linux and windows) over the USB port. Even trying to connect > through the dbg serial port failed. Is there something wrong with the board > or in the procedure I follow. The procedure is fine, I also suspect some hardware problem, to be honest. > Should I see a USB-CDC serial port when the SAM7 is running the SAM-BA > bootloader? Yes -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Dec 22 16:58:09 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 22 Dec 2010 17:58:09 +0100 Subject: TODO: OsmocomBB to continually iterate over all cells and dump SI Message-ID: <20101222165809.GG8073@prithivi.gnumonks.org> Hi! A number of people want to do some long-term evaluation of their cellular environment and would be interested in an 'app' for OsmocomBB that continuously scans the spectrum and dumps the cell parameters such as * ARFCN, Signal Level, SNR * frequency synch offset * SCH info (BCC/NCC) * SI (at least 1-4) from BCCH I would love to do it, but I simply don't have the time. I thought maybe somebody on this list is looking for a relatively simple task and has some time. I think this is a great project to work with OsmocomBB without having to go into the details. The algorithm would look something like STATE 1: Power Scan * do power measurement over all supported bands * pick strongest N carriers and iterate over them STATE 2: FCCH/SCH acquisition * try to get lock on the carrier * if not, go back to next carrier from power scan * if yes, continue with STATE 3 STATE 3: Wait until all relevant SI have been received * generate GSMTAP output for the SI messages (or timeout) * go back to STATE 2 for next strongest ARFCN * after last ARFCN, re-start from STATE 1 This is basically the initial step of the GSM 03.22 cell (re)selection that we already have as part of the 'mobile' program. So all the code is there, but what's needed is a separate rady-made app, not requiring any user interaction. It should also include some e.g. shell script that automatically generates a new pcap file every N minutes/hours, and make sure to never overwrite any existing PCAP file. In the end, having this running for an extended period of time should simply produce a large number of PCAP files without any manual interaction. Lock-ups in any state should be detected by timers, singalling a proper L1_RESET to make sure it continues. Unplugging / re-plugging the phone should also not require any re-start of the program. Optional extensions: * software to aggregate info from the pcap files (remove duplicate entries, e.g.) * optional logging of GPS coordinates from a GPS receiver If anyone has some time to give this some work, I'd most appreciate it. Please inform the mailing list to ensure no duplicate work is created. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From steve at steve-m.de Wed Dec 22 17:23:35 2010 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 22 Dec 2010 18:23:35 +0100 Subject: TODO: OsmocomBB to continually iterate over all cells and dump SI In-Reply-To: <20101222165809.GG8073@prithivi.gnumonks.org> References: <20101222165809.GG8073@prithivi.gnumonks.org> Message-ID: <4D123417.9020307@steve-m.de> Hi all, On 22.12.2010 17:58, Harald Welte wrote: > A number of people want to do some long-term evaluation of their cellular > environment and would be interested in an 'app' for OsmocomBB that continuously > scans the spectrum and dumps the cell parameters such as > * ARFCN, Signal Level, SNR > * frequency synch offset > * SCH info (BCC/NCC) > * SI (at least 1-4) from BCCH > * optional logging of GPS coordinates from a GPS receiver Just to avoid any duplicate of work as well: most of this is already done by cell_log (layer23/src/misc). It iterates over the whole spectrum and tries to get an Immediate Assignment by sending a RACH to every cell. It stores SI1-4, GPS position and the TA in a logfile, and using the gsmmap utility you can create a *.kml map of the calculated cell positions for Google Earth. So what's missing is really only the PCAP support and a command line switch to turn off the "active" scanning by sending no RACHs. Regards, Steve From osmocom at lakedaemon.net Wed Dec 22 18:01:37 2010 From: osmocom at lakedaemon.net (Jason) Date: Wed, 22 Dec 2010 18:01:37 +0000 Subject: TODO: OsmocomBB to continually iterate over all cells and dump SI In-Reply-To: <4D123417.9020307@steve-m.de> References: <20101222165809.GG8073@prithivi.gnumonks.org> <4D123417.9020307@steve-m.de> Message-ID: <4D123D01.1060008@lakedaemon.net> On 12/22/2010 05:23 PM, Steve Markgraf wrote: > Hi all, > > On 22.12.2010 17:58, Harald Welte wrote: > >> A number of people want to do some long-term evaluation of their cellular >> environment and would be interested in an 'app' for OsmocomBB that >> continuously >> scans the spectrum and dumps the cell parameters such as >> * ARFCN, Signal Level, SNR >> * frequency synch offset >> * SCH info (BCC/NCC) >> * SI (at least 1-4) from BCCH >> * optional logging of GPS coordinates from a GPS receiver > > Just to avoid any duplicate of work as well: most of this is already > done by cell_log (layer23/src/misc). It iterates over the whole spectrum > and tries to get an Immediate Assignment by sending a RACH to every cell. > It stores SI1-4, GPS position and the TA in a logfile, and using the > gsmmap utility you can create a *.kml map of the calculated cell > positions for Google Earth. > Funny, I was just looking at this last night. Would you mind if I added gpsd support to cell_log? > So what's missing is really only the PCAP support... would you want libpcap (a lot of unnecessary code), or just use the file and packet headers? > ...and a command line > switch to turn off the "active" scanning by sending no RACHs. > Since I'm just learning GSM, I've only compiled with TX disabled. My results have been pretty poor. Is there something I could add to handle passive scanning better? I've been getting nothing from cell_log, layer23, or mobile on lo (although I do see other loopback network traffic). I just started working on this a few days ago, so I'm not surprised. I'll dig into it more. The Getting Started guide was a great help! thx, Jason. From Andreas.Eversberg at versatel.de Thu Dec 23 09:31:49 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 23 Dec 2010 10:31:49 +0100 Subject: AW: TODO: OsmocomBB to continually iterate over all cells and dump SI Message-ID: > Just to avoid any duplicate of work as well: most of this is already > done by cell_log (layer23/src/misc). It iterates over the whole spectrum > and tries to get an Immediate Assignment by sending a RACH to every cell. > It stores SI1-4, GPS position and the TA in a logfile, and using the > gsmmap utility you can create a *.kml map of the calculated cell > positions for Google Earth. > So what's missing is really only the PCAP support and a command line > switch to turn off the "active" scanning by sending no RACHs. hi steve, exactly. almost everything is already there. there are some things that may need to be improved in my opinion: - deactivating/activating the RACH request - altering maximum distance (gps) moving off the position of last power scan, before restarting scanning process. - multiple radio support for faster scanning and deeper scanning while moving. - selecting between the generic text format and PCAP. - option to wait some more time to receive more system informations than the mandatory 1..4 regards, andreas From holger at freyther.de Thu Dec 23 12:50:34 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Thu, 23 Dec 2010 13:50:34 +0100 Subject: AW: TODO: OsmocomBB to continually iterate over all cells and dump SI In-Reply-To: References: Message-ID: <4D13459A.8000808@freyther.de> On 12/23/2010 10:31 AM, Andreas.Eversberg wrote: > - selecting between the generic text format and PCAP. We have support for writing PCAP headers in OpenBSC (used to), I have some in cellmgr_ng. I would propose to put the generation code into libosmocore and then use it. The header and the payloads are easy to write. > - option to wait some more time to receive more system informations than > the mandatory 1..4 Also some more text in the log file would be nice (e.g. the operator name), also cross referencing the neighbor cells, a script to diff between the cells of multiple scans... From holger at freyther.de Sun Dec 26 09:01:26 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 26 Dec 2010 10:01:26 +0100 Subject: AW: TODO: OsmocomBB to continually iterate over all cells and dump SI In-Reply-To: References: Message-ID: <4D170466.7030403@freyther.de> On 12/23/2010 10:31 AM, Andreas.Eversberg wrote: > hi steve, > > exactly. almost everything is already there. there are some things that > may need to be improved in my opinion: > > - deactivating/activating the RACH request > - altering maximum distance (gps) moving off the position of last power > scan, before restarting scanning process. > - multiple radio support for faster scanning and deeper scanning while > moving. > - selecting between the generic text format and PCAP. > - option to wait some more time to receive more system informations than > the mandatory 1..4 I will now work a bit on option parsing for these mini-apps and will disable the RACH requests while doing this. From ste7an at gmail.com Thu Dec 23 21:20:16 2010 From: ste7an at gmail.com (ste7an) Date: Thu, 23 Dec 2010 22:20:16 +0100 Subject: different behaviour when osmocom-bb runs on c155 and c115 Message-ID: When running the layer23/mobile host application in combination with layer1 firmware on a c115 (compal_e88 based) I can easily connect with a network (when using Sylvain's test trunk, which supports the SIM very well!). However, running the same code on the C155 (compal_e99 based) the phone refuses to connect to the network and keeps scanning ARFCN's. Is there any real difference between these phones except for the LCD's? In rffe_dualband.c I see a remark about the value of SYSTEM_INHERENT_GAIN that has been measured by Harald on the C123. May that be a different value for the C155? Is this a problem observed by others, or is there a workaround? -------------- next part -------------- An HTML attachment was scrubbed... URL: From squalyl at gmail.com Wed Dec 29 16:48:07 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Wed, 29 Dec 2010 17:48:07 +0100 Subject: Engagetted ! Message-ID: http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-call-all-you-need-is-a/ Congrats! From squalyl at gmail.com Wed Dec 29 16:54:12 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Wed, 29 Dec 2010 17:54:12 +0100 Subject: Engagetted ! In-Reply-To: References: Message-ID: ( sorry for the spam: original source http://www.wired.com/threatlevel/2010/12/breaking-gsm-with-a-15-phone-plus-smarts/ ) From sweisman at pobox.com Wed Dec 29 18:13:02 2010 From: sweisman at pobox.com (Scott Weisman) Date: Wed, 29 Dec 2010 20:13:02 +0200 Subject: Engagetted ! In-Reply-To: References: Message-ID: Sweet. Did this phone require the band-pass filter removed to get both audio streams? On Wed, Dec 29, 2010 at 6:54 PM, S?bastien Lorquet wrote: > ( > sorry for the spam: original source > > http://www.wired.com/threatlevel/2010/12/breaking-gsm-with-a-15-phone-plus-smarts/ > ) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Wed Dec 29 18:16:10 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 29 Dec 2010 19:16:10 +0100 Subject: Engagetted ! In-Reply-To: References: Message-ID: <20101229181610.11288.qmail@stuge.se> S?bastien Lorquet wrote: > http://www.wired.com/threatlevel/2010/12/breaking-gsm-with-a-15-phone-plus-smarts/ Could not help but laugh at the comments. :) //Peter From aifiltr0 at invyl.ath.cx Wed Dec 29 19:51:56 2010 From: aifiltr0 at invyl.ath.cx (Andrew) Date: Wed, 29 Dec 2010 22:51:56 +0300 Subject: Fwd: MTK port: Interesting device. Message-ID: Hello all. Just back from the hospital, so I haven't followed the development much for some time. Anyway, I've recently stumbled upon an interesting device: https://www.dealextreme.com/details.dx/sku.50391 I think I'll order that one sometime soon, so that I can look at it in more detail. This is a chinese phone with android, but some things make me think that's MTK inside. According to desctiption: ARM926EJ-S rev 5(v5l) BogoMIPS: 207.66 Android 2.2.1 OS system/Wifi(802.11b)/TV/GPS/FM/JAVA Price - 130 bucks. Sounds familiar? Compared to my E1000: ARM926EJ-S rev 5 (v5l) BogoMIPS: 104.24 Twice more Bogomips. The hardware pretty much seems like a typical MTK, and for that price I guess there actually is MTK inside, something a little better than 2635, so the problem is to find the sources somewhere (And my bet is, that if they don't make it to the mainline - they'll leak out to the web) If the chips are pretty much identical, and they are, this might be a good thing. I think I'll buy one after the holiday madness is over and, hopefully, provide teardown photos, firmware dump and more details. Regards, Andrew. From marcin.mielczarczyk at gmail.com Wed Dec 29 20:08:46 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Wed, 29 Dec 2010 21:08:46 +0100 Subject: MTK port: Interesting device. In-Reply-To: References: Message-ID: On Wed, Dec 29, 2010 at 8:51 PM, Andrew wrote: > Anyway, I've recently stumbled upon an interesting device: > https://www.dealextreme.com/details.dx/sku.50391 There are plenty of devices like this. These devices are based on MT6516. It's dual core SoC with Windows Mobile and Android already ported (delivered by MTK). Some of the peripherals are the same as on MT62xx and some are completely different. This topic has been already discussed on the list: http://lists.osmocom.org/pipermail/baseband-devel/2010-December/000855.html To follow chinese phones market (mainly based on MTK) I recommend following site: http://www.clonedinchina.com/ BR, Marcin From squalyl at gmail.com Wed Dec 29 20:21:33 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Wed, 29 Dec 2010 21:21:33 +0100 Subject: MTK port: Interesting device. In-Reply-To: References: Message-ID: Can we really deduce anything from BOGus MIPS? :-) Sebastien On Wed, Dec 29, 2010 at 8:51 PM, Andrew wrote: > > Hello all. > Just back from the hospital, so I haven't followed the development much > for some time. > Anyway, I've recently stumbled upon an interesting device: > https://www.dealextreme.com/details.dx/sku.50391 > I think I'll order that one sometime soon, so that I can look at it in > more detail. > This is a chinese phone with android, but some things make me think that's > MTK inside. > According to desctiption: > ARM926EJ-S rev 5(v5l) BogoMIPS: 207.66 > Android 2.2.1 OS system/Wifi(802.11b)/TV/GPS/FM/JAVA > Price - 130 bucks. > Sounds familiar? > Compared to my E1000: > ARM926EJ-S rev 5 (v5l) BogoMIPS: 104.24 > > Twice more Bogomips. The hardware pretty much seems like a typical MTK, > and for that price I guess there actually is MTK inside, something a > little > better than 2635, so the problem is to find the sources somewhere (And my > bet is, that if they don't make it to the mainline - they'll leak out to > the web) If the chips are pretty much identical, and they are, this might > be a good thing. I think I'll buy one after the holiday madness is over > and, hopefully, provide teardown photos, firmware dump and more details. > > Regards, > Andrew. > > > From lists at infosecurity.ch Thu Dec 30 16:45:54 2010 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Thu, 30 Dec 2010 17:45:54 +0100 Subject: On the gsm positioning faking Message-ID: <4D1CB742.50709@infosecurity.ch> Hi guys, i just looked at 27c3 talk on http://27c3.iphoneblog.de/recordings/3952.html (i really wanted to be there!) and heard about the concept of being able to fake gsm based position systems. Which could in theory the distance that could be faked respect to the knowledge that the BTS can acquire? I mean, the modified timing information provided by phone running osmocombb, how many meters distance from BTS could be? -naif From osmocom at lakedaemon.net Thu Dec 30 19:31:24 2010 From: osmocom at lakedaemon.net (Jason) Date: Thu, 30 Dec 2010 19:31:24 +0000 Subject: 27c3 videos Message-ID: <4D1CDE0C.5010204@lakedaemon.net> I found the videos at [1], but I don't have an iphone... Are the videos available in different formats? Apparently, Apple's HTTP streaming, segmented mpeg-ts is rather new [2] and there isn't much support for it. I found how to create them [3] and code [4] to create the playlist and segments, but nothing on how to play them or cat them back together. I tried using ffmpeg to convert them the mpeg-ps files, then catting them together (from the ffmpeg manual). This worked, except that the audio went out of sync, and every five seconds the screen goes grey because of the original file boundaries. Any pointers? thx, Jason. [1] http://27c3.iphoneblog.de/recordings/3952.html [2] http://tools.ietf.org/html/draft-pantos-http-live-streaming-01 [3] http://www.ioncannon.net/projects/http-live-video-stream-segmenter-and-distributor/ [4] https://github.com/carsonmcdonald/HTTP-Live-Video-Stream-Segmenter-and-Distributor From dpavlin at rot13.org Thu Dec 30 21:03:14 2010 From: dpavlin at rot13.org (Dobrica Pavlinusic) Date: Thu, 30 Dec 2010 22:03:14 +0100 Subject: 27c3 videos In-Reply-To: <4D1CDE0C.5010204@lakedaemon.net> References: <4D1CDE0C.5010204@lakedaemon.net> Message-ID: <20101230210314.GA16991@rot13.org> On Thu, Dec 30, 2010 at 07:31:24PM +0000, Jason wrote: > I found the videos at [1], but I don't have an iphone... Are the > videos available in different formats? Apparently, Apple's HTTP > streaming, segmented mpeg-ts is rather new [2] and there isn't much > support for it. > > I found how to create them [3] and code [4] to create the playlist > and segments, but nothing on how to play them or cat them back > together. > > I tried using ffmpeg to convert them the mpeg-ps files, then catting > them together (from the ffmpeg manual). This worked, except that > the audio went out of sync, and every five seconds the screen goes > grey because of the original file boundaries. > > Any pointers? There will be official recordings with high quality recordings, but for now http://27c3.hightech-lowlife.net/%5B3952%5D%20Running%20your%20own%20GSM%20stack%20on%20a%20phone/20101229-181502.wmv.mkv works nicely with mplayer -aspect 16:9 You might also find other useful pointers at http://events.ccc.de/congress/2010/wiki/Documentation p.s. besause of this video I'm now owner of C118 :-) > thx, > > Jason. > > [1] http://27c3.iphoneblog.de/recordings/3952.html > [2] http://tools.ietf.org/html/draft-pantos-http-live-streaming-01 > [3] http://www.ioncannon.net/projects/http-live-video-stream-segmenter-and-distributor/ > [4] https://github.com/carsonmcdonald/HTTP-Live-Video-Stream-Segmenter-and-Distributor > -- Dobrica Pavlinusic 2share!2flame dpavlin at rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin From osmocom at lakedaemon.net Fri Dec 31 02:14:15 2010 From: osmocom at lakedaemon.net (Jason) Date: Fri, 31 Dec 2010 02:14:15 +0000 Subject: 27c3 videos In-Reply-To: <20101230210314.GA16991@rot13.org> References: <4D1CDE0C.5010204@lakedaemon.net> <20101230210314.GA16991@rot13.org> Message-ID: <4D1D3C77.8030709@lakedaemon.net> On 12/30/2010 09:03 PM, Dobrica Pavlinusic wrote: > On Thu, Dec 30, 2010 at 07:31:24PM +0000, Jason wrote: >> I found the videos at [1], but I don't have an iphone... Are the >> videos available in different formats? ... >> Any pointers? > ... > You might also find other useful pointers at > > http://events.ccc.de/congress/2010/wiki/Documentation > Ahhh... found the list of mirrors [1] which have mp4 containers, torrents, etc. Looks like only the first day or so, so far. Thanks a ton! > p.s. besause of this video I'm now owner of C118 :-) > yep, bought a C123 a while ago when I first heard about osmocombb... thx, Jason. [1] http://events.ccc.de/congress/2010/wiki/Conference_Recordings From 246tnt at gmail.com Fri Dec 31 16:29:36 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 31 Dec 2010 17:29:36 +0100 Subject: IMPORTANT clarifications about 27C3 GSM Sniff Talk Message-ID: Hi, Since a lot of people are asking the same questions and there seems to be a rush on the C123 on ebay I tought some clarification is needed. Short version: - The exact tools I used on stage are _not_ and will _not_ be released (or sold ... several people asked ...) - Any one willing to re-code them without any apriori knowledge of GSM would most likely need months to read/understand both the specifications and the way the code works. (That's thousands of page of GSM spec and thousands of line of code) - Osmocom-BB project is not designed to be a sniffer, it's a baseband implementation, I just used part of it as a base. So basically, unless you are really interested in GSM and are willing to dedicate time to understand it deeply and to contribute the various projects, there is not much point in you buying phones, or hanging out in the ml/irc or whatever ... For those who are still reading and interested here's a little more detail: * The HLR query step: -> Go watch the awesome 25C3 talk about it * The TMSI recovering step - Won't be published - If you know how paging works, you know what to do anyway and it's trivial. Method is in the talk, there is nothing to it. * The targeted sniffing application - Won't be published either - Some improvements to the layer23 app frame work will be done but these are generic framework stuff, not app-specific - Again, if you know how L2 works and have looked at several traces, it's obvious what to do. - The 'DSP' part of the sniffer is public for a while with a small demo app (single phone and doesn't exploit the full potential of the DSP patch) and it's perfectly sufficient to debug things on your o wn controlled network. (This is basically what I showed at Deepsec 2010). * The tool to generate the input to Kraken - Won't be published either - Making the guesses is easy for anyone that knows what he's doing. * The improved Kraken - No idea about it, see with Karsten / Sacha / Frank, I only got access to it 1 hour or so before the talk :) * Conversion from burst to audio - This was a hacked software mostly with airprobe code. - The exact app will not be released but I'd like to see the capability put in some clean library we can re-use from airprobe and other application without having to multiply the code each time. - ... But since I'd like it to support AMR and viterbi softoutput before that happens, it could take some time. - Anyone familiar with GSM, airprobe and C could re-hack the same thing in an hour ... As you can see, everything you need to analyze your own network / your own traffic, even at the burst level is already published and has been for more than a month. The other tools have been written only so that we could demonstrate that what we _say_ is possible for about year, we can now do it _practically_. It's apparently needed to get people attentions, "theoretical" attacks are not enough to get the operators / gsma to react. We'll see if that did it ... A few advices that are always good: - Make sure to checkout the a5/1 project ML and airprobe project ML and try to ask your questions in the proper mailing list as much as possible. - Check the wiki and mailing list archives toroughly before asking questions. Cheers, Sylvain Munaut PS: I only posted on this list because it seems a lot of people were pointed here while in fact airprobe would probably be more appropriate to discuss attack scenarios and such, so make sure to answer / start new discussion on the right list.