From gscp42 at gmail.com Sat Nov 6 14:35:30 2010 From: gscp42 at gmail.com (Michael Sprecher) Date: Sat, 6 Nov 2010 15:35:30 +0100 Subject: problem starting out...please help In-Reply-To: References: <20100831140457.22679.qmail@stuge.se> Message-ID: Hi Scott If you're still not able to build osmocomBB on Arch Linux try to install the packeges cross-arm-elf-gcc and cross-arm-elf-newlib from AUR. It worked for me, so give it a try. Regards, Michael 2010/8/31 Scott Weisman : > This is very useful info. Thanks! I will look into building my own toolchain > then. > > I'm looking forward to playing around with this. > Scott > On Tue, Aug 31, 2010 at 5:04 PM, Peter Stuge wrote: >> >> Scott Weisman wrote: >> > /usr/bin/arm-elf-ld: this linker was not configured to use sysroots >> > collect2: ld returned 1 exit status >> >> As always, it would be helpful to also see the last few commands that >> were executed, to get more context. >> >> >> > I am running Arch Linux and have the packages cross-arm-elf-binutils >> > and cross-arm-elf-gcc-base installed. Does anyone have any >> > suggestions to fix this? >> >> Mh. My guess is that toolchain is intended for building Linux >> systems, or in any case building "systems" with some packaging >> support, and intent to install into a root filesystem - as opposed >> to just cross-compiling bare metal sources with no filesystem ever >> involved.. >> >> I assume you've googled for arch and this error and have found >> https://bbs.archlinux.org/viewtopic.php?id=62644 - and since you're >> an Arch user maybe you already know what PKGBUILD and ABS are and how >> they are intended to operate. (I've never used Arch, but I guess ABS >> is Arch Build System, which might support my other guess that your >> toolchain is just not suitable for building osmocom-bb.) >> >> >> //Peter >> > > From wbg_1000 at yahoo.com Sat Nov 6 14:20:36 2010 From: wbg_1000 at yahoo.com (eisencah eisenach) Date: Sat, 6 Nov 2010 07:20:36 -0700 (PDT) Subject: osmocom on windows In-Reply-To: <4CC13F9B.6060008@gmail.com> Message-ID: <669890.29248.qm@web112120.mail.gq1.yahoo.com> Hello everybody. Managed to compile the osmocom program under windows. Could anyone send me the image for the "Hello word" program so I could try to download it into the phone (haven't got to the part where I compile the firmware bit I would want to see osmocom work). Cheers, Mihai. --- On Fri, 10/22/10, Nordin wrote: From: Nordin Subject: Re: osmocom on windows To: baseband-devel at lists.osmocom.org Date: Friday, October 22, 2010, 10:39 AM ? Another thread is possible, but you could also do a non-blocking read of the serial port, when Select call timed out. If nothing, you'll return back to the WSASelect() and the whole process repeats. This means you do serial port handling on the time-out of the WSASelect() call. This way you omit synchronization between threads, but if you're familiar with multithreading, go ahead :) On 21-10-2010 19:48, eisencah eisenach wrote: > :D Yup the timers too. That's why I would like to keep that piece of code as it is and move only the serial port handling elsewhere (a different thread I) > > --- On Thu, 10/21/10, Holger Hans Peter Freyther? wrote: > > From: Holger Hans Peter Freyther > Subject: Re: osmocom on windows > To: baseband-devel at lists.osmocom.org > Date: Thursday, October 21, 2010, 8:09 PM > > On 10/21/2010 07:00 PM, eisencah eisenach wrote: >> Here's another one. Regarding the select mechanism (the one in select.c). >> Other then the serial port and sockets is anything else registered there? >> Cause I >???would like to keep sockets for communication after all (but the select >> function will not work on windows for serial ports handles). So I would use a >> different mechanism only for serial port scheduling. >> Cheers, >> Mihai. > well.. we handle the timers with it too. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.mielczarczyk at gmail.com Tue Nov 2 07:01:06 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Tue, 2 Nov 2010 08:01:06 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> Message-ID: Hi, > >> Also, do you know the RF transceiver chip used in the device? ?We already know >> the MT6129 and MT6139 from the MT622x based phones, but it might be a different >> one for the MT6235. >> > I unsoldered plastic antenna, but there is only WiFi. Seems that RF transceiver is under metal shield. I just received second piece of Sciphone and uploaded new pictures with descriptions on Wiki: http://bb.osmocom.org/trac/wiki/SciphoneDreamG2 Good thing is that I can fit my microSD card sniffer which will make SD controller development easier. First I'll try to identify GPIOs. BR, Marcin From wolfgang at sharism.cc Wed Nov 3 17:41:31 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Wed, 3 Nov 2010 17:41:31 +0000 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> Message-ID: <20101103174131.GA8814@asus.wolf> Marcin, > I unsoldered plastic antenna, but there is only WiFi. > Seems that RF transceiver is under metal shield. > I just received second piece of Sciphone and uploaded new pictures > with descriptions on Wiki: I very much enjoyed reading your Sciphone G2 news and it motivated me to jump in and try to help :-) So it turns out a good friend of mine is Vice President of the company that made the Sciphone G2 - it's a small world after all. I wrote up what I found so far http://en.qi-hardware.com/wiki/Sciphone_Dream_G2 The G2 was discontinued about a year ago, but over 200,000 were made so we should be able to find some still. He donated the absolute last 2 phones we could find in his office to the OsmocomBB project, a normal black one as well as a prototype red one. He also donated another 9 boards to OsmocomBB, I took this picture http://en.qi-hardware.com/wiki/File:Nine_Sciphone_G2_boards.jpg They are reworked/fixed, but _should_ work (note that 3 are without Wi-Fi). Now my question: For those 9 boards, what are the most important missing pieces so they can become useful for the OsmocomBB project? I guess a charger/USB cable would be nice (it's not a standard plug). What else? LCM? Maybe not so important? How about antennas? speaker/buzzer? If I just send these 9 boards to Harald the way they are on the picture, is that useful? Or should I try to find some more parts? I'm most concerned about the antenna, not sure whether this is easy to source/find. Separately, I will try to take pictures of the individual PCB layers, using a V3.1 PCB. I should have them by the end of the week. I am also trying to get the schematics, maybe BOM or other helpful data, but I'm not so sure on those, maybe they cannot find them anymore even if they would like to give them to us. Don't hold your breadth on those. Bottom line: 2 full G2 + 9 PCBA donated to OsmocomBB, PCBA pictures uploaded, PCB layer pictures coming. Schematics maybe. Wolfgang From marcin.mielczarczyk at gmail.com Wed Nov 3 18:22:58 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Wed, 3 Nov 2010 19:22:58 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101103174131.GA8814@asus.wolf> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> Message-ID: On Wed, Nov 3, 2010 at 6:41 PM, Wolfgang Spraul wrote: > Marcin, > > I very much enjoyed reading your Sciphone G2 news and it motivated me > to jump in and try to help :-) > So it turns out a good friend of mine is Vice President of the company > that made the Sciphone G2 - it's a small world after all. > I wrote up what I found so far > http://en.qi-hardware.com/wiki/Sciphone_Dream_G2 > I'm realy suprised :) I didn't expect taht it'll go that far. > The G2 was discontinued about a year ago, but over 200,000 were made so > we should be able to find some still. > He donated the absolute last 2 phones we could find in his office to the > OsmocomBB project, a normal black one as well as a prototype red one. > He also donated another 9 boards to OsmocomBB, I took this picture > http://en.qi-hardware.com/wiki/File:Nine_Sciphone_G2_boards.jpg > That's great news! > They are reworked/fixed, but _should_ work (note that 3 are without Wi-Fi). > Now my question: > For those 9 boards, what are the most important missing pieces so they > can become useful for the OsmocomBB project? > > I guess a charger/USB cable would be nice (it's not a standard plug). > What else? > LCM? Maybe not so important? > How about antennas? speaker/buzzer? > For sure these 9 boards will be useful for this project. Besides running osmocomBB we have to run Linux with drivers for MTK peripherals: GPIO, SD/MMC, NAND, I2C, SPI, UART, PWM, USB, LCD, etc. Most of these peripherals are available on mentioned boards so they'll be useful for drivers development. If it comes to USB cable, it's not that important because L12C connectors (which are in Sciphone G2) are pretty cheap and available here: http://www.ipmart.com/main/product/Cable,Compatible,for,China,Mobile,Phone,Connector,Plug,L12C_1X12pin,45689.php?prod=45689 So even without USB cables, LCD, antennas, speakers, etc. boards will be useful for some people. > If I just send these 9 boards to Harald the way they are on the picture, > is that useful? Or should I try to find some more parts? I'm most concerned > about the antenna, not sure whether this is easy to source/find. > I already answered above. > Separately, I will try to take pictures of the individual PCB layers, using > a V3.1 PCB. I should have them by the end of the week. > I am also trying to get the schematics, maybe BOM or other helpful data, > but I'm not so sure on those, maybe they cannot find them anymore even if > they would like to give them to us. Don't hold your breadth on those. > Wow, but I'm not holding my breath yet :) Schematics would be realy useful ... You can also ask about technical documentation for BT chip MT6601. I couldn't find datasheet and it'll be needed to make BT working. > Bottom line: 2 full G2 + 9 PCBA donated to OsmocomBB, PCBA pictures > uploaded, PCB layer pictures coming. Schematics maybe. > That's very good news! I appreciate your help. BR, Marcin From peter at stuge.se Wed Nov 3 18:44:52 2010 From: peter at stuge.se (Peter Stuge) Date: Wed, 3 Nov 2010 19:44:52 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> Message-ID: <20101103184452.31537.qmail@stuge.se> Marcin Mielczarczyk wrote: > > Bottom line: 2 full G2 + 9 PCBA donated to OsmocomBB, PCBA > > pictures uploaded, PCB layer pictures coming. Schematics maybe. > > That's very good news! Yes, awesome! //Peter From wolfram at the-dreams.de Wed Nov 3 21:24:47 2010 From: wolfram at the-dreams.de (Wolfram Sang) Date: Wed, 03 Nov 2010 22:24:47 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> Message-ID: <4CD1D31F.2060808@the-dreams.de> > For sure these 9 boards will be useful for this project. > Besides running osmocomBB we have to run Linux with drivers for MTK > peripherals: GPIO, SD/MMC, NAND, I2C, SPI, UART, PWM, USB, LCD, etc. Count me in for this work. I have to admit I never got around to test my Motorola-phones, but the vision to do a full Linux-port surely adds some endorphine here :) >> Bottom line: 2 full G2 + 9 PCBA donated to OsmocomBB, PCBA pictures >> uploaded, PCB layer pictures coming. Schematics maybe. BTW while looking for a source for the G2 in Europe, I found this: http://www.digizo.co.uk/products/G2-Sci-phone-Google-Android-Interface-Dream-Mobile-Phone-WiFi-Touchscreen-Triband-MSN-JAVA-Gmail.html Dunno if the price is good, but they seem to have a few in stock at least. (I was lucky though to find a used one in London during the two days I was there :)) Regards, Wolfram From steve at steve-m.de Wed Nov 3 21:51:02 2010 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 03 Nov 2010 22:51:02 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <4CD1D31F.2060808@the-dreams.de> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <4CD1D31F.2060808@the-dreams.de> Message-ID: <4CD1D946.30208@steve-m.de> Hi, On 03.11.2010 22:24, Wolfram Sang wrote: > BTW while looking for a source for the G2 in Europe, I found this: > > http://www.digizo.co.uk/products/G2-Sci-phone-Google-Android-Interface-Dream-Mobile-Phone-WiFi-Touchscreen-Triband-MSN-JAVA-Gmail.html I ordered there yesterday, and the phone shipped today. > Dunno if the price is good, but they seem to have a few in stock at > least. (I was lucky though to find a used one in London during the two > days I was there :)) The price is okay, a few other sellers from Hongkong charge ~90? as well. The benefit of having it shipped from the UK is no hassle with customs, of course. Regards, Steve From wolfgang at sharism.cc Tue Nov 9 04:57:39 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Tue, 9 Nov 2010 04:57:39 +0000 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> Message-ID: <20101109045739.GA11763@asus.wolf> Marcin et al, > Wow, but I'm not holding my breath yet :) > Schematics would be realy useful ... > You can also ask about technical documentation for BT chip MT6601. > I couldn't find datasheet and it'll be needed to make BT working. sorry it took a bit longer than I thought, but I was hard at work and can report some good progress. A package with 4 full G2 + 4 PCBA + some USB cables and batteries is on the way to Harald with EMS. Let's hope it arrives soon and without big customs problems. Thanks to generous Bluelans support, I have more stuff here, another 6 full phones (4 with buggy touch panel, 2 should be OK), plus another 4 or 5 PCB. I grinded down 2 PCBs to take pictures of the layers, and I broke another full set to make an illustrated disassembly guide. That set is probably still usable, although at least I ripped off the touch panel cable, and broke the glass under the touch panel, and maybe added some more damage as part of me making the disassembly guide. Well, hopefully it helps others making a safer disassembly, that was the point of it. I kept adding things to my G2 wiki page http://en.qi-hardware.com/wiki/Sciphone_Dream_G2 What we have now is: 1) disassembly guide 2) PCB layers, also 1 large PDF with all layers so it should be easy to flip pages and follow traces 3) G2 schematics PDF, thanks to Bluelans 4) bottom side (LCM side) component placement, thanks to Bluelans That pretty much concludes what I planned to do. Maybe they can find the top side component placement file as well, that would be nice. Not sure though. Also if the first package of phones arrives safely, I have more phones and boards I can send people. I plan to give away everything I have. One thing you could help me with is URLs to the datasheets, as many as we can find, or have open URLs for. http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#Key_Components You mentioned you are looking for MT6601, I can start to ask around a bit, also for the full 6235 SDK if we can find it somewhere. But I don't even have links to the 6235 or 6140 datasheets right now... Hope this helps, good luck for your work! Wolfgang From marcin.mielczarczyk at gmail.com Tue Nov 9 05:14:34 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Tue, 9 Nov 2010 06:14:34 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101109045739.GA11763@asus.wolf> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101109045739.GA11763@asus.wolf> Message-ID: Hi Wolfgang, On Tue, Nov 9, 2010 at 5:57 AM, Wolfgang Spraul wrote: > Marcin et al, > > guide. Well, hopefully it helps others making a safer disassembly, > that was the point of it. > I kept adding things to my G2 wiki page > http://en.qi-hardware.com/wiki/Sciphone_Dream_G2 Don't worry about broken touchpanel, this set will be still usable. Thank you for documenting it! > What we have now is: > > 1) disassembly guide > 2) PCB layers, also 1 large PDF with all layers so it should be easy > to flip pages and follow traces > 3) G2 schematics PDF, thanks to Bluelans > 4) bottom side (LCM side) component placement, thanks to Bluelans That's a lot of hardware now ... We have also schematics (which I see are almost the same as reference schematic for MT6235 which I sent before) and PCB layers, that's great! > That pretty much concludes what I planned to do. Maybe they can find > the top side component placement file as well, that would be nice. Not > sure though. > Also if the first package of phones arrives safely, I have more phones > and boards I can send people. I plan to give away everything I have. That's great, I appreciate it. > One thing you could help me with is URLs to the datasheets, as many > as we can find, or have open URLs for. > http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#Key_Components Best documents I found are on "www.pudn.com" There are a lot of materials about MTK platform. The problem is that you have to have account there. > Hope this helps, good luck for your work! Thank you very much for your help. BR, Marcin From wolfgang at sharism.cc Wed Nov 10 15:30:19 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Wed, 10 Nov 2010 15:30:19 +0000 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101109045739.GA11763@asus.wolf> Message-ID: <20101110153019.GA22502@asus.wolf> Marcin, a small update, for completeness... > We have also schematics (which I see are almost the same as reference > schematic for MT6235 which I sent before) and PCB layers, that's > great! Bluelans digged up and released the battery side component placement PDF file as well, I updated http://en.qi-hardware.com/wiki/Sciphone_Dream_G2#Schematics.2C_component_placement So we have component placement for both sides now, which should make working with the phone a bit easier... Cheers, Wolfgang From marcin.mielczarczyk at gmail.com Thu Nov 18 22:46:15 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Thu, 18 Nov 2010 23:46:15 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101116063059.GA30722@asus.wolf> References: <20101103174131.GA8814@asus.wolf> <20101109045739.GA11763@asus.wolf> <20101110153019.GA22502@asus.wolf> <20101111054311.GA25311@asus.wolf> <20101116012245.GA28111@asus.wolf> <20101116063059.GA30722@asus.wolf> Message-ID: Hi, Finally I have running Linux on Sciphone G2. Code for U-Boot and Linux kernel can be found here: http://git.osmocom.org/gitweb?p=uboot-mt623x.git;a=summary http://git.osmocom.org/gitweb?p=linux-mt623x.git;a=summary To run U-Boot in RAM you can use osmocon loader for MTK. When U-Boot will start than you can load Linux kernel using serial port (U-Boot commands: loadb or loady). Default load address is set to 0x800000, so Linux kernel will be loaded there. To start executing Linux kernel type in following command: bootm 0x800000 After this command Linux kernel will be relocated, uncompressed and executed. After short time you should have working console in Linux. For testing purposes I prepared binaries which you can load and check that Linux works on your phone: http://downloads.qi-hardware.com/people/marcin/g2_uboot.bin http://downloads.qi-hardware.com/people/marcin/g2_uImage.bin uImage binary has already ramfs image built in, so you don't need any additional filesystem. These binaries were also tested by Steve Markgraf and keytwo, so it should work on most G2s. Today I was also able to load files from MMC card in U-Boot, so hopefully this functionality will be available very soon. Next step will be running UBoot and Linux from NAND, to make development more convenient. Recently we discovered that Sciphone G2 phones are sold with different memory configurations. So far we identified 3 types of memories: HY27XS08121M - 512Mb (64MB) NAND + 32MB RAM (http://hynix.com/datasheet/pdf/flash/HY27US(08_16)12(1_2)B%20Series(Rev0.5).pdf) HY27XA081G1M - 1Gb (128MB) NAND + 32MB RAM (http://hynix.com/datasheet/eng/nand/details/small_11_HY27US081G1M.jsp?menu1=01&menu2=05&menu3=01&menuNo=1&m=5&s=1) TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM (http://www.datasheetcatalog.com/datasheets_pdf/T/C/5/8/TC58NVG0S3AFT.shtml) This has to be detected in osmocon loader and U-Boot. I write about it so, you'll be aware of it. When U-Boot starts it detects your memory configuration and shows you how much NAND and RAM you have. If it comes to status of work in progress, following drivers are under development: - NAND controller (U-Boot/Linux) - SD/MMC controller (U-Boot/Linux) - GPIO (Linux) - LCD (U-Boot/Linux) I saw that MT6140 (RF) is connected over I2C bus, so probably this driver will be next on the list. BR, Marcin From laforge at gnumonks.org Tue Nov 9 07:24:58 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 Nov 2010 08:24:58 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101109045739.GA11763@asus.wolf> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101109045739.GA11763@asus.wolf> Message-ID: <20101109072458.GP6600@prithivi.gnumonks.org> Hi Wolfgang, thanks a lot for your support, including the teardown, PCB layer photographs, schematics, etc. I think this really is getting into shape now and we have a much better base from where to work on actual software for MT6235 based phones. My biggest concerns at the moment are that all of the peripheral data sheets are electrical data sheets only and MTK never documents the register set of e.g. the MT6140 (RF transceiver), MT6601 (bluetooth), MT6188 (fm radio), wifi, etc. This means a lot of unneccessary reverse engineering unless we can find an alternative source for this kind of information. I'm less worried about bluetooth or FM radio. The GSM RF transceiver is probably possible to reverse engineer from the test mode + 3wire protocol sniffing, but wifi e.g. is defnitely too complex to do a 100% reverse engineered driver for... > But I don't even have links to the 6235 or 6140 datasheets right now... The links I know only go to 52RD BBS and similar sites, where you cannot download without an account. I have an account, but we don't want to put them in the wiki publicly ;) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From squalyl at gmail.com Tue Nov 9 09:10:35 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Tue, 9 Nov 2010 10:10:35 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101109072458.GP6600@prithivi.gnumonks.org> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101109045739.GA11763@asus.wolf> <20101109072458.GP6600@prithivi.gnumonks.org> Message-ID: For my part I am totally impressed by the PCB layers images. How do you get them? just grinding with fine sandpaper and a lot of patience, or do you have a machine? Sebastien On Tue, Nov 9, 2010 at 8:24 AM, Harald Welte wrote: > Hi Wolfgang, > > thanks a lot for your support, including the teardown, PCB layer > photographs, > schematics, etc. > > I think this really is getting into shape now and we have a much better > base > from where to work on actual software for MT6235 based phones. > > My biggest concerns at the moment are that all of the peripheral data > sheets > are electrical data sheets only and MTK never documents the register set of > e.g. the MT6140 (RF transceiver), MT6601 (bluetooth), MT6188 (fm radio), > wifi, etc. > > This means a lot of unneccessary reverse engineering unless we can find an > alternative source for this kind of information. I'm less worried about > bluetooth or FM radio. The GSM RF transceiver is probably possible to > reverse > engineer from the test mode + 3wire protocol sniffing, but wifi e.g. is > defnitely too complex to do a 100% reverse engineered driver for... > > > But I don't even have links to the 6235 or 6140 datasheets right now... > > The links I know only go to 52RD BBS and similar sites, where you cannot > download without an account. I have an account, but we don't want to put > them > in the wiki publicly ;) > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang at sharism.cc Tue Nov 9 09:42:42 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Tue, 9 Nov 2010 09:42:42 +0000 Subject: Linux + u-boot port to MT6235 In-Reply-To: References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101109045739.GA11763@asus.wolf> <20101109072458.GP6600@prithivi.gnumonks.org> Message-ID: <20101109094242.GA13124@asus.wolf> Sebastien, > For my part I am totally impressed by the PCB layers images. How do you get > them? just grinding with fine sandpaper and a lot of patience, or do you > have a machine? I don't know, I wish I could take pictures but they wouldn't want me to come to their shop :-) From laforge at gnumonks.org Wed Nov 3 21:47:45 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 3 Nov 2010 22:47:45 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101103174131.GA8814@asus.wolf> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> Message-ID: <20101103214745.GA4166@prithivi.gnumonks.org> Wolfgang, thanks a lot for your great help. It's really amazing. As Marcin said, getting access to some more boards/units would be useful, especially if they have JTAG access and even if some of them might not be fully functional. Charger/USB cable are definitely reqired, all the other parts are more or less optional. Schematics would also most definitely be great. PCB pictures might be useful as a replacement if no schematics are available. Sad to hear that it is already end of life, but good to know that there might be more MT6235 based designs that have JTAG exposed. Cheers from Luzern/Switzerland, 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 Nov 3 22:46:10 2010 From: steve at steve-m.de (Steve Markgraf) Date: Wed, 03 Nov 2010 23:46:10 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101103214745.GA4166@prithivi.gnumonks.org> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> Message-ID: <4CD1E632.7020808@steve-m.de> Hi Wolfgang, I'm really amazed by your commitment :) On 03.11.2010 22:47, Harald Welte wrote: > Sad to hear that it is already end of life, but good to know that there might > be more MT6235 based designs that have JTAG exposed. By the way - many shops still sell the "Sciphone G2+", do you know the difference compared to the G2? One thing I noticed is that the G2 seems to be triple-band (there's a 850/1800/1900 and a 900/1800/1900 variant), and the G2+ quad-band. Can you confirm this? Regards, Steve From wolfgang at sharism.cc Tue Nov 9 06:29:00 2010 From: wolfgang at sharism.cc (Wolfgang Spraul) Date: Tue, 9 Nov 2010 06:29:00 +0000 Subject: Linux + u-boot port to MT6235 In-Reply-To: <4CD1E632.7020808@steve-m.de> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD1E632.7020808@steve-m.de> Message-ID: <20101109062900.GB12340@asus.wolf> Steve, > By the way - many shops still sell the "Sciphone G2+", do you know > the difference compared to the G2? One thing I noticed is that the > G2 seems to be triple-band (there's a 850/1800/1900 and a > 900/1800/1900 variant), and the G2+ quad-band. > > Can you confirm this? A positive confirmation for this kind of thing is really hard. I asked Bluelans sales, and they said they never sold a "G2+". They thought some online shops just added the '+' to improve their sales over the ones that have no plus :-) As for the G2 being triple-band, do you have some links? All I heard is that G2 is quad-band. The box I am holding in my hand says "Quad-band phone with WIFI", although that also doesn't need to mean much. I could imagine that some ICs on the G2 can do quad, but other components on the board (filters?) actually pick 3 of those 4? So - I can only ask back :-) Can anyone confirm that the G2 is really and fully quad-band? Maybe we have to wait until OsmocomBB is at the point that we see it running... I google "Sciphone Dream G2 tri-band" : 10,300 results "Sciphone Dream G2 quad-band" : 15,800 results Welcome to China :-) Of course you also find "tri-band GMS" and whatever other typos. Sorry I have no definitive answer. Wolfgang From laforge at gnumonks.org Tue Nov 9 08:10:46 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 Nov 2010 09:10:46 +0100 Subject: G2 tri-band / quad-band In-Reply-To: <20101109062900.GB12340@asus.wolf> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD1E632.7020808@steve-m.de> <20101109062900.GB12340@asus.wolf> Message-ID: <20101109081046.GR6600@prithivi.gnumonks.org> On Tue, Nov 09, 2010 at 06:29:00AM +0000, Wolfgang Spraul wrote: > I could imagine that some ICs on the G2 can do quad, but other > components on the board (filters?) actually pick 3 of those 4? According to the schematics it is a quad-band design. The Antenna switch is a SP5T (two bands tx, 3 bands rx), followed by an additional filter that separates the 850 from the 900 in the RX path. Given that the filters (including the 850/900) are all unbalanced-to-balanced filters, I doubt that somebody would simply not place them (as you cannot replace them just with a 0ohms resistor or soemthing. By removing one filter you would not be able to produce a standard 850/1800/1900 or 950/1800/1900 configuration but something like 850/900/1800 or 850/900/1900 which doesn't maeke sense. My personal educated guess is: they are all quad-band. -- - 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 Tue Nov 9 09:09:42 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 9 Nov 2010 10:09:42 +0100 Subject: G2 tri-band / quad-band In-Reply-To: <20101109081046.GR6600@prithivi.gnumonks.org> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD1E632.7020808@steve-m.de> <20101109062900.GB12340@asus.wolf> <20101109081046.GR6600@prithivi.gnumonks.org> Message-ID: Hi, > Given that the filters (including the 850/900) are all unbalanced-to-balanced > filters, I doubt that somebody would simply not place them (as you cannot > replace them just with a 0ohms resistor or soemthing. ?By removing one filter > you would not be able to produce a standard 850/1800/1900 or 950/1800/1900 > configuration but something like 850/900/1800 or 850/900/1900 which doesn't > maeke sense. Have you noticed that the capacitors on the 850 path are marked as N/C ? I don't see why they wouldn't have put them tough ... it's not like it changes the price much. Sylvain From laforge at gnumonks.org Tue Nov 9 10:28:50 2010 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 Nov 2010 11:28:50 +0100 Subject: G2 tri-band / quad-band In-Reply-To: References: <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD1E632.7020808@steve-m.de> <20101109062900.GB12340@asus.wolf> <20101109081046.GR6600@prithivi.gnumonks.org> Message-ID: <20101109102850.GT6600@prithivi.gnumonks.org> On Tue, Nov 09, 2010 at 10:09:42AM +0100, Sylvain Munaut wrote: > Hi, > > > Given that the filters (including the 850/900) are all unbalanced-to-balanced > > filters, I doubt that somebody would simply not place them (as you cannot > > replace them just with a 0ohms resistor or soemthing. ?By removing one filter > > you would not be able to produce a standard 850/1800/1900 or 950/1800/1900 > > configuration but something like 850/900/1800 or 850/900/1900 which doesn't > > maeke sense. > > Have you noticed that the capacitors on the 850 path are marked as N/C ? no. ouch. > I don't see why they wouldn't have put them tough ... it's not like it > changes the price much. probably a 'marketing requirement'... "we don't want to sell a quadband phone for the same price like a tri-band phone" -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From osmocom at nohup.in Tue Nov 9 08:46:42 2010 From: osmocom at nohup.in (Rahul Khanna) Date: Tue, 9 Nov 2010 14:16:42 +0530 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101109062900.GB12340@asus.wolf> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD1E632.7020808@steve-m.de> <20101109062900.GB12340@asus.wolf> Message-ID: On Tue, Nov 9, 2010 at 11:59 AM, Wolfgang Spraul wrote: > > Steve, > > > By the way - many shops still sell the "Sciphone G2+", do you know > > the difference compared to the G2? One thing I noticed is that the > > G2 seems to be triple-band (there's a 850/1800/1900 and a > > 900/1800/1900 variant), and the G2+ quad-band. > > > > Can you confirm this? > > A positive confirmation for this kind of thing is really hard. > I asked Bluelans sales, and they said they never sold a "G2+". They > thought some online shops just added the '+' to improve their sales > over the ones that have no plus :-) > As for the G2 being triple-band, do you have some links? All I heard > is that G2 is quad-band. The box I am holding in my hand says > "Quad-band phone with WIFI", although that also doesn't need to mean > much. > I could imagine that some ICs on the G2 can do quad, but other > components on the board (filters?) actually pick 3 of those 4? > > So - I can only ask back :-) Can anyone confirm that the G2 is really > and fully quad-band? Maybe we have to wait until OsmocomBB is at the > point that we see it running... > > I google > "Sciphone Dream G2 tri-band" : 10,300 results > "Sciphone Dream G2 quad-band" : 15,800 results > > Welcome to China :-) > Of course you also find "tri-band GMS" and whatever other typos. > Sorry I have no definitive answer. > Wolfgang > Hi All, First and foremost, *awesome* work :-) I have been searching for getting Linux on MT 6235 after I happen to get this phone in India http://flyphone.in/products/B%20450.html?model_name=B%20450 I think it is based on MT 6235, as when I connect it using the USB cable to a Windows box and select the camera mode it identifies the camera as MT 6235. Reading in a document I found online (one question here, can I paste the link to the source which I found online, it is a confidential MTK presentation), it states that MT 6235 can only support up to 2MP camera and it states that MT 6238 can support upto 3MP, the phone manual says 3.2MP. Pardon my ignorance, but what would be the best way (source to read, experiment and create serial cable) to replicate the work you guys are doing with this phone. I tried the MTK flashtool but it fails, though it detects the phone as MT 6229. Thanks, Rahul From bouchtaoui at gmail.com Tue Nov 9 08:54:51 2010 From: bouchtaoui at gmail.com (Nordin) Date: Tue, 09 Nov 2010 09:54:51 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101109062900.GB12340@asus.wolf> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD1E632.7020808@steve-m.de> <20101109062900.GB12340@asus.wolf> Message-ID: <4CD90C5B.3030802@gmail.com> On 9-11-2010 7:29, Wolfgang Spraul wrote: > > A positive confirmation for this kind of thing is really hard. > I asked Bluelans sales, and they said they never sold a "G2+". They > thought some online shops just added the '+' to improve their sales > over the ones that have no plus :-) > As for the G2 being triple-band, do you have some links? All I heard > is that G2 is quad-band. The box I am holding in my hand says > "Quad-band phone with WIFI", although that also doesn't need to mean > much. > I could imagine that some ICs on the G2 can do quad, but other > components on the board (filters?) actually pick 3 of those 4? > > So - I can only ask back :-) Can anyone confirm that the G2 is really > and fully quad-band? Maybe we have to wait until OsmocomBB is at the > point that we see it running... > > I google > "Sciphone Dream G2 tri-band" : 10,300 results > "Sciphone Dream G2 quad-band" : 15,800 results > > Welcome to China :-) > Of course you also find "tri-band GMS" and whatever other typos. > Sorry I have no definitive answer. > Wolfgang Hahahaha, I really enjoyed your post :D From steve at steve-m.de Mon Nov 8 14:45:28 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 08 Nov 2010 15:45:28 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <20101103214745.GA4166@prithivi.gnumonks.org> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> Message-ID: <4CD80D08.3040003@steve-m.de> Hi Marcin, hi list, today I received the Sciphone G2 and 'hacked' the headphone cable into a serial cable (which worked quite well, compared to the Mobistel). osmocon worked on the first try. I only had to modify the UART_BASE address in my mtk test code (steve-m/mtk_hack). (log attached) I've used the FT2232 UART on the OpenMoko Debug Board, but it works with a PL2303 as well. Now we need to find out why it doesn't work for you... Regards, Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: osmocon_mt6235.txt URL: From laforge at gnumonks.org Mon Nov 8 17:00:06 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Nov 2010 18:00:06 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <4CD80D08.3040003@steve-m.de> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD80D08.3040003@steve-m.de> Message-ID: <20101108170006.GI6600@prithivi.gnumonks.org> Hi Steve, On Mon, Nov 08, 2010 at 03:45:28PM +0100, Steve Markgraf wrote: > today I received the Sciphone G2 and 'hacked' the headphone cable > into a serial cable (which worked quite well, compared to the > Mobistel). > > osmocon worked on the first try. I only had to modify the UART_BASE > address in my mtk test code (steve-m/mtk_hack). (log attached) this is great news. It means people without JTAG (and without soldering wires to test pads on the PCB) will be able to participate by simply loading code via the serial port. I can't wait until I receive the Sciphone G2 boards from Wolfgang Right now I've been soldering some wires to the test pads next to the MT6227 of the Mobistel EL570, I'm quite sure they also have JTAG on it. I'm planning to compare the GSM part of the 622x and 6235 as per the data sheet next. I hope they are reasonably similar, which would mean any testing / development we do on the 622x could later be leveraged to the 6235. 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 thegrugq at gmail.com Tue Nov 9 03:35:35 2010 From: thegrugq at gmail.com (the grugq) Date: Tue, 9 Nov 2010 10:35:35 +0700 Subject: Linux + u-boot port to MT6235 In-Reply-To: <4CD80D08.3040003@steve-m.de> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD80D08.3040003@steve-m.de> Message-ID: <01B5DE15-0BCA-4A95-B79D-B874F7D8AEF7@gmail.com> Hey, Will this theoretically work with any MTK6235 based phone? Or is the serial connection specific to the G2 device? There are plenty of MTK based phones out here, but finding a specific model is a long shot. Cheers, --gq On 8 Nov 2010, at 21:45, Steve Markgraf wrote: > Hi Marcin, hi list, > > today I received the Sciphone G2 and 'hacked' the headphone cable into a serial cable (which worked quite well, compared to the Mobistel). > > osmocon worked on the first try. I only had to modify the UART_BASE address in my mtk test code (steve-m/mtk_hack). (log attached) > > I've used the FT2232 UART on the OpenMoko Debug Board, but it works with a PL2303 as well. > > Now we need to find out why it doesn't work for you... > > Regards, > Steve > From marcin.mielczarczyk at gmail.com Tue Nov 9 04:39:16 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Tue, 9 Nov 2010 05:39:16 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <01B5DE15-0BCA-4A95-B79D-B874F7D8AEF7@gmail.com> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD80D08.3040003@steve-m.de> <01B5DE15-0BCA-4A95-B79D-B874F7D8AEF7@gmail.com> Message-ID: Hi, On Tue, Nov 9, 2010 at 4:35 AM, the grugq wrote: > Hey, > > > Will this theoretically work with any MTK6235 based phone? Or is the serial connection specific to the G2 device? There are plenty of MTK based phones out here, but finding a specific model is a long shot. This will work on all phones based on MT6235 as long as code will be executed in internal RAM (64KB) and you'll know where are serial port pins (these are specific for phone). There will be also differences in RAM, NAND, LCD, etc. and it's matter of writing new driveres for these peripherals. BR, Marcin From marcin.mielczarczyk at gmail.com Tue Nov 9 05:53:32 2010 From: marcin.mielczarczyk at gmail.com (Marcin Mielczarczyk) Date: Tue, 9 Nov 2010 06:53:32 +0100 Subject: Linux + u-boot port to MT6235 In-Reply-To: <4CD80D08.3040003@steve-m.de> References: <20101029161141.GN3544@prithivi.gnumonks.org> <20101030142554.GL8939@prithivi.gnumonks.org> <20101103174131.GA8814@asus.wolf> <20101103214745.GA4166@prithivi.gnumonks.org> <4CD80D08.3040003@steve-m.de> Message-ID: Hi Steve, hi list, On Mon, Nov 8, 2010 at 3:45 PM, Steve Markgraf wrote: > Hi Marcin, hi list, > > today I received the Sciphone G2 and 'hacked' the headphone cable into a > serial cable (which worked quite well, compared to the Mobistel). > > osmocon worked on the first try. I only had to modify the UART_BASE address > in my mtk test code (steve-m/mtk_hack). (log attached) That's really good. I connected PL2303 to my PC and it also worked (before I used two built-in ports in Dell computer). I had this kind of problem some time ago with mini2440 board (based on s3c2440). I was able to download the code and it started on the phone but hanged just after printing HW version. I'll check why is that. Unfortunatelly I had problems pushing my UBoot code to git.osmocom.org, so until I'll not solve them, you can use my patch from attachment. This patch should be applied on recent repository of UBoot: git://git.denx.de/u-boot.git After applying patch it should be possible to configure Sciphone G2 target: make sciphone_g2_config make CROSS_COMPILE=.... After compilation you should be able to download UBoot to Sciphone using osmocon. For this, there should be PLL turned on and then EMI controller initialized to be able to download UBoot code to external RAM (size of UBoot is about 120KB). You can find this initialization in "board/mtk/sciphone_g2/sciphone_g2.c" file. It should be applied to loader. BR, Marcin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sciphone_g2-Added-support-for-Sciphone-G2.patch Type: application/octet-stream Size: 44831 bytes Desc: not available URL: From oskar at enrutador.com Sat Nov 6 02:02:37 2010 From: oskar at enrutador.com (Oscar Soriano Riera) Date: Sat, 06 Nov 2010 03:02:37 +0100 Subject: Its posible that OsmocomBB work as a =?UTF-8?Q?USRP=3F?= Message-ID: Hi everyone from Spain I have one question: Its posible use OsmocomBB on C123 for do task as a USRP ? or similar scanner ? Thanks for your BIG work ???? congratulations -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Nov 6 07:32:31 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 6 Nov 2010 08:32:31 +0100 Subject: Its posible that OsmocomBB work as a USRP? In-Reply-To: References: Message-ID: <20101106073231.GF27685@prithivi.gnumonks.org> Hi Oscar, On Sat, Nov 06, 2010 at 03:02:37AM +0100, Oscar Soriano Riera wrote: > Its posible use > OsmocomBB on C123 for do task as a USRP ? or similar scanner ? No, I think you have some conceptual misunderstanding about radio technology in general. In your subject you ask if OsmocomBB can work as USRP: This is wrong, as OsmocomBB is a protocol stack and radio driver, and the USRP is hardware. How can some software work as hardware? In the body of your mail you ask if the C123 can act as USRP: No. The USRP is a wide-band software defined radio, and the Calypso/Iota/Rita design implements a more traditional narrow-band zero-if transceiver with a DSP in the baseband. Nevertheless, you can use both hardware design to receive and transmit GSM signals. But this is very far from what you ask by "one device working like the other" -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From oskar at enrutador.com Sat Nov 6 14:55:25 2010 From: oskar at enrutador.com (Oscar Soriano Riera) Date: Sat, 06 Nov 2010 15:55:25 +0100 Subject: Its posible that OsmocomBB work as a =?UTF-8?Q?USRP=3F?= In-Reply-To: <20101106073231.GF27685@prithivi.gnumonks.org> References: <20101106073231.GF27685@prithivi.gnumonks.org> Message-ID: <43eed512caea42ea16cda3cabf3cf13a@enrutador.com> Hi Harald Thanks for clarifying this confusion. I bought a motorola C123 on ebay with RS232 data cable. When I arrive I'll try this fantastic software. Thank you very much for your work, this world needs more people like you On Sat, 6 Nov 2010 08:32:31 +0100, Harald Welte wrote: > Hi Oscar, > > On Sat, Nov 06, 2010 at 03:02:37AM +0100, Oscar Soriano Riera wrote: > >> Its posible use >> OsmocomBB on C123 for do task as a USRP ? or similar scanner ? > > No, I think you have some conceptual misunderstanding about radio > technology in general. > > In your subject you ask if OsmocomBB can work as USRP: > This is wrong, as OsmocomBB is a protocol stack and radio driver, and > the USRP > is hardware. How can some software work as hardware? > > In the body of your mail you ask if the C123 can act as USRP: > No. The USRP is a wide-band software defined radio, and the > Calypso/Iota/Rita > design implements a more traditional narrow-band zero-if transceiver > with a DSP > in the baseband. > > Nevertheless, you can use both hardware design to receive and > transmit GSM > signals. But this is very far from what you ask by "one device > working like > the other" From devpurohit19 at yahoo.com Mon Nov 8 20:21:16 2010 From: devpurohit19 at yahoo.com (Dev Purohit) Date: Mon, 8 Nov 2010 12:21:16 -0800 (PST) Subject: application ./mobil In-Reply-To: Message-ID: <682002.15420.qm@web114213.mail.gq1.yahoo.com> Hello List, Ii'm facing problem when i'l trying to run ./mobil application i'm getting below error. if i need some USB or serial SIM reader, or should insert the sim in my MS itself thanks in advance for help. ========= Failed to connect to '/tmp/osmocom_sap'.? <<<<<<<<< Failed during sap_open(), no SIM reader <000e> sim.c:1206 init SIM client <0005> gsm48_cc.c:61 init Call Control <0001> gsm48_rr.c:4944 init Radio Ressource process <0004> gsm48_mm.c:1220 init Mobility Management process <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM. <0002> gsm322.c:3471 init PLMN process <0003> gsm322.c:3472 init Cell Selection process <0003> gsm322.c:3526 No stored BA list Failed to parse the config file: '/etc/osmocom/osmocom.cfg' Please check or create config file using: 'touch /etc/osmocom/osmocom.cfg' <<<<<<<< What Is the solution for this how i can do this ========== Regards, Dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Mon Nov 8 20:52:59 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 08 Nov 2010 21:52:59 +0100 Subject: application ./mobil In-Reply-To: <682002.15420.qm@web114213.mail.gq1.yahoo.com> References: <682002.15420.qm@web114213.mail.gq1.yahoo.com> Message-ID: <4CD8632B.80206@steve-m.de> Hi Dev, On 08.11.2010 21:21, Dev Purohit wrote: > Hello List, > > Ii'm facing problem when i'l trying to run ./mobil application i'm getting below error. > if i need some USB or serial SIM reader, or should insert the sim in my MS itself thanks in advance for help. If you want to use a real SIM-card in the phone, you need to use the sylvain/testing branch (git checkout sylvain/testing), and you need to tell mobile it should use a real SIM as well by adding "sim reader" to your osmocom.cfg. > Failed to connect to '/tmp/osmocom_sap'.<<<<<<<<< > Failed during sap_open(), no SIM reader This is normal for now, since we don't have working BTSAP. > Failed to parse the config file: '/etc/osmocom/osmocom.cfg' > Please check or create config file using: 'touch /etc/osmocom/osmocom.cfg'<<<<<<<< Nothing to add. Create this file and then save the config via the vty. (telnet localhost 4247 -> "enable" -> "configure terminal" -> "write") Regards, Steve From devpurohit19 at yahoo.com Mon Nov 8 22:25:03 2010 From: devpurohit19 at yahoo.com (Dev Purohit) Date: Mon, 8 Nov 2010 14:25:03 -0800 (PST) Subject: application ./mobil In-Reply-To: <4CD8632B.80206@steve-m.de> Message-ID: <265450.88085.qm@web114208.mail.gq1.yahoo.com> Hello Steve, Thank you for your very very quick response, ?I'm using? sylvain/testing branch only >use a real SIM as well by adding "sim reader" to your osmocom.cfg.<<< pls guide? me, how to add "sim reader" to my osmocom.cfg ? Regards, Dev --- On Mon, 11/8/10, Steve Markgraf wrote: From: Steve Markgraf Subject: Re: application ./mobil To: "Dev Purohit" Cc: baseband-devel at lists.osmocom.org Date: Monday, November 8, 2010, 8:52 PM Hi Dev, On 08.11.2010 21:21, Dev Purohit wrote: > Hello List, > > Ii'm facing problem when i'l trying to run ./mobil application i'm getting below error. > if i need some USB or serial SIM reader, or should insert the sim in my MS itself thanks in advance for help. If you want to use a real SIM-card in the phone, you need to use the sylvain/testing branch (git checkout sylvain/testing), and you need to tell mobile it should use a real SIM as well by adding "sim reader" to your osmocom.cfg. > Failed to connect to '/tmp/osmocom_sap'.<<<<<<<<< > Failed during sap_open(), no SIM reader This is normal for now, since we don't have working BTSAP. > Failed to parse the config file: '/etc/osmocom/osmocom.cfg' > Please check or create config file using: 'touch /etc/osmocom/osmocom.cfg'<<<<<<<< Nothing to add. Create this file and then save the config via the vty. (telnet localhost 4247 -> "enable" -> "configure terminal" -> "write") Regards, Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Mon Nov 8 22:36:09 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 08 Nov 2010 23:36:09 +0100 Subject: application ./mobil In-Reply-To: <265450.88085.qm@web114208.mail.gq1.yahoo.com> References: <265450.88085.qm@web114208.mail.gq1.yahoo.com> Message-ID: <4CD87B59.6090701@steve-m.de> Hi, On 08.11.2010 23:25, Dev Purohit wrote: >> use a real SIM as well by adding "sim reader" to your > osmocom.cfg.<<< > pls guide me, how to add "sim reader" to my osmocom.cfg ? There are 3 possibilities: "no sim", "sim test" for using the test-sim specified in the config file and "sim reader" for using a sim in the phone. See the attached config file. You should replace the IMEI, or use the random IMEI-feature. Put it to /etc/osmocom/ and make sure that the user that runs ./mobile has read/write permissions for this file. Regards, Steve -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: osmocom.cfg URL: From devpurohit19 at yahoo.com Tue Nov 9 15:51:06 2010 From: devpurohit19 at yahoo.com (Dev Purohit) Date: Tue, 9 Nov 2010 07:51:06 -0800 (PST) Subject: application ./mobil In-Reply-To: <4CD87B59.6090701@steve-m.de> Message-ID: <797477.30757.qm@web114211.mail.gq1.yahoo.com> Hello Steve, ? Thanks?alot, ?it was great help. ? Regards, Dev ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From technosabby at gmail.com Wed Nov 10 15:48:16 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 10 Nov 2010 21:18:16 +0530 Subject: GSMTAP Message-ID: Hello All, I have a question regarding GSMTAP , If it is used for sending messages to wireshark only or it has some other significant, like communication between L2 and L3 or communication with layer1, as the uint8_t and uint16_t were widely used in source code Kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Nov 10 18:14:17 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Nov 2010 19:14:17 +0100 Subject: GSMTAP In-Reply-To: References: Message-ID: <20101110181417.GC11011@prithivi.gnumonks.org> On Wed, Nov 10, 2010 at 09:18:16PM +0530, Marten Christophe wrote: > Hello All, > > I have a question regarding GSMTAP , If it is used for sending messages to > wireshark only or it has some other significant, like communication between > L2 and L3 or communication with layer1, as the > uint8_t and uint16_t were widely used in source code GSMTAP is a purely 'artificial' data format that is used by OpenBTS, airprobe and OsmocomBB to forward GSM MAC blocks (layer 2 frames with 23 bytes length) of the Um interface into wireshark. There's no other purpuse to it. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From heiko at sntech.de Fri Nov 12 13:11:49 2010 From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=) Date: Fri, 12 Nov 2010 14:11:49 +0100 Subject: Sciphone Dream G2 WLan MT5921 Message-ID: <201011121411.55662.heiko@sntech.de> Hi, Harald Welte wrote: > bluetooth or FM radio. The GSM RF transceiver is probably possible to > reverse engineer from the test mode + 3wire protocol sniffing, but wifi e.g. is > defnitely too complex to do a 100% reverse engineered driver for... while looking through the component listing on Wolgang's wiki page I recognized the MediaTek MT5921 WLan-chipset. This should be the same (or at least similar) chip built into the german Thalia/Bol/Buch.de Oyo ebook-reader (also released in France). The module is called mt5921sta_spi.ko and claims to be released under the GPL but until now no source release happened for any GPL component. The module is also contained in the firmware of the Booq Avant released in Spain (http://www.booqreaders.com/en/product_Avant) and possibly many more ebook-readers as these models seem to share their basic design. Heiko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From steve at steve-m.de Fri Nov 12 13:52:54 2010 From: steve at steve-m.de (Steve Markgraf) Date: Fri, 12 Nov 2010 14:52:54 +0100 Subject: Sciphone Dream G2 WLan MT5921 In-Reply-To: <201011121411.55662.heiko@sntech.de> References: <201011121411.55662.heiko@sntech.de> Message-ID: <4CDD46B6.5030701@steve-m.de> Hi. On 12.11.2010 14:11, Heiko St?bner wrote: > This should be the same (or at least similar) chip built into the german > Thalia/Bol/Buch.de Oyo ebook-reader (also released in France). The module is > called mt5921sta_spi.ko and claims to be released under the GPL but until now > no source release happened for any GPL component. Hm, that's interesting. Someone already asked them and they released the U-Boot sources and said "they're working on it": http://www.fwma.de/pmwiki/pmwiki.php?n=Main.OYO#toc10 Regards, Steve From heiko at sntech.de Fri Nov 12 14:27:59 2010 From: heiko at sntech.de (Heiko =?iso-8859-1?q?St=FCbner?=) Date: Fri, 12 Nov 2010 15:27:59 +0100 Subject: Sciphone Dream G2 WLan MT5921 In-Reply-To: <4CDD46B6.5030701@steve-m.de> References: <201011121411.55662.heiko@sntech.de> <4CDD46B6.5030701@steve-m.de> Message-ID: <201011121528.04881.heiko@sntech.de> Hi, Am Freitag 12 November 2010 schrieb Steve Markgraf: > On 12.11.2010 14:11, Heiko St?bner wrote: > > This should be the same (or at least similar) chip built into the german > > Thalia/Bol/Buch.de Oyo ebook-reader (also released in France). The module > > is called mt5921sta_spi.ko and claims to be released under the GPL but > > until now no source release happened for any GPL component. > > Hm, that's interesting. Someone already asked them and they released the > U-Boot sources and said "they're working on it": but they take awfully long for something which normaly should be available when the product is released (I got the u-boot sources from them on 2010-11-03 and they are silent ever since) > http://www.fwma.de/pmwiki/pmwiki.php?n=Main.OYO#toc10 [you will find my mmind-nick there too :-) ] Heiko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From vamposdecampos at gmail.com Wed Nov 17 21:35:14 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Wed, 17 Nov 2010 23:35:14 +0200 Subject: [PATCH 0/4] Fixes for gta0x targets Message-ID: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> Hi all, I've been trying to join the party with my OpenMoko GTA02, and I found that a few tweaks were required. Patch 1/4 was required to get the romloader to start, otherwise osmocon would only receive an occasional '\x00' character instead of the ident_cmd. It works perfectly with the beacon interval reduced to 13 mS, but I've made it configurable just in case other targets don't like it. Patches 2/4 and 3/4 are bugfixes for the calypso uart code. The LCR register ended up being clobbered, and this rendered the uart on my board silent. Finally, I'm using the GTA02 AP as the "host", communicating via the internal ttySAC0 UART. Patch 4/4 allowed me to cross-compile osmocon & friends on my x86 box with the AP ARM as the target. Now I can run, ./osmocon -m romload -p /dev/ttySAC0 -i 13 -d tr firmware/layer1.highram.bin while toggling power via, echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on and get: OSMOCOM Layer 1 (revision osmocon_v0.0.0-696-ge801cee-modified) ====================================================================== Device ID code: 0xb496 Device Version code: 0x0000 ARM ID code: 0xfff3 cDSP ID code: 0x0128 Die ID code: e4942219e4949b52 ====================================================================== REG_DPLL=0x2413 CNTL_ARM_CLK=0xf0a1 CNTL_CLK=0xff91 CNTL_RST=0xfff3 CNTL_ARM_DIV=0xfff9 ====================================================================== Cheers, Alex Alex Badea (4): osmocon: make beacon interval configurable via cmdline target uart: fix preservation of LCR target uart: remove REG_OFFS() macro side-effect toplevel Makefile: accept arguments for host ./configure calls src/Makefile | 8 ++++---- src/host/osmocon/osmocon.c | 26 ++++++++++++++++---------- src/target/firmware/calypso/uart.c | 10 +++++----- 3 files changed, 25 insertions(+), 19 deletions(-) From vamposdecampos at gmail.com Wed Nov 17 21:35:15 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Wed, 17 Nov 2010 23:35:15 +0200 Subject: [PATCH 1/4] osmocon: make beacon interval configurable via cmdline In-Reply-To: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> References: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290029718-15910-2-git-send-email-vamposdecampos@gmail.com> Beacons with the default 50 mS interval are too far apart to be picked up by the OpenMoko gta0x Calypso chip. Make them configurable via a -i commandline argument. As recommended in the OpenMoko wiki[1], an interval of 13 mS works. [1] http://wiki.openmoko.org/wiki/GSM/Flashing (-od fluid argument) Signed-off-by: Alex Badea --- src/host/osmocon/osmocon.c | 26 ++++++++++++++++---------- 1 files changed, 16 insertions(+), 10 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index 024697d..6f6f566 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -51,7 +51,7 @@ #define MAX_HDR_SIZE 128 #define MAGIC_OFFSET 0x3be2 -#define BEACON_INTERVAL 50000 +#define DEFAULT_BEACON_INTERVAL 50000 #define ROMLOAD_INIT_BAUDRATE B19200 #define ROMLOAD_DL_BAUDRATE B115200 #define ROMLOAD_BLOCK_HDR_LEN 10 @@ -137,6 +137,7 @@ struct dnload { int dump_rx; int dump_tx; + int beacon_interval; /* data to be downloaded */ uint8_t *data; @@ -289,7 +290,7 @@ static void beacon_timer_cb(void *p) if (!(rc == sizeof(romload_ident_cmd))) printf("Error sending identification beacon\n"); - bsc_schedule_timer(p, 0, BEACON_INTERVAL); + bsc_schedule_timer(p, 0, dnload.beacon_interval); } } @@ -304,7 +305,7 @@ static void mtk_timer_cb(void *p) if (!(rc == 1)) printf("Error sending identification beacon\n"); - bsc_schedule_timer(p, 0, BEACON_INTERVAL); + bsc_schedule_timer(p, 0, dnload.beacon_interval); } } @@ -888,7 +889,7 @@ static int handle_read(void) serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); tick_timer.cb = &beacon_timer_cb; tick_timer.data = &tick_timer; - bsc_schedule_timer(&tick_timer, 0, BEACON_INTERVAL); + bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); } } else if (!memcmp(buffer, phone_nack, sizeof(phone_nack))) { printf("Received DOWNLOAD NACK from phone, something went" @@ -1003,7 +1004,7 @@ static int handle_read_romload(void) "something went wrong, aborting\n"); serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); dnload.romload_state = WAITING_IDENTIFICATION; - bsc_schedule_timer(&tick_timer, 0, BEACON_INTERVAL); + bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); } break; case WAITING_CHECKSUM_ACK: @@ -1025,7 +1026,7 @@ static int handle_read_romload(void) "match ours, aborting\n", ~buffer[2]); serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); dnload.romload_state = WAITING_IDENTIFICATION; - bsc_schedule_timer(&tick_timer, 0, BEACON_INTERVAL); + bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); bufptr -= 1; } break; @@ -1042,7 +1043,7 @@ static int handle_read_romload(void) printf("Received branch nack, aborting\n"); serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); dnload.romload_state = WAITING_IDENTIFICATION; - bsc_schedule_timer(&tick_timer, 0, BEACON_INTERVAL); + bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); } break; default: @@ -1244,6 +1245,7 @@ static int parse_mode(const char *arg) "\t\t [ -l /tmp/osmocom_loader ]\n" \ "\t\t [ -m {c123,c123xor,c140,c140xor,c155,romload,mtk} ]\n" \ "\t\t [ -c /to-be-chainloaded-file.bin ]\n" \ + "\t\t [ -i beacon-interval (mS) ]\n" \ "\t\t file.bin\n\n" \ "* Open serial port /dev/ttyXXXX (connected to your phone)\n" \ "* Perform handshaking with the ramloader in the phone\n" \ @@ -1452,8 +1454,9 @@ int main(int argc, char **argv) dnload.mode = MODE_C123; dnload.chainload_filename = NULL; + dnload.beacon_interval = DEFAULT_BEACON_INTERVAL; - while ((opt = getopt(argc, argv, "d:hl:p:m:c:s:v")) != -1) { + while ((opt = getopt(argc, argv, "d:hl:p:m:c:s:i:v")) != -1) { switch (opt) { case 'p': serial_dev = optarg; @@ -1478,6 +1481,9 @@ int main(int argc, char **argv) case 'c': dnload.chainload_filename = optarg; break; + case 'i': + dnload.beacon_interval = atoi(optarg) * 1000; + break; case 'h': default: usage(argv[0]); @@ -1530,14 +1536,14 @@ int main(int argc, char **argv) serial_set_baudrate(ROMLOAD_INIT_BAUDRATE); tick_timer.cb = &beacon_timer_cb; tick_timer.data = &tick_timer; - bsc_schedule_timer(&tick_timer, 0, BEACON_INTERVAL); + bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); } else if (dnload.mode == MODE_MTK) { tmp_load_address = MTK_ADDRESS; serial_set_baudrate(MTK_INIT_BAUDRATE); tick_timer.cb = &mtk_timer_cb; tick_timer.data = &tick_timer; - bsc_schedule_timer(&tick_timer, 0, BEACON_INTERVAL); + bsc_schedule_timer(&tick_timer, 0, dnload.beacon_interval); } dnload.load_address[0] = (tmp_load_address >> 24) & 0xff; -- 1.7.0.4 From vamposdecampos at gmail.com Wed Nov 17 21:35:16 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Wed, 17 Nov 2010 23:35:16 +0200 Subject: [PATCH 2/4] target uart: fix preservation of LCR In-Reply-To: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> References: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290029718-15910-3-git-send-email-vamposdecampos@gmail.com> Store old_lcr only when switching to LCR == 0xBF. We don't want to clobber old_lcr when switching back, otherwise we can't restore the previous LCR value. Signed-off-by: Alex Badea --- src/target/firmware/calypso/uart.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/target/firmware/calypso/uart.c b/src/target/firmware/calypso/uart.c index a46fff9..4d7df09 100644 --- a/src/target/firmware/calypso/uart.c +++ b/src/target/firmware/calypso/uart.c @@ -127,12 +127,12 @@ static void uart_set_lcr7bit(int uart, int on) static uint8_t old_lcr; static void uart_set_lcr_bf(int uart, int on) { - old_lcr = readb(UART_REG(uart, LCR)); - - if (on) + if (on) { + old_lcr = readb(UART_REG(uart, LCR)); writeb(0xBF, UART_REG(uart, LCR)); - else + } else { writeb(old_lcr, UART_REG(uart, LCR)); + } } /* Enable or disable the TCR_TLR latch bit in MCR[6] */ -- 1.7.0.4 From vamposdecampos at gmail.com Wed Nov 17 21:35:17 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Wed, 17 Nov 2010 23:35:17 +0200 Subject: [PATCH 3/4] target uart: remove REG_OFFS() macro side-effect In-Reply-To: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> References: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290029718-15910-4-git-send-email-vamposdecampos@gmail.com> Don't assign to the variable given as argument. This prevents clobbering the local 'reg' variables in uart_reg_{read,write}(), which would in turn prevent the latch bits from being restored correctly. Signed-off-by: Alex Badea --- src/target/firmware/calypso/uart.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/target/firmware/calypso/uart.c b/src/target/firmware/calypso/uart.c index 4d7df09..394078d 100644 --- a/src/target/firmware/calypso/uart.c +++ b/src/target/firmware/calypso/uart.c @@ -43,7 +43,7 @@ #define LCR7BIT 0x80 #define LCRBFBIT 0x40 #define MCR6BIT 0x20 -#define REG_OFFS(m) ((m) &= ~(LCR7BIT|LCRBFBIT|MCR6BIT)) +#define REG_OFFS(m) ((m) & ~(LCR7BIT|LCRBFBIT|MCR6BIT)) /* read access LCR[7] = 0 */ enum uart_reg { RHR = 0, -- 1.7.0.4 From vamposdecampos at gmail.com Wed Nov 17 21:35:18 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Wed, 17 Nov 2010 23:35:18 +0200 Subject: [PATCH 4/4] toplevel Makefile: accept arguments for host ./configure calls In-Reply-To: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> References: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290029718-15910-5-git-send-email-vamposdecampos@gmail.com> Append $(HOST_CONFARGS) to ./configure scripts for 'host' applications. This allows e.g. cross-compiling on an x86 build system for an OpenMoko gta0x host, using an invocation such as: $ make HOST_CONFARGS="--host=arm-angstrom-linux-gnueabi" Signed-off-by: Alex Badea --- src/Makefile | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/Makefile b/src/Makefile index c8caff0..1567d2d 100644 --- a/src/Makefile +++ b/src/Makefile @@ -23,7 +23,7 @@ shared/libosmocore/configure: shared/libosmocore/configure.in cd shared/libosmocore && autoreconf -i shared/libosmocore/build-host/Makefile: shared/libosmocore/configure shared/libosmocore/build-host - cd shared/libosmocore/build-host && ../configure + cd shared/libosmocore/build-host && ../configure $(HOST_CONFARGS) shared/libosmocore/build-host/src/.libs/libosmocore.la: shared/libosmocore/build-host/Makefile cd shared/libosmocore/build-host && make @@ -51,7 +51,7 @@ host/osmocon/configure: host/osmocon/configure.ac cd host/osmocon && autoreconf -i host/osmocon/Makefile: host/osmocon/configure - cd host/osmocon && $(OSMOCORE_CONFIGURE_ENV) ./configure + cd host/osmocon && $(OSMOCORE_CONFIGURE_ENV) ./configure $(HOST_CONFARGS) host/osmocon/osmocon: host/osmocon/Makefile libosmocore-host make -C host/osmocon @@ -64,7 +64,7 @@ host/gsmmap/configure: host/gsmmap/configure.ac cd host/gsmmap && autoreconf -i host/gsmmap/Makefile: host/gsmmap/configure - cd host/gsmmap && $(OSMOCORE_CONFIGURE_ENV) ./configure + cd host/gsmmap && $(OSMOCORE_CONFIGURE_ENV) ./configure $(HOST_CONFARGS) host/gsmmap/gsmmap: host/gsmmap/Makefile libosmocore-host make -C host/gsmmap @@ -77,7 +77,7 @@ host/layer23/configure: host/layer23/configure.ac cd host/layer23 && autoreconf -i host/layer23/Makefile: host/layer23/configure - cd host/layer23 && $(OSMOCORE_CONFIGURE_ENV) ./configure + cd host/layer23 && $(OSMOCORE_CONFIGURE_ENV) ./configure $(HOST_CONFARGS) host/layer23/layer23: host/layer23/Makefile libosmocore-host make -C host/layer23 -- 1.7.0.4 From laforge at gnumonks.org Thu Nov 18 06:37:47 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Nov 2010 07:37:47 +0100 Subject: [PATCH 0/4] Fixes for gta0x targets In-Reply-To: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> References: <1290029718-15910-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <20101118063747.GB17373@prithivi.gnumonks.org> Hi Alex! Thanks a lot for your bugfixes and updates. Your work on the Openmoko phones is definitely appreciated. I've applied all patches to the repo. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From hrnlacerda at gmail.com Thu Nov 18 18:59:42 2010 From: hrnlacerda at gmail.com (Hernani) Date: Thu, 18 Nov 2010 16:59:42 -0200 Subject: Its posible that OsmocomBB work as a USRP? Message-ID: Ok, first of all congratulation for this project... Ok, I understood that it wouldn?t work as USRP. But would it allow you to tune (or listen - sory don?t know the tecnical term in english) an especific ARFCN and time slot ? Hernani > Hi Harald > > Thanks for clarifying this confusion. I bought a motorola C123 on ebay > with RS232 data cable. When I arrive I'll try this fantastic software. > Thank you very much for your work, this world needs more people like > you > > On Sat, 6 Nov 2010 08:32:31 +0100, Harald Welte > > wrote: >>* Hi Oscar, *>>* *>*> On Sat, Nov 06, 2010 at 03:02:37AM +0100, Oscar Soriano Riera wrote: *>>* *>>*> Its posible use *>>*> OsmocomBB on C123 for do task as a USRP ? or similar scanner ? *>>* *>*> No, I think you have some conceptual misunderstanding about radio *>*> technology in general. *>>* *>*> In your subject you ask if OsmocomBB can work as USRP: *>*> This is wrong, as OsmocomBB is a protocol stack and radio driver, and *>*> the USRP *>*> is hardware. How can some software work as hardware? *>>* *>*> In the body of your mail you ask if the C123 can act as USRP: *>*> No. The USRP is a wide-band software defined radio, and the *>*> Calypso/Iota/Rita *>*> design implements a more traditional narrow-band zero-if transceiver *>*> with a DSP *>*> in the baseband. *>>* *>*> Nevertheless, you can use both hardware design to receive and *>*> transmit GSM *>*> signals. But this is very far from what you ask by "one device *>*> working like *>*> the other" * -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.grela at gmail.com Thu Nov 18 21:11:00 2010 From: maciej.grela at gmail.com (Maciej Grela) Date: Thu, 18 Nov 2010 22:10:00 +0059 Subject: Its posible that OsmocomBB work as a USRP? In-Reply-To: References: Message-ID: 2010/11/18 Hernani : > Ok, first of all congratulation for this project... > > Ok, I understood that it wouldn?t work as USRP. > But would it allow you to tune (or listen - sory don?t know the tecnical > term in english) an especific ARFCN and time slot ? > Yes, you can set the frequency in the downlink range (the ARFCN) and then synchronize your timing generator to the FB (Frequency correction burst) which is sent in every frame in timeslot 0. After that you can receive bursts sent in other timeslots. Br, Maciej Grela From laforge at gnumonks.org Thu Nov 18 22:51:51 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Nov 2010 23:51:51 +0100 Subject: Announcing Osmocom SIMtrace Message-ID: <20101118225151.GL17373@prithivi.gnumonks.org> Hi all! After what has become much more time than originally anticipated, I'm happy to announce the first developer version of Osmocom SIMtrace: http://bb.osmocom.org/trac/wiki/SIMtrace (project page) git://git.osmocom.org/simtrace.git (host software + wireshark) git://git.gnumonks.org/openpcd.git (firmware) You can use it to passively sniff the smart card interface between SIM and phone. It consists of some firmware for an AT91SAM7S USB-attached microcontroller, together with a host PC program that receives the APDUs from USB. As none of my projects is complete without wireshark integration, SIMtrace abuses the GSMTAP format to feed messages into wireshark. A simplistic wireshark dissector for the GSM TS 11.11 APDUs is included, and it is expected to become much more complete in the fuutre (USIM support, parsing of file contents, etc.) What can you use it for? * Determine what is really going on between phone and sim * Debugging of SIM Application Toolkit (SAT) programs Why is it better than existing hardware like Season or the RebelSIM Scanner? * We do proper auto-bauding and support PPS, i.e. you can automatically see all communication on any SIM card interface * We support all clock rates / dividers as per the ISO 7816-3 spec Future plans: * In addition to passive tracing, implement SIM-card side interface in the hardware and have SIM/USIM simulator as host PC software. * Build custom board for it, with 1.8V SIM support 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 squalyl at gmail.com Thu Nov 18 23:32:22 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Fri, 19 Nov 2010 00:32:22 +0100 Subject: Announcing Osmocom SIMtrace In-Reply-To: <20101118225151.GL17373@prithivi.gnumonks.org> References: <20101118225151.GL17373@prithivi.gnumonks.org> Message-ID: Wow this is a very cool project. Congrats! Sebastien On Thu, Nov 18, 2010 at 11:51 PM, Harald Welte wrote: > Hi all! > > After what has become much more time than originally anticipated, I'm happy > to announce the first developer version of Osmocom SIMtrace: > > http://bb.osmocom.org/trac/wiki/SIMtrace (project page) > git://git.osmocom.org/simtrace.git (host software + wireshark) > git://git.gnumonks.org/openpcd.git (firmware) > > You can use it to passively sniff the smart card interface between SIM and > phone. It consists of some firmware for an AT91SAM7S USB-attached > microcontroller, together with a host PC program that receives the APDUs > from USB. > > As none of my projects is complete without wireshark integration, > SIMtrace abuses the GSMTAP format to feed messages into wireshark. A > simplistic wireshark dissector for the GSM TS 11.11 APDUs is included, > and it is expected to become much more complete in the fuutre (USIM > support, > parsing of file contents, etc.) > > What can you use it for? > * Determine what is really going on between phone and sim > * Debugging of SIM Application Toolkit (SAT) programs > > Why is it better than existing hardware like Season or the RebelSIM > Scanner? > * We do proper auto-bauding and support PPS, i.e. you can automatically > see all communication on any SIM card interface > * We support all clock rates / dividers as per the ISO 7816-3 spec > > Future plans: > * In addition to passive tracing, implement SIM-card side interface > in the hardware and have SIM/USIM simulator as host PC software. > * Build custom board for it, with 1.8V SIM support > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Fri Nov 19 10:15:55 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Fri, 19 Nov 2010 11:15:55 +0100 Subject: AW: Announcing Osmocom SIMtrace Message-ID: > As none of my projects is complete without wireshark integration, > SIMtrace abuses the GSMTAP format to feed messages into wireshark. A > simplistic wireshark dissector for the GSM TS 11.11 APDUs is included, > and it is expected to become much more complete in the fuutre (USIM support, > parsing of file contents, etc.) hi laforge, cool project! i think it can be usefull to debugging the sim client/reader of osmocom-bb. as DATA_IND/DATA_REQ is already tapped at layer23/src/common/l1ctl.c, it would be cool if SIM_IND/SIM_REQ will be tapped for wireshark too. regards, andreas From laforge at gnumonks.org Fri Nov 19 15:54:40 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 19 Nov 2010 16:54:40 +0100 Subject: Announcing Osmocom SIMtrace In-Reply-To: References: Message-ID: interesting idea, andreas. i think it should be pretty easy: simply generate GSMTAP_TYpE_SIM messages, the new type is defined in gsmtap.h of current libosmocore.git -- Sent from a mobile device, excuse my short response From squalyl at gmail.com Fri Nov 19 16:04:36 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Fri, 19 Nov 2010 17:04:36 +0100 Subject: Announcing Osmocom SIMtrace In-Reply-To: References: Message-ID: Hello, I'm wondering about the hardware. here, we have an open pcd board. Can't we use some free gpio lines on this device, reprogram the cpu, and get it going? We have some correct card connectors, too, so if that's just a matter of soldering some wires on the openpcd board, I'd be happy to test that ! Regards Sebastien On Fri, Nov 19, 2010 at 4:54 PM, Harald Welte wrote: > interesting idea, andreas. > > i think it should be pretty easy: simply generate GSMTAP_TYpE_SIM messages, > the new type is defined in gsmtap.h of current libosmocore.git > -- > Sent from a mobile device, excuse my short response > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Nov 19 16:24:27 2010 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 19 Nov 2010 17:24:27 +0100 Subject: Announcing Osmocom SIMtrace In-Reply-To: References: Message-ID: <6a2c06d4-8cb1-435a-b497-0a0289bf028e@email.android.com> you would have to check the schematics of openpcd, but i think it is not easily possible. however, devices like the olimex sam7-h64 are inexpensive and peovida all io lines. "S?bastien Lorquet" wrote: >Hello, > >I'm wondering about the hardware. > >here, we have an open pcd board. > >Can't we use some free gpio lines on this device, reprogram the cpu, >and get >it going? > >We have some correct card connectors, too, so if that's just a matter >of >soldering some wires on the openpcd board, I'd be happy to test that ! > >Regards >Sebastien > >On Fri, Nov 19, 2010 at 4:54 PM, Harald Welte >wrote: > >> interesting idea, andreas. >> >> i think it should be pretty easy: simply generate GSMTAP_TYpE_SIM >messages, >> the new type is defined in gsmtap.h of current libosmocore.git >> -- >> Sent from a mobile device, excuse my short response >> >> -- Sent from a mobile device, excuse my short response From drasko.draskovic at gmail.com Fri Nov 19 16:34:33 2010 From: drasko.draskovic at gmail.com (Drasko DRASKOVIC) Date: Fri, 19 Nov 2010 17:34:33 +0100 Subject: Announcing Osmocom SIMtrace In-Reply-To: <6a2c06d4-8cb1-435a-b497-0a0289bf028e@email.android.com> References: <6a2c06d4-8cb1-435a-b497-0a0289bf028e@email.android.com> Message-ID: On Fri, Nov 19, 2010 at 5:24 PM, Harald Welte wrote: > you would have to check the schematics of openpcd, but i think it is not easily possible. > > however, devices like the olimex sam7-h64 are inexpensive and peovida all io lines. Would be there a difference in FW to be used for this board (as I understand current implementation is SAM7-P64) ? BR, Drasko From lists at infosecurity.ch Fri Nov 19 10:49:29 2010 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Fri, 19 Nov 2010 11:49:29 +0100 Subject: Announcing Osmocom SIMtrace In-Reply-To: <20101118225151.GL17373@prithivi.gnumonks.org> References: <20101118225151.GL17373@prithivi.gnumonks.org> Message-ID: <4CE65639.1000304@infosecurity.ch> Any progress, any new step announced in this new opensource mobile telephony environment i feel the world more free and just immagine the potentiality of those technologies! Great, my compliments, i am very excited to see all those progress! The lobbyist TLC industry will learn a very strong lesson from this mobile opensource revolution! -naif On 18/11/10 23.51, Harald Welte wrote: > After what has become much more time than originally anticipated, I'm happy > to announce the first developer version of Osmocom SIMtrace: From ml at mail.tsaitgaist.info Sun Nov 21 14:14:34 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Sun, 21 Nov 2010 15:14:34 +0100 Subject: simtrac hw Message-ID: <4CE9294A.8060205@mail.tsaitgaist.info> Hi, Because I'm also deceived by the rebelSIM, I was programming a sim sniffer using an atmega, by detecting the clock freq. manualy. Until Harald announced his SIMtrac. His solution is way easier, and more reliable. This is why I've now done a hw design for it. I don't know if it's the right mailing list, but it seemed to be the best. I'm not a electronic expert, I just follow datasheets and examples. I used the openPCD schema to do this one. There is : - the AT91SAM7SXXX - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual size, as on the rebelSIM - 1 SC port (IN) to connect the SIM for the phone (I would use the ones from rebelSIM) - 1 SC port (OUT) to be able to use the signal using external HW - the sam-ba port to be able to flash it here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe please tell me if there is something wrong, or needs some improvement. I will design the PCB shortly. thanks, tsaitgaist From ml at mail.tsaitgaist.info Sun Nov 21 15:36:33 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Sun, 21 Nov 2010 16:36:33 +0100 Subject: simtrac hw In-Reply-To: <4CE9294A.8060205@mail.tsaitgaist.info> References: <4CE9294A.8060205@mail.tsaitgaist.info> Message-ID: <4CE93C81.2080905@mail.tsaitgaist.info> I removed the PLL part and used only 6 out of 8 contacts from the SC https://file.tsaitgaist.info/www/?a=d&i=LqeRpJ14RJ On 21.11.2010 15:14, ml at mail.tsaitgaist.info wrote: > Hi, > > Because I'm also deceived by the rebelSIM, I was programming a sim > sniffer using an atmega, by detecting the clock freq. manualy. Until > Harald announced his SIMtrac. > His solution is way easier, and more reliable. This is why I've now done > a hw design for it. > I don't know if it's the right mailing list, but it seemed to be the best. > I'm not a electronic expert, I just follow datasheets and examples. I > used the openPCD schema to do this one. > There is : > - the AT91SAM7SXXX > - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual > size, as on the rebelSIM > - 1 SC port (IN) to connect the SIM for the phone (I would use the ones > from rebelSIM) > - 1 SC port (OUT) to be able to use the signal using external HW > - the sam-ba port to be able to flash it > > here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe > please tell me if there is something wrong, or needs some improvement. I > will design the PCB shortly. > > thanks, > tsaitgaist > > From vogelchr at vogel.cx Sun Nov 21 17:19:38 2010 From: vogelchr at vogel.cx (Christian Vogel) Date: Sun, 21 Nov 2010 18:19:38 +0100 Subject: simtrac hw In-Reply-To: <4CE93C81.2080905@mail.tsaitgaist.info> References: <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> Message-ID: Hi Tsaitgaist, > I removed the PLL part and used only 6 out of 8 contacts from the SC > https://file.tsaitgaist.info/www/?a=d&i=LqeRpJ14RJ I have no experience with ARM microcontrollers, but according to the datasheet VDDPLL powers the oscillator, you should not leave it unconnected. VDDCORE powers the internal logic and is specified as 1.65V to 1.95V. Your "PWR_FLAG" signal connects the output of the 1.8V regulator with +5V USB. This will most likely fry the chip as soon as power is applied. Have a look at ?5.4 of the Atnek AT81SAN7S512 datasheet dated 2010-08-30. Please don't order PCBs until one of the more ARM savy guys has had a thorough look over your design. Chris From laforge at gnumonks.org Sun Nov 21 19:53:49 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Nov 2010 20:53:49 +0100 Subject: simtrac hw In-Reply-To: <4CE9294A.8060205@mail.tsaitgaist.info> References: <4CE9294A.8060205@mail.tsaitgaist.info> Message-ID: <20101121195349.GE26868@prithivi.gnumonks.org> Hi! On Sun, Nov 21, 2010 at 03:14:34PM +0100, ml at mail.tsaitgaist.info wrote: > His solution is way easier, and more reliable. This is why I've now done > a hw design for it. thanks a lot. > I don't know if it's the right mailing list, but it seemed to be the best. well, I think it is low-traffic and we might just use this mailing list for the time being. > - the AT91SAM7SXXX > - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual > size, as on the rebelSIM > - 1 SC port (IN) to connect the SIM for the phone (I would use the ones > from rebelSIM) > - 1 SC port (OUT) to be able to use the signal using external HW > - the sam-ba port to be able to flash it I think we should consider the following use cases: 1) passive sniffer this is what simtrace is doing right now and what your hardware is also prepared for. 2) card simulation this is possible with the same circuit. Simply connect it _only_ to the phone and not to a smart card at all. The wiring will be the same, but the USART will be used in Rx and Tx mode. Only software/firmware changes required. 3) man in the middle in this case, we want to connect as master (reader) to the SIM card, and as slave (card-side interface) to the phone. In order to make we run USART0 as clock-slave (like in case 1 + 2 above), but we also connect a sim card socket to USART1, which we can then run in clock-master mode, i.e. like any 'regular' SAM7 based smart card reader. The easiest solution would be to add yet another sim card socket which is connected to USART1 (TXD1/SCK1). But then we have 3-4 sim card sockets in one device, which I think is clumsy. It may be possible to add some jumpers or dip switches that change the behavior, i.e. "one setting for sniffer + card simluation, another setting for man-in-the-middle" > here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe > please tell me if there is something wrong, or needs some improvement. I > will design the PCB shortly. please take time for detailed review before doign any pcbs... thinking more before prototyping will save time and money. Another request: Pleaes make the DRxD / DTxD (Debug UART) pins available on the board, preferrably on the same type of header that we use on the OpenPCD. It will not add any cost to the design, but enable you to print debug messages to a serial port, which is very useful during firmware development. Also, the JTAG lines should be routed to a standard 20-pin ARM-JTAG connector. Both the Debug-UART and the JTAG headers can not be placed/soldered for normal boards, but people who want to do development will likely find both of them very useful. 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 ml at mail.tsaitgaist.info Mon Nov 22 00:39:07 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Mon, 22 Nov 2010 01:39:07 +0100 Subject: simtrac hw In-Reply-To: <20101121195349.GE26868@prithivi.gnumonks.org> References: <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195349.GE26868@prithivi.gnumonks.org> Message-ID: <4CE9BBAB.7020005@mail.tsaitgaist.info> thanks for the feedback and recommendations I added the JTAG and debug connectors. I hope it will not use more then 2 layers in the end, so normal people can build the pcb at home. I could not login/register on the osmocom trac wiki to put the files there. Here the current version : https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps I now use this direct link (it could take some time until the DN is spread over all DNS) I did not yet add the MiM solution, because there are still have some open aspects : MiM : - should it use the clock provider by the reader - or should we provided our own clock (3.8432MHz/9600bps for simplicity) using the reader clock would provide better timing but cold be harder to do (I don't know well this chip yet) emulation : - how to know what the user wants (sniff vs emulation) if the mode is combined with the sniffer ? - the user has to tell the program - or by detecting the presence of a card (provided by the id-1 socket, but some tricks have to be used for the id-000 socket) - or by having a switch with 3 modes (sniff,emulation,MiM) (my favorite solution) I did a very simple PCB just to test the sniffer. I will take time to get a good design for the promising SIMtrac. kevin On 21.11.2010 20:53, Harald Welte wrote: > Hi! > > On Sun, Nov 21, 2010 at 03:14:34PM +0100, ml at mail.tsaitgaist.info wrote: > >> His solution is way easier, and more reliable. This is why I've now done >> a hw design for it. > > thanks a lot. > >> I don't know if it's the right mailing list, but it seemed to be the best. > > well, I think it is low-traffic and we might just use this mailing list > for the time being. > >> - the AT91SAM7SXXX >> - 2 SC sockets (ID-1 and ID-000) for the SIM in credit card and usual >> size, as on the rebelSIM >> - 1 SC port (IN) to connect the SIM for the phone (I would use the ones >> from rebelSIM) >> - 1 SC port (OUT) to be able to use the signal using external HW >> - the sam-ba port to be able to flash it > > I think we should consider the following use cases: > > 1) passive sniffer > > this is what simtrace is doing right now and what your hardware is also > prepared for. > > 2) card simulation > > this is possible with the same circuit. Simply connect it _only_ to > the phone and not to a smart card at all. The wiring will be the same, > but the USART will be used in Rx and Tx mode. Only software/firmware > changes required. > > 3) man in the middle > > in this case, we want to connect as master (reader) to the SIM card, > and as slave (card-side interface) to the phone. > > In order to make we run USART0 as clock-slave (like in case 1 + 2 above), > but we also connect a sim card socket to USART1, which we can then run > in clock-master mode, i.e. like any 'regular' SAM7 based smart card reader. > > The easiest solution would be to add yet another sim card socket which is > connected to USART1 (TXD1/SCK1). But then we have 3-4 sim card sockets > in one device, which I think is clumsy. > > It may be possible to add some jumpers or dip switches that change the > behavior, i.e. "one setting for sniffer + card simluation, another setting for > man-in-the-middle" > >> here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe >> please tell me if there is something wrong, or needs some improvement. I >> will design the PCB shortly. > > please take time for detailed review before doign any pcbs... thinking more > before prototyping will save time and money. > > Another request: Pleaes make the DRxD / DTxD (Debug UART) pins available on the > board, preferrably on the same type of header that we use on the OpenPCD. It > will not add any cost to the design, but enable you to print debug messages to > a serial port, which is very useful during firmware development. > > Also, the JTAG lines should be routed to a standard 20-pin ARM-JTAG connector. > > Both the Debug-UART and the JTAG headers can not be placed/soldered for normal > boards, but people who want to do development will likely find both of them > very useful. > > Regards, > Harald From laforge at gnumonks.org Mon Nov 22 00:46:23 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Nov 2010 01:46:23 +0100 Subject: simtrac hw In-Reply-To: <4CE9BBAB.7020005@mail.tsaitgaist.info> References: <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195349.GE26868@prithivi.gnumonks.org> <4CE9BBAB.7020005@mail.tsaitgaist.info> Message-ID: <20101122004623.GP26868@prithivi.gnumonks.org> Hi! On Mon, Nov 22, 2010 at 01:39:07AM +0100, ml at mail.tsaitgaist.info wrote: > I did not yet add the MiM solution, because there are still have some > open aspects : > MiM : > - should it use the clock provider by the reader No, we don't want this. Real phones do things like CLOCKSTOP and we might not want to stop our actual SIM card during that time. > - or should we provided our own clock (3.8432MHz/9600bps for simplicity) > using the reader clock would provide better timing but cold be harder to > do (I don't know well this chip yet) The AT91SAM7 can provide the clock on the SCLK0/SCLK1 pin of the USART, there is no need for any external circuitry. > emulation : > - how to know what the user wants (sniff vs emulation) if the mode is > combined with the sniffer ? simply send a configuration message via USB from the simtrace program. > - the user has to tell the program btw: please don't quote the full message at the bottom of your mail, thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ml at mail.tsaitgaist.info Mon Nov 22 11:23:37 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Mon, 22 Nov 2010 12:23:37 +0100 Subject: simtrac hw In-Reply-To: <20101122004623.GP26868@prithivi.gnumonks.org> References: <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195349.GE26868@prithivi.gnumonks.org> <4CE9BBAB.7020005@mail.tsaitgaist.info> <20101122004623.GP26868@prithivi.gnumonks.org> Message-ID: <4CEA52B9.9050707@mail.tsaitgaist.info> > > simply send a configuration message via USB from the simtrace program. > How about having the reader on port 0 and the sc on port 1 Then the 3 modes would be software controlled The sniffer part could be done by the MiM by just forwarding the messages. The freq could be regenerated, or forwarded using a software switch. It would not be a real sniffer, but simpler to design and implement. reset, clockstop, freq. changing, and proactive SIM could also be done by the chip. is there another SC feature that could be problematic ? apart using contact 4/8 which we ignore, and 20MHz freq. which I've never seen yet. Kevin From keytwho at hotmail.com Mon Nov 22 11:35:46 2010 From: keytwho at hotmail.com (None None) Date: Mon, 22 Nov 2010 11:35:46 +0000 Subject: simtrac hw In-Reply-To: <4CEA52B9.9050707@mail.tsaitgaist.info> References: <4CE9294A.8060205@mail.tsaitgaist.info>, <20101121195349.GE26868@prithivi.gnumonks.org>, <4CE9BBAB.7020005@mail.tsaitgaist.info>, <20101122004623.GP26868@prithivi.gnumonks.org>, <4CEA52B9.9050707@mail.tsaitgaist.info> Message-ID: you have to take in consideration the "retransmission" also. the other thiing is that all cards are not 3.3v some are 1.8. that could be read in ATR. so if you want it to be compatible with any phone, you need on one side to give an ATR to the phone that tells it it could work with 3.3v and be able to read the actual sim with 1.8v... I've already done that kind of device a while ago with a FT2232 and scenix microcontroller. (http://88.191.12.21/fakesim.jpg) and I can mim, sniff, read... So i'm familiar with it. -- k2 > Date: Mon, 22 Nov 2010 12:23:37 +0100 > From: ml at mail.tsaitgaist.info > To: laforge at gnumonks.org > Subject: Re: simtrac hw > CC: baseband-devel at lists.osmocom.org > > > > > > simply send a configuration message via USB from the simtrace program. > > > How about having the reader on port 0 and the sc on port 1 > Then the 3 modes would be software controlled > The sniffer part could be done by the MiM by just forwarding the messages. > The freq could be regenerated, or forwarded using a software switch. > It would not be a real sniffer, but simpler to design and implement. > reset, clockstop, freq. changing, and proactive SIM could also be done > by the chip. is there another SC feature that could be problematic ? > apart using contact 4/8 which we ignore, and 20MHz freq. which I've > never seen yet. > > Kevin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Nov 22 12:13:22 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Nov 2010 13:13:22 +0100 Subject: simtrac hw In-Reply-To: <4CEA52B9.9050707@mail.tsaitgaist.info> References: <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195349.GE26868@prithivi.gnumonks.org> <4CE9BBAB.7020005@mail.tsaitgaist.info> <20101122004623.GP26868@prithivi.gnumonks.org> <4CEA52B9.9050707@mail.tsaitgaist.info> Message-ID: <20101122121322.GB26868@prithivi.gnumonks.org> On Mon, Nov 22, 2010 at 12:23:37PM +0100, ml at mail.tsaitgaist.info wrote: > > > > > simply send a configuration message via USB from the simtrace program. > > > How about having the reader on port 0 and the sc on port 1 > Then the 3 modes would be software controlled > The sniffer part could be done by the MiM by just forwarding the messages. A sniffer by definition is passive. Running MITM to sniff is modifying the behavior of the timing. I intentionally didn't want that. -- - 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 Sun Nov 21 19:56:44 2010 From: peter at stuge.se (Peter Stuge) Date: Sun, 21 Nov 2010 20:56:44 +0100 Subject: simtrac hw In-Reply-To: <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> References: <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> Message-ID: <20101121195644.10439.qmail@stuge.se> ml at mail.tsaitgaist.info wrote: > a hw design Cool! > - the AT91SAM7SXXX I'd use a more modern chip that is simpler to work with; something like NXP LPC1343 Cortex-M3 with USB or TI Stellaris LM36432 with 10/100 Ethernet. They're both single supply 3.3V chips. The NXP only needs five-size passive support components. > here the schema : https://file.tsaitgaist.info/www/?a=d&i=CWn6xIaCVe I get nonsense messages visiting that page. :\ "needs input" something or other. Maybe you can attach them to the wiki? Christian Vogel wrote: > according to the datasheet VDDPLL powers the oscillator, you should > not leave it unconnected. VDDCORE powers the internal logic and > is specified as 1.65V to 1.95V. There might be an internal voltage regulator also for this chip, but I would really go with cm3 for a new design. //Peter From laforge at gnumonks.org Sun Nov 21 22:29:10 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Nov 2010 23:29:10 +0100 Subject: simtrac hw In-Reply-To: <20101121195644.10439.qmail@stuge.se> References: <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195644.10439.qmail@stuge.se> Message-ID: <20101121222910.GJ26868@prithivi.gnumonks.org> Hi Peter and others, On Sun, Nov 21, 2010 at 08:56:44PM +0100, Peter Stuge wrote: > > - the AT91SAM7SXXX > > I'd use a more modern chip that is simpler to work with; something > like NXP LPC1343 Cortex-M3 with USB or TI Stellaris LM36432 with > 10/100 Ethernet. They're both single supply 3.3V chips. The NXP only > needs five-size passive support components. no, no, no, no ;) There is working firmware (drivers, T=0 sniffing, ...) for the AT91SAM7 now, I put quite a bit of effort into making this work. Furthermore, the AT91SAM7 USART has the unique property that you can use it in T=0 mode but still operate as clock slave, i.e. run as sniffer or card mode, not behaving like a card reader. We really do not need any external logic, simply connect the SIM card to the right pins of the SAM7, load the (gpl licensed, of course) firmware that I wrote and run the equally free software 'simtrace' host program + wireshark. Porting this to a different microcontroller will again require significant development on the software side, which I don't think is what we need... -- - 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 Mon Nov 22 02:49:09 2010 From: peter at stuge.se (Peter Stuge) Date: Mon, 22 Nov 2010 03:49:09 +0100 Subject: simtrac hw In-Reply-To: <4CE9BBAB.7020005@mail.tsaitgaist.info> <20101121222910.GJ26868@prithivi.gnumonks.org> References: <20101121195349.GE26868@prithivi.gnumonks.org> <4CE9BBAB.7020005@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195644.10439.qmail@stuge.se> <20101121222910.GJ26868@prithivi.gnumonks.org> Message-ID: <20101122024909.5149.qmail@stuge.se> Harald Welte wrote: > > > - the AT91SAM7SXXX > > > > I'd use a more modern chip > > no, no, no, no ;) After seeing the schematic I tend to agree. > There is working firmware (drivers, T=0 sniffing, ...) for the > AT91SAM7 now, I put quite a bit of effort into making this work. > Furthermore, the AT91SAM7 USART has the unique property that you > can use it in T=0 mode but still operate as clock slave, i.e. run > as sniffer or card mode, not behaving like a card reader. I think every sync serial peripheral that I've seen can operate in slave mode like that, and I agree that it's important. > We really do not need any external logic, simply connect the SIM > card to the right pins of the SAM7, load the (gpl licensed, of > course) firmware that I wrote and run the equally free software > 'simtrace' host program + wireshark. > > Porting this to a different microcontroller will again require > significant development on the software side, which I don't think > is what we need... I disagree that significant effort would be required. It should be straightforward to use another controller, but since the schematic wouldn't really be much simpler there may not be much point to it. But one thing that I think matters is that it's very easy and cheap to get hold of a really simple (e.g.) LPC1343 development board in neat size that people could use instead of having to build their own hardware. I think that wall clock time would be about same for porting the software and producing a board. ml at mail.tsaitgaist.info wrote: > I could not login/register on the osmocom trac wiki to put the files > there. Hopefully someone will fix that. > Here the current version : > https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps Thanks for uploading it! > I added the JTAG and debug connectors. I hope it will not use more > then 2 layers in the end, so normal people can build the pcb at home. Since the crystal is around 18 MHz this might even work OK as a single layer board, maybe with a solid ground plane on the back for the ambitious. > - the user has to tell the program > - or by detecting the presence of a card (provided by the id-1 > socket, but some tricks have to be used for the id-000 socket) > - or by having a switch with 3 modes (sniff,emulation,MiM) (my > favorite solution) It would be really nice to not have to deal with switches, and just let the host software tell the hardware which mode to use. A USB device control request could do the trick easily. //Peter From sweisman at pobox.com Mon Nov 22 07:33:40 2010 From: sweisman at pobox.com (Scott Weisman) Date: Mon, 22 Nov 2010 09:33:40 +0200 Subject: simtrac hw In-Reply-To: <20101122024909.5149.qmail@stuge.se> 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> Message-ID: I'm no expert on this (I think that's pretty obvious), but wouldn't it just be easier to buy one of the supported Osmocom phones, which already has all the hardware needed and a library of code, and make the code with that? Scott On Mon, Nov 22, 2010 at 4:49 AM, Peter Stuge wrote: > Harald Welte wrote: > > > > - the AT91SAM7SXXX > > > > > > I'd use a more modern chip > > > > no, no, no, no ;) > > After seeing the schematic I tend to agree. > > > > There is working firmware (drivers, T=0 sniffing, ...) for the > > AT91SAM7 now, I put quite a bit of effort into making this work. > > Furthermore, the AT91SAM7 USART has the unique property that you > > can use it in T=0 mode but still operate as clock slave, i.e. run > > as sniffer or card mode, not behaving like a card reader. > > I think every sync serial peripheral that I've seen can operate in > slave mode like that, and I agree that it's important. > > > > We really do not need any external logic, simply connect the SIM > > card to the right pins of the SAM7, load the (gpl licensed, of > > course) firmware that I wrote and run the equally free software > > 'simtrace' host program + wireshark. > > > > Porting this to a different microcontroller will again require > > significant development on the software side, which I don't think > > is what we need... > > I disagree that significant effort would be required. It should be > straightforward to use another controller, but since the schematic > wouldn't really be much simpler there may not be much point to it. > > But one thing that I think matters is that it's very easy and cheap > to get hold of a really simple (e.g.) LPC1343 development board in > neat size that people could use instead of having to build their own > hardware. I think that wall clock time would be about same for > porting the software and producing a board. > > > ml at mail.tsaitgaist.info wrote: > > I could not login/register on the osmocom trac wiki to put the files > > there. > > Hopefully someone will fix that. > > > > Here the current version : > > https://gsm.tsaitgaist.info/SIMtrac/v0.2/trac.ps > > Thanks for uploading it! > > > > I added the JTAG and debug connectors. I hope it will not use more > > then 2 layers in the end, so normal people can build the pcb at home. > > Since the crystal is around 18 MHz this might even work OK as a > single layer board, maybe with a solid ground plane on the back for > the ambitious. > > > > - the user has to tell the program > > - or by detecting the presence of a card (provided by the id-1 > > socket, but some tricks have to be used for the id-000 socket) > > - or by having a switch with 3 modes (sniff,emulation,MiM) (my > > favorite solution) > > It would be really nice to not have to deal with switches, and just > let the host software tell the hardware which mode to use. A USB > device control request could do the trick easily. > > > //Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Nov 22 11:29:11 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Nov 2010 12:29:11 +0100 Subject: simtrac hw In-Reply-To: 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> Message-ID: <20101122112911.GY26868@prithivi.gnumonks.org> Hi Scott, On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote: > I'm no expert on this (I think that's pretty obvious), but wouldn't it just > be easier to buy one of the supported Osmocom phones, which already has all > the hardware needed and a library of code, and make the code with that? it will simply not work. the phone only implements the READER side interface, but not the CARD site interface. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sweisman at pobox.com Mon Nov 22 12:21:31 2010 From: sweisman at pobox.com (Scott Weisman) Date: Mon, 22 Nov 2010 14:21:31 +0200 Subject: simtrac hw In-Reply-To: <20101122112911.GY26868@prithivi.gnumonks.org> 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> Message-ID: Thanks Harald. Is there a doc somewhere to explain what that means? I'm confused, because to me "reader" and "sniffer" have sufficiently overlapping meanings. What does a SIM sniffer sniff? What benefit is there to support a MITM use case? Scott On Mon, Nov 22, 2010 at 1:29 PM, Harald Welte wrote: > Hi Scott, > > On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote: > > > I'm no expert on this (I think that's pretty obvious), but wouldn't it > just > > be easier to buy one of the supported Osmocom phones, which already has > all > > the hardware needed and a library of code, and make the code with that? > > it will simply not work. the phone only implements the READER side > interface, > but not the CARD site interface. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From squalyl at gmail.com Mon Nov 22 12:47:40 2010 From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=) Date: Mon, 22 Nov 2010 13:47:40 +0100 Subject: simtrac hw In-Reply-To: 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> Message-ID: MITM is useful to create a generic tool that is able to rewrite APDUs on-the-fly. Like a live apdu patcher. A sniffer only *listens* the sim<->reader lines, without writing anything. It's "passive" in the sense that all it does is listening. The timing is VERY important, a man in the middle will introduce latencies that can be *very* easily detected. It is essential that in a sniffer, all lines between the sim and the reader are directly, electrically connected, without any repeating hardware in the middle. > the other thing is that all cards are not 3.3v some are 1.8 In ALL situations, Vcc shall just be forwarded from the reader to the card. You can use an ADC line and a voltage divider to measure this line. This is important since a cold reset can be executed by the reader, and that will interrupt Vcc. And I see that the 3rd edition of ISO7816-3 now mandates that: "No card shall be damaged when the interface device applies a class not supported by the card". So the voltage is not important. My opinion is that in practice, all SIMs vendors, that will want their cards to work on the largest number of phones, will support all the 3 voltage classes (5,3.3,1.8V). If not, you cannot destroy a card by applying any of these 3 supply voltages. Sebastien On Mon, Nov 22, 2010 at 1:21 PM, Scott Weisman wrote: > Thanks Harald. Is there a doc somewhere to explain what that means? I'm > confused, because to me "reader" and "sniffer" have sufficiently overlapping > meanings. What does a SIM sniffer sniff? > > What benefit is there to support a MITM use case? > > Scott > > On Mon, Nov 22, 2010 at 1:29 PM, Harald Welte wrote: > >> Hi Scott, >> >> On Mon, Nov 22, 2010 at 09:33:40AM +0200, Scott Weisman wrote: >> >> > I'm no expert on this (I think that's pretty obvious), but wouldn't it >> just >> > be easier to buy one of the supported Osmocom phones, which already has >> all >> > the hardware needed and a library of code, and make the code with that? >> >> it will simply not work. the phone only implements the READER side >> interface, >> but not the CARD site interface. >> >> -- >> - Harald Welte >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at mail.tsaitgaist.info Mon Nov 22 14:24:55 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Mon, 22 Nov 2010 15:24:55 +0100 Subject: simtrac hw In-Reply-To: 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> Message-ID: <4CEA7D37.7000000@mail.tsaitgaist.info> On 22.11.2010 13:47, S?bastien Lorquet wrote: > MITM is useful to create a generic tool that is able to rewrite APDUs > on-the-fly. Like a live apdu patcher. In this direction, we could interrupt the I/O line between reader and SC after the interesting header has been detected, and send our custom response. Thus the MitM would replaces the responses instead of patching them. This could lead having different states between SC and reader (general issue with MitM). Having to possibility to separately control the SC and reader could enable use to put them in the right state with additional APDU. I did not mesure/test timings of SCs, so I can't tell it it's feasible, but with a fast processor (18MHz), may be ? With the interrupt solution (instead of patching and forwarding) the timing would modified only for the custom responses. This is good if the reader only does MitM detection on the average timing, but bad if it uses peaks as an alert. I don't know which is the most common (if there is) > So the voltage is not important. My opinion is that in practice, all > SIMs vendors, that will want their cards to work on the largest number > of phones, will support all the 3 voltage classes (5,3.3,1.8V). If not, > you cannot destroy a card by applying any of these 3 supply voltages. > To be able to be compatible with all 3 classes, we could use multiple level shifter. It would make the hw more complicated and expensive, but would be the right way (if it's worse doing it) From laforge at gnumonks.org Mon Nov 22 14:56:23 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Nov 2010 15:56:23 +0100 Subject: simtrac hw In-Reply-To: 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> Message-ID: <6fbd9ccd-1145-4403-927b-08fa0d2fdd62@email.android.com> thanls for your comments, and i'm happy to see we agree. regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort. i think we don't need to worry about 5V anymore. Last time I've seen a 5V simcard is 10 years ago. Also, AFAIR those baseband processors that i've seen all are <= 3.3v, even for things as ancient as the calypso. -- Sent from a mobile device, excuse my short response From kevredon at mail.tsaitgaist.info Wed Nov 24 08:17:02 2010 From: kevredon at mail.tsaitgaist.info (Kevin Redon) Date: Wed, 24 Nov 2010 09:17:02 +0100 Subject: simtrac hw In-Reply-To: <6fbd9ccd-1145-4403-927b-08fa0d2fdd62@email.android.com> 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> Message-ID: <4CECC9FE.4080705@mail.tsaitgaist.info> Also, we could add a SC reader mode, using the CCID USB profile. I linked the SC output to serial port 1 (to be able to control in and output separately) I added NPN transistors to be able to block I/O (for MitM) or completely separate the output from the input (for emulation,reader) > > regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort. 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 ml at mail.tsaitgaist.info Wed Nov 24 08:17:39 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Wed, 24 Nov 2010 09:17:39 +0100 Subject: simtrac hw In-Reply-To: <6fbd9ccd-1145-4403-927b-08fa0d2fdd62@email.android.com> 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> Message-ID: <4CECCA23.1080802@mail.tsaitgaist.info> Also, we could add a SC reader mode, using the CCID USB profile. I linked the SC output to serial port 1 (to be able to control in and output separately) I added NPN transistors to be able to block I/O (for MitM) or completely separate the output from the input (for emulation,reader) > > regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort. 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 ml at mail.tsaitgaist.info Thu Nov 25 11:11:06 2010 From: ml at mail.tsaitgaist.info (ml at mail.tsaitgaist.info) Date: Thu, 25 Nov 2010 12:11:06 +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: <4CEE444A.3070507@mail.tsaitgaist.info> I found a listing of possible SIM sockets : http://www.mlelectronic.com/sim-card-connectors/sim-information.asp The push-push solution seems to be the best one. It also has a card presence switch, like the credit card size (id-1) generally has. This could make the software more accurate (in the mode menu for example) It's just harder to find in shops. kevin On 24.11.2010 09:17, ml at mail.tsaitgaist.info wrote: > Also, we could add a SC reader mode, using the CCID USB profile. > > I linked the SC output to serial port 1 (to be able to control in and > output separately) > I added NPN transistors to be able to block I/O (for MitM) or completely > separate the output from the input (for emulation,reader) > >> >> regaeding voltage: the sam7 can operate its io pins at either 1.8 or 3.3V. So it would be nice to somehow exploit that ability... though making this automatic is probably too much effort. > > 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 laforge at gnumonks.org Mon Nov 22 14:50:20 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Nov 2010 15:50:20 +0100 Subject: simtrac hw In-Reply-To: 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> Message-ID: <9c2bd5be-3a52-4ae0-b7bf-ccff7f09e4e6@email.android.com> this is quite basic smartcard terminology. a smart card reader is the master, it drives the clock, reset lines and issues commands to rhe card. the card is a slave to the clock and reset lines. on a protocol level, it only responds to commands by the reader. see iso 7816-3 for details on this. asynchronous t=0 is the predominant protocol used in sim cards. a sniffer just passively listens to the communication between card and reader. -- Sent from a mobile device, excuse my short response From laforge at gnumonks.org Mon Nov 22 08:51:30 2010 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Nov 2010 09:51:30 +0100 Subject: simtrac hw In-Reply-To: <20101122024909.5149.qmail@stuge.se> References: <4CE9BBAB.7020005@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <4CE93C81.2080905@mail.tsaitgaist.info> <4CE9294A.8060205@mail.tsaitgaist.info> <20101121195644.10439.qmail@stuge.se> <20101121222910.GJ26868@prithivi.gnumonks.org> <20101122024909.5149.qmail@stuge.se> Message-ID: <20101122085130.GV26868@prithivi.gnumonks.org> Hi Peter, On Mon, Nov 22, 2010 at 03:49:09AM +0100, Peter Stuge wrote: > > There is working firmware (drivers, T=0 sniffing, ...) for the > > AT91SAM7 now, I put quite a bit of effort into making this work. > > Furthermore, the AT91SAM7 USART has the unique property that you > > can use it in T=0 mode but still operate as clock slave, i.e. run > > as sniffer or card mode, not behaving like a card reader. > > I think every sync serial peripheral that I've seen can operate in > slave mode like that, and I agree that it's important. Are you sure? Please note that the variant of ISO7816-3 that we primarily want is T=0 in asynchronous mode. Here we actually have I/O asynchronous to the clock (i.e. the clock is not a bit clock), but still want to derive the baud rate off an external clock (with programmable, non-power-of-two divider) Even for the SAM7 what we are doing is not documented, they only describe the T=0 USART mode with internal / master clock in their data sheet. The SAM7 USART is not used in synchronous mode. I'm not saying no other chip can do it, but I find it a very uncommon feature, as there is no regular commercial application to it. You either want a synchronous USART _or_ you want to operate in T=0 / T=1, but in the latter case: why would you ever do something else than implement an actual card reader? ;) > I disagree that significant effort would be required. You will need to write drivers for the USB device controller (preferrably compatible to what simtrace currently understands, you will need to properly drive the USART, you will need a timer/counter block for waiting time detection and combine all that with the end-of-apdu-detection, nRST logic, PPS, etc. I would be surprised if you need less than two full days for development and debugging all of this. But for what? To what advantage? Even if the schematic lacks 3 or 4 components and is 10 EUR cheaper... who would want to invest that much time in something that is merely a tool that will never be produced in large quantities? Furthermore, a LPC1343 has only one UART, removing the man-in-the-middle option... and even card simulation will be difficult, as the UART has no T=0 mode and thus cannot generate the T=0 specific tri-stating of a single shared Rx/Tx line, and will not do the NACK that will pull the I/O line low during one of the two stop bits. > But one thing that I think matters is that it's very easy and cheap > to get hold of a really simple (e.g.) LPC1343 development board in > neat size that people could use instead of having to build their own > hardware. I think that wall clock time would be about same for > porting the software and producing a board. I also agree. People will be either part of two groups: 1) people able to build their own hardware. They can use the SAM7-P64 or SAM7-H64 boards from Olimex (or similar boards) + the RebelSIM Scanner as mechanical adapter 2) people who are not able or interested in building stuff but who prefer to buy a product and simply use it. I don't think there is much room left for people actually building more than '1', i.e. producing the PCB, soldering it, etc. My approach is thus different: I'm discussing whether bitmanufaktur.de wants to include such a product into their (temporarily offline) webshop that also sells the openPCD, openPICC and openBeacon hardware. It looks good, but is likely to happen deep into Q1/2011, as far as I can tell (mostly due to constraints with their overloaded manufacturer). 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 vamposdecampos at gmail.com Sun Nov 21 20:45:21 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 21 Nov 2010 22:45:21 +0200 Subject: [PATCH 0/2] Small CBCH fixes, and playground Message-ID: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> Hi all, I've been looking at receiving CBCH traffic (where I live, 226-01 broadcasts a geographical area name with each cell). Patches 1/1 and 1/2 are small fixes for the layer23 system information parser, for storing the required CBCH channel description and mobile allocation info. I'll also reply with WIP patches for a small CBCH sniffing l23 app, and for decoding CBCH in Wireshark. The latter is a quick hack job, as it only decodes the first block, and it's bodged onto the LAPDm dissector. Also a question: what would be the best place to integrate CBCH handling into osmocom-bb? I'm guessing host/layer23/src/common/lapdm.c would handle block reassembly, then send CBS frames up the stack. Would any existing messages fit the bill (RSL_MT_UNIT_DATA_IND?) or should we add a new one? Cheers, Alex Alex Badea (2): layer23 sysinfo: store chan_nr when decoding CBCH Channel Description layer23 sysinfo: fix parsing of CBCH Mobile Allocation src/host/layer23/src/common/sysinfo.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) From vamposdecampos at gmail.com Sun Nov 21 20:47:58 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 21 Nov 2010 22:47:58 +0200 Subject: [RFC][PATCH wireshark] packet-lapdm: dissect CBS payloads In-Reply-To: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> Hack dissection of Cell Broadcast Service into LAPDm. First-Block payloads are also dissected directly. --- packet-lapdm.c | 164 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 163 insertions(+), 1 deletion(-) diff --git a/epan/dissectors/packet-lapdm.c b/epan/dissectors/packet-lapdm.c index dbeac85..e1d67b4 100644 --- a/epan/dissectors/packet-lapdm.c +++ b/epan/dissectors/packet-lapdm.c @@ -61,12 +61,25 @@ #include #include +#include +#include "packet-gsm_map.h" +#include "packet-gsm_sms.h" + static int proto_lapdm = -1; static int hf_lapdm_address = -1; static int hf_lapdm_ea = -1; static int hf_lapdm_cr = -1; static int hf_lapdm_sapi = -1; static int hf_lapdm_lpd = -1; +static int hf_lapdm_cb_lb = -1; +static int hf_lapdm_cb_seq = -1; +static int hf_lapdm_cbs_serial_gs = -1; +static int hf_lapdm_cbs_serial_mcode = -1; +static int hf_lapdm_cbs_serial_updnum = -1; +static int hf_lapdm_cbs_msgid = -1; +static int hf_lapdm_cbs_page_num = -1; +static int hf_lapdm_cbs_page_cnt = -1; +static int hf_lapdm_cbs_content = -1; static int hf_lapdm_control = -1; static int hf_lapdm_n_r = -1; @@ -103,6 +116,8 @@ static gint ett_lapdm_control = -1; static gint ett_lapdm_length = -1; static gint ett_lapdm_fragment = -1; static gint ett_lapdm_fragments = -1; +static gint ett_lapdm_cbs_serial = -1; +static gint ett_lapdm_cbs_dcs = -1; static GHashTable *lapdm_fragment_table = NULL; static GHashTable *lapdm_reassembled_table = NULL; @@ -121,6 +136,12 @@ static gboolean reassemble_lapdm = TRUE; #define LAPDM_CR 0x02 /* Command/Response bit */ #define LAPDM_EA 0x01 /* First Address Extension bit */ #define LAPDM_LPD 0x60 /* Link Protocol Discriminator */ +#define LAPDM_LPD_CB 0x20 /* Cell Broadcast LPD */ +#define LAPDM_CB_LB 0x10 /* Cell Broadcast Last Bit */ +#define LAPDM_CB_SEQ 0x0f /* Cell Broadcast sequence number */ +#define LAPDM_CBS_SERIAL_GS 0xc0 /* CBS Serial Number - Geographical Scope */ +#define LAPDM_CBS_SERIAL_MCODE 0x3ffc /* CBS Serial Number - Message Code */ +#define LAPDM_CBS_SERIAL_UPDNUM 0x03 /* CBS Serial Number - Update Number */ /* * Bits in the length field. @@ -132,6 +153,7 @@ static gboolean reassemble_lapdm = TRUE; #define LAPDM_LEN_SHIFT 2 #define LAPDM_HEADER_LEN 3 +#define LAPDM_CB_HEADER_LEN 1 #define LAPDM_SAPI_RR_CC_MM 0 #define LAPDM_SAPI_SMS 3 @@ -179,6 +201,33 @@ static const value_string lapdm_el_vals[] = { { 0, NULL } }; +/* 04.12 section 3.3.1 */ +static const value_string lapdm_lb_vals[] = { + { 0, "More blocks" }, + { 1, "Last block" }, + { 0, NULL } +}; + +/* 04.12 section 3.3.1 */ +static const value_string lapdm_seq_vals[] = { + { 0, "First block" }, + { 1, "Second block" }, + { 2, "Third block" }, + { 3, "Fourth block" }, + { 8, "First schedule block" }, + { 15, "Null message" }, + { 0, NULL } +}; + +/* 03.41 section 9.3.2.1 */ +static const value_string lapdm_serial_gs_vals[] = { + { 0, "Cell wide (immediate)" }, + { 1, "PLMN wide" }, + { 2, "Location Area wide" }, + { 3, "Cell wide" }, + { 0, NULL } +}; + static const fragment_items lapdm_frag_items = { /* Fragment subtrees */ @@ -209,6 +258,79 @@ lapdm_defragment_init (void) static void +dissect_lapdm_cb(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree) +{ + proto_tree *lapdm_tree, *addr_tree; + proto_item *lapdm_ti, *addr_ti; + guint8 addr, seq; + tvbuff_t *payload; + int offset; + int length, out_len; + gchar msgbuf[88]; + + addr = tvb_get_guint8(tvb, 0); + if (tree) { + lapdm_ti = proto_tree_add_item(tree, proto_lapdm, tvb, 0, LAPDM_CB_HEADER_LEN, FALSE); + lapdm_tree = proto_item_add_subtree(lapdm_ti, ett_lapdm); + + addr_ti = proto_tree_add_uint(lapdm_tree, hf_lapdm_address, tvb, 0, 1, addr); + addr_tree = proto_item_add_subtree(addr_ti, ett_lapdm_address); + + proto_tree_add_uint(addr_tree, hf_lapdm_lpd, tvb, 0, 1, addr); + proto_tree_add_uint(addr_tree, hf_lapdm_cb_lb, tvb, 0, 1, addr); + proto_tree_add_uint(addr_tree, hf_lapdm_cb_seq, tvb, 0, 1, addr); + } else { + lapdm_ti = NULL; + lapdm_tree = NULL; + } + + col_append_str(pinfo->cinfo, COL_INFO, "CBS "); + + offset = 1; + + /* TODO: reassemble blocks 1-3 */ + seq = addr & LAPDM_CB_SEQ; + if (seq == 0) { + proto_item *ti; + proto_tree *subtree; + + ti = proto_tree_add_text(lapdm_tree, tvb, offset, 2, "Serial Number"); + subtree = proto_item_add_subtree(ti, ett_lapdm_cbs_serial); + + proto_tree_add_item(subtree, hf_lapdm_cbs_serial_gs, tvb, offset, 1, FALSE); + proto_tree_add_item(subtree, hf_lapdm_cbs_serial_mcode, tvb, offset, 2, FALSE); + offset++; + proto_tree_add_item(subtree, hf_lapdm_cbs_serial_updnum, tvb, offset, 1, FALSE); + offset++; + + proto_tree_add_item(lapdm_tree, hf_lapdm_cbs_msgid, tvb, offset, 2, FALSE); + offset += 2; + + ti = proto_tree_add_text(lapdm_tree, tvb, offset, 1, "Data Coding Scheme"); + subtree = proto_item_add_subtree(ti, ett_lapdm_cbs_dcs); + dissect_cbs_data_coding_scheme(tvb_new_subset(tvb, offset, 1, -1), pinfo, subtree); + offset++; + + proto_tree_add_item(lapdm_tree, hf_lapdm_cbs_page_num, tvb, offset, 1, FALSE); + proto_tree_add_item(lapdm_tree, hf_lapdm_cbs_page_cnt, tvb, offset, 1, FALSE); + offset++; + + length = tvb_length(tvb) - offset; + out_len = gsm_sms_char_7bit_unpack(0, length, sizeof(msgbuf) - 1, + tvb_get_ptr(tvb, offset, length), msgbuf); + msgbuf[out_len] = '\0'; + proto_tree_add_string(lapdm_tree, hf_lapdm_cbs_content, tvb, offset, length, + gsm_sms_chars_to_utf8(msgbuf, out_len)); + + col_append_fstr(pinfo->cinfo, COL_INFO, " [%s]", gsm_sms_chars_to_utf8(msgbuf, out_len)); + } + + payload = tvb_new_subset_remaining(tvb, offset); + call_dissector(data_handle, payload, pinfo, tree); +} + + +static void dissect_lapdm(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree) { proto_tree *lapdm_tree, *addr_tree, *length_tree; @@ -227,6 +349,11 @@ dissect_lapdm(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree) col_set_str(pinfo->cinfo, COL_PROTOCOL, "LAPDm"); addr = tvb_get_guint8(tvb, 0); + if ((addr & LAPDM_LPD) == LAPDM_LPD_CB) { + dissect_lapdm_cb(tvb, pinfo, tree); + return; + } + length = tvb_get_guint8(tvb, 2); cr = addr & LAPDM_CR; @@ -360,6 +487,39 @@ proto_register_lapdm(void) { "SAPI", "lapdm.sapi", FT_UINT8, BASE_DEC, VALS(lapdm_sapi_vals), LAPDM_SAPI, "Service access point identifier", HFILL }}, + { &hf_lapdm_cb_lb, + { "LB", "lapdm.cb.lb", FT_UINT8, BASE_DEC, + VALS(lapdm_lb_vals), LAPDM_CB_LB, "Last Block bit", HFILL }}, + + { &hf_lapdm_cb_seq, + { "SEQ", "lapdm.cb.seq", FT_UINT8, BASE_DEC, + VALS(lapdm_seq_vals), LAPDM_CB_SEQ, "Sequence Number", HFILL }}, + + { &hf_lapdm_cbs_serial_gs, + { "GS", "lapdm.cbs.serial.gs", FT_UINT8, BASE_DEC, + VALS(lapdm_serial_gs_vals), LAPDM_CBS_SERIAL_GS, "Geographic Scope", HFILL }}, + { &hf_lapdm_cbs_serial_mcode, + { "Message Code", "lapdm.cbs.serial.mcode", FT_UINT16, BASE_DEC, + NULL, LAPDM_CBS_SERIAL_MCODE, NULL, HFILL }}, + { &hf_lapdm_cbs_serial_updnum, + { "Update Number", "lapdm.cbs.serial.updnum", FT_UINT8, BASE_DEC, + NULL, LAPDM_CBS_SERIAL_MCODE, NULL, HFILL }}, + + { &hf_lapdm_cbs_msgid, + { "Message Identifier", "lapdm.cbs.msgid", FT_UINT16, BASE_DEC, + NULL, 0, NULL, HFILL }}, + + { &hf_lapdm_cbs_page_num, + { "Page number", "lapdm.cbs.page.num", FT_UINT8, BASE_DEC, + NULL, 0xf0, NULL, HFILL }}, + { &hf_lapdm_cbs_page_cnt, + { "Total pages", "lapdm.cbs.page.cnt", FT_UINT8, BASE_DEC, + NULL, 0x0f, NULL, HFILL }}, + + { &hf_lapdm_cbs_content, + { "Content of Message", "lapdm.cbs.content", FT_STRING, BASE_NONE, + NULL, 0x00, NULL, HFILL }}, + { &hf_lapdm_control, { "Control Field", "lapdm.control_field", FT_UINT8, BASE_HEX, NULL, 0x0, NULL, HFILL }}, @@ -461,7 +621,9 @@ proto_register_lapdm(void) &ett_lapdm_control, &ett_lapdm_length, &ett_lapdm_fragment, - &ett_lapdm_fragments + &ett_lapdm_fragments, + &ett_lapdm_cbs_serial, + &ett_lapdm_cbs_dcs, }; module_t *lapdm_module; From laforge at gnumonks.org Sun Nov 21 22:32:40 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Nov 2010 23:32:40 +0100 Subject: [RFC][PATCH wireshark] packet-lapdm: dissect CBS payloads In-Reply-To: <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <20101121223240.GK26868@prithivi.gnumonks.org> Hi Alex, first of all thanks for your CBCH contribution, it is much apperciated. To me, the osmocom-bb patches all look fine. I'll let Andreas have a look at them and decide, since it's mostly his code that is touched by your patches. Regarding the wireshark patch: I suggest submitting that directly to the wireshark project. You typically do this by creating a bugzilla ticket and attaching your patch. It will then be reviewed and hopefully included. I am not an official wireshark developer either, just contributing patches here and there. But if you run into any trouble and need some support arguing for inclusion of your patch, let me know. 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 vamposdecampos at gmail.com Mon Nov 22 09:11:36 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Mon, 22 Nov 2010 11:11:36 +0200 Subject: [RFC][PATCH wireshark] packet-lapdm: dissect CBS payloads In-Reply-To: <20101121223240.GK26868@prithivi.gnumonks.org> References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> <20101121223240.GK26868@prithivi.gnumonks.org> Message-ID: Hi, thanks everyone for your feedback. On Mon, Nov 22, 2010 at 12:32 AM, Harald Welte wrote: > Regarding the wireshark patch: ? I suggest submitting that directly to the > wireshark project. ?You typically do this by creating a bugzilla ticket and > attaching your patch. ?It will then be reviewed and hopefully included. I plan to do that, but it needs some cleanup first. At the very least, the CBS-specific dissection should be factored out into another module, since the messages are also present between CBC <-> BSC <-> BTS. Presumably, only block reassembly should sit in packet-lapdm.c. Thanks, Alex From holger at freyther.de Sun Nov 21 22:33:08 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Sun, 21 Nov 2010 23:33:08 +0100 Subject: [RFC][PATCH wireshark] packet-lapdm: dissect CBS payloads In-Reply-To: <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <4CE99E24.3080009@freyther.de> On 11/21/2010 09:47 PM, Alex Badea wrote: > Hack dissection of Cell Broadcast Service into LAPDm. First-Block payloads > are also dissected directly. Cool, could you send a mail to the wireshark-dev and ask them how to proceed with this kind of patch? thanks holger From steve at steve-m.de Sun Nov 21 23:38:55 2010 From: steve at steve-m.de (Steve Markgraf) Date: Mon, 22 Nov 2010 00:38:55 +0100 Subject: [RFC][PATCH wireshark] packet-lapdm: dissect CBS payloads In-Reply-To: <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> <1290372478-5976-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <4CE9AD8F.8080201@steve-m.de> Hi, On 21.11.2010 21:47, Alex Badea wrote: > Hack dissection of Cell Broadcast Service into LAPDm. First-Block payloads > are also dissected directly. Cool stuff! 262-07 (O2 Germany) transmits the cell location as well. They are encoded as Gauss-Kr?ger coordinates, which can be converted with this script: http://www.nobbi.com/download/gauss-converter.tar.gz Works fine and the location matches. Andreas: This would be a cool addon for cell_log ;) Regards, Steve From laforge at gnumonks.org Sun Nov 21 22:34:45 2010 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Nov 2010 23:34:45 +0100 Subject: [PATCH 0/2] Small CBCH fixes, and playground In-Reply-To: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <20101121223445.GL26868@prithivi.gnumonks.org> Alex: Ah well, this was so non-intrusive that I simply applied the first three patches of your patchset (excluding the wireshark patch which you should submit direcly to the wireshark folks) Andreas: Hope this is fine for you. -- - 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 Mon Nov 22 09:38:44 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 22 Nov 2010 10:38:44 +0100 Subject: [PATCH 0/2] Small CBCH fixes, and playground In-Reply-To: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> Message-ID: > Also a question: ?what would be the best place to integrate CBCH > handling into osmocom-bb? ?I'm guessing host/layer23/src/common/lapdm.c > would handle block reassembly, then send CBS frames up the stack. I don't know CBCH at all, but a general rule would be: Is the block reassembly part of LAPDm ? (i.e. GSM 04.06 ?) - If yes, then it fits in lapdm.c - If no and nothing else fits, create a new file for it. Cheers, Sylvain From vamposdecampos at gmail.com Mon Nov 22 19:09:41 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Mon, 22 Nov 2010 21:09:41 +0200 Subject: [PATCH 0/2] Small CBCH fixes, and playground In-Reply-To: References: <1290372323-5862-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <4CEABFF5.7040301@gmail.com> On 11/22/2010 11:38 AM, Sylvain Munaut wrote: >> Also a question: what would be the best place to integrate CBCH >> handling into osmocom-bb? I'm guessing host/layer23/src/common/lapdm.c >> would handle block reassembly, then send CBS frames up the stack. > > I don't know CBCH at all, but a general rule would be: > > Is the block reassembly part of LAPDm ? (i.e. GSM 04.06 ?) > - If yes, then it fits in lapdm.c > - If no and nothing else fits, create a new file for it. Actually, the only link to 04.06 is a note in section 3.2 saying: > LPD = "0 1" corresponds to the data link protocol used for SMSCB (see 3GPP TS 04.12). ... whereupon the LPD=01 address field variant is redefined to contain different bit-fields. This supports the idea that implementation of SMSCB should be entirely separate from LAPDm. Thanks, Alex From xalexu at gmail.com Mon Nov 22 14:03:41 2010 From: xalexu at gmail.com (chenyu xu) Date: Mon, 22 Nov 2010 22:03:41 +0800 Subject: Fresh people's build problem Message-ID: Hello guys: In order to participate in OSMOCOM-BB project, I have buy the old moto C118 and made the T191 cable by myself. But when I run "make" in ****/src/osmocom-bb/src directory, the error info is below: alexander at Foundation:~/src/osmocom-bb/src$ make cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections -I../../../../target/firmware/include" configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for arm-elf-linux-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make sets $(MAKE)... (cached) yes checking for arm-elf-linux-gcc... arm-elf-gcc checking whether the C compiler works... no configure: error: in `/home/alexander/src/osmocom-bb/src/shared/libosmocore/build-target': configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [shared/libosmocore/build-target/Makefile] Error 77 After my investigating on this issue, I think I must build my own arm-elf-linux-gcc, am I right? I want to know how the experienced person handle this scenario? Please answer my questions! Thanks! alexander Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: From xalexu at gmail.com Fri Nov 26 02:27:06 2010 From: xalexu at gmail.com (xuchenyu) Date: Thu, 25 Nov 2010 18:27:06 -0800 (PST) Subject: Fresh people's build problem In-Reply-To: References: Message-ID: <1290738426866-1970625.post@n3.nabble.com> I have known the reason why I built failed, I used the wrong toolchain(the toolchain is 64 bits, but my desktop is 32 bits). Then I downloaded the 3.4.3 toolchain. It made some progress in building, but there were some errors. The error info is below: make[4]: Entering directory `/home/xuchenyu/test/osmocom-bb/src/shared/libosmocore/build-target/src' CC msgb.lo In file included from ../../include/osmocore/msgb.h:23, from ../../src/msgb.c:27: ../../../../target/firmware/include/stdint.h:13:25: stdint.h: No such file or directory make[4]: *** [msgb.lo] Error 1 make[4]: Leaving directory `/home/xuchenyu/test/osmocom-bb/src/shared/libosmocore/build-target/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/xuchenyu/test/osmocom-bb/src/shared/libosmocore/build-target/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/xuchenyu/test/osmocom-bb/src/shared/libosmocore/build-target' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/xuchenyu/test/osmocom-bb/src/shared/libosmocore/build-target' make: *** [shared/libosmocore/build-target/src/.libs/libosmocore.a] Error 2 I think it missed some C library head files(c99), how do I include these missing head files? What will happen if I include the desktop 's C lib head? Thanks!! -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Fresh-people-s-build-problem-tp1946367p1970625.html Sent from the baseband-devel mailing list archive at Nabble.com. From vamposdecampos at gmail.com Sat Nov 27 18:00:39 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 27 Nov 2010 20:00:39 +0200 Subject: [PATCH libosmocore] gsm_04_12: fix 04.13 typos Message-ID: <1290880839-10247-1-git-send-email-vamposdecampos@gmail.com> There are two occurrences of "413" in the 04.12 header file. These are probably typos; correct them to "412". Signed-off-by: Alex Badea --- include/osmocore/protocol/gsm_04_12.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/osmocore/protocol/gsm_04_12.h b/include/osmocore/protocol/gsm_04_12.h index bd9e088..9b1538a 100644 --- a/include/osmocore/protocol/gsm_04_12.h +++ b/include/osmocore/protocol/gsm_04_12.h @@ -10,7 +10,7 @@ #define GSM412_SEQ_TRD_BLOCK 0x2 #define GSM412_SEQ_FTH_BLOCK 0x3 #define GSM412_SEQ_FST_SCHED_BLOCK 0x8 -#define GSM413_SEQ_NULL_MSG 0xf +#define GSM412_SEQ_NULL_MSG 0xf struct gsm412_block_type { uint8_t seq_nr : 4, @@ -19,7 +19,7 @@ struct gsm412_block_type { spare : 1; } __attribute__((packed)); -struct gsm413_sched_msg { +struct gsm412_sched_msg { uint8_t beg_slot_nr : 6, type : 2; uint8_t end_slot_nr : 6, -- 1.7.0.4 From bongio87 at yahoo.it Sat Nov 27 20:20:38 2010 From: bongio87 at yahoo.it (luca bongiorni) Date: Sat, 27 Nov 2010 20:20:38 +0000 (GMT) Subject: Sciphone's Versions and European Shops In-Reply-To: Message-ID: <415561.21392.qm@web29618.mail.ird.yahoo.com> Hi mates, i was thinking to start to work also on Sciphone and starting to learn as much as i can and contribute to the community (even if actually i'm a noob of phone firmwares, i worked only on MIPS router firmwares ). Have you some usefull books/wiki/etc to start on? These are the 3 versions identified of Sciphone: HY27XS08121M - 512Mb (64MB) NAND + 32MB RAM HY27XA081G1M - 1Gb (128MB) NAND + 32MB RAM TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM How i could ask to sellers for the best version? (TC58NVG0S3AFT - 1Gb (128MB) NAND + 64MB RAM) Do you know an european shop where i can find it? Thankyou for attention folks Regards Luca -------------- next part -------------- An HTML attachment was scrubbed... URL: From aifiltr0 at invyl.ath.cx Sat Nov 27 21:15:01 2010 From: aifiltr0 at invyl.ath.cx (Andrew) Date: Sun, 28 Nov 2010 00:15:01 +0300 Subject: Linux + u-boot port to MT6235 (E1000 phone) Message-ID: Hello, everyone. I've just stumbled on the post in maillists following a news tip on one of the linux forums. I myself have two MTK-based devices - E1000 (MTK6335) and Nokla TV E71 (MTK6225) and have done some research some time ago. However, from what I heard there was no MMU there (even on 35), so I didn't study the possibility to start linux there. To make the story short, I'm now trying to run all the good stuff on my phone and cannot get past the loader. While now I cannot get past the osmocon part and upload ramloader: When I hook up my phone I get ---cut--- ~~~ Welcome to MTK Bootloader V005 (since 2005) ~~~ **===================================================** Main=0x3, Tmp=0x0, Fota=0x0, Bak=0x0 Number of image segments = 4 ..[0] Image size = 352Bytes, start addr. =0x428 ..[1] Image size = 4516152Bytes, start addr. =0x0 ..[2] Image size = 12494144Bytes, start addr. =0x452938 ..[3] Image size = 10340676Bytes, start addr. =-0xe000000 Start loading image... ....................................................................NFB image index: 1... Bye bye bootloader, jump to=0x0 ---cut--- And this comes out at 115200 baud. Trying osmocon: osmocon looks like it sends the beacon - but nothing happens - the phone just turns on. (I do hold the power button, but that just doesn't help) I altered the sources and changed initial baudrate to 115200, but nothing still. I have not yet figured out jtag pins out there, and I guess I will hook my old atmega-based jtag scanner only if there would be not other way to make serial method work. I think I can be of some help, since I have the hardware and some experience in kernel hacking. But I guess I cannot be of any use in the gsm part since I just don't know that stuff. That's it, And thanks for starting the porting process. From vamposdecampos at gmail.com Sat Nov 27 21:34:46 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 27 Nov 2010 23:34:46 +0200 Subject: [PATCH libosmocore] gsm_08_58: add struct and constants for RSL_IE_CB_CMD_TYPE Message-ID: <1290893686-24093-1-git-send-email-vamposdecampos@gmail.com> Signed-off-by: Alex Badea --- include/osmocore/protocol/gsm_08_58.h | 21 +++++++++++++++++++++ 1 files changed, 21 insertions(+), 0 deletions(-) diff --git a/include/osmocore/protocol/gsm_08_58.h b/include/osmocore/protocol/gsm_08_58.h index 5fe332e..74a4083 100644 --- a/include/osmocore/protocol/gsm_08_58.h +++ b/include/osmocore/protocol/gsm_08_58.h @@ -441,6 +441,27 @@ struct rsl_ie_chan_ident { #define RSL_CHANNEED_TCH_F 0x02 #define RSL_CHANNEED_TCH_ForH 0x03 +/* Chapter 9.3.45 */ +struct rsl_ie_cb_cmd_type { + uint8_t last_block:2; + uint8_t spare:1; + uint8_t def_bcast:1; + uint8_t command:4; +} __attribute__ ((packed)); +/* ->command */ +#define RSL_CB_CMD_TYPE_NORMAL 0x00 +#define RSL_CB_CMD_TYPE_SCHEDULE 0x08 +#define RSL_CB_CMD_TYPE_DEFAULT 0x0e +#define RSL_CB_CMD_TYPE_NULL 0x0f +/* ->def_bcast */ +#define RSL_CB_CMD_DEFBCAST_NORMAL 0 +#define RSL_CB_CMD_DEFBCAST_NULL 1 +/* ->last_block */ +#define RSL_CB_CMD_LASTBLOCK_4 0 +#define RSL_CB_CMD_LASTBLOCK_1 1 +#define RSL_CB_CMD_LASTBLOCK_2 2 +#define RSL_CB_CMD_LASTBLOCK_3 3 + /* Chapter 3.3.2.3 Brocast control channel */ /* CCCH-CONF, NC is not combined */ #define RSL_BCCH_CCCH_CONF_1_NC 0x00 -- 1.7.0.4 From vamposdecampos at gmail.com Sat Nov 27 21:35:08 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sat, 27 Nov 2010 23:35:08 +0200 Subject: [PATCH libosmocore] protocol: introduce gsm_03_41.h Message-ID: <1290893708-24127-1-git-send-email-vamposdecampos@gmail.com> This currently contains definitions for the BTS->MS SMSCB message. Signed-off-by: Alex Badea --- include/osmocore/protocol/gsm_03_41.h | 34 +++++++++++++++++++++++++++++++++ 1 files changed, 34 insertions(+), 0 deletions(-) create mode 100644 include/osmocore/protocol/gsm_03_41.h diff --git a/include/osmocore/protocol/gsm_03_41.h b/include/osmocore/protocol/gsm_03_41.h new file mode 100644 index 0000000..250d667 --- /dev/null +++ b/include/osmocore/protocol/gsm_03_41.h @@ -0,0 +1,34 @@ +#ifndef PROTO_GSM_03_41_H +#define PROTO_GSM_03_41_H + +#include + +/* GSM TS 03.41 definitions */ + +/* Chapter 9.3.2 */ +struct gsm341_ms_message { + struct { + uint8_t code_hi:6; + uint8_t gs:2; + uint8_t update:2; + uint8_t code_lo:6; + } serial; + uint16_t msg_id; + struct { + uint8_t language:4; + uint8_t group:4; + } dcs; + struct { + uint8_t total:4; + uint8_t current:4; + } page; + uint8_t data[0]; +} __attribute__((packed)); + +/* Section 9.3.2.1 - Geographical Scope */ +#define GSM341_GS_CELL_WIDE_IMMED 0 +#define GSM341_GS_PLMN_WIDE 1 +#define GSM341_GS_LA_WIDE 2 +#define GSM341_GS_CELL_WIDE 3 + +#endif /* PROTO_GSM_03_41_H */ -- 1.7.0.4 From 246tnt at gmail.com Sun Nov 28 14:17:38 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 28 Nov 2010 15:17:38 +0100 Subject: [PATCH libosmocore] protocol: introduce gsm_03_41.h In-Reply-To: <1290893708-24127-1-git-send-email-vamposdecampos@gmail.com> References: <1290893708-24127-1-git-send-email-vamposdecampos@gmail.com> Message-ID: Hi, This was missing a proper modification to the Makefile.am for it to install properly in the standalone libosmocore version I fixed it and I'm checking it right now. I'll push it when I'm done, along with the pull of the new libosmocore in the osmocom-bb tree. Cheers, Sylvain From vamposdecampos at gmail.com Sat Nov 27 22:49:58 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 28 Nov 2010 00:49:58 +0200 Subject: [RFC][PATCH] layer1: clear dedicated mode on FULL reset Message-ID: <1290898198-26625-1-git-send-email-vamposdecampos@gmail.com> This is particularly useful if a layer23 app exists uncleanly; the next app would not be able to synchronize at all. Signed-off-by: Alex Badea --- More to the point, I'd get stuck on the CBCH ;) I'm not sure if this would negatively impact other FULL reset use-cases, hence the RFC. Thanks, Alex src/target/firmware/layer1/l23_api.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/target/firmware/layer1/l23_api.c b/src/target/firmware/layer1/l23_api.c index 19838f1..82b86d7 100644 --- a/src/target/firmware/layer1/l23_api.c +++ b/src/target/firmware/layer1/l23_api.c @@ -381,6 +381,7 @@ static void l1ctl_rx_reset_req(struct msgb *msg) switch (reset_req->type) { case L1CTL_RES_T_FULL: printf("L1CTL_RESET_REQ: FULL!\n"); + l1s.dedicated.type = GSM_DCHAN_NONE; l1s_reset(); l1s_reset_hw(); audio_set_enabled(0); -- 1.7.0.4 From 246tnt at gmail.com Sat Nov 27 22:56:10 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 27 Nov 2010 23:56:10 +0100 Subject: [RFC][PATCH] layer1: clear dedicated mode on FULL reset In-Reply-To: <1290898198-26625-1-git-send-email-vamposdecampos@gmail.com> References: <1290898198-26625-1-git-send-email-vamposdecampos@gmail.com> Message-ID: That assignement should be done in l1s_reset and not there. I ll fix it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamposdecampos at gmail.com Sun Nov 28 14:07:26 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 28 Nov 2010 16:07:26 +0200 Subject: [PATCH 0/3] layer23 SMSCB support Message-ID: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Hi, This patch series adds layer23 support for receiving SMSCB messages. Patches 1/3 and 2/3 add common layer2 code for reassembling blocks and sending them up to L3. Patch 3/3 is an addition to cell_log for logging cell-info-display-type SMSCB messages, if available. This series requires patches[1][2][3] to libosmocore protocol headers. Cheers, Alex [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000827.html [2] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000830.html [3] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000831.html Alex Badea (3): layer23: introduce SMSCB framework layer23 smscb: reassemble blocks and pass them up to L3 layer23 cell_log: log CBCH cell info src/host/layer23/include/osmocom/bb/common/lapdm.h | 2 + src/host/layer23/include/osmocom/bb/common/smscb.h | 28 +++ src/host/layer23/src/common/Makefile.am | 2 +- src/host/layer23/src/common/lapdm.c | 7 + src/host/layer23/src/common/smscb.c | 211 ++++++++++++++++++++ src/host/layer23/src/misc/cell_log.c | 107 ++++++++++- 6 files changed, 354 insertions(+), 3 deletions(-) create mode 100644 src/host/layer23/include/osmocom/bb/common/smscb.h create mode 100644 src/host/layer23/src/common/smscb.c From vamposdecampos at gmail.com Sun Nov 28 14:07:27 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 28 Nov 2010 16:07:27 +0200 Subject: [PATCH 1/3] layer23: introduce SMSCB framework In-Reply-To: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290953249-24365-2-git-send-email-vamposdecampos@gmail.com> Define a smscb_entity struct. Add it to lapdm_entity. Pass LAPDm frames with LPD=01 to SMSCB, and skip any further LAPDm processing. Signed-off-by: Alex Badea --- src/host/layer23/include/osmocom/bb/common/lapdm.h | 2 + src/host/layer23/include/osmocom/bb/common/smscb.h | 23 ++++++++++ src/host/layer23/src/common/Makefile.am | 2 +- src/host/layer23/src/common/lapdm.c | 7 +++ src/host/layer23/src/common/smscb.c | 46 ++++++++++++++++++++ 5 files changed, 79 insertions(+), 1 deletions(-) create mode 100644 src/host/layer23/include/osmocom/bb/common/smscb.h create mode 100644 src/host/layer23/src/common/smscb.c diff --git a/src/host/layer23/include/osmocom/bb/common/lapdm.h b/src/host/layer23/include/osmocom/bb/common/lapdm.h index de954fb..364d165 100644 --- a/src/host/layer23/include/osmocom/bb/common/lapdm.h +++ b/src/host/layer23/include/osmocom/bb/common/lapdm.h @@ -7,6 +7,7 @@ #include #include +#include enum lapdm_state { LAPDm_STATE_NULL = 0, @@ -66,6 +67,7 @@ struct lapdm_entity { struct lapdm_datalink datalink[_NR_DL_SAPI]; int last_tx_dequeue; /* last entity that was dequeued */ int tx_pending; /* currently a pending frame not confirmed by L1 */ + struct smscb_entity smscb; struct osmocom_ms *ms; }; diff --git a/src/host/layer23/include/osmocom/bb/common/smscb.h b/src/host/layer23/include/osmocom/bb/common/smscb.h new file mode 100644 index 0000000..d689cd7 --- /dev/null +++ b/src/host/layer23/include/osmocom/bb/common/smscb.h @@ -0,0 +1,23 @@ +#ifndef _OSMOCOM_SMSCB_H +#define _OSMOCOM_SMSCB_H + +#include + +struct osmocom_ms; +struct msgb; +struct l1ctl_info_dl; + +struct smscb_entity { + struct osmocom_ms *ms; +}; + +/* initialize a SMSCB entity */ +void smscb_init(struct smscb_entity *se, struct osmocom_ms *ms); + +/* deinitialize a SMSCB entity */ +void smscb_exit(struct smscb_entity *se); + +/* input into SMSCB layer (from layer 1) */ +int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg, struct l1ctl_info_dl *l1i); + +#endif /* _OSMOCOM_SMSCB_H */ diff --git a/src/host/layer23/src/common/Makefile.am b/src/host/layer23/src/common/Makefile.am index 4e2686c..6f5f4f1 100644 --- a/src/host/layer23/src/common/Makefile.am +++ b/src/host/layer23/src/common/Makefile.am @@ -3,4 +3,4 @@ AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) noinst_LIBRARIES = liblayer23.a liblayer23_a_SOURCES = l1ctl.c l1l2_interface.c sap_interface.c lapdm.c \ - logging.c networks.c sim.c sysinfo.c gps.c + logging.c networks.c sim.c sysinfo.c gps.c smscb.c diff --git a/src/host/layer23/src/common/lapdm.c b/src/host/layer23/src/common/lapdm.c index dc9c916..9233dbb 100644 --- a/src/host/layer23/src/common/lapdm.c +++ b/src/host/layer23/src/common/lapdm.c @@ -79,6 +79,7 @@ #define LAPDm_SAPI_SMS 3 #define LAPDm_ADDR(lpd, sapi, cr) ((((lpd) & 0x3) << 5) | (((sapi) & 0x7) << 2) | (((cr) & 0x1) << 1) | 0x1) +#define LAPDm_ADDR_LPD(addr) (((addr) >> 5) & 0x03) #define LAPDm_ADDR_SAPI(addr) (((addr) >> 2) & 0x7) #define LAPDm_ADDR_CR(addr) (((addr) >> 1) & 0x1) #define LAPDm_ADDR_EA(addr) ((addr) & 0x1) @@ -193,6 +194,8 @@ void lapdm_init(struct lapdm_entity *le, struct osmocom_ms *ms) for (i = 0; i < ARRAY_SIZE(le->datalink); i++) lapdm_dl_init(&le->datalink[i], le); + smscb_init(&le->smscb, ms); + le->ms = ms; } @@ -227,6 +230,8 @@ void lapdm_exit(struct lapdm_entity *le) unsigned int i; struct lapdm_datalink *dl; + smscb_exit(&le->smscb); + for (i = 0; i < ARRAY_SIZE(le->datalink); i++) { dl = &le->datalink[i]; lapdm_dl_flush_tx(dl); @@ -1551,6 +1556,8 @@ int l2_ph_data_ind(struct msgb *msg, struct lapdm_entity *le, struct l1ctl_info_ case LAPDm_FMT_B: case LAPDm_FMT_B4: mctx.addr = msg->l2h[0]; + if (LAPDm_ADDR_LPD(mctx.addr) == LAPDm_LPD_SMSCB) + return smscb_ph_data_ind(&le->smscb, msg, l1i); if (!(mctx.addr & 0x01)) { LOGP(DLAPDM, LOGL_ERROR, "we don't support " "multibyte addresses (discarding)\n"); diff --git a/src/host/layer23/src/common/smscb.c b/src/host/layer23/src/common/smscb.c new file mode 100644 index 0000000..31a5752 --- /dev/null +++ b/src/host/layer23/src/common/smscb.c @@ -0,0 +1,46 @@ +/* GSM SMSCB (TS 04.12) implementation */ + +/* (C) 2010 by Alex Badea + * + * All Rights Reserved + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + * + */ + +#include +#include +#include + +void smscb_init(struct smscb_entity *se, struct osmocom_ms *ms) +{ + se->ms = ms; +} + +void smscb_exit(struct smscb_entity *se) +{ +} + +int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg, struct l1ctl_info_dl *l1i) +{ + uint8_t addr = msg->l2h[0]; + uint8_t seq = addr & 0x0f; + + LOGP(DLAPDM, LOGL_NOTICE, "SMSCB: received message: seq=%d len=%d\n", + seq, msg->len); + + msgb_free(msg); + return 0; +} -- 1.7.0.4 From vamposdecampos at gmail.com Sun Nov 28 14:07:28 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 28 Nov 2010 16:07:28 +0200 Subject: [PATCH 2/3] layer23 smscb: reassemble blocks and pass them up to L3 In-Reply-To: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290953249-24365-3-git-send-email-vamposdecampos@gmail.com> We (re)construct an equivalent RSL_MT_SMS_BC_CMD from received frames. Signed-off-by: Alex Badea --- src/host/layer23/include/osmocom/bb/common/smscb.h | 5 + src/host/layer23/src/common/smscb.c | 177 +++++++++++++++++++- 2 files changed, 176 insertions(+), 6 deletions(-) diff --git a/src/host/layer23/include/osmocom/bb/common/smscb.h b/src/host/layer23/include/osmocom/bb/common/smscb.h index d689cd7..a475a78 100644 --- a/src/host/layer23/include/osmocom/bb/common/smscb.h +++ b/src/host/layer23/include/osmocom/bb/common/smscb.h @@ -7,7 +7,12 @@ struct osmocom_ms; struct msgb; struct l1ctl_info_dl; +#define SMSCB_MAX_BLOCKS 4 + struct smscb_entity { + uint8_t seq_next; + uint8_t sched:1; + struct msgb *blocks[SMSCB_MAX_BLOCKS]; struct osmocom_ms *ms; }; diff --git a/src/host/layer23/src/common/smscb.c b/src/host/layer23/src/common/smscb.c index 31a5752..f520f25 100644 --- a/src/host/layer23/src/common/smscb.c +++ b/src/host/layer23/src/common/smscb.c @@ -21,26 +21,191 @@ */ #include +#include #include #include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define SMSCB_LPD 1 + +#define SMSCB_ALLOC_SIZE 256 +#define SMSCB_ALLOC_HEADROOM 64 + +static void smscb_reset(struct smscb_entity *se) +{ + int k; + + for (k = 0; k < SMSCB_MAX_BLOCKS; k++) { + msgb_free(se->blocks[k]); + se->blocks[k] = NULL; + } + se->sched = 0; + se->seq_next = 0; +} void smscb_init(struct smscb_entity *se, struct osmocom_ms *ms) { + memset(se, 0, sizeof(*se)); se->ms = ms; } void smscb_exit(struct smscb_entity *se) { + smscb_reset(se); +} + +static int smscb_rx_msg(struct smscb_entity *se, const struct l1ctl_info_dl *l1i) +{ + struct msgb *msg; + struct abis_rsl_cchan_hdr *ch; + int k; + uint8_t msglen, *tlv; + struct gsm_time tm; + struct rsl_ie_cb_cmd_type cmd_type = {}; + + msg = msgb_alloc_headroom( + SMSCB_ALLOC_HEADROOM + SMSCB_ALLOC_SIZE, + SMSCB_ALLOC_HEADROOM, "smscb_data"); + if (!msg) + return -ENOMEM; + + msg->l2h = msgb_put(msg, sizeof(*ch)); + ch = (struct abis_rsl_cchan_hdr *) msg->l2h; + rsl_init_cchan_hdr(ch, RSL_MT_SMS_BC_CMD); + ch->c.msg_discr |= ABIS_RSL_MDISC_TRANSP; + ch->chan_nr = l1i->chan_nr; + + cmd_type.command = + se->sched ? RSL_CB_CMD_TYPE_SCHEDULE : + RSL_CB_CMD_TYPE_NORMAL; + cmd_type.last_block = + se->blocks[3] ? RSL_CB_CMD_LASTBLOCK_4 : + se->blocks[2] ? RSL_CB_CMD_LASTBLOCK_3 : + se->blocks[1] ? RSL_CB_CMD_LASTBLOCK_2 : + RSL_CB_CMD_LASTBLOCK_1; + msgb_tv_put(msg, RSL_IE_CB_CMD_TYPE, *((uint8_t *) &cmd_type)); + + for (k = 0, msglen = 0; se->blocks[k] && k < SMSCB_MAX_BLOCKS; k++) + msglen += se->blocks[k]->len; + tlv = msgb_put(msg, TLV_GROSS_LEN(msglen)); + *tlv++ = RSL_IE_SMSCB_MSG; + *tlv++ = msglen; + for (k = 0; se->blocks[k] && k < SMSCB_MAX_BLOCKS; k++) { + memcpy(tlv, se->blocks[k]->data, se->blocks[k]->len); + tlv += se->blocks[k]->len; + } + + /* + * TS 05.02 chapter 6.5.4: basic vs. extended CBCH + * is indicated by multiframe number + */ + gsm_fn2gsmtime(&tm, ntohl(l1i->frame_nr)); + msgb_tv_put(msg, RSL_IE_SMSCB_CHAN_INDICATOR, !(tm.tc < 4)); + + return rslms_sendmsg(msg, se->ms); +} + +static int smscb_rx_null_msg(struct smscb_entity *se, const struct l1ctl_info_dl *l1i) +{ + struct msgb *msg; + struct abis_rsl_cchan_hdr *ch; + struct gsm_time tm; + struct rsl_ie_cb_cmd_type cmd_type = {}; + + msg = msgb_alloc_headroom( + SMSCB_ALLOC_HEADROOM + SMSCB_ALLOC_SIZE, + SMSCB_ALLOC_HEADROOM, "smscb_data"); + if (!msg) + return -ENOMEM; + + msg->l2h = msgb_put(msg, sizeof(*ch)); + ch = (struct abis_rsl_cchan_hdr *) msg->l2h; + rsl_init_cchan_hdr(ch, RSL_MT_SMS_BC_CMD); + ch->c.msg_discr |= ABIS_RSL_MDISC_TRANSP; + ch->chan_nr = l1i->chan_nr; + + cmd_type.command = RSL_CB_CMD_TYPE_NULL; + msgb_tv_put(msg, RSL_IE_CB_CMD_TYPE, *((uint8_t *) &cmd_type)); + msgb_tlv_put(msg, RSL_IE_SMSCB_MSG, 0, NULL); + + gsm_fn2gsmtime(&tm, ntohl(l1i->frame_nr)); + msgb_tv_put(msg, RSL_IE_SMSCB_CHAN_INDICATOR, !(tm.tc < 4)); + + return rslms_sendmsg(msg, se->ms); } int smscb_ph_data_ind(struct smscb_entity *se, struct msgb *msg, struct l1ctl_info_dl *l1i) { - uint8_t addr = msg->l2h[0]; - uint8_t seq = addr & 0x0f; + struct gsm412_block_type *bt = (struct gsm412_block_type *) msg->l2h; + uint8_t seq; + uint8_t last; + + LOGP(DLAPDM, LOGL_NOTICE, "SMSCB: received message: len=%d" + " seq=%d lb=%d lpd=%d spare=%d\n", + msg->len, bt->seq_nr, bt->lb, bt->lpd, bt->spare); + + if (bt->lpd != SMSCB_LPD) { + msgb_free(msg); + return -EINVAL; + } + + msgb_pull(msg, sizeof(*bt)); + + seq = bt->seq_nr & 3; + last = bt->lb; + + if (bt->seq_nr == GSM412_SEQ_NULL_MSG) { + smscb_rx_null_msg(se, l1i); + smscb_reset(se); + msgb_free(msg); + return 0; + } + + if (seq != se->seq_next) { + LOGP(DLAPDM, LOGL_ERROR, "SMSCB: got sequence %d (expected %d)\n", + bt->seq_nr, se->seq_next); + smscb_reset(se); + if (seq) { + msgb_free(msg); + return -EINVAL; + } + } - LOGP(DLAPDM, LOGL_NOTICE, "SMSCB: received message: seq=%d len=%d\n", - seq, msg->len); + switch (bt->seq_nr) { + case GSM412_SEQ_FST_SCHED_BLOCK: + se->sched = 1; + break; + case GSM412_SEQ_FTH_BLOCK: + last = 1; + break; + } - msgb_free(msg); - return 0; + switch (bt->seq_nr) { + case GSM412_SEQ_FST_SCHED_BLOCK: + case GSM412_SEQ_FST_BLOCK: + case GSM412_SEQ_SND_BLOCK: + case GSM412_SEQ_TRD_BLOCK: + case GSM412_SEQ_FTH_BLOCK: + msgb_free(se->blocks[seq]); + se->blocks[seq] = msg; + se->seq_next = seq + 1; + if (!last) + return 0; + smscb_rx_msg(se, l1i); + smscb_reset(se); + return 0; + default: + LOGP(DLAPDM, LOGL_ERROR, "SMSCB: unhandled sequence number %d\n", + bt->seq_nr); + msgb_free(msg); + return -EINVAL; + } } -- 1.7.0.4 From vamposdecampos at gmail.com Sun Nov 28 14:07:29 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Sun, 28 Nov 2010 16:07:29 +0200 Subject: [PATCH 3/3] layer23 cell_log: log CBCH cell info In-Reply-To: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Message-ID: <1290953249-24365-4-git-send-email-vamposdecampos@gmail.com> If System Information contained CBCH channel description, tune to it and log SMSCB messages with a Geographical Scope of Cell Wide (Immediate) -- these are typically used for "Cell Info Display". The CBCH timeout is set to a generous 8 seconds; this is because we need 4 frames for reassembly, we usually miss the first, and we might hit a burst of Null SMSCB messages. Signed-off-by: Alex Badea --- src/host/layer23/src/misc/cell_log.c | 107 +++++++++++++++++++++++++++++++++- 1 files changed, 105 insertions(+), 2 deletions(-) diff --git a/src/host/layer23/src/misc/cell_log.c b/src/host/layer23/src/misc/cell_log.c index e6c5771..37aa271 100644 --- a/src/host/layer23/src/misc/cell_log.c +++ b/src/host/layer23/src/misc/cell_log.c @@ -26,6 +26,7 @@ #include #include #include +#include #include @@ -34,7 +35,9 @@ #include #include #include +#include #include +#include #include #include @@ -49,6 +52,7 @@ #define READ_WAIT 2, 0 #define RACH_MAX 2 #define RACH_WAIT 0, 900000 +#define CBCH_WAIT 8, 0 #define MIN_RXLEV -106 #define MAX_DIST 2000 @@ -57,6 +61,7 @@ enum { SCAN_STATE_SYNC, SCAN_STATE_READ, SCAN_STATE_RACH, + SCAN_STATE_CBCH, }; /* ranges of bands */ @@ -114,6 +119,7 @@ struct rach_ref { static void start_sync(void); static void start_rach(void); +static void start_cbch(void); static void start_pm(void); static void log_gps(void) @@ -227,6 +233,11 @@ static void timeout_cb(void *arg) rach_count++; start_rach(); break; + case SCAN_STATE_CBCH: + LOGP(DRR, LOGL_INFO, "Timeout reading CBCH\n"); + l1ctl_tx_dm_rel_req(ms); + start_sync(); + break; } } @@ -244,6 +255,33 @@ static void start_timer(int sec, int micro) bsc_schedule_timer(&timer, sec, micro); } +static void start_cbch(void) +{ + struct gsm48_sysinfo *s = &sysinfo; + int res; + + if (!s->chan_nr) { + LOGP(DRR, LOGL_DEBUG, "No CBCH description in sysinfo\n"); + res = -1; + } else if (s->h) { + res = l1ctl_tx_dm_est_req_h1(ms, + s->maio, s->hsn, s->hopping, s->hopp_len, + s->chan_nr, s->tsc, + GSM48_CMODE_SIGN); + } else { + res = l1ctl_tx_dm_est_req_h0(ms, s->arfcn, + s->chan_nr, s->tsc, GSM48_CMODE_SIGN); + } + + if (res < 0) { + start_sync(); + return; + } + + state = SCAN_STATE_CBCH; + start_timer(CBCH_WAIT); +} + static void start_rach(void) { struct gsm48_sysinfo *s = &sysinfo; @@ -253,7 +291,7 @@ static void start_rach(void) if (rach_count == RACH_MAX) { log_sysinfo(); - start_sync(); + start_cbch(); return; } @@ -426,7 +464,7 @@ static int ta_result(uint8_t ta) } log_sysinfo(); - start_sync(); + start_cbch(); return 0; } @@ -730,6 +768,66 @@ int chan_conf(struct osmocom_ms *ms, struct msgb *msg) return 0; } +static int sms_cb_cmd(struct osmocom_ms *ms, struct msgb *msg) +{ + struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); + struct tlv_parsed tv; + struct rsl_ie_cb_cmd_type *cmd_type; + struct gsm341_ms_message *cbmsg; + unsigned int cbmsglen; + char buf[256], *p; + + rsl_tlv_parse(&tv, ch->data, msgb_l2len(msg) - sizeof(*ch)); + if (!TLVP_PRESENT(&tv, RSL_IE_SMSCB_MSG) || + !TLVP_PRESENT(&tv, RSL_IE_CB_CMD_TYPE)) { + LOGP(DRR, LOGL_ERROR, "SMS_BC_CMD missing mandatory IEs\n"); + return -EINVAL; + } + + cmd_type = (struct rsl_ie_cb_cmd_type *) TLVP_VAL(&tv, RSL_IE_CB_CMD_TYPE); + cbmsg = (struct gsm341_ms_message *) TLVP_VAL(&tv, RSL_IE_SMSCB_MSG); + cbmsglen = TLVP_LEN(&tv, RSL_IE_SMSCB_MSG); + if (cbmsglen < sizeof(*cbmsg)) { + LOGP(DRR, LOGL_ERROR, "RSL_IE_SMSCB_MSG too short\n"); + return -EINVAL; + } + + if (cmd_type->command != RSL_CB_CMD_TYPE_NORMAL) + return 0; + if (cbmsg->serial.gs != GSM341_GS_CELL_WIDE_IMMED) + return 0; + + gsm_7bit_decode(buf, cbmsg->data, cbmsglen - sizeof(*cbmsg)); + if ((p = strchr(buf, '\r'))) + *p = 0; + + LOGP(DSUM, LOGL_INFO, "Cell info: code=%d update=%d id=%d text=\"%s\"\n", + cbmsg->serial.code_lo | (cbmsg->serial.code_hi << 6), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + buf); + + LOGFILE("[cbch]\n"); + LOGFILE("arfcn %d\n", sysinfo.arfcn); + LOGFILE("gs %d code %d update %d msg_id %d page %d numpages %d\n", + cbmsg->serial.gs, + cbmsg->serial.code_lo | (cbmsg->serial.code_hi << 6), + cbmsg->serial.update, + ntohs(cbmsg->msg_id), + cbmsg->page.current, cbmsg->page.total); + LOGFILE("text \"%s\"\n", buf); + LOGFILE("\n"); + LOGFLUSH(); + + l1ctl_tx_dm_rel_req(ms); + stop_timer(); + + start_sync(); + + return 0; + +} + static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) { struct abis_rsl_cchan_hdr *ch = msgb_l2(msg); @@ -744,6 +842,11 @@ static int rcv_cch(struct osmocom_ms *ms, struct msgb *msg) msgb_free(msg); return rc; } + if (state == SCAN_STATE_CBCH && msg_type == RSL_MT_SMS_BC_CMD) { + rc = sms_cb_cmd(ms, msg); + msgb_free(msg); + return rc; + } LOGP(DRSL, LOGL_NOTICE, "RSLms message unhandled\n"); msgb_free(msg); -- 1.7.0.4 From vamposdecampos at gmail.com Mon Nov 29 07:53:45 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Mon, 29 Nov 2010 09:53:45 +0200 Subject: [PATCH 3/3] layer23 cell_log: log CBCH cell info In-Reply-To: <1290953249-24365-4-git-send-email-vamposdecampos@gmail.com> References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> <1290953249-24365-4-git-send-email-vamposdecampos@gmail.com> Message-ID: On Sun, Nov 28, 2010 at 4:07 PM, Alex Badea wrote: > If System Information contained CBCH channel description, > tune to it and log SMSCB messages with a Geographical Scope > of Cell Wide (Immediate) -- these are typically used for > "Cell Info Display". Please don't apply this patch until we teach L1 that CBCH is downlink-only. Thanks to Sylvain for pointing this out. Cheers, Alex From 246tnt at gmail.com Sun Nov 28 20:53:58 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 28 Nov 2010 21:53:58 +0100 Subject: [PATCH 0/3] layer23 SMSCB support In-Reply-To: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Message-ID: Hi, > This patch series adds layer23 support for receiving SMSCB messages. > > Patches 1/3 and 2/3 add common layer2 code for reassembling blocks and > sending them up to L3. Patch 3/3 is an addition to cell_log for logging > cell-info-display-type SMSCB messages, if available. > Small warning to everyone Don't use those (or the cbch_sniff app) with a firmware that has TX enabled ... Cheers, Sylvain From vamposdecampos at gmail.com Mon Nov 29 07:51:57 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Mon, 29 Nov 2010 09:51:57 +0200 Subject: [PATCH 0/3] layer23 SMSCB support In-Reply-To: References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Message-ID: On Sun, Nov 28, 2010 at 10:53 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > >> This patch series adds layer23 support for receiving SMSCB messages. >> >> Patches 1/3 and 2/3 add common layer2 code for reassembling blocks and >> sending them up to L3. ?Patch 3/3 is an addition to cell_log for logging >> cell-info-display-type SMSCB messages, if available. >> > > Small warning to everyone > > Don't use those (or the cbch_sniff app) with a firmware that has TX enabled ... I have Tx disabled anyway, but it didn't hit me until you said it out loud. Dedicated-mode SDCCH also has uplink slots, doesn't it? To make this work I guess we need to implement some separate CBCH mode in L1. In which case, I suppose it should be possible to continue receiving CCCH at the same time? Thanks, Alex From 246tnt at gmail.com Mon Nov 29 08:09:34 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 29 Nov 2010 09:09:34 +0100 Subject: [PATCH 0/3] layer23 SMSCB support In-Reply-To: References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Message-ID: Hi, > I have Tx disabled anyway, but it didn't hit me until you said it out loud. > Dedicated-mode SDCCH also has uplink slots, doesn't it? Yes. And it also has SACCH slots that the CBCH doesn't have. > To make this work I guess we need to implement some separate CBCH mode in > L1. Yup. It seems that CBCH never have subslots ? (Looking at GSM 05.02 Clause 7 Table 3 of 9). If it says SDCCH4 it's always B32..B35 (like a SDCCH4 subslot 2) If it says SDCCH8 it's always B8..B11 (like a SDCCH8 subslot 2) I'll look into adding a command to support going to that channel along with the appropriate scheduling. > In which case, I suppose it should be possible to continue receiving CCCH > at the same time? No, we can only get data from 1 timeslot in each frame, so if it's in a SDCCH8 there can be conflicts. (If it's in SDCCH/4 then that should be OK) We'll probably be able to do that only when we get to DRX (where we only listen to specific slots). Cheers, Sylvain From vamposdecampos at gmail.com Mon Nov 29 09:06:26 2010 From: vamposdecampos at gmail.com (Alex Badea) Date: Mon, 29 Nov 2010 11:06:26 +0200 Subject: [PATCH 0/3] layer23 SMSCB support In-Reply-To: References: <1290953249-24365-1-git-send-email-vamposdecampos@gmail.com> Message-ID: On Mon, Nov 29, 2010 at 10:09 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > It seems that CBCH never have subslots ? (Looking at GSM 05.02 Clause > 7 Table 3 of 9). > > If it says SDCCH4 it's always B32..B35 (like a SDCCH4 subslot 2) > If it says SDCCH8 it's always B8..B11 (like a SDCCH8 subslot 2) Looks like it. In subclause 6.4.1 it says: > Where the SMSCB is supported, the CBCH replaces SDCCH number 2 in cases v) and vii) above. ... where v) and vii) are: > v) FCCH + SCH + BCCH + CCCH + SDCCH/4(0..3) + SACCH/C4(0..3) > vii) SDCCH/8(0 .7) + SACCH/C8(0 . 7) I've only seen SDCCH8-type CBCH live in my area, though. > I'll look into adding a command to support going to that channel along > with the appropriate scheduling. Thanks! Alex From ton.slewe at gmail.com Sun Nov 28 22:09:59 2010 From: ton.slewe at gmail.com (Ton Slewe) Date: Sun, 28 Nov 2010 23:09:59 +0100 Subject: bb-osmocom: sim.c Message-ID: <4CF2D337.6010504@gmail.com> I have trying the osmocom apps today (firmware). One of the apps, simtest, did not seem to work well. I have tracked down the error to sim.c. I tried to push it to the GIT repository which does not seem to work (credentials?). Maybe somebody can patch it in their version and then push it. Or otherwise please point me in the direction to get it fixed in the repository. Some of the variables on top of the file are not declared as volatile (they should be because they are modified in an Interrupt Service Routine). I changed all the variables on top of the file into volatile: static volatile int sim_rx_character_count = 0; /* How many bytes have been received by calypso_sim_receive() */ static volatile int sim_tx_character_count = 0; /* How many bytes have been transmitted by calypso_sim_transmit() */ static volatile int sim_tx_character_length = 0; /* How many bytes have to be transmitted by calypso_sim_transmit() */ static volatile uint8_t *rx_buffer = 0; /* RX-Buffer that is issued by calypso_sim_receive() */ static volatile uint8_t *tx_buffer = 0; /* TX-Buffer that is issued by calypso_sim_transmit() */ Now simtest is working as expected. Kind regards, Ton From holger at freyther.de Mon Nov 29 10:38:53 2010 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 29 Nov 2010 11:38:53 +0100 Subject: bb-osmocom: sim.c In-Reply-To: <4CF2D337.6010504@gmail.com> References: <4CF2D337.6010504@gmail.com> Message-ID: <4CF382BD.9080302@freyther.de> On 11/28/2010 11:09 PM, Ton Slewe wrote: > I have trying the osmocom apps today (firmware). One of the apps, > simtest, did not seem to work well. > > I have tracked down the error to sim.c. I tried to push it to the GIT > repository which does not seem to work (credentials?). Maybe somebody > can patch it in their version and then push it. Or otherwise please > point me in the direction to get it fixed in the repository. You can use git format-patch and send us the patch you did. Some of us can then apply and push it to the repository. regards holger From spaar at mirider.augusta.de Mon Nov 29 12:22:35 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Mon, 29 Nov 2010 12:22:35 Subject: bb-osmocom: sim.c Message-ID: <4cf39b0b.mirider@mirider.augusta.de> Hello Ton, On Sun, 28 Nov 2010 23:09:59 +0100, "Ton Slewe" wrote: > > I have tracked down the error to sim.c. I tried to push it to the GIT > repository which does not seem to work (credentials?). Maybe somebody > can patch it in their version and then push it. Or otherwise please > point me in the direction to get it fixed in the repository. You have take the version from Sylvain's testing branch (Sylvain, please correct me if the extended SIM driver is no longer there) ? I ask because there is already a fixed version with several improvments which is supposed to work in this branch (at least for those SIM task required to access a real network). Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From ton at slewe.com Mon Nov 29 22:05:41 2010 From: ton at slewe.com (Ton Slewe) Date: Mon, 29 Nov 2010 23:05:41 +0100 Subject: bb-osmocom: sim.c In-Reply-To: <4cf39b0b.mirider@mirider.augusta.de> References: <4cf39b0b.mirider@mirider.augusta.de> Message-ID: 2010/11/29 Dieter Spaar > Hello Ton, > > On Sun, 28 Nov 2010 23:09:59 +0100, "Ton Slewe" > wrote: > > > > I have tracked down the error to sim.c. I tried to push it to the GIT > > repository which does not seem to work (credentials?). Maybe somebody > > can patch it in their version and then push it. Or otherwise please > > point me in the direction to get it fixed in the repository. > > You have take the version from Sylvain's testing branch (Sylvain, please > correct me if the extended SIM driver is no longer there) ? > > I ask because there is already a fixed version with several improvments > which is supposed to work in this branch (at least for those SIM task > required to access a real network). > > Best regards, > Dieter > -- > Dieter Spaar, Germany spaar at mirider.augusta.de > > Attached is the git patch file with the 'volatile' corrections (and added some conditional debugging statements). The patch is derived from the source code in git:// git.osmocom.org/osmocom-bb.git. I did not see a reaction from Sylvain yet, so I am not sure this patch is still needed. * * Kind regards, Ton -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-volatile-to-the-global-vars-that-are-written-i.patch Type: text/x-patch Size: 3207 bytes Desc: not available URL: From 246tnt at gmail.com Tue Nov 30 09:01:00 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 30 Nov 2010 10:01:00 +0100 Subject: bb-osmocom: sim.c In-Reply-To: <4cf39b0b.mirider@mirider.augusta.de> References: <4cf39b0b.mirider@mirider.augusta.de> Message-ID: > You have take the version from Sylvain's testing branch (Sylvain, please > correct me if the extended SIM driver is no longer there) ? You're right. The new SIM code is only in sylvain/testing for now. So no point in trying to use/patch the SIM code in master. Cheers, Sylvain