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