OpenBSC June 2010

openbsc@lists.osmocom.org

26 participants
52 discussions

by Harald Welte

Hi! Collin Mulliner, Tobias Engel and myself have been meeting yesterday to discuss a generic application interface for OpenBSC. They are both doing security analysis and want to achieve a clean way how an external application can get access to a more or less transparent communication channel to the phone. The purpose of this is to be able to send intentionally malformed packets to the mobile phone GSM stack at various different levels within the stack. As of now, they have both hacked some custom code into openbsc that gets them half way where they want to be - but not quite all the way. The requirements can be summarized as follows: 1) Ability to establish a SDCCH or TCH channel by paging the phone As of now, the 'silent call' feature from the VTY already does this. 2) Ability to send arbitrary layer3 protocol messages to the phone Adding this is relatively easy (use rsl_sendmsg on the lchan from the silent call) 3) Ability to receive responses from the phone, as well as error conditions such as 'readio link failure'. We don't have a solution for this yet, and we also have no clean way to identify what might be a response from the phone to the external app, and what might be a message from the phone to the normal network code in OpenBSC 4) Ability to selectively disable partial protocol handling in OpenBSC. Let's say you want to play with the mobile phone call control implementation. In this case, you want to make sure all CC related messages go from/to the external program and not from the regular OpenBSC network code. So what I've been thinking of as a solution to the problem: * store a bypass_flags bitmask related to the subscriber structure, where we indicate values such as BYPASS_RR, BYPASS_MM, BYPASS_CC, BYPASS_SAPI3. * if we process an incoming message from the MS in gsm0408_rcvmsg(), we check if a bypass flag matching the message is found. If yes, forward the message to the external program * if we want to send a message from our own protocol stack to the MS, we check if a bypass flag matching the message is found. If yes, we drop the message that we were about to send. * any messages received from the application will be forwarded to the MS The application interface protocol will likely have a close resemblance to RSL RLL. We need to exchange the following primitives with the application, like: * ESTABLISH REQUEST -- app requests a channel be established to MS (by IMSI) * ESTABLISH CONFIRM -- network confirms a channel has been established * ESTABLISH INDICATION -- network tells app connection was made by MS * [UNIT] DATA REQUEST -- app requests data to be sent to MS * [UNIT] DATA INDICATION -- network indicates data was received from MS * ERROR INDICATION -- network tells app something went wrong * RELEASE REQUEST -- app asks network to release channel * RELEASE CONFIRM -- net tells app that channel was released (as rqd) * RELEASE INDICATION -- net tells app that channel was released (by MS) The channel_number of RSL (indicating on-air timeslot) doesn't make much sense in this context, of course. The link_identifier on the other hand is great as it allows the app to indicate SDCCH/FACCH or SACCH as well as the SAPI. The actual RSL-like protocol would be encapsulated by UDP and available on a socket of the MSC. What do you think? 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)

14 years, 4 months

RFC: Relicensing OpenBSC under AGPLv3

by Harald Welte

Hi all! This subject came to my attention again recently: Why not relicense OpenBSC under AGPLv3? Right now we are licensing under GPLv2+ (v2 or any later version). However, if an operator was to make lots of private modifications and then operate it on his own network, there would be no distribution and thus no need for him to release his modified versions of the source code. This may sound a bit strange to those who have been with the project since its early days. But we are reaching production quality now, and we already have the first number of production deployments of the software. Companies like Netzing and On-waves have been FOSS-friendly and funding parts of our development effort. They have no issues with the result being Free Software again. However, there are definitely other companies out there who are less fond of sharing... So thus my idea is to put OpenBSC under AGPLv3. This way whoever uses OpenBSC _in modified form_ to operate a communications network will have to provide the source code to that modified form on a network server at no charge. The only controversial question to me is "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source". 1) does a gsm network count as computer network? i'd say yes. 2) is using a gsm network 'interacting with it remotely'? I'd also say yes 3) what does 'prominently offer' mean in the context of GSM? We don't want the operator to spam their users with advertisement SMS just to know that they can get the soruce code, after all. Notwithstanding those open questions, such a network operator would always have the option of simply sending back his changes for integration in the official project - and thus he would no longer use a modified version which then means there is no need for the prominent notice / download at all. We can make this very clear in the project documentation, putting further encouragement The actual relicensing should be less problematic than I thought, since AGPLv3 is compatible with GPLv3. So I could re-license all parts that I own copyright on (which should be the majority of the code base anyway) under AGPLv3, while the former GPLv2+ components (like VTY code from zebra, or contributions by other people) then become GPLv3-or-later. Of course I would want to encourage all developers/contributors to also follow the re-licensing. Particularly Holger Freyther, Dieter Spaar, Andreas Eversberg, Jan Luebbe, Sylvain Munaut, Daniel Willmann, Stefan Schmidt. So let's start with a poll: a) Do you think re-licensing to AGPLv3 is a good idea? b) If you have contributed, would you re-license your code under AGPLv3? If we have some kind of concesus in the community, I would approach On-waves whether they would want to do the same for their share of the copyright. As their "modifications" are all part of OpenBSC git repository, they would not be subject to any different conditions than before. Thanks in advance for your feedback, 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)

14 years, 5 months

[PATCH 0/1] Add bport0/1 support for bs11_config

by Daniel Willmann

Hello, second try to add support to bs11_config for bport0/1 configuration. This time with enum abis_bs11_line_cfg. It seems sometimes creating bport1 fails, even LMT shows create obj greyed out. Don't know why yet. Regards, Daniel Willmann Daniel Willmann (1): Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config openbsc/include/openbsc/abis_nm.h | 10 +++++++++- openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++-- openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 3 deletions(-)

14 years, 6 months

Re: [BUG REPORT]: Unable to send SMS

by Luca Bertoncello

Am Wed, 23 Jun 2010 20:18:56 +0800 schrieb Holger Freyther <zecke(a)selfish.org>: > the first pointer is to the sha1/commit id[1]. So every commit has an > id, it happens to be the sha1 hash over some parts of the content. Now > git log will show all these as "commit". Now the openbsc version is > generated by the little "./git-version-gen" utility. In fact the > utility is calling "git describe" (man git-describe). > > E.g. it looks like this: > 0.9.0-891-gaf7edd9 > > 0.9.0 is the last tag we had.. > 891 is the number of commits since that tag > gaf7edd9 is the commit/sha1. This is what you want. > > I hope this helps Unfortunately not... I tried to give git-describe in the tree of the "sms-sending"-BSC (0.9.0-531-gb938d6b) and in the tree of the last version (0.9.0-890-g2788b96), then I tried to use git bisect: lucabert@Luca:/tmp/bsc/openbsc$ git bisect good gb938d6b Bad rev input: gb938d6b lucabert@Luca:/tmp/bsc/openbsc$ git bisect bad g2788b96 fatal: Needed a single revision Bad rev input: g2788b96 It seems not to work... Maybe I need vacancy? I can't understand what you suppose I can do... Thanks for your suggestion! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

14 years, 11 months

Re: Segmentation fault while sending sms via bsc_hack_VTY

by Richard Zahoransky

-------- Original-Nachricht -------- > Datum: Wed, 30 Jun 2010 12:10:20 +0800 > Von: Holger Hans Peter Freyther <holger(a)freyther.de> > An: openbsc(a)lists.gnumonks.org > Betreff: Re: Segmentation fault while sending sms via bsc_hack_VTY > > > > thanks a lot for starting to debug this. Could you help me a bit with > > your test setup? Which type of BTS do you use? Could you get us a pcap > > file for the Channel Activate NACK? Attached I have a pcap file from bsc_hack. It logged until the segmentation fault happened. Additionally, I have captured the bsc_hack output and valgrind output in the other file. There you also find the openbsc config file. Only bsc_hack was started, without lcr or openggsn for this testing. We use two nanoBTS - ipaccess-find prints out: MAC Address='00:02:95:00:2f:b7' IP Address='10.1.1.10' Unit ID='1802/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_48' Software Version='168c002_v100b16d0' Unit Name='nbts-00-02-95-00-2F-B7' Serial Number='00071355' MAC Address='00:02:95:00:57:3e' IP Address='10.1.1.11' Unit ID='1800/0/0' Location 1='' Location 2='BTS_NBT131G' Equipment Version='165a029_55' Software Version='168a302_v142b13d0' Unit Name='nbts-00-02-95-00-57-3E' Serial Number='00107709' Each BTS has its own part in the openbsc.cfg > > please confirm that both the SMS crash and the NACKs are resolved. I loaded and built the current version from OpenBSC (Jun., 30. ~ 3:00 p.m.). SMS still crashes when sending from vty console. As far as I can tell, the NACKs are resolved. > > thanks thank you too!

14 years, 11 months

Cryptography VTY Bugreport

by Philipp Fabian Benedikt Maier

Hi folks. I am currently playing with the crypto features of openBSC. When i want to enter the key for a specific subscriber in the VTY console openBSC crashes. When i create the entry manually with sqlite3 and try again the entry in the database will be overwritten and it seems to work. The string i entered in VTY was: subscriber imsi 001010000000000 a3a8 comp128v1 DEADBEEF0C0FFEE0F00D013370D00F23 The gdb backtrace is: openbsc@openBSC:~/openbsc/openbsc/src$ gdb -- pid 1612 GNU gdb (GDB) 7.1-ubuntu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... pid: No such file or directory. Attaching to process 1612 Reading symbols from /home/openbsc/openbsc/openbsc/src/bsc_hack...done. Reading symbols from /usr/local/lib/libosmocore.so.0...done. Loaded symbols for /usr/local/lib/libosmocore.so.0 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libdbi.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdbi.so.0 Reading symbols from /usr/local/lib/libosmovty.so.0...done. Loaded symbols for /usr/local/lib/libosmovty.so.0 Reading symbols from /lib/tls/i686/cmov/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libcrypt.so.1 Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/tls/i686/cmov/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Reading symbols from /usr/lib/dbd/libdbdsqlite3.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/dbd/libdbdsqlite3.so Reading symbols from /usr/lib/libsqlite3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libsqlite3.so.0 Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 0x00c9d422 in __kernel_vsyscall () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x0046450b in vfprintf () from /lib/tls/i686/cmov/libc.so.6 #1 0x00484147 in vasprintf () from /lib/tls/i686/cmov/libc.so.6 #2 0x006b042f in dbi_conn_queryf () from /usr/lib/libdbi.so.0 #3 0x08054c05 in db_sync_authinfo_for_subscr (ainfo=0x579ff4, subscr=0x994ec18) at db.c:413 #4 0x0805408e in ena_subscr_a3a8 (self=0x8089ee0, vty=0x99501f8, argc=4, argv=0xbfc33f6c) at vty_interface_layer3.c:502 #5 0x00a74cfb in cmd_execute_command_real (vline=<value optimized out>, vty=<value optimized out>, cmd=0x0) at command.c:1874 #6 0x00a74e27 in cmd_execute_command (vline=0x994a5c0, vty=0x99501f8, cmd=0x0, vtysh=0) at command.c:1909 #7 0x00a7766f in vty_command (vty=0x99501f8) at vty.c:321 #8 vty_execute (vty=0x99501f8) at vty.c:585 #9 vty_read (vty=0x99501f8) at vty.c:1319 #10 0x00a793aa in client_data (fd=0x99504d4, what=1) at telnet_interface.c:128 #11 0x003b7925 in bsc_select_main (polling=0) at select.c:119 #12 0x0804bc66 in main (argc=3, argv=0xbfc34604) at bsc_hack.c:271 (gdb) Maybe this helps to find the bug. regards. Philipp -- ______________________________________ Philipp Fabian Benedikt Maier philipp.maier(a)runningserver.com Funk: DO5DXT http://www.runningserver.com http://www.diskettenschlitz.de ______________________________________

