June 2010 - OpenBSC - lists.osmocom.org

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)

13 years, 3 months

3
9
0 0

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)

13 years, 4 months

3
5
0 0

[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(-)

13 years, 5 months

4
5
0 0

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 _______________________________________________________________________

13 years, 10 months

4
28
0 0

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!

13 years, 10 months

3
2
0 0

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 ______________________________________

13 years, 10 months

4
4
0 0

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 ______________________________________

13 years, 10 months

2
1
0 0

[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

13 years, 10 months

2
1
0 0

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

13 years, 10 months

3
5
0 0

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.

13 years, 10 months

3
4
0 0

Working GSM1800 config for latest OpenBSC

by Stephen Mortimer

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?

13 years, 10 months

4
4
0 0

ipaccess-config now able to set static IP address / mask / gateway

by Harald Welte

Hi! I've committed some changes to enable ipaccess-config to set static IP address, netmask and gateway. A full command looks like this: ./ipaccess/ipaccess-config -U dhcp-enabled -S static-ip -S static-gw -i 192.168.100.222/255.255.255.0 -g 192.168.100.1 -r 192.168.100.120 This will * unset DHCP client functionality * set static IP address nvram flag * set static gateway nvram flag * set the BTS IP to 192.168.100.222 netmask 255.255.255.0 * set the default gateway to 192.168.100.1 * restart the BTS 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)

13 years, 10 months

1
0
0 0

Arfcn calculation tool

by dexter

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

13 years, 10 months

2
2
0 0

BSC API updates

by Holger Freyther

Hi all, I just pushed zecke/remove-use-count with two commits to almost complete the split. This code allocates the "struct gsm_subscriber_connection" dynamically and the follow on commit is removing the use_count and releases a channel as soon as it is unused (no operation/transaction is left on it). I would like to land this code now and continue with: -) Land some channel release changes from the On-Waves branch -) Update the channel release documentation... -) Start recreating the osmo-bsc... -) Implement the assignment command and use it from gsm_04_08.c and suddenly we can easily switch from very early to early assignment...

13 years, 10 months

1
0
0 0

Segmentation fault while sending sms via bsc_hack_VTY

by Richard M. Zahoransky

