- OpenBSC - lists.osmocom.org

Segfault from Race condition when closing channel?
by Harald Welte 05 Jul '10

05 Jul '10

As horiz0n on IRC points out: 00:16 <horiz0n> hehe, calling the c123 from my 9500 communicator crashes openbsc 00:17 <horiz0n> here is the log http://notepad.cc/share/LQ3awCtXz9 00:21 <horiz0n> and here the debug log http://notepad.cc/share/tPJYXo3SJG <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:1109 CIPHERING MODE COMPLETE <0003> gsm_04_08_utils.c:197 Sending Channel Release: Chan: Number: 0 Type: 2 <0004> abis_rsl.c:586 (bts=0,trx=0,ts=1,ss=0) DEACTivate SACCH CMD <0000> chan_alloc.c:363 (bts=0,trx=0,ts=1,ss=0) Recycling Channel <0000> abis_rsl.c:1388 (bts=0,trx=0,ts=1,ss=0) SAPI=0 DATA INDICATION ./runbsc.sh: line 6: 1179 Segmentation fault sudo ./bsc_hack -e 1 -d DINP:DNM:DRSL:DRR:DMM:DCC:DRLL:DMNCC:DSMS:DPAG,0:0:0 So what happens: We get a CM Service request, then go through authentication and ciphering. At that point, the network decides to release the channel and the channel is not completely closed yet (only SACCH deactivated) when we get an incoming SETUP message. This message is treated as a new message (msc_compl_l3, but it has no conn->subscr and the code segfaults in trans_find_by_id(subscr=NULL, ...) So I think there are actually multiple bugs. 1) the channel should not be released at that time 2) we have some kind of a race condition at channel release, where incoming messages should either be discarded _or_ should still be processed with all the data structures intact. 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)

2 2

GPRS / OsmoSGSN status update
by Harald Welte 03 Jul '10

03 Jul '10

Good news, everyone [tm] GPRS is by now in a fairly useful state. I've spent the better part of the last 3 days to fix all the remaining known bugs. It is working fine from a variety of phones including a G1 (MSM7200) , K800i (unkown baseband), TYTN2 (also Qualcomm MSM but with windows mobile), E680 (Neptune LTE), ... The following parts are still missing: * Integration with the HLR, so every phone is accepted on GPRS * IP Header compression (ROHC) * Data compression (v.42bis) * Authentication (depends on HLR integration) * GEA3 Encryption (though most of the infrastructure is there) * Ability to route APNs to different GGSNs So everyone who has access to a nanoBTS: Try it now. The build/config instructions haven't changed from what I described last time when I wrote a GPRS status update to this list. 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)

2 2

Re: Segmentation fault while sending sms via bsc_hack_VTY
by Richard Zahoransky 02 Jul '10

02 Jul '10

-------- 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!

3 2

Re: Cryptography VTY Bugreport (patch inside)
by cscan＠gmx.net 02 Jul '10

02 Jul '10

Sorry. Now with the patch file included.

1 0

Cryptography VTY Bugreport
by Philipp Fabian Benedikt Maier 02 Jul '10

02 Jul '10

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 ______________________________________

4 4

Arfcn calculation tool
by Philipp Fabian Benedikt Maier 30 Jun '10

30 Jun '10

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 ______________________________________

2 1

[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 30 Jun '10

30 Jun '10

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

2 1

Re: Segmentation fault while sending sms via bsc_hack_VTY
by Richard Zahoransky 30 Jun '10

30 Jun '10

> 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

3 5

SS7 protocols support in openbsc project
by mosbah abdelkader 29 Jun '10

29 Jun '10

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

3 4

Working GSM1800 config for latest OpenBSC
by Stephen Mortimer 28 Jun '10

28 Jun '10

I have a ip.access nanoBTS (version 165AU9012)v(37) and have been using it with a very early version of OpenBSC (OpenBSC 0.01) and am now trying to upgrade to the latest version downloaded from GIT (OpenBSC version 0.9.0.565-993d). When I use the configuration that works on the old version, with this latest version, I get the following error: user@ubuntu:~/openbsc/src$ ./bsc_hack <0005> bsc_init.c:1024 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! <0005> bsc_init.c:1024 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! DB: Database initialized. DB: Database prepared. <000d> input/ipaccess.c:632 accept()ed new OML link from 192.168.2.3 <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff <000d> input/ipaccess.c:477 no matching signalling link for hh->proto=0xff Can anyone explain why I get this error and maybe send me a config that would work?

4 4