OpenBSC

openbsc@lists.osmocom.org

1 participants
4173 discussions

Help by connecting OpenBSC with Asterisk

by Luca Bertoncello

Hi, List! I have now to connect OpenBSC with Asterisk, in order to use a VoIP-phone to call mobiles (and viceversa). I found this HowTo: http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR Since I don't know Asterisk I'm not sure if it is what I really need... In the HowTo 2 ISDN-Cards are used. Need I really these? I'm using a nanoBTS (accessed over Ethernet), so I think I don't need the Cologne Chips E1 PCI card. Is it right? Then, at least as first step, I don't want to connect my Asterisk with the rest of the world. I really want to create my own test-network with a VoiIP-phone and a couple of mobiles. Do I really need a ISDN-card? And last, but not least, (as I said, I don't know Asterisk!!), how can I decide, that a number I choose from mobile or VoiIP-phone is a mobile or a VoiIP-phone? Maybe there is a running configuration of Asterisk I can use as example? Thanks a lot for your help! -- _______________________________________________________________________ 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 _______________________________________________________________________

15 years, 2 months

Segfault from Race condition when closing channel?

by Harald Welte

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)

15 years, 2 months

GPRS / OsmoSGSN status update

by Harald Welte

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)

15 years, 2 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!

15 years, 2 months

Re: Cryptography VTY Bugreport (patch inside)

by cscan＠gmx.net

Sorry. Now with the patch file included.

15 years, 2 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 ______________________________________

15 years, 2 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 ______________________________________

15 years, 2 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

15 years, 2 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

15 years, 2 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.

15 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC