OpenBSC

openbsc@lists.osmocom.org

4315 discussions

State of Frequency Hopping in OpenBSC
by Harald Welte 21 Jun '10

21 Jun '10

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)

1 1

Bug in OpenBSC?
by Luca Bertoncello 18 Jun '10

18 Jun '10

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

1 0

Last openbsc version known-working for BS-11?
by Harald Welte 18 Jun '10

18 Jun '10

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)

1 1

Request for help on the BSC API
by Holger Hans Peter Freyther 17 Jun '10

17 Jun '10

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

2 1

AW: Problem compiling OpenBSC on Kubuntu Hardy
by Andreas.Eversberg 17 Jun '10

17 Jun '10

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.

3 2

Problem compiling OpenBSC on Kubuntu Hardy
by Luca Bertoncello 17 Jun '10

17 Jun '10

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

3 2

Re: open bsc and lcr: layer_3 thread read socket error
by Richard Zahoransky 16 Jun '10

16 Jun '10

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

1 0

Status of the BSC/MSC API split
by Holger Freyther 16 Jun '10

16 Jun '10

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

1 0

AW: Operation management in the MSC code
by Andreas.Eversberg 15 Jun '10

15 Jun '10

>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

3 2

open bsc and lcr: layer_3 thread read socket error
by Richard Zahoransky 15 Jun '10

15 Jun '10

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

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC