- OpenBSC - lists.osmocom.org

BTS initialization / OML / sequencing
by Harald Welte 23 Jun '10

23 Jun '10

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)

4 5

Correctness / Sequencing / Asynchronous-ness
by Harald Welte 22 Jun '10

22 Jun '10

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)

3 3

Solving the problem "ambiguous column name" in SQL-Queries
by Luca Bertoncello 22 Jun '10

22 Jun '10

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

1 0

OpenBSC unsubscribe notification
by mailman-bounces＠lists.gnumonks.org 22 Jun '10

22 Jun '10

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

1 0

show subscriber cache and sms send pending
by jason mercury 21 Jun '10

21 Jun '10

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.

2 1

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