Hello, We have a working OpenBSC-LCR-Asterisk setup by now. Sending SMS from one cell phone to another works perfectly after typing "sms send pending" in the vty-console. Is it always needed to trigger the sms-sending manually or is there a fixed intervall in which sms will be transfered? Still a problem exists. If we try to send a sms directly from the bsc_hack_vty with "subscriber extension xxx sms send "TEXT"", the bsc_hack crashes: <0008> paging.c:225 Start paging of subscriber 36 on bts 0. <0008> paging.c:225 Start paging of subscriber 36 on bts 1. <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0008> paging.c:87 Going to send paging commands: imsi: '262012840035907' tmsi: '0x79d38c8e' <0004> abis_rsl.c:1165 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(871) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x15 <0004> abis_rsl.c:969 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0009> abis_rsl.c:831 MEASUREMENT RESULT NR=0 RXL-FULL-ul=-108dBm RXL-SUB-ul=-108dBm RXQ-FULL-ul=6 RXQ-SUB-ul=6 BS_POWER=0 NOT VALID NUM_NEIGH=0 <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) Failure Event Report Type=processing failure Severity=warning level failure <0000> abis_rsl.c:1276 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION <0003> gsm_04_08.c:799 PAGING RESPONSE: mi_type=0x04 MI(2043907214) <0003> gsm_04_08.c:817 <- Channel was requested by 262012840035907 <0008> paging.c:289 Stop paging on bts 0, calling cbfn. <0007> gsm_04_11.c:1151 paging_cb_send_sms(hooknum=1, event=0, msg=(nil),lchan=0x85365d8, sms=0x859cd58) <0008> paging.c:293 Stop paging on bts 1 silently. <0009> abis_rsl.c:831 MEASUREMENT RESULT NR=1 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=6 RXQ-SUB-ul=6 BS_POWER=0 L1_MS_PWR= 2dBm L1_FPC=0 L1_TA=0 NOT VALID NUM_NEIGH=0 <0000> abis_rsl.c:1276 (bts=0,trx=0,ts=0,ss=0) SAPI=0 DATA INDICATION <0003> gsm_04_08.c:835 CLASSMARK CHANGE CM2(len=3) CM3(len=2) <0009> abis_rsl.c:831 MEASUREMENT RESULT NR=2 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 2dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm RXL-SUB-dl=-47dBm RXQ-FULL-dl=7 RXQ-SUB-dl=3 NUM_NEIGH=1 <0009> abis_rsl.c:863 IDX=0 ARFCN=877 BSIC=63 => -56 dBm <0000> abis_rsl.c:1276 (bts=0,trx=0,ts=0,ss=0) SAPI=3 ESTABLISH CONFIRM <0007> gsm_04_11.c:1125 rll_ind_cb(lchan=0x85365d8, link_id=3, sms=0x859cd58, type=0 <0007> gsm_04_11.c:1057 send_sms_lchan() <0001> transaction.c:69 subscr=0x859cb98, subscr->net=0x8533960 Program received signal SIGSEGV, Segmentation fault. 0x003a4785 in ?? () from /lib/tls/i686/cmov/libc.so.6 gdb bt prints out: Program received signal SIGSEGV, Segmentation fault. 0x003a4785 in ?? () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0x003a4785 in ?? () from /lib/tls/i686/cmov/libc.so.6 #1 0x001729e9 in gsm48_encode_bcd_number (bcd_lv=0xbffff130 "", max_len=12 '\f', h_len=1, input=0xa6 <Address 0xa6 out of bounds>) at gsm48_ie.c:83 #2 0x080d137d in gsm340_gen_oa (conn=0x8536990, sms=0x8592f90) at gsm_04_11.c:423 #3 gsm340_gen_tpdu (conn=0x8536990, sms=0x8592f90) at gsm_04_11.c:461 #4 gsm411_send_sms_lchan (conn=0x8536990, sms=0x8592f90) at gsm_04_11.c:1096 #5 0x080bfe2f in complete_rllr (rllr=0x8592f18, type=BSC_RLLR_IND_EST_CONF) at bsc_rll.c:59 #6 0x080b7238 in abis_rsl_rx_rll (msg=0x8591db8) at abis_rsl.c:1303 #7 abis_rsl_rcvmsg (msg=0x8591db8) at abis_rsl.c:1728 #8 0x080c3c8a in handle_ts1_read (bfd=0x858550c, what=<value optimized out>) at input/ipaccess.c:489 #9 ipaccess_fd_cb (bfd=0x858550c, what=<value optimized out>) at input/ipaccess.c:597 #10 0x0016f925 in bsc_select_main (polling=1) at select.c:119 #11 0x08050289 in handle_gsm_bs () at gsm_bs.cpp:864 #12 0x08084343 in main (argc=2, argv=0xbffff884) at main.c:472 Maybe someone expirienced the same problems or can provide some help? Best Regards and Thank you, Richard Zahoransky

13 years, 10 months

2
2
0 0

GSM video lectures (en)

by Benjamin Hagemann

Hello, I found some english lectures about communication by university Freiburg (germany) as video: http://itunes.uni-freiburg.de/uebersicht/podcast_content?id_content=48 e.g. Protocols and technologies of telephone networks ISDN network functions, introduction to GSM digital mobile Extension of GSM overview GSM data services UTMS as the world wide 3G mobile standard You can watch it online as flash or download a .mp4 file :) -- regards, Benny gpg 0xFC505AB0 jabber benny(a)benny.de sip benny(a)benny.de

13 years, 10 months

1
0
0 0

Bug in "subscriber ... name", if name contains spaces

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! I found a bug in OpenBSC. If I try to change the name of a subscriber using Telnet (command "subscriber ... name") I got an error, if the name contains spaces (for example: first and lastname). I found the problem and I wrote a patches. I send it as attachment. Greetings - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMH1ulAXzltVKV/2wRAlV9AJ9NoQUnUs9HL0d/UnExoBzfjbgZzwCeMJPy NFRpXWHlpRKMTYftSrbqehI= =b5i3 -----END PGP SIGNATURE-----

13 years, 10 months

2
1
0 0

Measuring signal

by Sylvain Munaut

Hi, > I'm reading the book "Die GSM-Dm-Kanäle im Dialog" by Joachim Göller, > and I learned, that a mobile phone sends, about every second, a > MEASUREMENT REPORT to the station, where it is logged. > In this report the mobile sends the signal power of the cell, where > it is logged, and of other neighborhood cells. > With these signals, I can measure the distance of the mobile from my > cell(s). > > But I don't understand how can I get this values using OpenBSC. It only does that when in an active dedicated channel (either a call or a sms or some other transaction). If you enable the debug for the DMEAS (either in the console or with the -d option), you should see those reports. Also, it sends reports only for neighbor cell of your network (as specified in the BCCH SI messages). Cheers, Sylvain

13 years, 10 months

3
9
0 0

[PATCH] Solving problem of "ambiguous column name"

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! As I promise, here my patch, to solve the problem I explained on 18.06.2010. I'm now sure, my patch is NOT responsible of the problem sending SMS, then I'd like to submit it to the list. Greetings - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIdheAXzltVKV/2wRAnhaAJ96NdDGLzdAxvn6e1XV8uF8Xf62mACgqbPp AD8uCeWjX/poI/fycmE0R1Y= =+3SS -----END PGP SIGNATURE-----

13 years, 10 months

1
0
0 0

Measuring signal

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, again! I have another question, and this is: how can I measure the distance of a mobile from a BTS? I'm reading the book "Die GSM-Dm-Kanäle im Dialog" by Joachim Göller, and I learned, that a mobile phone sends, about every second, a MEASUREMENT REPORT to the station, where it is logged. In this report the mobile sends the signal power of the cell, where it is logged, and of other neighborhood cells. With these signals, I can measure the distance of the mobile from my cell(s). But I don't understand how can I get this values using OpenBSC. Can someone explain me how can I do this? Thanks a lot! - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIb5RAXzltVKV/2wRAv4zAKDpdHjed/uWweDtoknOaaHIOZlB1QCgtkhs 2jxsdaR/Y2ZmHdT1Nh/mVVY= =9tWf -----END PGP SIGNATURE-----

13 years, 10 months

1
0
0 0

[BUG REPORT]: Unable to send SMS

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! It seems not possible to send SMS anymore with the yesterday's version of OpenBSC (0.9.0.889-f7a1c). I tryed with another old version (0.9.0.531-b938) and it works (same NanoBTS, same configuration). If I activate the log on Telnet I get: <0002> gsm_04_08.c:621 <- CM SERVICE REQUEST serv_type=0x04 mi_type=0x04 M(1552623826) <0012> db.c:159 DBI: 1: ambiguous column name: updated <0002> gsm_04_08.c:572 -> CM SERVICE ACK <0012> db.c:159 DBI: 1: ambiguous column name: updated <0004> abis_rsl.c:1313 RF release on (bts=0,trx=0,ts=2,ss=0) but state ACTIVE <0004> abis_rsl.c:1024 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state ACTIVE <0004> abis_rsl.c:1313 RF release on (bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1024 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE on the old version, and: <0002> gsm_04_08.c:770 <- CM SERVICE REQUEST serv_type=0x04 mi_type=0x04 M(1910630704) <0002> gsm_04_08.c:695 -> CM SERVICE ACK <0004> abis_rsl.c:1350 RF release on (bts=0,trx=0,ts=2,ss=0) but state ACTIVE <0004> abis_rsl.c:1039 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state ACTIVE <0004> abis_rsl.c:1350 RF release on (bts=0,trx=0,ts=2,ss=0) but state NONE <0004> abis_rsl.c:1039 (bts=0,trx=0,ts=2,ss=0) CHAN REL ACK but state NONE on the new one. I see, the line 572 (or 695) in gsm_04_08.c, and it is the same function (gsm48_tx_mm_serv_ack), but with other parameters. Has someone else the same problem? How can I solve it? Thanks a lot - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIbMRAXzltVKV/2wRAufHAJ9YkFNYhEXzdNSCuNwDEJcdoICWaACg5SD8 vITTtkdXrlqbxQOHFnoBpeE= =69Za -----END PGP SIGNATURE-----

13 years, 10 months

5
9
0 0

BTS initialization / OML / sequencing

by Harald Welte

Hi! There is a more or less common pattern going through a lot of the problems that we've been debugging recently, e.g.: * ip.access BTS OML initialization sometimes doesn't complete * BS-11 initialization problems (no BCCH content) When I started to write OpenBSC (at that time still called bs11-abis), I didn't know much about GSM 12.21 and was simply starting. As there is no explicit information in 12.21 or 08.59 on whether or not there can be multiple outstanding OML requests on one OML link, I simply assumed that I could send a number of commands without having to wait for their ACK. This made it easy to make quick progress early on in the project. However, now we are facing some problems, e.g. we send RSL messages before OML has completed its initialization. I suspect the BTSs don't like that in a number of cases. Possible solutiosn to this: 1) Always store the last OML command that we have issued and wait for an explicit ACK/NACK before sending the next one. This means all msgb's sent down by abis_nm_sendmsg() will end up in a queue which is dequeued by ACK/NACK responses before sending the next command. It's simple to implement and probably solves some of the ordering issues. However, the caller has no idea when the queued operation will actually complete (or if it will complete) 2) Implement some kind of blocking OML layer that will block the caller of abis_nm_sendmsg() until the ACK/NACK has been received. This means that writing the OML code will be much more natural, i.e. if the BTS returns an error, the OML code can deal with it at exactly the message that has caused the error. However, this would imply that OML bringup would have to spawn one thread for each BTS that is about to be brought up, as we cannot block the full BSC just because one of the BTS's is reinitialized. This would be a big difference from the existing non-blocking asynchronous single-process + single-thread model that we have, and there is probably a bit of thinking required how this would affect concurrent accesses to our data structures. As OML is fairly independent from everything else, I don't think it will be much of an issue, though. At the moment I'm slightly more inclined to actually go for '2', since it is a cleaner solution from my point of view. 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)

13 years, 10 months

4
5
0 0

Correctness / Sequencing / Asynchronous-ness

by Harald Welte

Hi! Some other 'bug' that I discovered while looking at traces recently is in RSL, where we * Send RSL ACTIVATE CHANNEL to open a channel on the BTS side * Send RR IMMEDIATE ASSIGN through the AGCH to the MS and only later receive RSL ACT CHAN ACK. This seems to work fine, since we queue the messages in-order and dequeue them in-order and simply assume the BTS will ACK. but what if it cannot activate the channel due to a hardware problem? Or what if we have a bug and try to assign the same channel twice? However, on the E1 protocol analyzer the ordering of events was reversed, i.e. the IMMEDIATE ASSIGN happened before the RSL CHAN ACT. I couldn't understand why, since we always enqueue at the end of the queue and dequeue from the front. But what I was missing: In a multi-TRX setup, the IMMEDIATE ASSIGN gets sent over the TRX0 (AGCH, part of BCCH) while the RSL CHAN ACTIVATE gets sent over TRX1. Each TRX has its own RSL link, and the TRX0 link might be ready to receive our message a bit sooner than the TRX1 link... So in this case, we send the messages in wrong order, and risk a channel assignment error. What needs to be done is to actually send the RSL CHAN ACT, save the state, wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN. Similar issues might exist in other cases of channel activation, such as handover. -- - 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)

13 years, 10 months

3
3
0 0

Solving the problem "ambiguous column name" in SQL-Queries

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, list! I wrote an E-Mail on 18.06.2010, asking why many errors: <0012> db.c:157 DBI: 1: ambiguous column name: id <0012> db.c:157 DBI: 1: ambiguous column name: updated appear (by sending, over Telnet, "sms send pending" and "subscriber ... name ..."). Now I decided to search in the code for a reason. There are two functions in db.c (db_sms_get_unsent_by_subscr [line 1055] and get_equipment_by_subscr [line 301]) having queries with ambiguous column name. I suggest to correct the queries, adding the table name. Unfortunately, I'm not sure, which names are correct... I think, for db_sms_get_unsent_by_subscr it should be correct so: result = dbi_conn_queryf(conn, "SELECT * FROM SMS,Subscriber " "WHERE sms.receiver_id >= %llu AND sms.sent is NULL " "AND sms.receiver_id = subscriber.id " "AND subscriber.lac > 0 " "ORDER BY sms.receiver_id, sms.id LIMIT 1", min_subscr_id); or better, using JOIN: result = dbi_conn_queryf(conn, "SELECT * FROM SMS JOIN Subscriber " "ON (SMS.received_id = Subscriber.id) " "WHERE sms.receiver_id >= %llu AND sms.sent is NULL " "AND subscriber.lac > 0 " "ORDER BY sms.receiver_id, sms.id LIMIT 1", min_subscr_id); and for get_equipment_by_subscr so: result = dbi_conn_queryf(conn, "SELECT equipment.* FROM Equipment,EquipmentWatch " "WHERE EquipmentWatch.equipment_id=Equipment.id " "AND EquipmentWatch.subscriber_id = %llu " "ORDER BY Equipment.updated DESC", subscr->id); or, with the JOIN: result = dbi_conn_queryf(conn, "SELECT equipment.* FROM Equipment JOIN EquipmentWatch " "ON (EquipmentWatch.equipment_id = Equipment.id) " "WHERE EquipmentWatch.subscriber_id = %llu " "ORDER BY Equipment.updated DESC", subscr->id); but, as I said, I'm not sure... Can someone confirm me, that I understood the queries correctly and my correction proposals are right? If they are right, I'll write a patch and submit it to the list. I think, correcting this bug is important, since the queries with this ambiguous column name will NOT be executed. Thanks a lot - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMIH4WAXzltVKV/2wRAr/mAJ9cQGOgl+ZTiutmehhS1aaeFegAmgCfWDxu gUh/bQqXuK6PKdzWQ7gq6oo= =GgRb -----END PGP SIGNATURE-----

13 years, 11 months

1
0
0 0

OpenBSC unsubscribe notification

by mailman-bounces＠lists.gnumonks.org

openbsc(a)walsleben.info has been removed from OpenBSC.

13 years, 11 months

1
0
0 0

show subscriber cache and sms send pending

by jason mercury

Hi to all, I couldn't use sms send pending and show subscriber cache commands of Telnet interface. Could anybody explain the functions and usage of these commands? Thanks. Jason.

13 years, 11 months

2
1
0 0

Location of the DB of OpenBSC

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! OpenBSC saves his DB normally in the current directory, but I can overwrite this property with -l. Now I'd like to know WHERE OpenBSC created the DB, and what is his name. Is it possible? I searched in the telnet's commands but I found anything useful... Thanks a lot - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMH27kAXzltVKV/2wRAhf5AKCTWzNChFAa+p8NfWppobxLCOU91wCcCaAd Ez8o4AvIPuC0lvrSU89sBDo= =++RV -----END PGP SIGNATURE-----

13 years, 11 months

3
3
0 0

[PATCH] * gmtime(NULL) returns NULL at least in glibc and *can not* be used as time(NULL). Since we compare two time_t values when checking the validity period this can be replaced by time(NULL)

by Nico Golde

--- openbsc/src/gsm_04_11.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index ee0aba5..5a2b231 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -305,7 +305,7 @@ static unsigned long gsm340_vp_absolute(u_int8_t *sms_vp) unsigned long minutes; expires = gsm340_scts(sms_vp); - now = mktime(gmtime(NULL)); + now = time(NULL); if (expires <= now) minutes = 0; else -- 1.7.1

13 years, 11 months

2
1
0 0

State of Frequency Hopping in OpenBSC

by Harald Welte

Hi! I've now merged the 'laforge/hopping' branch to master, and wanted to update you on the state of frequency hopping support: First, the bad news: It is still not working with the BS-11 :( All OML attributes that I can think of are set correctly, they have been verified from wireshark, and the BTS acknowledges all those attributes. On RSL, the channels are activated the right way, and even the SYSTEM INFORMATIO 1 (cell channel allocation) as well as the chennel description and mobile allocation parts of the IMMEDIATE ASSIGN are encoded correctly. Still, the MS and BTS fail to establish any hopping channel. Dieter is now trying to get the BS-11 hopping configuration working with his Racal 6113. If that works, the protocol trace should reveal where we still do something wrong. If you want to play with it: The BTS attributes as well as the TRX attributes are not yet 100% finished like they should be. So you need to apply the attached patch as a hack on top of master. Please note that the bs11_attr_radio_trx1 contains hard-coded ARFCN 117 and 119, i.e. you will have to modify this unless your hopping sequence also only consists of those two ARFCN. I've also attached a config file for your reference. -- - 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)

13 years, 11 months

1
1
0 0

Bug in OpenBSC?

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, list! I have a NanoBTS connected to my KUbuntu Hardy. I compiled the last version of OpenBSC from GIT (0.9.0.860-71d36) and it runs. Now, if I give (from Telnet) the command "sms send pending" I get in the Log the following message: <0012> db.c:157 DBI: 1: ambiguous column name: id And, if I send a "subscriber" command (extension, name, etc.) I get: <0012> db.c:157 DBI: 1: ambiguous column name: updated Maybe there are some problem with the SQL-queries? The same version on Debian lenny does not have problem. Thanks a lot! - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMG20/AXzltVKV/2wRAmF6AKCTrG6E8Tw2yYN5fx1nECuv/9UYwQCgsOE0 1CMPlGxfpXa4WlEtHwa+ciA= =63FZ -----END PGP SIGNATURE-----

13 years, 11 months

1
0
0 0

Last openbsc version known-working for BS-11?

by Harald Welte

Hi! This is to all those BS-11 users out there: What was the last version (git version number preferrably) of OpenBSC that has been working fine for you? I've tried today. Everything seems to work fine from the OpenBSC side, i.e. OML and RSL are initialized. On the Air interface howerver, I can only see the carrier (RxLev) on the ARFCN go high, but the phones never get further than decoding the BSIC. They don't list the network in the network selection, and they never consider selecting this cell if it is part of a bigger network. I thought of some problem in the SYstem Information, but after checking them manually in wireshark (from the bsc_hack generated pcap file), there seems no obvious mistake. So I'm suspecting some kind of regression in current OpenBSC. Thus my question for feedback: Which version did you last use successfully with the BS-11? Thanks, 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)

13 years, 11 months

1
1
0 0

Request for help on the BSC API

by Holger Hans Peter Freyther