14 years, 11 months

Arfcn calculation tool

by Philipp Fabian Benedikt Maier

Hi Folks. I always found it annoying to calculate the correspondending frequency of an arfcn by hand or with the webbased arfcn calculator. So i wrote a little program to do the work for me: http://www.root.runningserver.com/web/runningserver/software/arfcncalc.tar Maybe the one or other here on the list will find it useful. regards. Philipp -- ______________________________________ Philipp Fabian Benedikt Maier philipp.maier(a)runningserver.com Funk: DO5DXT http://www.runningserver.com http://www.diskettenschlitz.de ______________________________________

14 years, 11 months

[PATCH] * Fix null ptr dereference and sms memleak in case the recipient of an sms sent via vty is not attached. Store the sms in the database in this case for later delivery.

by Nico Golde

The problem is that sms_from_text returns NULL in case the subscriber is not attached which a) leaks memory of the previously allocated sms and b) runs into a null ptr dereference in _send_sms_str(). There may be a better solution than this but this is the easiest way of noticing and taking action I could find without changing return values of sms_from_text. --- openbsc/src/vty_interface_layer3.c | 16 ++++++++++------ 1 files changed, 10 insertions(+), 6 deletions(-) diff --git a/openbsc/src/vty_interface_layer3.c b/openbsc/src/vty_interface_layer3.c index d80f7c9..0a65eec 100644 --- a/openbsc/src/vty_interface_layer3.c +++ b/openbsc/src/vty_interface_layer3.c @@ -166,11 +166,6 @@ struct gsm_sms *sms_from_text(struct gsm_subscriber *receiver, const char *text) if (!sms) return NULL; - if (!receiver->lac) { - /* subscriber currently not attached, store in database? */ - return NULL; - } - sms->receiver = subscr_get(receiver); strncpy(sms->text, text, sizeof(sms->text)-1); @@ -195,7 +190,16 @@ static int _send_sms_str(struct gsm_subscriber *receiver, char *str, sms = sms_from_text(receiver, str); sms->protocol_id = tp_pid; - gsm411_send_sms_subscr(receiver, sms); + + if(!receiver->lac){ + /* subscriber currently not attached, store in database */ + if (db_sms_store(sms) != 0) { + LOGP(DSMS, LOGL_ERROR, "Failed to store SMS in Database\n"); + return CMD_WARNING; + } + } else { + gsm411_send_sms_subscr(receiver, sms); + } return CMD_SUCCESS; } -- 1.7.1

14 years, 11 months

Re: Segmentation fault while sending sms via bsc_hack_VTY

by Richard Zahoransky

> Date: Mon, 28 Jun 2010 09:15:11 +0800 > From: Holger Hans Peter Freyther <holger(a)freyther.de> > To: openbsc(a)lists.gnumonks.org > Re: Segmentation fault while sending sms via bsc_hack_VTY > Could you try two things? One is to build with OpenBSC with -O0 (either > by passing CFLAGS on configure or changing the Makefile) and then run > OpenBSC with valgrind and report the line number. > On second look, this seems to be a week or two old OpenBSC? is that > true? Would it be a lot of work to test the latest version of OpenBSC? the new version does not seem to build correct. Make prints out: sgsn_libgtp.c: In function ‘sgsn_create_pdp_ctx’: sgsn_libgtp.c:117: error: ‘struct pdp_t’ has no member named ‘priv’ sgsn_libgtp.c: In function ‘cb_data_ind’: sgsn_libgtp.c:373: error: ‘struct pdp_t’ has no member named ‘priv’ sgsn_libgtp.c:396: warning: assignment makes pointer from integer without a cast maybe this could be because I have installed openggsn? anyway, when using make -k (and ./coonfigure CFLAGS="-O0"), bsc_hack builds and starts. Still it "crashes" when I try to send SMS from the bsc_hack_vty. There is no segmantation fault, but this: <0008> paging.c:130 No slots available on bts nr 1 <0008> paging.c:130 No slots available on bts nr 0 and <0004> abis_rsl.c:831 (bts=1,trx=0,ts=0,ss=0) CHANNEL ACTIVATE NACKCAUSE=0x6f(Protocol error, unspecified) <0011> handover_logic.c:197 unable to find HO record it repeats (endlessly?) Valgrind reports: ==26461== Invalid read of size 4 ==26461== at 0x806DA60: subscr_paging_cb (linuxlist.h:163) ==26461== by 0x806EE46: paging_T3113_expired (paging.c:209) ==26461== by 0x403D3EF: bsc_update_timers (timer.c:160) ==26461== by 0x403D8F6: bsc_select_main (select.c:94) ==26461== by 0x804BC75: main (bsc_hack.c:271) ==26461== Address 0x4731120 is 432 bytes inside a block of size 440 free'd ==26461== at 0x4024B3A: free (vg_replace_malloc.c:366) ==26461== by 0x40471AF: talloc_free (talloc.c:610) ==26461== by 0x806DD34: subscr_put (gsm_subscriber_base.c:133) ==26461== by 0x806E9F5: paging_remove_request (paging.c:77) ==26461== by 0x806EE02: paging_T3113_expired (paging.c:204) ==26461== by 0x403D3EF: bsc_update_timers (timer.c:160) ==26461== by 0x403D8F6: bsc_select_main (select.c:94) ==26461== by 0x804BC75: main (bsc_hack.c:271) ==26461== and ==26524== Syscall param ioctl(TCSET{S,SW,SF}) points to uninitialised byte(s) ==26524== at 0x4431A5F: tcsetattr (tcsetattr.c:88) ==26524== by 0x4069865: vty_create (vty.c:1399) ==26524== by 0x406A289: telnet_new_connection (telnet_interface.c:167) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== Address 0xbefa82c8 is on thread 1's stack ==26524== ==26524== Use of uninitialised value of size 4 ==26524== at 0x43A9288: _itoa_word (_itoa.c:196) ==26524== by 0x43ACAE1: vfprintf (vfprintf.c:1613) ==26524== by 0x444DBF3: __vsnprintf_chk (vsnprintf_chk.c:65) ==26524== by 0x444DB13: __snprintf_chk (snprintf_chk.c:36) ==26524== by 0x40417E4: hexdump (stdio2.h:65) ==26524== by 0x8072538: ipaccess_fd_cb (ipaccess.c:566) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== ==26524== Syscall param socketcall.send(msg) points to uninitialised byte(s) ==26524== at 0x443BE78: send (socket.S:100) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== Address 0x4736d9d is 261 bytes inside a block of size 1,140 alloc'd ==26524== at 0x4024F20: malloc (vg_replace_malloc.c:236) ==26524== by 0x4045291: _talloc_zero (talloc.c:355) ==26524== by 0x403DD66: msgb_alloc (msgb.c:37) ==26524== by 0x8061FF9: rsl_msgb_alloc (msgb.h:159) ==26524== by 0x806436E: rsl_chan_activate_lchan (abis_rsl.c:443) ==26524== by 0x80653D0: abis_rsl_rcvmsg (abis_rsl.c:1228) ==26524== by 0x80725F9: ipaccess_fd_cb (ipaccess.c:489) ==26524== by 0x403D924: bsc_select_main (select.c:119) ==26524== by 0x804BC75: main (bsc_hack.c:271) ==26524== Best Regards, Richard

14 years, 11 months

SS7 protocols support in openbsc project

by mosbah abdelkader

Hello, Is there a support of SS7 protocol stack over MTP (TDM) or SCTP (SIGTRAN) in the openbsc project. Thank you.

14 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2010