baseband-devel April 2014

baseband-devel@lists.osmocom.org

14 participants
31 discussions

[PATCH] Update GPRS cipher API to comply with ETSI TS 155.22
by Max 17 Jun '14

17 Jun '14

--- include/osmocom/crypt/gprs_cipher.h | 8 ++++++-- src/gsm/gprs_cipher_core.c | 20 +++++++++++++++++--- src/gsm/libosmogsm.map | 1 + 3 files changed, 24 insertions(+), 5 deletions(-) diff --git a/include/osmocom/crypt/gprs_cipher.h b/include/osmocom/crypt/gprs_cipher.h index 3051071..b6b8e93 100644 --- a/include/osmocom/crypt/gprs_cipher.h +++ b/include/osmocom/crypt/gprs_cipher.h @@ -10,6 +10,7 @@ enum gprs_ciph_algo { GPRS_ALGO_GEA1, GPRS_ALGO_GEA2, GPRS_ALGO_GEA3, + GPRS_ALGO_GEA4, _GPRS_ALGO_NUM }; @@ -28,7 +29,7 @@ struct gprs_cipher_impl { /* As specified in 04.64 Annex A. Uses Kc, IV and direction * to generate the 1523 bytes cipher stream that need to be * XORed wit the plaintext for encrypt / ciphertext for decrypt */ - int (*run)(uint8_t *out, uint16_t len, uint64_t kc, uint32_t iv, + int (*run)(uint8_t *out, uint16_t len, uint8_t *kc, uint32_t iv, enum gprs_cipher_direction direction); }; @@ -40,11 +41,14 @@ int gprs_cipher_load(const char *path); /* function to be called by core code */ int gprs_cipher_run(uint8_t *out, uint16_t len, enum gprs_ciph_algo algo, - uint64_t kc, uint32_t iv, enum gprs_cipher_direction dir); + uint8_t *kc, uint32_t iv, enum gprs_cipher_direction dir); /* Do we have an implementation for this cipher? */ int gprs_cipher_supported(enum gprs_ciph_algo algo); +/* Return key length for supported cipher, in bytes */ +unsigned gprs_cipher_key_length(enum gprs_ciph_algo algo); + /* GSM TS 04.64 / Section A.2.1 : Generation of 'input' */ uint32_t gprs_cipher_gen_input_ui(uint32_t iov_ui, uint8_t sapi, uint32_t lfn, uint32_t oc); diff --git a/src/gsm/gprs_cipher_core.c b/src/gsm/gprs_cipher_core.c index b9a22a1..450272b 100644 --- a/src/gsm/gprs_cipher_core.c +++ b/src/gsm/gprs_cipher_core.c @@ -26,8 +26,8 @@ #include <osmocom/core/utils.h> #include <osmocom/core/linuxlist.h> #include <osmocom/core/plugin.h> - #include <osmocom/crypt/gprs_cipher.h> +#include <osmocom/gsm/gea.h> static LLIST_HEAD(gprs_ciphers); @@ -53,12 +53,14 @@ int gprs_cipher_register(struct gprs_cipher_impl *ciph) int gprs_cipher_load(const char *path) { /* load all plugins available from path */ - return osmo_plugin_load_all(path); + if (path) + return osmo_plugin_load_all(path); + return 0; } /* function to be called by core code */ int gprs_cipher_run(uint8_t *out, uint16_t len, enum gprs_ciph_algo algo, - uint64_t kc, uint32_t iv, enum gprs_cipher_direction dir) + uint8_t *kc, uint32_t iv, enum gprs_cipher_direction dir) { if (algo >= ARRAY_SIZE(selected_ciphers)) return -ERANGE; @@ -73,6 +75,18 @@ int gprs_cipher_run(uint8_t *out, uint16_t len, enum gprs_ciph_algo algo, return selected_ciphers[algo]->run(out, len, kc, iv, dir); } +unsigned gprs_cipher_key_length(enum gprs_ciph_algo algo) +{ + switch (algo) { + case GPRS_ALGO_GEA0: return 0; + case GPRS_ALGO_GEA1: return 8; + case GPRS_ALGO_GEA2: return 8; + case GPRS_ALGO_GEA3: return 8; + case GPRS_ALGO_GEA4: return 16; + default: return 0; + } +} + int gprs_cipher_supported(enum gprs_ciph_algo algo) { if (algo >= ARRAY_SIZE(selected_ciphers)) diff --git a/src/gsm/libosmogsm.map b/src/gsm/libosmogsm.map index 3a4a643..3beb1e9 100644 --- a/src/gsm/libosmogsm.map +++ b/src/gsm/libosmogsm.map @@ -31,6 +31,7 @@ gprs_cipher_load; gprs_cipher_register; gprs_cipher_run; gprs_cipher_supported; +gprs_cipher_key_length; gprs_tlli_type; gprs_tmsi2tlli; -- 1.8.3.2

3 3

Osmovom-BB on Raspberry Pi
by Richard Menedetter 16 Jun '14

16 Jun '14

Hi All Just wanted to confirm that I got Osmocom-BB up and running on a Raspberry Pi. I did not use the GPIO UART pins but USB <-> serial converters. I tried Motorola C118 and C155 with success. Everything you need is already described: http://bb.osmocom.org/trac/wiki/GnuArmToolchain http://bb.osmocom.org/trac/wiki/libosmocore http://bb.osmocom.org/trac/wiki/Software/GettingStarted?redirectedfrom=Gett… My previous problem seems to have been a not fully compatible crosscompiled toolchain. (it worked mostly, but I could not log-in to a cell and the spectrum view crashed on the RSSI Firmware. Also if you want transmit capability (or flashing) then you need to activate those features in the makefile. Thanks Sylvain (confirming c118 will work) and all others who are involved!! PS: Any news on the "emulated BTS" that has been presented at last years chaos communication congress? I have 2 C118s + 1 normal USB serial dongle + 1 capable of burst ind. I hope this will suffice to also run also a possible future 1 trasmit phone + 1 receive phone configuration. I assume that even without the filter change it should be enough to send a few meters of distance.

5 10

c139/c140 jtag anyone?
by Craig Comstock 19 May '14

19 May '14

I'm at the point w/ flashing firmware where I feel like I need to use a debugger w/ JTAG. I figured I could probably use serial line logging somehow but JTAG seems better and I should learn it anyway. Has anyone pried open the shield on a c139/c140 and tried attaching to the JTAG test points that are just inside the shield next to the test points which are accessible via the battery compartment?

2 3

Useful article on patching Nokia DCT4+ firmware
by Andrew Tipton 06 May '14

06 May '14

Hi folks, Came across this article in the latest PoC||GTFO journal describing (part of) the process for patching firmware on Nokia DCT4+ phones. The good stuff is pages 22-29 of this file: http://openwall.info/wiki/_media/people/solar/pocorgtfo03.pdf Alas, this does not appear to permit patching the first 1MB of firmware, so may not be helpful for OsmocomBB. But perhaps someone with more time on their hands can take this and run with it... Cheers, -Andrew

2 1

baseband-devel unsubscribe notification
by mailman-bounces＠lists.osmocom.org 28 Apr '14

28 Apr '14

lea_lss_bollnas(a)telia.com has been removed from baseband-devel.

1 0

Frame Structure and Multiframe questions
by R M 26 Apr '14

26 Apr '14

Hi, I am trying to understand the Multiframe structure in GSM. Here is my question: Lets say that in a particular cell, only two GSM frequencies are available to cater to all the traffic. FB is the frequency of the beacon channel and FT is the frequency of the traffic channel. FBT0 is having the following configuration FCCH + SCH + BCCH + CCCH. Now a phone which is in this cell, gets paged for an incoming SMS. The phone responds to the paging request and gets an immediate assignment. The immediate assignment assigns it a channel with the following configuration: FTT2 and channel multiplexing is SDCCH/8 + SACCH/8. Now how does the phone know the multiframe structure of FTT2 ? In other words how does the phone know how long it has to wait, so that it can transmit in the right time-slot ? The same question applies to the BTS if we are talking about down-link ? Is there a relation between the multiframe structure of FBT0 and FTT2 ? Thanks and Regards, R M

2 1

Re: strange crashes in current main branch
by Christophe Devine 24 Apr '14

24 Apr '14

Quick heads up: I finally ended up using a LM 317T to lower the output voltage to ~4V, using R1=220, R2=550 and a 1uF capacitor, plus a OTB battery pcb. The phone doesn't get as hot as before, and the "battery" powers without delay. https://drive.google.com/file/d/0ByHQWL5Q6bSwTWo3ZnBHTS1KeXc/edit?usp=shari… https://drive.google.com/file/d/0ByHQWL5Q6bSwM1FPeS1iVlBYX3M/edit?usp=shari…

1 0

Re: strange crashes in current main branch
by Christophe Devine 23 Apr '14

23 Apr '14

Tim, Following your advice, I disassembled a battery, and directly connected the output of a 3.6v motorola charger to gnd and positive side of the charging pcb (of course the lithium cell is completely disconnected). See pictures below, gnd is the middle pad whereas the positive pad is on the left. When doing so be careful not to heat or pierce the lithium battery, and afterwards put some tape to ensure electrical isolation: https://drive.google.com/file/d/0ByHQWL5Q6bSwOHVPNlV5T2ZyZndLZmwtMF9JQ2V0eH… https://drive.google.com/file/d/0ByHQWL5Q6bSwTGNfeUFOVFM5cldPNFZ3djMyMmlSNV… https://drive.google.com/file/d/0ByHQWL5Q6bSwUm9XUnBOcU5SRFg4T3VpNEFZOUFHaU… The result appears to work although strangely sometimes after unplugging the charger for some time and replugging it the microcontroller on the pcb will not wake up. However it does immediately wake up if I measure the current between the + and - output with a basic multimeter, but with the black probe on the + and the red probe on the - (other way does not work). There's probably something I'm missing here, but it's not that big a deal. Maybe this is caused by a quirk in the microcontroller, as I've tried the same procedure on a new compatible battery (branded "OTB", see http://pmcdn.priceminister.com/photo/926610349.jpg) and it doesn't have this problem, the microcontroller wakes up immediately and powers the phone. The voltage might be a bit too high, but the phone seems to work fine (firmware reports a full battery - also it gets slightly hotter). On Wed, Apr 23, 2014 at 3:05 PM, Christophe Devine < devinechristophe(a)gmail.com> wrote: > Tim, > > Following your advice, I disassembled a battery, and directly connected > the output of a 3.6v motorola charger to gnd and positive side of the > charging pcb (of course the lithium cell is completely disconnected). See > pictures below, gnd is the middle pad whereas the positive pad is on the > left. When doing so be careful not to heat or pierce the lithium battery, > and afterwards put some tape to ensure electrical isolation. > > The result appears to work although strangely sometimes after unplugging > the charger for some time and replugging it the microcontroller on the pcb > will not wake up. However it does immediately wake up if I measure the > current between the + and - output with a basic multimeter, but with the > black probe on the + and the red probe on the - (other way does not work). > There's probably something I'm missing here, but it's not that big a deal. > > Maybe this is caused by a quirk in the microcontroller, as I've tried the > same procedure on a new compatible battery (branded "OTB", see > http://pmcdn.priceminister.com/photo/926610349.jpg) and it doesn't have > this problem, the microcontroller wakes up immediately and powers the > phone. The voltage might be a bit too high, but the phone seems to work > fine (firmware reports a full battery). > > Christophe > > > On Thu, Apr 10, 2014 at 8:44 PM, Tim Ehlers <osmocom(a)ehlers.info> wrote: > >> On Thu, 10 Apr 2014, Max.Suraev(a)fairwaves.co wrote: >> >> I modified the mobile battery, removing the battery itself, and >>>> replacing it with a >>>> 3.7V AC-Adapter, so that I don't need the charging. >>>> >>> >>> Interesting - can you describe those modifications in more details? >>> Which adapter have you used? How did you connect it exactly? Some pics? >>> >> >> ohh, this is no "advanced" modification. I just read on the battery, that >> it outputs 3.7V, then I found for an ACDC-adapter, outputing 3.3V DC (this >> is enough, but the phone tells you that the battery is nearly empty if you >> boot the original firmware; but we use osmocom :). >> >> I openened the white plastic cover (or more correct, opened the sticker >> around the battery), removed the Li-ION battery from the little electronic >> parts and soldered the DC-adapter there instead. >> >> Cheers >> >> Tim >> >> >

1 0

Mobile app crashing while making call
by Akib Sayyed 17 Apr '14

17 Apr '14

Guys I am trying to make call using mobile app but when i try to call it crashes here is report http://pastebin.com/nsdxLvPg -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243

3 3

arm-elf-gcc
by Ahmad Jan 15 Apr '14

15 Apr '14

While installing osmocom-bb, i came across the "building the source" section. It says in later part that: " If your GCC binary that produces ARM code is not called *arm-elf-gcc* you will need to invoke the following statement and provide the basename of the toolchain with the ending *-*" cd src make -e CROSS_TOOL_PREFIX=arm-OTHER_NAME- How can i find out that my GCC binary is called as *arm-elf-gcc *or something else?

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel April 2014