Dear Andreas,
the coverity prevent utility has found three inconsistencies in the
lapd_core.c and the gsm_04_08.c and I think you are suited the best
to comment on how to resolve them.
src/gsm/lapd_core.c
static int lapd_res_req(struct osmo_dlsap_prim *dp, struct lapd_msg_ctx *lctx)
...
1943 LOGP(DLLAPD, LOGL_INFO, "perform re-establishment (SABM) length=%d\n",
1944 msg->len);
...
CID 1040665 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking "msg" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1956 if (msg && msg->len)
so we already dereferenced msg to print the length. So at this point,
is it legetimate to a have NULL msgb or shall the null check be removed?
src/libmsc/gsm_04_08.c
static int gsm48_cc_rx_connect(struct gsm_trans *trans, struct msgb *msg)
...
2090 if (trans->subscr) {
2091 connect.fields |= MNCC_F_CONNECTED;
2092 strncpy(connect.connected.number, trans->subscr->extension,
2093 sizeof(connect.connected.number)-1);
2094 strncpy(connect.imsi, trans->subscr->imsi,
2095 sizeof(connect.imsi)-1);
2096 }
...
CID 1040740 (#1 of 1): Dereference after null check (FORWARD_NULL)
6. var_deref_op: Dereferencing null pointer "trans->subscr".
2117 osmo_counter_inc(trans->subscr->net->stats.call.mt_connect);
2118
2119 return mncc_recvmsg(trans->subscr->net, trans, MNCC_SETUP_CNF, &connect);
trans->subscr is conditionally dereferenced and then unconditionally,
what is correct?
static int gsm48_cc_rx_setup(struct gsm_trans *trans, struct msgb *msg)
...
1761 if (trans->subscr) {
1762 setup.fields |= MNCC_F_CALLING;
1763 strncpy(setup.calling.number, trans->subscr->extension,
1764 sizeof(setup.calling.number)-1);
1765 strncpy(setup.imsi, trans->subscr->imsi,
1766 sizeof(setup.imsi)-1);
1767 }
...
CID 1040739 (#1 of 1): Dereference after null check (FORWARD_NULL)
14. var_deref_model: Passing null pointer "trans->subscr" to function "subscr_name(struct gsm_subscriber *)", which dereferences it. [show details]
1813 LOGP(DCC, LOGL_INFO, "Subscriber %s (%s) sends SETUP to %s\n",
1814 subscr_name(trans->subscr), trans->subscr->extension,
1815 setup.called.number);
1816
1817 osmo_counter_inc(trans->subscr->net->stats.call.mo_setup);
Same thing as above. Can the null check be removed? Would you have the
time to do that?
Hi all,
Attached patch fixes lengths of MS Network Capability and MS Radio
Access Capability elements.
Original code was inconsistent about lengths and could lead to out of
bounds write. Lengths were also inconsistent with the TS 24.008.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Dear members,
In connection with the problem I found, I kindly ask someone, to
please check my configuration, because I want to rule out any
configuration related issue, don't want to waste anyones time with
sending false bug reports.
Currently I am using a GSM1800 Nokia InSite unit with a Dahdi E1 card
and OpenBSC, the DAHDI card is the timing source.
/etc/dahdi/system.conf
span=1,0,0,ccs,hdb3,crc4
bchan=2-31
dchan=1
OpenBSC conf:
password foo
line vty
no login
e1_input
e1_line 0 driver dahdi
network
network country code 1
mobile network code 1
short name OpenBSC
long name OpenBSC
mm info 1
timer t3101 10
timer t3113 60
bts 0
type nokia_site
band GSM1800
cell_identity 1
location_area_code 1
base_station_id_code 63
training_sequence_code 7
ms max power 40
periodic location update 10
oml e1 line 0 timeslot 5 sub-slot full
oml e1 tei 1
trx 0
arfcn 885
nominal power 22
max_power_red 0
rsl e1 line 0 timeslot 4 sub-slot full
rsl e1 tei 1
timeslot 0
phys_chan_config CCCH+SDCCH4
e1 line 0 timeslot 2 sub-slot 0
timeslot 1
phys_chan_config TCH/F
e1 line 0 timeslot 2 sub-slot 1
timeslot 2
phys_chan_config TCH/F
e1 line 0 timeslot 2 sub-slot 2
timeslot 3
phys_chan_config TCH/F
e1 line 0 timeslot 2 sub-slot 3
timeslot 4
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 0
timeslot 5
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 1
timeslot 6
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 2
timeslot 7
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 3
My main concern is about the OML and RSL TEI addresses.
If I understand it correctly, OML TEI identifies the BTS, RSL TEI
identifies the TRX of that BTS. So if I have 2 BTSs and 2-2 TRXs, then
the correct configuration would be looking like this:
BTS0:
oml: te1 1
trx0: tei 1
trx1: tei 2
trx2: tei 3
....
BTS1:
oml: tei 2
trx0: tei 1
trx1: tei 2
trx2: tei 3
...
?
Even the Nokia BTS commissioning documentation is unclear about the
specifics:
sapi =Service access point identifier. (62 for OMUSIG, 0 for TRXSIG.)
tei =Terminal end point identifier. Must the same as defined in the BTS.
Usually the same as the TRX number. For OMU link, the value is 1.
According to this, every OML TEI of every BTS should be "1" ? The
other funny part is, that it sais it must be the same as defined in the
BTS, but Nokia BTS Manager does not have any parameter for TEI or SAPI
to set.
My other concerns are BSIC and Training Sequence Code (TSC).
As I know, BSIC identifies the BTS in a location and/or routing area,
it means that a location/routing area can have 64 BTSs at top
(BSIC=0-63), and every BTS have to use unique BSIC in the same LAC?
TSC is another mystery. Nokia Docs sais:
train_seq = Training sequence code. (eg. BCC value of the BSIC, eg. 7)
This has to be 7 all the time, or if I have more than one BTS (in the
same LAC and on the same E1)I have to change this?
Finally, DAHDI configuration:
How many D channels should I specify? For example if I have 2 BTSs on
the same E1, I have to specify two D channels for every OMUSIG
timeslots? Or I have to specify D channels for every timeslots I use
for signalling (OMUSIG and TRXSIG for all BTSs)? Or maybe I don't have
to allocate even one D channel, because I dedicate separate signalling and TCH
timeslots for every BTS?
I searched a lot about this topic, but the information available is
limited, not specific and most of the time lead to more questions...
I hope someone can enlighten me in this topic.
BR,
Csaba
Hi all,
Attached is a shell script I found useful for monitoring a live
installation of OsmoNITB. I hope it'll be useful for someone else and
propose to check it into the 'contrib' directory of the OpenBSC
repository.
Actually I believe that Holger's zecke/features/nitb-ctrl-interface
branch should be merged into the master, as it makes such monitoring
much easier and failsafe.
PS I think it would be useful create a wiki-page with cheat-sheet of
useful commands during the OpenBSC operation. I could start putting
something together if there are no objections to that. I would
appreciate recommendations for the wiki page name and location too.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Dear members,
It seems that the latest Osmo-nitb (0.13.0.48-9e22) broke
compatibility with Nokia InSite.
I am using a GSM1800 unit with an E1
dahdi card, and with the following config it was working fine with a
previous version (osmo-nitb v.0.13.0.33-e152a4):
openbsc.cfg:
! OpenBSC configuration saved from vty
! !
password foo
!
line vty
no login
!
e1_input
e1_line 0 driver dahdi
network
network country code 1
mobile network code 1
short name OpenBSC
long name OpenBSC
mm info 1
timer t3101 10
timer t3113 60
bts 0
type nokia_site
band GSM1800
cell_identity 1
location_area_code 1
base_station_id_code 63
training_sequence_code 7
ms max power 40
periodic location update 10
oml e1 line 0 timeslot 5 sub-slot full
oml e1 tei 1
trx 0
arfcn 885
nominal power 22
max_power_red 0
rsl e1 line 0 timeslot 4 sub-slot full
rsl e1 tei 1
timeslot 0
phys_chan_config CCCH+SDCCH4
e1 line 0 timeslot 2 sub-slot 0
timeslot 1
phys_chan_config TCH/F
e1 line 0 timeslot 2 sub-slot 1
timeslot 2
phys_chan_config TCH/F
e1 line 0 timeslot 2 sub-slot 2
timeslot 3
phys_chan_config TCH/F
e1 line 0 timeslot 2 sub-slot 3
timeslot 4
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 0
timeslot 5
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 1
timeslot 6
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 2
timeslot 7
phys_chan_config TCH/F
e1 line 0 timeslot 3 sub-slot 3
/etc/dahdi/system.conf
span=1,0,0,ccs,hdb3,crc4
bchan=2-31
dchan=1
Error message with the most recent verion:
root@openbsc:~# osmo-nitb -c /root/1800_nokia.cfg
<0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=62 / TEI=1
<0018> input/lapd.c:223 k=1 N200=3 N201=260 T200=1.0 T203=10.0
<0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=62
<0018> input/lapd.c:212 LAPD Allocating SAP for SAPI=62 / TEI=1
<0018> input/lapd.c:223 k=1 N200=3 N201=260 T200=1.0 T203=10.0
<0018> input/lapd.c:485 LAPD DL-ESTABLISH request TEI=1 SAPI=62
DB: Database initialized.
DB: Database prepared.
<001d> sms_queue.c:220 Attempting to send 20 SMS
<0018> input/lapd.c:624 LAPD DL-ESTABLISH confirm TEI=1 SAPI=62
<0005> bts_nokia_site.c:58 bootstrapping OML for BTS 0
<0005> bts_nokia_site.c:1679 ABIS_OM_MDISC_FOM
<0005> bts_nokia_site.c:1507 (0x81) NOKIA_BTS_ACK
<0005> bts_nokia_site.c:1539 ACK = 1
<0018> input/lapd.c:513 LAPD DL-RELEASE request TEI=1 SAPI=62
<0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62
<0018> input/lapd.c:513 LAPD DL-RELEASE request TEI=1 SAPI=62
<0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62
Segmentation fault (core dumped)
root@openbsc:~#
I have to admit that even with the previous versions I had issues,
like a lot of radio link failures, unstable voice calls (lasting only
1-2 minutes), but now it wont start at all.
Thanks in advance!
Csaba
hi,
i experienced audio glitches while another phone does location updating:
<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x18 to MS.
<0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=0
RXL-FULL-ul=-110dBm RXL-SUB-ul=-47dBm R Q-FULL-ul=0 RXQ-SUB-ul=0
BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 NOT VALID NUM_NEIGH=0
<0003> bsc_api.c:615 CLASSMARK CHANGE CM2(len=3) CM3(len=4)
dbi access time 95ms
Stalled 96ms
<0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=1
RXL-FULL-ul=-66dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0
BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm
RXL-SUB-dl=-47dB RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7
dbi access time 50ms
dbi access time 0ms
dbi access time 49ms
dbi access time 58ms
dbi access time 83ms
dbi access time 0ms
dbi access time 0ms
dbi access time 0ms
dbi access time 72ms
<0003> gsm_04_08_utils.c:315 TX CIPHERING MODE CMD
Stalled 319ms
<0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=2
RXL-FULL-ul=-65dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0
BS_POWER=0 L1_MS_PWR= 0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm
RXL-SUB-dl=-47dB RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7
<0003> osmo_msc.c:105 CIPHERING MODE COMPLETE
dbi access time 0ms
dbi access time 69ms
<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x02 to MS.
<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x32 to MS.
dbi access time 66ms
dbi access time 0ms
dbi access time 0ms
<0003> gsm_04_08.c:1249 TX APPLICATION INFO id=0x00, len=4
<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 06) Sending 0x38 to MS.
dbi access time 0ms
Stalled 140ms
the total time that openbsc was stalling is 555ms in this case. there
are only 4 subscribers in hlr and counter writing is disabled. is there
any trick to make database access faster?
speeding up the db access does not solve the problem. an async db access
is one solution, but there is other code at openbsc that might require
some time. (e.g. handling of many measurement reports) one solution is
to have an own thread for the audio processing. this thread must access
different interfaces independently from the rest of the openbsc code:
- RTP sockets
- MNCC socket
- TRAU sockets of E1 timeslots
MNCC socket could be split into two sockets: one for signalling, one for
audio traffic. this way it is not required to use queues and signals
between main thread and audio thread. a problem in case of
multithreading is osmo_select_main(). it uses global list of file
descriptors and global rb-tree for timers. one solution would be having
multiple lists and trees for each thread id. this way it is not required
to change timer and file descriptor api.
another solution could be a seperate process, which handles audio only.
i don't really like a sepeate process, since it requires some interface
to openbsc and makes everything more complex. even though i don't like
threads, multithreading seems to be the best solution to me at the moment.
was there any effort to solve the problem or to handle audio? are there
any suggestions about it?
regard,
andreas