OpenBSC June 2010

openbsc@lists.osmocom.org

26 participants
52 discussions

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

15 years, 2 months

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)

15 years, 2 months

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)

15 years, 2 months

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

15 years, 2 months

OpenBSC unsubscribe notification

by mailman-bounces＠lists.gnumonks.org

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

15 years, 2 months

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.

15 years, 2 months

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

15 years, 2 months

[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

15 years, 2 months

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)

15 years, 2 months

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

15 years, 2 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2010