OpenBSC

openbsc@lists.osmocom.org

4315 discussions

[PATCH] Solving problem of "ambiguous column name"
by Luca Bertoncello 23 Jun '10

23 Jun '10

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

1 0

Measuring signal
by Luca Bertoncello 23 Jun '10

23 Jun '10

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

1 0

[BUG REPORT]: Unable to send SMS
by Luca Bertoncello 23 Jun '10

23 Jun '10

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

5 9

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC