December 2011 - baseband-devel

Engagetted !

by Sébastien Lorquet

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

6 months, 1 week

5
5
0 0

Please can anyone advise me - FMTOOL Error and no further processing

by Raz Sharif

Dear all, I vae the C115 with a T1 USB to Serial cable with the Prolific chipset. When i run osmocon i get :- an its just sits there with no further processing. ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin read_file(../../target/firmware/board/compal_e88/loader.compalram.bin): file_size=17120, hdr_len=4, dnload_len=17127 read_file(../../target/firmware/board/compal_e88/loader.compalram.bin): file_size=17120, hdr_len=4, dnload_len=17127 got 1 bytes from modem, data looks like: 00 . got 2 bytes from modem, data looks like: 2f 00 /. got 1 bytes from modem, data looks like: 1b . got 3 bytes from modem, data looks like: f6 02 00 ... got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD got 1 bytes from modem, data looks like: 66 f got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6d m got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6c l Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . I think the cable is ok as when i run my fingers on the tip i get random Zeros so it appears to be talking to the cable. Also when i tried to run Mobile i get the :- even though i created the Mobile.cfg file in /etc/osmoco Failed to parse the config file: '/home/raz/.osmocom/bb/mobile.cfg' Please check or create config file using: 'touch /home/raz/.osmocom/bb/mobile.cfg' I have spent some hours researching the lists and trying various things to no avail but I want to continue until I resolve this issues and use this great stack to learn about the GSM network. Please advise. Great full for any help or pointers but this maybe a timing issue that is difficult to debug. Thanks Raz

7 years, 11 months

5
6
0 0

cell re-selection

by Andreas.Eversberg

hi, i did a lot of resarch and testing on cell selection and re-selection process the last two week. the cell selection process, network selection process (manual and automatic) and mobility management process were already implemented in OsmocomBB a long time, but turned out to be buggy and incomplete. i made test drives to check the process and debugged it. the re-selection process is new. it is used to track surrounding cells while listening to the BCCH of the current cell (camping on a cell). special extension to the layer1 firmare is used to measure neighbour cells. if an neighbour cell becomes 'better', the mobile switches to that cell, depening on different criteria. now it is possible to move with OsmocomBB. the re-selection process is not handover! handover is a process where a phone switches between cells while doing a call. handover is one next step to implement. the process is a little more complex, because it requires not only neighbour cell measurements, but also syncing to them without interrupting the traffic channel. most layer 3 stuff of handover is already implemented. if you like to play and test your moving OsmocomBB, you can check out the "jolly/roaming" branch. it contains the extension to layer1, as well as sim reader and fixes from "sylvain/testing" branch. use both "mobile" and "layer1" firmware from this branch. in order to see some process at VTY, you can do: enable monitor network 1 (continously display the strongest cell and neighbour cells) show ms 1 (to see current states) show neighbour-cells 1 (to see a more detailed current list of neighbours) andreas

8 years, 1 month

3
3
0 0

AW: The call has been rejected

by Andreas.Eversberg

hi josephli, > Read stored BA list mnc=01 the mobile application stores the last cells and neighbour cells (band allocation) of each network. this way the scanning is much faster when restarting. because you use the SIM card with MNC == 02 the first time, there is no band allocation stored for that. the mobile will do a full scan in this case. > while the sim card service I am tesing is actually with mnc 00 and 02. i know that MNC == 0 will not work until i commited improvements of cell selection process last sunday. you should retry that, but first try with an MNC > 0. can you provide debug output when trying a call? also can you provide VTY output of "show ms" before you make the call? regards, andreas

11 years

3
2
0 0

status report layer1 and layer23

by Andreas.Eversberg

hi, i just fixed some locking issues the last days. fix will follow. it took a bit longer, because there were some race conditions. it took up to about one hour until it crashed. my way to detect the area where the crash happened, was to turn on buzzer before that area, and turn it off after that area. after many hours of approximation, i finally found out that the major crash happend during _talloc_zero. (first it looks for a free memory chunk, then it allocates it.) since it can be called from all contexts (main, irq, fiq), it need to be locked against any interrupt, otherwise the memory chunk can be assigned multiple times. (the process of _talloc_free is "atomic" and requires no locking.) because it seems pretty stable, i think it is time to merge some branches into the master. (i made a 6 hours call yesterday. and no crash after bugfix ever since.) i will do that together with sylvain, if we find the time this weekend. currently i use the jolly/voice together with the sylvain/traffic branch. i am able to use an isdn phone togehter with linux-call-router and make/receive calls. audio is passed both ways. i think this is a stage where it actually become "usable". (if not moving arround.) one of my major work for the next weeks/months will be the neighbour cell measurement, cell re-selection, and handover. this is essential when moving with the phone. regards, andreas

11 years

2
1
0 0

cp2102 (betemcu, B75937)

by lonelysurfer

...a never ending story: i have a working ftdi-ttl, but the cp2102-adapters (http://www.ebay.de/itm/USB-2-0-to-UART-TTL-6PIN-Module-Serial-Converter-CP2…) with the same cable dont work under ubuntu or windows. if i rub the top of the 2.55mm with my finger random data appears. but the loader doesnt upload the firmware. i used the txd, rxd and gnd pins and checked the connections with a multimeter. i tested -m c123xor, -m c123 and the default firmware. flashing custom baudrates was no problem. rivers are installed correctly (stady ttyusb0 under ubuntu/ com1 under win). is there any hint? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/cp2102-betemcu-B75937-tp3489336p… Sent from the baseband-devel mailing list archive at Nabble.com.

11 years, 8 months

3
4
0 0

Receiving on TS=1 ?

by Sylvain Munaut

Hi, I've hacked something together to quickly test non-combined CCCH. However, I've hit a problem when trying to receive anything on another timeslot than 0. The TX side seems to work fine as the BTS can see my location update request and answers with a reject, but on the MS side, I never see the reject and wireshark only shows invalid incohrent data on the RX. The frames for SDCCH/8 show really nothing valid (looks like random bytes), things like 09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36 ... while the frames for the associated SAACH show at least something gsm-like : 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b but that's not quite a SI5/6 ... To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 * 156.25) when I'm in dedicated channel mode by chaning the 'start' in l1s_tx_win_ctrl / l1s_rx_win_ctrl Is there something else that should be done ? Cheers, Sylvain

11 years, 9 months

2
5
0 0

burst_ind and TCH

by Mad

Hi Sylvain, hi list! I'm experimenting with burst_ind and TCHs right now and ran into some problem I couldn't solve yet. After receiving an Assignment Command for a hopping TCH/F I call l1ctl_tx_dm_est_req_h1() with all necessary parameters and tch_mode GSM48_CMODE_SPEECH_V1 or _EFR. After that I do get burst indications containing the received bits on up- and downlink for the active arfcn on each consecutive frame number. BUT the rx level measurements are most of the time very low and sporadic higher, surely not from that nearby bts and the very close cellphone. It looks like the layer1 doesn't "hit" the right timeslot on the right arfcn at the right time. There are some possible sources of error leading to that, like hopping parameters, channel number and MA list. But I checked these and I took all of them directly from the ASS CMD, the MA as word list in ascending order, like in layer23 IMM ASS handling. The specific AC doesn't have any specialties like Starting Time or "before time" parameters. So my question is if there is some obvious pitfall I'm missing and are there any suggestions how to debug that? Regards, Mad

11 years, 9 months

4
5
0 0

bursts****.dat

by Victor P

Hi, I am trying to use burst_ind branch of osmocom. I have noticed that layer23 creates bursts****.dat files when it indicates uplink. What data are written to these files and what should I use to see its data? Thank you.

11 years, 10 months

5
6
0 0

Use OsmocomBB as OpenBTS / airprobe clock generator

by Harald Welte

Hi! Recently we've had the idea of using OsmocomBB with a simple firmware that synchronizes to an existing GSM networks FCCH and use the resulting 13MHz clock to drive the USRP for airprobe or OpenBTS. Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to multiply it up to the required 52 MHz. However, neither the Openmoko nor the Compal/Motorola phones expose any of the 3 clock output pads :( So the only choice is to use something along the lines of the http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html as a quad clock multiplier and attach it to the CLK13OUT signal of the phone. The chip is available for 9 USD in single quantities at digikey, and possibly cheaper at other sources. Combined with a sub-20EUR phone it might be a very cheap but still accurate frequency source for OpenBTS - at least as long as there are any commercial gsm networks available. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 1 month

8
17
0 0

osmocombb and usrp

by Paul Lambert

Hello, I have a ursp1 working fine and I want to use my c123 to conenct to it with osmocombb. Now I face some problems. First of all I have no sim, so I do: sim testcard 1 001 01 The usrp runs a testnetwork (001 01) I don't know how I can associate with the usrp. I tried: network search (lot of output and also my testnet) network show (nothing happens) network select 1 001 01: Network not in list! Any idea what I'm doing wrong? Would be really Cool if i could use opensource only. With best regards, Paul

12 years, 2 months

3
3
0 0

Creating a real usable phone using OsmocomBB

by Harald Welte

Hi all! I've mentioned this before, and I keep getting back to it: With all the great work that has been put into OsmocomBB, we are "at an arms lengh" away from being able to create a true Free Software mobile phone. We already have the hardware drivers, protocol stack and even the 'mobile' program which can be used for making and receiving voice calls and sending/receiving SMS text messages on real GSM networks! While the journey has been a lot of fun and everyone involved has learned a lot, we have so far been catering mstly about "scratching our own itch", i.e. implementing what we needed in order to satisfy our ego and/or to implement the ideas we had regarding cellular security. I believe we cannot miss the bigger opportunity here to put our code into bigger use: To create something like a very simple GSM feature phone. When we look at various areas of computing like Operating Systems or Web browsers, Free Software is not just "the hobby project catching up" with the vendors of proprietary software. Free Software can compete. In the cellular area, we have still not managed to even implement the most basic GSM feature phone that existed 15 years ago using proprietary software. We need to work on closing that gap. We need to show that a small community of Free Software developers can actually implement what teams of hundreds of engineers did in a proprietary software setting 15 years ago - despite all the lack of hardware documentation or any kind of positive feedback from the cellular chipset, handset or operator industry. If we don't at least get a 2G GSM cellphone implemented now, it will probably not happen before 2G networks become insignificant in large parts of the world. This is a call to all hands, please support this project! Regards, Harald == Technical aspects == I believe the first major decision is whether we focus on 1) the Openmoko FreeRunner / Neo1973 phones Advantages: * large screen for UI with bells and whistles * lots of RAM and Flash, even script languages or compilation on the device itself possible * second processor doesn't require us to run stack + UI on once CPU * easier debugging of UI * various existing telephony middleware and phone dialer UI projects of which hopefully one could be recycled or 2) the Motorola/Compal C1xx phones Advantags: * many more phones available, even after our software is released * lower cost of the individual phone * less power consumption due to only one small ARM7 core * smaller screen also means less fancy UI requirements Problems: * full stack + UI needs to run on calypso (L2/L3) and we'd probably some kind of RTOS like NuttX instead of our 'bare iron' code. ==== What we need in any case ==== * power management on the baseband processor through all of the stack (though it's mostly a driver/L1 kind of thing) == Summary / Opinion == It seems like running the OsmocomBB layer1 + 'mobile' as-is on the Openmoko baseband + application processor might be the quicker road to progress. Sure, the power consumption will be horrible as the AP will have to be woken up for each and every SI message, neighbor cell measurment or paging request that ew see comining in in our paging group (even in idle mode). But then, there is always the negative impact of using a relatively complex system, with two processors, a complex software stack (Linux, X11, toolkit, etc.) on one of them, etc. On the other hand, using the C1xx phones will result in a much more widely available result. The phones can still be bought in batches of 1,000 units, and they are small enough for lots of people to carry around. Furthermore, the battery lifetime is far beyond anything you would ever be able to achieve on a power-hungry smartphone platform. I believe it would be the "smart' solution, as it means we need to get everything integrated, etc. What does the community on this list think? Which way shoul we go? But maybe the best thing is to actually stat working on the power management aspects, as we will need them in both cases. Happy hacking, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 3 months

14
27
0 0

Linux + u-boot port to MT6235

by Marcin Mielczarczyk

Hi All! That's true, I managed to run U-Boot on MT6235, but linux kernel is not fully functional yet (it's fresh stuff as I managed to ran it on Tuesday and then I was off to conference). For MT6235 development I chose Sciphone G2, which is pretty cheap. After some time I managed to download code to SRAM (just 64KB) using MTK's FlashTool. MTK FlashTool communicates over UART directly with MT6235 bootloader and sends its own chunk of code (about 58KB) which is executed in SRAM and communicates with FlashTool. I found on pudn.com some pack to customize code loaded by FlashTool, thanks to which I could download my own code to SRAM (without JTAG). The problem was that it had to be linked with some security libraries which occupied about 56KB and not much memory left for my own code. Then I decided to try find JTAG pins to get all control on MT6235. That took me sometime, but finally I succeeded. The other bigger issue was initializing DRAM controller to be able to download bigger code (linux kernel + uboot) to external RAM. In sciphone there is problem that all interesting chips are under metal shield which is pretty havily soldered. In this case I couldn't read what kind of RAM memory is mounted without destroying the board (I don't have such soldering machine which could unsolder so big metal shield). Thanks to JTAG I could attach to target and then dump DRAM controller registers from processor running MTK's software, but setting these values after processor start and configuration of PLL didn't work. I decided to disassemble bootloader which could show me how DRAM controller is initialized and how code fron NAND is loaded (to be able to flash U-Boot and kernel to NAND so MT6235 will start my code automatically and I will not have to use JTAG). Currently I have knowledge how internal MT6235 bootloader is loading code from memory during startup and I also extracted procedure of DRAM controller initialization. Thanks to that I'm able to run U-Boot from the very begining of processor startup. The problem is that I have just one piece of Sciphone G2 and I don't want to flash it yet to not break existing code in it. Thanks to running device I'm able to attach with JTAG and check how peripherals are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm not 100% sure if I will flash it back, phone will startup. That's why I bought second piece of Sciphone G2 and should receive it today or on Tuesday (this Monday is holiday in Poland). In this case I'll flash U-Boot to NAND and try to make it working. Then we could load the rest of code from U-Boot (to RAM or NAND over serial). You can see how my setup looks on attached picture. The good thing about it is that the same bootloader is used in MT622x, so it should be fairly easy to do the same on phones based on that SoCs (but unfortuantely it's just ARM7). If it comes to code, of course I can share it on "git.osmocom.org". Currently it's just basic port of U-Boot and not much for linux kernel, but I'm working on this now so I'll push it when it'll be ready. Currently I'm working on driver for NAND memory for U-Boot, so we could flash linux kernel. When that will be ready I'll push the code. Then I'll switch to linux kernel and when it'll be functional I also push the code. At this stage you will not need to have JTAG and you could load the code over serial in U-Boot. If it comes to GSM I didn't work with it before. I actualy worked 6 months in L2/3 team for LTE (on RRC) but it's different story. That could be really outstanding thing if we could run first phone ever with whole code open (from BB up to APP). BR, Marcin

12 years, 3 months

13
37
0 0

Newbie DSP Questions

by Avner Ezra

Hi I'm newbie in DSP and SDR, but I'm really interested in this matter and I want to learn. I have bunch of questions which has short answers, if you can please answer them in easy terms and words, so I can understand them well. I hope this thread will help a lot of other newbies to understand DSP stuff better. I have a Linux with every needed tools like osmocomm, gnuradio, openbts, kalibrate, uhd drivers, ... and USRP N210 hardware ready. Everything works normal and well. A) Sometimes when I scan a network bandwidth like GSM1800 using kalibrate, I see some channels like 820, 538, etc. When I re-scan, I cannot find them. Does this mean that kalibrate finds a channel when a mobile handset has a live conversation or sms send or receive in progress? or what? B) I want to wideband capture for example 125 ARFCN. It needs 25MHz bandwidth which USRP N210 can handle and stream it easily. Even AFAIK I can double this number and capture 250 ARFCN using single N210 (50MHz, in USRPN210 data sheet it says it's capable of streaming 50MHz wide signals). How can I wideband capture 125 ARFCNs? I tried to do it using: ./uhd_rx_cfile.py -f `arfcncalc -a 512 -b 1800 -d` --samp-rate=25000000 -N 200000000 -g 70 b1.cfile What I understood and decided to write such command above: B-1) arfcncalc calculates frequency of first GSM1800 channel (512 ARFCN) which is start point (in above command) B-2) Sampling Rate is the bandwidth I want to capture, in our case it's 25MHz means 125 ARFCN which each ARFCN has 200kHz bandwidth B-3) 200M samples will be received (-N parameter) B-4) Gain value is 70, means it will boost antennas to maximum power to receive signals, I think USRPN210 max. gain is 80 B-5) My decimation rate here using 25M sampling rate and USRP N210 which has 100MHz ADC, will be 4. So if I decided to read cfile I have to use 4 as decimation rate. Please explain and tell me if I'm correct or wrong about above statements. Does this will work and I'll have a 125 ARFCN from 512 to 637 ARFCNs captures into b1.cfile? If so why in http://gnuradio.org/doc/doxygen-3.4/classusrp__source__base.html#adf8529d74… documentation, it says set_rx_freq should set center of frequency, so for example if you want to capture from 512 to 637, you should set frequency to frequency of ARFCN 574? C) How can I seperate and process 200khz by 200khz channels in wideband captured file? Thank you so much for your time Your help and answers will solve problem of a lot of newbies like me. Best Wishes

12 years, 3 months

4
4
0 0

R: GPRS decode tutorial

by Luca Bongiorni

Hi Dario, i suggest you to download the last Sylvain's burst_ind, because is improved of some features and patch it manually with Nohl's patch. Then you will be able to dump the bursts using ccch_scan, instead of layer23. Cheers, Luca > Can someone drive me to the right direction? P.S: http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/1754

12 years, 3 months

3
2
0 0

Compiling failure with Ubuntu 11.10 64 bits

by Eric Tyberghien

Hi all I'm using Ubuntu 11.10 64 bits and I try to compile osmocom-bb but it fails due to the enable-linker-buid-id option not supported by the ld linker Here is the make : root@erict-G5360fr-m:/home/erict/Téléchargements/osmocom-bb/src# make cd shared/libosmocore/build-target && ../configure \ --host=arm-elf --enable-embedded --disable-shared \ --disable-tests ac_cv_header_sys_select_h=no \ --disable-tests ac_cv_header_sys_socket_h=no \ CFLAGS="-Os -ffunction-sections -I/home/erict/Téléchargements/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs" 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-strip... arm-elf-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-gcc... arm-elf-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-elf-gcc accepts -g... yes checking for arm-elf-gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of arm-elf-gcc... gcc3 checking build system type... x86_64-unknown-linux-gnu checking host system type... arm-unknown-elf checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by arm-elf-gcc... /root/install/gnuarm-4.0.2/arm-elf/bin/ld checking if the linker (/root/install/gnuarm-4.0.2/arm-elf/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /root/install/gnuarm-4.0.2/bin/arm-elf-nm -B checking the name lister (/root/install/gnuarm-4.0.2/bin/arm-elf-nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 3458764513820540925 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking how to convert x86_64-unknown-linux-gnu file names to arm-unknown-elf format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /root/install/gnuarm-4.0.2/arm-elf/bin/ld option to reload object files... -r checking for arm-elf-objdump... arm-elf-objdump checking how to recognize dependent libraries... unknown checking for arm-elf-dlltool... no checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for arm-elf-ar... arm-elf-ar checking for archiver @FILE support... no checking for arm-elf-strip... (cached) arm-elf-strip checking for arm-elf-ranlib... arm-elf-ranlib checking command to parse /root/install/gnuarm-4.0.2/bin/arm-elf-nm -B output from arm-elf-gcc object... ok checking for sysroot... no checking for arm-elf-mt... no checking for mt... mt configure: WARNING: using cross tools not prefixed with host triplet checking if mt is a manifest tool... no checking how to run the C preprocessor... arm-elf-gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... no checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... no checking for objdir... .libs checking if arm-elf-gcc supports -fno-rtti -fno-exceptions... no checking for arm-elf-gcc option to produce PIC... -fPIC -DPIC checking if arm-elf-gcc PIC flag -fPIC -DPIC works... yes checking if arm-elf-gcc static flag -static works... yes checking if arm-elf-gcc supports -c -o file.o... yes checking if arm-elf-gcc supports -c -o file.o... (cached) yes checking whether the arm-elf-gcc linker (/root/install/gnuarm-4.0.2/arm-elf/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes checking for ANSI C header files... (cached) yes checking execinfo.h usability... no checking execinfo.h presence... no checking for execinfo.h... no checking for sys/select.h... (cached) no checking for sys/socket.h... (cached) no checking syslog.h usability... no checking syslog.h presence... no checking for syslog.h... no checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking for size_t... yes checking for working alloca.h... yes checking for alloca... yes checking for library containing dlopen... no checking for doxygen... false checking if arm-elf-gcc supports -fvisibility=hidden... yes configure: creating ./config.status config.status: creating libosmocore.pc config.status: creating libosmocodec.pc config.status: creating libosmovty.pc config.status: creating libosmogsm.pc config.status: creating include/osmocom/Makefile config.status: creating include/osmocom/vty/Makefile config.status: creating include/osmocom/codec/Makefile config.status: creating include/osmocom/crypt/Makefile config.status: creating include/osmocom/gsm/Makefile config.status: creating include/osmocom/gsm/protocol/Makefile config.status: creating include/osmocom/core/Makefile config.status: creating include/Makefile config.status: creating src/Makefile config.status: creating src/vty/Makefile config.status: creating src/codec/Makefile config.status: creating src/gsm/Makefile config.status: creating tests/Makefile config.status: creating tests/timer/Makefile config.status: creating tests/sms/Makefile config.status: creating tests/msgfile/Makefile config.status: creating tests/ussd/Makefile config.status: creating tests/smscb/Makefile config.status: creating tests/bits/Makefile config.status: creating utils/Makefile config.status: creating Doxyfile.core config.status: creating Doxyfile.gsm config.status: creating Doxyfile.vty config.status: creating Doxyfile.codec config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands cd shared/libosmocore/build-target && make make[1]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target » make all-recursive make[2]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target » Making all in include make[3]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude » Making all in osmocom make[4]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom » Making all in codec make[5]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/codec » make[5]: Rien à faire pour « all ». make[5]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/codec » Making all in crypt make[5]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/crypt » make[5]: Rien à faire pour « all ». make[5]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/crypt » Making all in gsm make[5]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/gsm » Making all in protocol make[6]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/gsm/protocol » make[6]: Rien à faire pour « all ». make[6]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/gsm/protocol » make[6]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/gsm » make[6]: Rien à faire pour « all-am ». make[6]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/gsm » make[5]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/gsm » Making all in core make[5]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/core » make[5]: Rien à faire pour « all ». make[5]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom/core » make[5]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom » make[5]: Rien à faire pour « all-am ». make[5]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom » make[4]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude/osmocom » make[4]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude » make[4]: Rien à faire pour « all-am ». make[4]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude » make[3]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/i nclude » Making all in src make[3]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc » Making all in . make[4]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc » make[4]: Rien à faire pour « all-am ». make[4]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc » Making all in vty make[4]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc/vty » make[4]: Rien à faire pour « all ». make[4]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc/vty » Making all in codec make[4]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc/codec » make[4]: Rien à faire pour « all ». make[4]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc/codec » Making all in gsm make[4]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc/gsm » make[4]: Rien à faire pour « all ». make[4]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc/gsm » make[3]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/s rc » Making all in tests make[3]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/t ests » make[4]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/t ests » make[4]: Rien à faire pour « all-am ». make[4]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/t ests » make[3]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/t ests » Making all in utils make[3]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/u tils » make[3]: Rien à faire pour « all ». make[3]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target/u tils » make[3]: entrant dans le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target » make[3]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target » make[2]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target » make[1]: quittant le répertoire « /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-target » cd shared/libosmocore/build-host && ../configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes 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 gcc... gcc checking whether the C compiler works... no configure: error: in `/home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/build-host': configure: error: C compiler cannot create executables See `config.log' for more details make: *** [sharedroland(a)redhat.com> /libosmocore/build-host/Makefile] Erreur 77 The config.log file is like that root@erict-G5360fr-m:/home/erict/Téléchargements/osmocom-bb/src/shared/libos moco re# cat config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by libosmocore configure UNKNOWN-dirty, which was generated by GNU Autoconf 2.68. Invocation command line was $ ./configure configure -v --with-pkgversion=Ubuntu/Linaro 4.6.1-9ubuntu3 --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --disable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu ## --------- ## ## Platform. ## ## --------- ## hostname = erict-G5360fr-m uname -m = x86_64 uname -r = 3.0.0-14-generic uname -s = Linux uname -v = #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games PATH: /root/install/gnuarm-4.0.2/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2324: checking for a BSD-compatible install configure:2392: result: /usr/bin/install -c configure:2403: checking whether build environment is sane configure:2453: result: yes configure:2594: checking for a thread-safe mkdir -p configure:2633: result: /bin/mkdir -p configure:2646: checking for gawk configure:2662: found /usr/bin/gawk configure:2673: result: gawk configure:2684: checking whether make sets $(MAKE) configure:2706: result: yes configure:2800: checking whether make sets $(MAKE) configure:2822: result: yes configure:2839: checking for x86_64-linux-gnu-gcc configure:2855: found /usr/bin/x86_64-linux-gnu-gcc configure:2866: result: x86_64-linux-gnu-gcc configure:3135: checking for C compiler version configure:3144: x86_64-linux-gnu-gcc --version >&5 x86_64-linux-gnu-gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3155: $? = 0 configure:3144: x86_64-linux-gnu-gcc -v >&5 Using built-in specs. COLLECT_GCC=x86_64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) configure:3155: $? = 0 configure:3144: x86_64-linux-gnu-gcc -V >&5 x86_64-linux-gnu-gcc: error: unrecognized option '-V' x86_64-linux-gnu-gcc: fatal error: no input files compilation terminated. configure:3155: $? = 4 configure:3144: x86_64-linux-gnu-gcc -qversion >&5 x86_64-linux-gnu-gcc: error: unrecognized option '-qversion' x86_64-linux-gnu-gcc: fatal error: no input files compilation terminated. configure:3155: $? = 4 configure:3175: checking whether the C compiler works configure:3197: x86_64-linux-gnu-gcc conftest.c >&5 /usr/local/bin/ld: unrecognized option '--build-id' /usr/local/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status configure:3201: $? = 1 configure:3239: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "libosmocore" | #define PACKAGE_TARNAME "libosmocore" | #define PACKAGE_VERSION "UNKNOWN-dirty" | #define PACKAGE_STRING "libosmocore UNKNOWN-dirty" | #define PACKAGE_BUGREPORT "openbsc-devel(a)lists.openbsc.org" | #define PACKAGE_URL "" | #define PACKAGE "libosmocore" | #define VERSION "UNKNOWN-dirty" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3244: error: in `/home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore': configure:3246: error: C compiler cannot create executables See `config.log' for more details ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_build_alias_set=set ac_cv_env_build_alias_value=x86_64-linux-gnu ac_cv_env_host_alias_set=set ac_cv_env_host_alias_value=x86_64-linux-gnu ac_cv_env_target_alias_set=set ac_cv_env_target_alias_value=x86_64-linux-gnu ac_cv_path_install='/usr/bin/install -c' ac_cv_path_mkdir=/bin/mkdir ac_cv_prog_AWK=gawk ac_cv_prog_CC=x86_64-linux-gnu-gcc ac_cv_prog_make_make_set=yes ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL='${SHELL} /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/missing --run aclocal-1.11' ALLOCA='' AMDEPBACKSLASH='' AMDEP_FALSE='' AMDEP_TRUE='' AMTAR='${SHELL} /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/missing --run tar' AM_BACKSLASH='\' AM_DEFAULT_VERBOSITY='0' AR='' AUTOCONF='${SHELL} /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/missing --run autoconf' AUTOHEADER='${SHELL} /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/missing --run autoheader' AUTOMAKE='${SHELL} /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/missing --run automake-1.11' AWK='gawk' CC='x86_64-linux-gnu-gcc' CCDEPMODE='' CFLAGS='' CPP='' CPPFLAGS='' CYGPATH_W='echo' DEFS='' DEPDIR='' DLLTOOL='' DOXYGEN='' DSYMUTIL='' DUMPBIN='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ENABLE_MSGFILE_FALSE='' ENABLE_MSGFILE_TRUE='' ENABLE_PLUGIN_FALSE='' ENABLE_PLUGIN_TRUE='' ENABLE_SERIAL_FALSE='' ENABLE_SERIAL_TRUE='' ENABLE_TALLOC_FALSE='' ENABLE_TALLOC_TRUE='' ENABLE_TESTS_FALSE='' ENABLE_TESTS_TRUE='' ENABLE_UTILITIES_FALSE='' ENABLE_UTILITIES_TRUE='' ENABLE_VTY_FALSE='' ENABLE_VTY_TRUE='' EXEEXT='' FGREP='' GREP='' HAVE_DOXYGEN_FALSE='' HAVE_DOXYGEN_TRUE='' INSTALL_DATA='${INSTALL} -m 644' INSTALL_PROGRAM='${INSTALL}' INSTALL_SCRIPT='${INSTALL}' INSTALL_STRIP_PROGRAM='$(install_sh) -c -s' LD='' LDFLAGS='' LIBOBJS='' LIBRARY_DL='' LIBS='' LIBTOOL='' LIPO='' LN_S='' LTLIBOBJS='' MAKEINFO='${SHELL} /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/missing --run makeinfo' MANIFEST_TOOL='' MKDIR_P='/bin/mkdir -p' NM='' NMEDIT='' OBJDUMP='' OBJEXT='' OTOOL64='' OTOOL='' PACKAGE='libosmocore' PACKAGE_BUGREPORT='openbsc-devel(a)lists.openbsc.org' PACKAGE_NAME='libosmocore' PACKAGE_STRING='libosmocore UNKNOWN-dirty' PACKAGE_TARNAME='libosmocore' PACKAGE_URL='' PACKAGE_VERSION='UNKNOWN-dirty' PATH_SEPARATOR=':' RANLIB='' SED='' SET_MAKE='' SHELL='/bin/bash' STRIP='' SYMBOL_VISIBILITY='' VERSION='UNKNOWN-dirty' ac_ct_AR='' ac_ct_CC='' ac_ct_DUMPBIN='' am__EXEEXT_FALSE='' am__EXEEXT_TRUE='' am__fastdepCC_FALSE='' am__fastdepCC_TRUE='' am__include='' am__isrc='' am__leading_dot='.' am__quote='' am__tar='${AMTAR} chof - "$$tardir"' am__untar='${AMTAR} xf -' bindir='${exec_prefix}/bin' build='x86_64-linux-gnu' build_alias='x86_64-linux-gnu' build_cpu='' build_os='' build_vendor='' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' host='x86_64-linux-gnu' host_alias='x86_64-linux-gnu' host_cpu='' host_os='' host_vendor='' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' install_sh='${SHELL} /home/erict/Téléchargements/osmocom-bb/src/shared/libosmocore/install-sh' libdir='/usr/lib' libexecdir='/usr/lib' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' mkdir_p='/bin/mkdir -p' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/usr' program_transform_name='s&$$&-4.6&' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='x86_64-linux-gnu' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "libosmocore" #define PACKAGE_TARNAME "libosmocore" #define PACKAGE_VERSION "UNKNOWN-dirty" #define PACKAGE_STRING "libosmocore UNKNOWN-dirty" #define PACKAGE_BUGREPORT "openbsc-devel(a)lists.openbsc.org" #define PACKAGE_URL "" #define PACKAGE "libosmocore" #define VERSION "UNKNOWN-dirty" configure: exit 77 oot@erict-G5360fr-m:/home/erict/Téléchargements/osmocom-bb/src/shared/libosm ocore# Any idea ? Best greetings for the new year Eric

12 years, 3 months

1
0
0 0

Hide extension..

by MArc Richter

Hey! So is it possibel to to hide the sender extension with SMS ? regards Marc

12 years, 3 months

4
5
0 0

Quick Recap of running the 28C3 network

by Holger Hans Peter Freyther

Hi all, just a quick review of things we saw/learned during the congress * OsmocomBB LAPDm and nanoBTS LAPDm appear to have some communication issues leading to timeouts (nanoBTS resends a message with N(R) not incremented as a response to our I frame with Identity Response (or timeout) but with the old data). We don't have a fix/clear understanding of this yet... looks a bit like a bug in the nanoBTS firmware (but then other phones appear to work just fine) * CHANNEL ACTIVATION NACK on a TS. No idea why (maybe we closed a channel with our auto-timer but the nanoBTS thinks it is open). IIRC the nanoBTS sends us a report about open channels, we should cross-check every n-th report with our view of the channels... on top of that we should block failed channels (configurable, still to do). * Open channels... E.g. with a nanoBTS reboot or "drop bts connection ", there was a bug in libosmo-abis that the e1inp_event was not sent as the link was already taken out of the list of sign links when close is called (fixed in libosmo-abis and sharing code between rsl.c and ipaccess.c) * one OML NACK drops all BTS.. The code is there to deal with a crashed BTS to not have it connected in a bad state... (fixed in zecke/28c3) * subscriber queue, thanks to jolly's SMS setup we increased the amount of SMS and there still appear to be paths in the code that do not properly release the transaction/subscr_put and the queue got stuck. We should start by merging jolly's sms rework.. and see how we can move the queue out of process... * Local End Release for SAPI > 0 should be done in the channel release code, we need to implement T3109... thanks to jolly reading GSM 08.58/04.08 with me and discussing the normal/abnormal case. I have some work in progress (only tested the success case) patches in the zecke/28c3 branch. * I uploaded our scripts but somehow the core dumping does not work correctly (core_pattern appears to be right though) for running the network * Purging subscribers from the VLR, we do it too aggressively (on failed paging), it should take the periodic updating timer into account. * Sometimes i miss dates.. e.g. when was the channel opened probably some more things I forgot now, would be a great opportunity if someone gives a hand in cleaning things up. holger PS: jenkins will be back in january, ZFS crashed, the secret key was on the ZFS, grep didn't find the backup script...

12 years, 3 months

1
0
0 0

Re: baseband-devel Digest, Vol 23, Issue 24

by Andres Berroa

Yes, the SIM works on other phones, even on the same phone with the original firmware, so I suspect it's a driver problem. On Tue, Dec 20, 2011 at 7:00 AM, <baseband-devel-request(a)lists.osmocom.org>wrote: > Send baseband-devel mailing list submissions to > baseband-devel(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request(a)lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Re: Fwd: SIM_JOB_RUN_GSM_ALGO fails (Sebastien Lorquet) > > > ---------- Forwarded message ---------- > From: Sebastien Lorquet <sebastien(a)lorquet.fr> > To: baseband-devel(a)lists.osmocom.org > Cc: > Date: Mon, 19 Dec 2011 17:01:53 +0100 > Subject: Re: Fwd: SIM_JOB_RUN_GSM_ALGO fails > Hi, > > SW1SW2 = 0000 let me think that the command was not actually sent to the > card, or the card was mute, or the error is very low level. > > is the failing sim OK in a real phone? > > Regards, > Sebastien > > PS: A very minor point, I don't know how the debug function is supposed to > work, but the "data=" field is not the data, but the whole command. > > Le 19/12/2011 16:36, Ethan Brown a écrit : > > Hello, > > The command SIM_JOB_RUN_GSM_ALGO fails on one of my sim cards. Here is > the log from mobile app: > > <0005> gsm48_mm.c:1637 AUTHENTICATION REQUEST (seq > 0) > > <0005> subscriber.c:957 Generating KEY at > SIM > > <000f> sim.c:209 got new job: SIM_JOB_RUN_GSM_ALGO > (handle=00000006) > > <000f> sim.c:539 RUN GSM > ALGORITHM > > <000f> sim.c:187 sending APDU (class 0xa0, ins 0x88, data=a0 88 00 00 10 > 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56 01 93 ) > <000f> sim.c:877 received APDU (len=0 sw1=0x00 > sw2=0x00) > > <000f> sim.c:953 command > failed > > <000f> sim.c:151 sending result to callback function > (type=1) > > <0005> subscriber.c:991 key generation on SIM failed (cause 2) > > > And this is the log from L1: > > SIM Request (21): a0 88 00 00 10 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56 > 01 93 > Triggering SIM transmission Character underflow!Triggering SIM reception > Max characters received!SIM: ACK does not match request, response[0]=60, > sim_data[1]=88 > SIM Response (2): 00 00 > > > The SIM I used for that test is somewhat different than other SIMs I have > tested and worked before. I attached a picture of two SIMs I used. The > green SIM is the one that fails running SIM_JOB_RUN_GSM_ALGO. The white > one works perfectly. > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel(a)lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > >

12 years, 4 months

2
1
0 0

Fwd: SIM_JOB_RUN_GSM_ALGO fails

by Ethan Brown

Hello, The command SIM_JOB_RUN_GSM_ALGO fails on one of my sim cards. Here is the log from mobile app: <0005> gsm48_mm.c:1637 AUTHENTICATION REQUEST (seq 0) <0005> subscriber.c:957 Generating KEY at SIM <000f> sim.c:209 got new job: SIM_JOB_RUN_GSM_ALGO (handle=00000006) <000f> sim.c:539 RUN GSM ALGORITHM <000f> sim.c:187 sending APDU (class 0xa0, ins 0x88, data=a0 88 00 00 10 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56 01 93 ) <000f> sim.c:877 received APDU (len=0 sw1=0x00 sw2=0x00) <000f> sim.c:953 command failed <000f> sim.c:151 sending result to callback function (type=1) <0005> subscriber.c:991 key generation on SIM failed (cause 2) And this is the log from L1: SIM Request (21): a0 88 00 00 10 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56 01 93 Triggering SIM transmission Character underflow!Triggering SIM reception Max characters received!SIM: ACK does not match request, response[0]=60, sim_data[1]=88 SIM Response (2): 00 00 The SIM I used for that test is somewhat different than other SIMs I have tested and worked before. I attached a picture of two SIMs I used. The green SIM is the one that fails running SIM_JOB_RUN_GSM_ALGO. The white one works perfectly.

12 years, 4 months

2
1
0 0

Re: burst couter in app_cch_scan

by lonelysurfer＠web.de

the tables from your conv_tch_afs.c I thought, that I need them to get the voice. ___________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

12 years, 4 months

1
0
0 0

Re: burst couter in app_cch_scan

by lonelysurfer＠web.de

...ASF-Tables for the different channel codec modes ___________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

12 years, 4 months

2
2
0 0

Re: burst couter in app_cch_scan

by lonelysurfer＠web.de

>It should work for the SACCH and SACCH but will _not_ decode the FACCH You mean the counter should work for SACH and FACCH? I know...other channels are decoded differently. Thats why I am asking. I am trying to implement FACH and hopefully ASF. I used your tch_h_1 mframe task to grab the tch. Best regards, Tobias ___________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

12 years, 4 months

2
1
0 0

burst couter in app_cch_scan

by lonelysurfer＠web.de

is the burst couter in app_cch_scans local_burst_decode() bid = -1; ... if (bid == -1) return; also working for tch? Im asking, because "if (bid == -1)" is not triggered correctly with my tch samples. Regards, Tobias ___________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

12 years, 4 months

2
1
0 0

Please report all known bugs/issues to trac!

by Harald Welte

Hi all! I would like to ask everyone to report known issues with OsmocomBB to the trac at http://bb.osmocom.org/trac/newticket I think there is a lot of knowledge already somwewhere in the project, but it's not readily available. Especially as there is some movement towards creating an actual usable phone, it would be great to have a collection of all known problems in the existing code. Don't worry too much if you don't know the correct component to which to attach the report, we will figure that out. If you don't have a wiki account for bb.osmocom.org, just send me a mail and I will create it. Thanks for your cooperation! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 4 months

1
0
0 0

RFC: Osmocom developer workshop 2012

by Harald Welte

<DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Hi all, this idea has been around for quite some time, and for 2012 I really want to turn it into reality: I'd like to have a Osmocom developer workshop The idea here is to get all the active contributors of the project together for a couple of days (maybe 2-4 days), in order to exchange ideas, get to know each other better and last but not least work together on ironing out some of the more difficult issues. * City: Regarding the location: I think for me it is only possible to organize it if it is to be held in Berlin. I'mn happy if somebody else wants to host it at some other location, but then that person would also have to take care of local organization. Berlin also has good train and flight connections, which is definitely a plus. * Venue: If it is in Berlin, we might consider talking with c-base or Raumfahrtagentur as possible venues. * Date: Regarding a proposed date, I'm completely open for suggestions. Of course there shouldn't be any overlap with other major FOSS or Sescurity related conferences, and it should also not coincide with major public holidays, as that only makes travel + accomodation more expensive. * Funding: As we don't have that many commercial users of Osmocom projects, getting funding for e.g. travel / accomodation is probably going to be difficult. We can ask the "usual suspects" among those commercial users we know,, but I guess it will only be possible in exceptional cases to provide that kind of funding. Any ideas / comments / feedback is much appreciated. If somebody has a particular suggestion. <DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Cheers, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 4 months

2
2
0 0

[PATCH] osmocon: correct parsing of -m

by Alexander Huemer

--- src/host/osmocon/osmocon.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index 5f28992..fc29506 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -123,6 +123,7 @@ enum dnload_mode { MODE_C155, MODE_ROMLOAD, MODE_MTK, + MODE_INVALID, }; struct dnload { @@ -1184,7 +1185,7 @@ static int parse_mode(const char *arg) else if (!strcasecmp(arg, "mtk")) return MODE_MTK; - return -1; + return MODE_INVALID; } #define HELP_TEXT \ @@ -1413,7 +1414,7 @@ int main(int argc, char **argv) break; case 'm': dnload.mode = parse_mode(optarg); - if (dnload.mode < 0) + if (dnload.mode == MODE_INVALID) usage(argv[0]); break; case 's': -- 1.7.8

12 years, 4 months

3
10
0 0

Filter Replacement and sharing experience

by Holger Hans Peter Freyther

Hi all, there appears to be moderate interest in doing the filter rework and I encourage anyone that modified a phone to share the experience with all of us. I have created a simple docbook that uses the pictures uploaded by Luka and annotates them with a "calloutlist". The docbook xml can be found here[1] and the draft PDF is in the wiki as well. It would be nice if all of us could contribute about the motivation of the rework, maybe a bit of history (how the RX path was identified, how new baluns were selected, ...), experience/tools used during the rework, review the draft, note the differences of the various phones. cheers holger [1] http://bb.osmocom.org/trac/attachment/wiki/Hardware/FilterReplacement/userm…

12 years, 4 months

3
5
0 0

About DSP API

by Ethan Brown

Do any of you know where can I find documentation about the DSP API used in Osmocom?

12 years, 4 months

2
10
0 0

Re: Creating a real usable phone using OsmocomBB

by Alexander Chemeris

Harald, interesting information! Do you have a link to those carrier predictions? -- Alexander Chemeris Sent from my Android device. Sorry for my brevity. On Dec 13, 2011 6:19 PM, "Harald Welte" <laforge(a)gnumonks.org> wrote: Hi Alexander, On Tue, Dec 13, 2011 at 04:09:56PM +0300, Alexander Chemeris wrote: > Excuse me for offtopic: I won... it depends on the Operator and where you are. They all only use 2100 MHz for 3G, not the lower 900/1800 MHz bands (which they could do legally after a EU regulation). But yes, indoor coverage can be really bad. For example in my apartment it is difficult to have 3G of all operators, and the one I use mostly (Eplus) barely has 2G coverage here. T-mobile and Vodafone are generally better. It's of course different if you're at major locations like train stations or the big squares downtown... Another note: I've recently seen some operator predictions for Germany, and they assume something like GSM being in operation until 2020 - definitely significantly longer than the life time of their existing GSM licenses (expiring in 2016). This tells us a lot about the installed/deployed user base, as well as the limited 3/3.5/4G coverage.. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ===================...

12 years, 4 months

2
1
0 0

Re: Creating a real usable phone using OsmocomBB

by Alexander Chemeris

Interesting. In Moscow WiMAX quality is very unstable, but 3G/UMTS works pretty well. At least it's much faster then EDGE. Coverage is another topic, but it's not that bad given that 3G is still being rolled out. Having only this experience I expected similar situation in other major cities. Apparently different history and background make their corrections. -- Alexander Chemeris Sent from my Android device. Sorry for my brevity. On Dec 13, 2011 6:47 PM, "Peter Stuge" <peter(a)stuge.se> wrote: Alexander Chemeris wrote: > Excuse me for offtopic: I wonder why there is no 3G in Berlin? This > lo... Sorry - I was unclear. There are networks, but there is not nearly enough capacity for all users. This isn't neccessarily because of inadequate infrastructure, it may just be the best we can do with the shared medium at the cost of what the market is prepared to pay. When a Berlin friend visited Sweden his 3G USB modem LED was suddenly shining with a color he had never seen before. //Peter

12 years, 4 months

1
0
0 0

Re: Creating a real usable phone using OsmocomBB

by Alexander Chemeris

Excuse me for offtopic: I wonder why there is no 3G in Berlin? This looks quite weird. -- Alexander Chemeris Sent from my Android device. Sorry for my brevity. On Dec 13, 2011 4:59 PM, "Peter Stuge" <peter(a)stuge.se> wrote: Harald Welte wrote: > > I'm not sure if there are any modems based on Calypso chipset, but > > even ... Don't be so sure. I've met competent engineers who have very weird issues with their M2M equipment being suddenly unreachable on the network without the modem reporting any error status. > Sierra, Cinterion, Wavecom and others have a well-established market, > and their products do ve... This is also not neccessarily for us to see. I think it's an interesting and relevant parallell track. There's no reason *not* to do it when it is *easier* than the other things we want to do, is my reasoning somehow. > The target user for the "OsmocomBB based phone" would be primarily a > "free software enthusiast... Also not neccessarily the only market we have. By now it's easy to customize your smartphone with tons of apps and so on, but regular users also like to change technology to fit them now and then. OK, it could be argued that they fall under the definition of free software enthusiasts, but the people I think of usually don't. > And such users are interested in real telephones, notin modems for > embedded systems. Maybe they have laptops and would like to use open source internet connectivity as well. In Berlin there's e.g. never 3G service available anyway, so 2G-only may be fine. Just because it's not for me or you doesn't mean that noone else will not want it. :) //Peter

12 years, 4 months

4
3
0 0

Re: Creating a real usable phone using OsmocomBB

by Alexander Chemeris

Hi Harald and all, I want to point that except usual mobile phones there are GSM modems which do not require any UI and thus require less work to be done. Also they are often connected to a power grid and don't have strict power consumption limits. And at last, but not at least modem users often need some peculiat functionality, which they would love to see embedded. And that's where OsmocomBB stands out significantly from all existing modems. I'm not sure if there are any modems based on Calypso chipset, but even a phone serving as a modem may suffice in some cases. -- Alexander Chemeris Sent from my Android device. Sorry for my brevity. On Dec 11, 2011 2:55 PM, "Harald Welte" <laforge(a)gnumonks.org> wrote: Hi all! I've mentioned this before, and I keep getting back to it: With all the great work that has been put into OsmocomBB, we are "at an arms lengh" away from being able to create a true Free Software mobile phone. We already have the hardware drivers, protocol stack and even the 'mobile' program which can be used for making and receiving voice calls and sending/receiving SMS text messages on real GSM networks! While the journey has been a lot of fun and everyone involved has learned a lot, we have so far been catering mstly about "scratching our own itch", i.e. implementing what we needed in order to satisfy our ego and/or to implement the ideas we had regarding cellular security. I believe we cannot miss the bigger opportunity here to put our code into bigger use: To create something like a very simple GSM feature phone. When we look at various areas of computing like Operating Systems or Web browsers, Free Software is not just "the hobby project catching up" with the vendors of proprietary software. Free Software can compete. In the cellular area, we have still not managed to even implement the most basic GSM feature phone that existed 15 years ago using proprietary software. We need to work on closing that gap. We need to show that a small community of Free Software developers can actually implement what teams of hundreds of engineers did in a proprietary software setting 15 years ago - despite all the lack of hardware documentation or any kind of positive feedback from the cellular chipset, handset or operator industry. If we don't at least get a 2G GSM cellphone implemented now, it will probably not happen before 2G networks become insignificant in large parts of the world. This is a call to all hands, please support this project! Regards, Harald == Technical aspects == I believe the first major decision is whether we focus on 1) the Openmoko FreeRunner / Neo1973 phones Advantages: * large screen for UI with bells and whistles * lots of RAM and Flash, even script languages or compilation on the device itself possible * second processor doesn't require us to run stack + UI on once CPU * easier debugging of UI * various existing telephony middleware and phone dialer UI projects of which hopefully one could be recycled or 2) the Motorola/Compal C1xx phones Advantags: * many more phones available, even after our software is released * lower cost of the individual phone * less power consumption due to only one small ARM7 core * smaller screen also means less fancy UI requirements Problems: * full stack + UI needs to run on calypso (L2/L3) and we'd probably some kind of RTOS like NuttX instead of our 'bare iron' code. ==== What we need in any case ==== * power management on the baseband processor through all of the stack (though it's mostly a driver/L1 kind of thing) == Summary / Opinion == It seems like running the OsmocomBB layer1 + 'mobile' as-is on the Openmoko baseband + application processor might be the quicker road to progress. Sure, the power consumption will be horrible as the AP will have to be woken up for each and every SI message, neighbor cell measurment or paging request that ew see comining in in our paging group (even in idle mode). But then, there is always the negative impact of using a relatively complex system, with two processors, a complex software stack (Linux, X11, toolkit, etc.) on one of them, etc. On the other hand, using the C1xx phones will result in a much more widely available result. The phones can still be bought in batches of 1,000 units, and they are small enough for lots of people to carry around. Furthermore, the battery lifetime is far beyond anything you would ever be able to achieve on a power-hungry smartphone platform. I believe it would be the "smart' solution, as it means we need to get everything integrated, etc. What does the community on this list think? Which way shoul we go? But maybe the best thing is to actually stat working on the power management aspects, as we will need them in both cases. Happy hacking, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 4 months

3
2
0 0

Re: Creating a real usable phone using OsmocomBB

by msokolov＠ivan.Harhan.ORG

Hello folks, Just my two cents: one factor that seems to be overlooked in the C1xx vs. GTA0x decision is the support for different GSM RF bands. From my reading of the OsmocomBB wiki, it appears that all those C1xx phones support only EGSM and DCS1800 bands, but not PCS1900. It seems like most current active developers are located in world regions where EGSM and DCS1800 bands are used, but in my area the only usable GSM band is PCS1900, or maybe GSM850 too: haven't been able to try the latter as I don't have any devices that support it. OTOH, my Neo Freerunner (which is currently doing shelf duty as a paperweight lacking functional source-enabled Calypso fw) supports the PCS1900 band in addition to EGSM and DCS1800. But if the community goes the C1xx route and produces GPL code that runs fully on the Calypso, no PC needed, does power mgmt and implements some UI on the Calypso-controlled LCD and keypad, I expect no difficulty with taking that code, replacing the Calypso-based UI with some simple protocol for interfacing with the UI over the modem UART (maybe not the same as the infamous AT command interface, but doing the same job on the same level of abstraction), and running it on my GTA02, hence I'm not complaining. As far as the power management etc advantages of the simpler phones without an application processor: does anyone know of any basic Leonardo-style phones which are like the famous C1xx, but support the PCS1900 band, are physically available, and documented no worse than C1xx in terms of the availability of schematics and docs for display and other non-Calypso components? The fact that C1xx phones can be bought in 1000 unit quantities is great news for those living in areas with EGSM/DCS1800 services, but doesn't do much good for those living in PCS1900/GSM850 lands... MS

12 years, 4 months

7
10
0 0

Re: Creating a real usable phone using OsmocomBB

by msokolov＠ivan.Harhan.ORG

Denis 'GNUtoo' Carikli <GNUtoo(a)no-log.org> wrote: > That's exactly what I was thinking about, since running the layer23 on the > Application CPU is not a so good idea, it renders the phone usable only for a > small period of time(since,in that configuration, you cannot suspend the AP > CPU because it has to run the telephony code). It's obvious that running layer23 on the AP is a *terrible* idea. It needs to move into the Calypso (or other BP) before there can be any serious thought of OsmocomBB truly replacing the existing proprietary BP code. However, my own skill & knowledge level is nowhere close to what would be needed for that job. But I was thinking of taking the current sorry state of things (layer23 external to the BP) and making it run on a self-contained GTA02: have the Samsung AP run layer23 instead of acting as a pass- through to a PC, then add some UI to it: the very same UI I wanted to implement in the first place before I got sidetracked to the baseband issues. The result of that would be having the GTA02 act as a "normal" feature phone in every way except for draining the battery in a couple of hours while doing nothing. The last aspect would make it rather unusable practically (unless perhaps one replaces the standard Li-ion battery with an automotive-sized lead-acid one), but it would be a tangible hands-on "teaser" of what would be possible if someone with the necessary knowledge and skills took the bother to redesign the code (move layer23 into the Calypso) such that proper PM could be implemented. > Why is AT bad? what other protocol do you propose? What Peter said: : Um, no, it's the other way around. AT is 30 years of horrible. If I were able to lay my hands on some source for an *existing* implementation of the AT command interface on the BP side, I would have no problem with implementing it on the AP side in my UI. But if I have to write the code from scratch on both sides of the interface, I'll probably implement some ad hoc protocol of my own rather than attempt to implement the "standard" one and get it wrong. MS

12 years, 4 months

1
0
0 0

Trouble with C117 while using osmocon

by Sreeraj R

Hi all, I am just a beginner and is using the following hardware Phone : C117 Serial Adapter : CP2102 based The propt message that I am getting is different compared to that mentioned in the wiki (http://bb.osmocom.org/trac/wiki/CompalRamloader). Command: ./osmocon -d t -p /dev/ttyUSB0 -m c123 ../../target/firmware/board/compal_e88/loader.compalram.bin Gives me the following data {00,f1,01,72,82,bf,7d,fd,7f,00,a6,51,d2,51,0a,3a,02,4d,a3,a3,da,00,00} Entire log after short power button key press is http://pastebin.com/AqcNm6dq. Can anyone give some pointers, or did I go wrong somewhere. The wiki specifies C117 board is similar to C123. regards Sreeraj R

12 years, 4 months

2
1
0 0

Re: gnuarm version

by R M

Hi, I am using this version of GNU Arm. http://www.gnuarm.com/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.exe Regards, RM On 12/4/11, Juantxi <juantxipazos(a)yahoo.es> wrote: > > Hello, what version of gnuarm uses? > thank >

12 years, 4 months

1
0
0 0

Re: RFC: Osmocom developer workshop 2012

by Harald Welte

Hi! Thinking a bit more about timing, it seems that the second half of March is a good idea. April is a bad idea, at least for the first two weeks, as this is easter holiday time in a lot of German states. This will cause lots of tourists, as well as full hotels, trains, flights, etc. So I'd propose something like four days in the second half of march. Should we try to overlap/extend a weekend? I guess this would help people with e regular dayjob, as not as many holidays would be required. If there are no objections in the next 48 hours, I will talk to C-Base about availability during that timeframe. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

12 years, 4 months

3
4
0 0

Script for parsing boot loader into COFF

by R M

Hi, Is there a script for parsing the boot loader code into a COFF format so that it can be loaded into IDA? Regards, RM

12 years, 4 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel December 2011