Hi, I landed the first big change, the gsm48_rcvmsg is now inside the bsc_api.c. And on first msg the BSC API will call the compl_l3 (COMPLETE LAYER3) callback. This method will always be called for any new connection and is the perfect place to enable encryption.. I would be very happy if someone could take the task and change the osmo_msc.c and gsm_04_08.c to first make use of the ACCEPT/REJECT policy and then enable the auth/security on this new connection and then dispatch the original message (but CM Service Reject). Another task would be to move the Cipher Mode code into the BSC API, the gsm_04_08.c code should not directly change the attributes in the lchan and should not send the cipher mode RR message. The next thing to kill is the unconditional usage of &lchan->conn as I will start allocating the conn dynamically... (one conn can have multiple lchan's for handover and early assignment). I will now work on refcounting and moving the transaction into the subscriber connection...(some other work before) so I will probably not make it before sunday as I will be out of town. regards holger

13 years, 11 months

2
1
0 0

AW: Problem compiling OpenBSC on Kubuntu Hardy

by Andreas.Eversberg

diff --git a/openbsc/src/gsm_04_11.c b/openbsc/src/gsm_04_11.c index 57d8089..faa5f69 100644 --- a/openbsc/src/gsm_04_11.c +++ b/openbsc/src/gsm_04_11.c @@ -340,14 +340,14 @@ static unsigned long gsm340_validity_period(u_int8_t sms_vpf, u_int8_t *sms_vp) /* ignore additional fi */ if (fi & (1<<7)) sms_vp++; /* read validity period format */ - switch (fi & 0b111) { - case 0b000: + switch (fi & 0x7) { + case 0x0: return gsm340_vp_default(); /* no vpf specified */ - case 0b001: + case 0x1: return gsm340_vp_relative(sms_vp); - case 0b010: + case 0x2: return gsm340_vp_relative_integer(sms_vp); - case 0b011: + case 0x3: return gsm340_vp_relative_semioctet(sms_vp); default: /* The GSM spec says that the SC should reject any ---------- -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther Gesendet: Donnerstag, 17. Juni 2010 16:26 An: openbsc(a)lists.gnumonks.org Betreff: Re: Problem compiling OpenBSC on Kubuntu Hardy On 06/17/2010 10:20 PM, Luca Bertoncello wrote: > Hi, List! > > gsm_04_11.c:364:8: Fehler: ungültiger Suffix »b011« an Ganzzahlkonstante Your compiler does not like to have numbers in binary, please prepare a patch (I say that once a month and then nothing happens) to use these in hex.

13 years, 11 months

3
2
0 0

Problem compiling OpenBSC on Kubuntu Hardy

by Luca Bertoncello

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, List! I'm trying to compile OpenBSC (last version from GIT) on my KUbuntu Hardy (8.04). Unfortunately, I get this error: make[3]: Betrete Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I.. -Wall -I/usr/local/include/ -I/usr/local/include/ -g -O2 -MT gsm_04_11.o -MD -MP -MF .deps/gsm_04_11.Tpo -c -o gsm_04_11.o gsm_04_11.c gsm_04_11.c:357:16: Fehler: ungültiger Suffix »b111« an Ganzzahlkonstante gsm_04_11.c:358:8: Fehler: ungültiger Suffix »b000« an Ganzzahlkonstante gsm_04_11.c:360:8: Fehler: ungültiger Suffix »b001« an Ganzzahlkonstante gsm_04_11.c:362:8: Fehler: ungültiger Suffix »b010« an Ganzzahlkonstante gsm_04_11.c:364:8: Fehler: ungültiger Suffix »b011« an Ganzzahlkonstante gsm_04_11.c: In Funktion »gsm340_rx_tpdu«: gsm_04_11.c:563: Warnung: Vergleich ist durch beschränkten Wertebereich des Datentyps stets »unwahr« make[3]: *** [gsm_04_11.o] Fehler 1 make[3]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Verlasse Verzeichnis '/home/lucabert/BSC/openbsc/openbsc' make: *** [all] Fehler 2 I see the line in gsm_04_11.c and it seems OK. What is the problem? Ubuntu Hardy uses gcc 4.2.4. Thanks a lot! - -- _______________________________________________________________________ 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 _______________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMGi88AXzltVKV/2wRAvkcAKCehGaHly78lnO1j7DXdzk72lPycgCfYVzd 9RIkN4/q3i3Es4Y0HIFLJpk= =u1eY -----END PGP SIGNATURE-----

13 years, 11 months

3
2
0 0

Re: open bsc and lcr: layer_3 thread read socket error

by Richard Zahoransky

-------- Original-Nachricht -------- > Datum: Tue, 15 Jun 2010 21:02:12 +0800 > Von: Holger Freyther <zecke(a)selfish.org> > An: openbsc(a)lists.gnumonks.org > Betreff: Re: open bsc and lcr: layer_3 thread read socket error > On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > > Hello, > > > > my name is Richard and I am working on OpenBSC and LCR for my > university. We plan to deploy a GSM-Network on the campus for research. > > Hi, > > where is that university located? It is the Albert-Ludwigs-Universität in Freiburg, Baden-Württemberg, Germany. > I can't help with LCR but as a general > hint you can use strace and at least see which filedescriptor returned > that error, it might be a hint. > > Have you tested the BTS with something like bsc_hack? Does this work? > Yes, bsc_hack works with no problems. Thank you for your advice! We have solved the problem. We simply didn't load the mISDN_dsp module. We did not integrate the mISDN_l1loop into the kernel but start it with insmod mISDN_l1loop.ko (located in a subfolder of the mISDN-Folder after running 'make') Still, if we load the l1loop with -nchannel=30 the lcr would somtimes print out the already said error message but it doesn't hang. It is then still possible to place a phone call from the cell phones. As workaround, we load the module with 8 channels instead of 30. It seems to work without the error message. Only one error is left. LCR prints: 'ERROR Port 1 already in use by LCR. You can't use a NT port multiple times.' On startup. Outgoing calls work but we still have to test incoming calls.

13 years, 11 months

1
0
0 0

Status of the BSC/MSC API split

by Holger Freyther

Hi all, here is just a small information of what is going on and what will happen in the near future. Done: - Create bsc_api.c for the BSC API handling - Create osmo_msc.c for the callbacks... - Start to remove lchan usage from MSC code What will happen: - No MSC code will directly touch/use/know about the lchan - Move the gsm48_recvmsg into the BSC API and dispatch - The transaction will be anchored inside the subscriber con and no transactions will clear the channel immediately - Need to add API for Cipher, Handover, Assignment handling - pick a better name for subscriber_connection. What can happen after this: - We can reimplement the bottom of the BSC API with SCCP and have a true MSC codebase... If any of you is adding new L3 code, please do not use the LCHAN directly but the subscriber connection. thanks holger

13 years, 11 months

1
0
0 0

AW: Operation management in the MSC code

by Andreas.Eversberg

>1.) kill the transaction... >2.) generalize it with the "operation". Right now we do have two >operations, one for LU, one for AUTH, we should have them for USSD, SMS >and CC as well. hi holger, the "transaction" represents the instance of calling party / called party / sms sender / ... will the states of it be moved to the "operation"? (e.g. call state, transaction_id, callref, protocol) in this case the call control / sms must use "operation" instance instead. i currently use "transaction" in osmocom-bb for call control and later sms and supplementary services. i think that the sms code should be re-usable in osmocom-bb, so the "operation" instance should be equal (defined in libosmocore) and the sms function sould be available in something like a "libsms", like the "libvty". note: osmocom-bb is at a point where SMS could be sent and received, if a shared sms library would be available. andreas

13 years, 11 months

3
2
0 0

open bsc and lcr: layer_3 thread read socket error

by Richard Zahoransky

Hello, my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research. We have successfully installed OpenBSC, Asterisk, LCR and mISDN. Lcr starts correctly (as far as I can say). The nanoBTS connects to OpenBSC and boot up. On the local machine, we can place outgoing calls with asterisk but when we dial from the cellphones, the lcr prints out: "layer3_thread read socket error No space left on device". I don't know if this is an error in LCR, OpenBSC, mISDN or just in my own config files. We ran through the How-to "OpenBSC_LCR" on http://openbsc.osmocom.org/trac/wiki: gsm is enabled in options.conf GSM interface is active in interface.conf mISDN_l1loop interfaces are created and the routing.conf looks also as described: ----------------------routing.conf (lcr)---------------------- [main] interface=GSM : remote application=asterisk context=btsctrl #interface=xyz : goto ruleset=xyz extern : goto ruleset=extern intern : goto ruleset=intern : disconnect cause=31 ------------------------------------------------------------- the rest of the file is untouched. on the local asterisk, the chan_lcr.so is loaded. the context btsctrl is defined is the extensions.conf: ----------------------extension.conf (asterisk)-------------- [default] exten => _0.,1,Dial(SIP/10${EXTEN}@comsys02) [btsctrl] exten => _X.,1,Set,CALLERID(num)=5552342 exten => _X.,n,dial(SIP/10${EXTEN}@comsys02) ------------------------------------------------------------- it connects to the remote asterisk server as user comsys02, defined in sip.conf ----------------------sip.conf (asterisk)-------------------- register => comsys02:xxx@132.230.4.8/comsys02 [general] port=5060 bindaddr=0.0.0.0 [btsctrl] type=friend context=default secret=xxx host=dynamic [comsys02] type=friend context=btsctrl username=comsys02 fromuser=comsys02 secret=xxx host=132.230.4.8 qualify=yes nat=yes ------------------------------------------------------------- now everything seems to work, but when i dial a number, it prints out: "layer3_thread read socket error No space left on device", many times per second. On the phone I hear static noise. lcradmin prints out the following: ACTION (match) action remote line 8 EP(1): ACTION remote (setup) number 076719235 remote as* EP(1): SETUP ACKNOWLEDGE to CH(1) EP(1): TONE to CH(1) directory default name dialing EP(1): TONE to CH(1) directory default name cause_10 EP(1): DISCONNECT to CH(1) cause value=16 location=1-Lo* CH(1): MNCC_DISC_REQ LCR<-BSC port 1 progress coding=3 * CH(1): MNCC_REL_IND LCR<-BSC port 1 cause coding=0 loca* EP(1): RELEASE from CH(1) cause value=31 location=1-Loc* EP(1): ACTION hangup and the local asterisk output is: NOTICE[10941]: chan_lcr.c:1731 handle_retry: [call=NULL ast=NULL] Retry to open socket. NOTICE[10941]: chan_lcr.c:364 send_message: [call=NULL ast=NULL] Sending MESSAGE_NEWREF to socket. maybe someone also encountered this problem or can help us with the configuration many thanks in advance and best regards, richard

13 years, 11 months

3
2
0 0

AW: open bsc and lcr: layer_3 thread read socket error

by Andreas.Eversberg

hi, first try the bsc_hack. it has a bult-in MSC, so you can call from mobile phone to mobile phone. if this works, try to use LCR without asterisk. if you have no ISDN card, then you can also dial via LCR from mobile to mobile. if this works, then try asterisk... andreas On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > Hello, > > my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research.

13 years, 11 months

1
0
0 0

Operation management in the MSC code

by Holger Freyther

Hi, I am going through the SMS code right now and try to convert it to the BSC API and there is something that is quite bad. There are many paths were sending a SMS can end, some do not free the SMS, some not the transaction, some do not remove lock on the channel. I would like to make the radical proposal to solve that. 1.) kill the transaction... 2.) generalize it with the "operation". Right now we do have two operations, one for LU, one for AUTH, we should have them for USSD, SMS and CC as well. Each gsm_subscriber_connection (MSC data) has an operation manager, when a lchan is opened we will attempt to create an operation for the initial message, at the end of one operation the operation manager will check if all operations are completed and then send a clear using the BSC API. The consequence of that is: 1.) we get rid of the refcount and can close channels faster 2.) we will notice... when we run into a timeout and should not... I know this will be a bigger change on the MSC side of things but what do you guys think about it? z.

13 years, 11 months

2
1
0 0

GPRS/SGSN progress update

by Harald Welte

Hi all, I've been working on the SGSN code again for two days, and there is quite a bit of progress, even if it doesn't really make much difference in what you can do. I'm still working on the signalling plane, an we still cannot send/receive user plane packets (the actual TCP/IP). However, a number of bugs / misunderstandings have been fixed: 1) When we send BSSGP Downlink-Unitdata, we have to always include the IMSI of the target phone, as well as the "MS Radio Access Capabilities" IE. This is apparently needed for the BTS to know when and how it can schedule packets to be sent on the radio interface. However, I personally think it's an ugly layering violation. All this information is part of the "GMM State" in the SGSN, i.e. higher than layer3. It now needs to be passed through LLC down into BSSGP, where it is used :( 2) LLC UI Frames have sequence numbers that need to be incremented with every frame. 3) Some phones apparently don't like it if they don't get a P-TMSI allocated during GPRS ATTACH and ROUTEING AREA UPDATE. According to the spec, it's optional and I thought I could skip that feature to make things easier initially. 4) There are two levels of C/R (Command/Response) bits, one at the LLC and the other at the BSSGP layer. The LLC bit is now set correctly, but the BSSGP C/R packet seems to be set even wrong by the BTS. However, I'm now simulating the behaviour of exissting Gb protocol traces 5) The 04.08 GMM timers T3350 and T3370 have been implemented properly, including re-transmissions of the according MM frames 6) As part of P-TMSI Reallocation, there are time windows when the SGSN has to consider both the old and the newly allocated P-TMSI are valid simultaneously Finally, I've found one other bug that I'm about to fix now: When we assign a new P-TMSI, this implicitly means that the TLLI will change, too. Since the TLLI changes, the LLC protocol created a new "LL Entity" data structure and re-started the sequence number at 0, resulting in all messages being dropped in the phone until the sequence number is higher than the previous one. I have some hope that this is the last bug before I can see packets on the data plane coming out the TUN device on OpenGGSN. After that, there are still the following major TODOs: * actually check the HLR rather than accepting every IMSI * implement BSSGP flow control for BVC and MS level * implement SNDCP fragmentation/reassembly Followed by more optional features, such as * implement SNDCP header compression * implement SNDCP payload compression * implement LLC re-transmissions * implement GEA3 encryption 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)

13 years, 11 months

3
7
0 0

Encryption branch

by Harald Welte

Dear Sylvaion, I've tried my best to forward-port your 'sylvain/encryption' branch to current OpenBSC, and you can find the result in laforge/encryption. I haven't yet had time to test it, but I wouldn't be surprised to see something break, considering that your code predated the introduction of 'gsm_subscriber_connection'. Unfortunately merging the branch to master is also not really an option right now, as it is likely to cause trouble with the BSC/MSC split, as we will have to align our encryption support with how the A-Interface between BSC and MSC handles things. Nonetheless, I really would like to see this feature move ahead. There is definitely a demand for it in the research community. 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)

13 years, 11 months

4
13
0 0

UMTS support??

by Nordin

Well guys, Just being curious, are there any plans for UMTS support? I remember Harald said something about an ASN.1 PER was an obstacle to start for UMTS support. Are there also nanoBTS for UMTS, I only know of 2G devices... It was just quite on the list :p Greetz, Nordin :-)

13 years, 11 months

4
6
0 0

Hello, UMTS support and HSS/HLR

by Dragos Vingarzan

Hi guys, wow, finally found this project/list :). First a bit of background: working at Fraunhofer FOKUS, in Berlin; "maintaining" openimscore.org (when I still find the time); working on openepc.net; currently doing some prototypes for the LTE access part - MME/HSS/eNodeB - only Layer 3 and up. What brings me here is that I have a need for getting a test-bed setup as complete as possible, without black-boxes.The ultimate dream is to have everything from radio to application layers running on COTS hardware for test-bed purposes (nothing commercial). Obviously I am coming from the upper layers to the lower ones, as we had to satisfy first the Application Server guys. So far we've done prototypes for P/I/S-CSCF, HSS(Cx,Sh) and some light MGCF, BGCF/etc with the OpenIMSCore. With OpenEPC we are adding some PDN-Gw, ANGw(SGw/ePDG), PCRF, PCEF, BBERF, ANDSF, HSS (Sp) and working on the afore-mentioned MME, HSS(S6a,etc), eNodeB. Of course, all are prototypes, but we try to make them as inter-operable as economically feasible. Now I am also very interested in UMTS. We're demo-ing EPS hand-overs and the sort between WiFi, LTE (just using it as an air bridge for now) and 3G, but we use commercial 3G, which is quite frustrating as it seems to have a directly proportional probability to fail with the number of phones present in the demo room. However, I do have an Oyster 3G femto from ip.access and would very much like to explore on how can I use it in an environment completely under control. I know about other BTS alternatives, but I really just need the PS part and I need good data-rates. (CS is out of scope for me as it's supposed to be phased out at a point and we have already the all-IP stuff on top, even like 3GPP likes to see it) I see that I am not the only one interested. Now I am still trying to get some more documentation from ip.access. If any of you already figured out how to do the basic operations or at least what is required, I would really appreciate the pointers. Then regarding the HLR - it seems that you have some troubles with it. Well, we have done a couple of HSSs in the past 5 or so years, which is supposed to be an HLR evolution suitable for all-IP environments. So we have all the irrelevant, but required, DB back-end, provisioning interfaces or AKA authentication sorted. Unfortunately it only has support for Diameter, with RADIUS on the road-map due to integration with non-3GPP trusted access networks (WPA with EAP-SIM/EAP-AKA). Also these days I am trying to add support for LTE network attachments through the S6a Diameter interface. If you can provide me with some quick requirements to what you need for the HLR, I hope that we could help. Cheers, -Dragos

13 years, 11 months

2
2
0 0

bts for sale

by Rabbit

Sorry for the intrusion but I thought maybe someone here would be interested. I have two ipaccess bts 165au to sell. Both are fully working with POE. I'm also including the ipaccess software and manuals. Software: BTS installer, BTS Manager, IPaccess BSC which runs on redhat(all rpm files). Also have an msc which runs on windows but you'll need a license and dongle to make it work or defeat the dongle. Documentations are PDFs. You can pick it up in London or can ship it. pics: http://tinypic.com/3ia3muxg

13 years, 11 months

3
3
0 0

Rejecting cause

by jason mercury

Hi , I have same problem with Luca. I could not attach my phone (Nokia N79) to the network unless I close and re-open my phone. When authorized=0 I could not see any location update reject log related my phone on the screen. Changing reject cause was helpful for some other phones but It did not work for N79. I have seen a error message on the bsc_hack screen I think that this can be related to the problem: <0000> abis_rsl.c:1237 (bts=0,trx=0,ts=0,ss=0) ERROR INDICATION cause=Timer T200 expired (N200+1) times Please help. Thanks. Jason.

13 years, 11 months

2
1
0 0

Rejecting cause

by Luca Bertoncello

Hi, all! If I try to change to my Test-Network with my mobile phone (not known from network and not yet authorized!!) I can't change (of course). Then I authorize my phone and I try again. It does not work. I have to turn off and on my phone in order to change to the network. I got the information that I can solve this problem by changing the reject cause (location updating reject cause). Unfortunately I don't know any cause that say the phone "OK, try again later", so that my phone will try again later. Can someone help me and say me a code? I have to give a numeric code, but I don't know any. It was suggested to send a "network failure" or "congestion" or "overload", but I don't know the code for these cause... Thanks 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 _______________________________________________________________________

13 years, 11 months

2
1
0 0

Future of the HLR

by Harald Welte

Hi all! One of the issues I want to adress in the coming weeks is the HLR. At the moment, we don't have an HLR in the traditional GSM sense. We have something that corresponds to the same function, but without all of the usual interfaces. This is not a problem in itself, as we do not intend to interwork the internal-MSC of the OpenBSC with a traditional HLR at this point. The current implemnetation just synchronously calls subscriber_get(), which does a database lookup. It expects this lookup to succeed synchronously, which is only true as long as nobody else is accessing the hlr.sqlite3 database simultaneously. This is problem 'A'. Simultaneous accesses to the database could either be manual updates, or the 'hlrsync.pl' script, or some other kind of user interface to the database. The problem gets worse if we now start to have a SGSN. The SGSN currently does not access hlr.sqlite3. But if I start to implement it, we will have concurrent accesses from bsc_hack and osmo-sgsn to the sqlite3 database, which means that problem 'A' will become worse. So what needs to be done: 1) Accesses like subscriber_get() need to become asynchronous, i.e. at the time we search for a subscriber we simply issue a call and do some state transition. Once the database process is finished retrieving the subscriber data, we can continue the operation. 2) Introduce an actual message-based protocol between the HLR database process and the OpenBSC and OsmoSGSN software. Both of those fit together quite nicely. And rather than inventing our own protocol, we should directly use the GSM MAP (09.02) messages intended for the respective operations. That might sound complex, but we can leave out the other parts of SS7 (MTP, SCCP, TCAP) for now. But if we already start to encode the information elements and messages themselves according to MAP, we would have a very clear migration path towards * turning our HLR into something that can interoperate with real GSM networks * allowing our Layer3/MSC code in OpenBSC to use a real GSM HLR The MAP asn.1 code can be processed quite nicely by asn1c, thus it should be possible to integrate with our C code quite nicely. I'm right now studying TCAP and how it is being used by MAP in order to determine if (and how much of) TCAP we would need. After that is finished, I'll likely start working on a minimal HLR process (using the sqlite3 database backend) and then convert the OpenBSC code to asynchonous MAP-based subscriber lookups. 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)

13 years, 11 months

1
0
0 0

Setting the power of a BTS

by Luca Bertoncello

Hi, List! I'm new to OpenBSC, and I'm experimenting some configuration of the program. Now I have to try to change the power of the BaseStation, so that I can set how far mobile phones can catch the signal of my BaseStation. I thought, I can change the values of "ms max power" or "nominal power", but I don't see any difference. Is it possible to do what I try? If yes, how? Thanks for any 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 _______________________________________________________________________

13 years, 11 months

5
10
0 0

OpenBTS OML sequencing / startup problems

by Harald Welte

Hi zecke, one of the things that I've been thinking about earlier today while talking with Roch was the fact that we do the A-bis OML overlapping / asynchronously, i.e. if we send a 'set attribute ...' or 'opstart' message, we never wait for the acknowledgement before sending the next message. While this might be efficient and compliant with the specification, it is likely to expose bugs like race conditions in software that has never been tested against it. So one of the ideas would be to make the abis_nm.c layer queue up messages during abis_nm_sendmsg() and determine based on the messagetype if it is a message that we're expecting an ACK/NACK as response. If yes, delay transmission of further enqueued OML messages until such ACK/NACK is received. Of course, there probably should also be a timer whose expiration should generate at least a log file entry (and after which we continue with the next message from the queue) I'm not sure if you feel in the mood for implementing something like this or not. I can also stop with GPRS work and have a look at it. This request/response tracking would probably also be useful once we extend our ability to send OML messages from e.g. external applications. We could then notice who submitted the message and deliver the result back to the caller without having to consider re-ordering or something like that. Regards, Harlad -- - 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)

13 years, 11 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2010