OpenBSC

openbsc@lists.osmocom.org

16 participants
4247 discussions

Location of the DB of OpenBSC
by Luca Bertoncello 21 Jun '10

21 Jun '10

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

3 3

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

21 Jun '10

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

2 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC