Hi lynxis,
I have reverted your recent commit 38e9ea3 (see below): it introduces a
reproducable segfault in openbsc, because msg->trx is not actually set/used in
the openbsc code paths (it seems only osmo-bts uses msg->trx).
FYI, struct msgb is used very generically in osmocom, and it's dangerous to
assume that any of its members are valid or consistent with other callers,
without fully understanding and testing the surrounding code paths.
commit 38e9ea3f7f385c6660c5958970af5c71adc1682b
Author: Alexander Couzens <lynxis(a)fe80.eu>
Date: Tue Aug 23 06:27:19 2016 +0200
bsc: count the usage of codec by setting the lchan active
we count the codec when the channel was successful setted up
Change-Id: Ifc8a406a11dce16b9e7f3310841e470545550a2c
Backtrace:
20161010011516712 DCC <0001> ../../../src/libmsc/transaction.c:71 subscr=0x813b20, net=0x7e0150
20161010011516712 DPAG <0007> ../../../src/libbsc/paging.c:291 Start paging of subscriber 49 on bts 0.
20161010011517034 DRLL <0000> ../../../src/libbsc/abis_rsl.c:1959 (bts=0,trx=0,ts=2,ss=0) SAPI=0 DATA INDICATION
20161010011517034 DRSL <0004> ../../../src/libbsc/abis_rsl.c:2176 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3
Program received signal SIGSEGV, Segmentation fault.
count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
104 rate_ctr_inc(&bts->network->bsc_ctrs->ctr[BSC_CTR_CODEC_V1_FR]);
(gdb) bt
#0 count_codecs (lchan=0x1, bts=<optimized out>) at ../../../src/libbsc/abis_rsl.c:104
#1 0x0000000000425661 in abis_rsl_rx_dchan (msg=<optimized out>) at ../../../src/libbsc/abis_rsl.c:1516
#2 abis_rsl_rcvmsg (msg=0x8143f0) at ../../../src/libbsc/abis_rsl.c:2611
#3 0x00007ffff71420d0 in handle_ts1_read (bfd=<optimized out>) at ../../src/input/ipaccess.c:271
#4 ipaccess_fd_cb (bfd=0x815af8, what=1) at ../../src/input/ipaccess.c:386
#5 0x00007ffff7779b62 in osmo_fd_disp_fds (_eset=0x7fffffffe590, _wset=0x7fffffffe510, _rset=0x7fffffffe490) at ../../src/select.c:149
#6 osmo_select_main (polling=polling@entry=0) at ../../src/select.c:189
#7 0x0000000000406fac in main (argc=<optimized out>, argv=0x7fffffffe738) at ../../../src/osmo-nitb/bsc_hack.c:385
(gdb)
Hope you can find a different way to count codec uses :)
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi all,
I'd like to share my odd? interesting? unnerving? experience today. All I
wanted to do is quickly check something (gerrit #713) on sysmobts, but I faced
a series of problems.
First some sysmobts related problems, later two problems entirely unrelated to
osmocom...
(*)
My sysmobts SDK no longer works: libosmo-abis now requires libortp >= 0.22.0,
but the SDK I have used so far doesn't have that:
poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160323112523.sh
(I didn't go through it in this sequence, but tried these things:)
a) tried to build a more recent libortp into the installed SDK. It goes fine up
to a point. It takes a bit of work to find and fetch all the repositories that
are required:
git://git.linphone.org/bcunit.gitgit://git.linphone.org/bctoolbox.gitgit://git.linphone.org/ortp.git
but sadly, bctoolbox wants libpolarssl aka mbedtls
git@github.com:ARMmbed/mbedtls.git
-- which has no automake/autoconf, only a plain Makefile! It also has cmake and
others, but so far I only know how to tell the ./configure script to
cross-compile and install into the SDK, so I kind of gave up on figuring out
cmake for that, for now.
b) just reverted the libortp version bumping commit in libosmo-abis
(15d9b7929d449e4138bcb003c614035bceadc3d1)
Everything compiles and works out, but alas, I get constant very weird
distortion/blip-tones/hickups on the voice channels, a bit of voice still
audible but definitely some bad codec problem. A regression? Is it related to
libortp? This happens both for a TS config of TCH/H and TCH/F.
c) tried fetching a new SDK from 201310-testing/sdk:
poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.3-20160910200558.sh
This has the same problem with too old libortp. Again I revert the libortp
version bump from libosmo-abis. Same results as above: badly broken voice.
d) tried a new 1.5.4 SDK from 201310-nightly/sdk:
poky-eglibc-i686-meta-toolchain-osmo-armv5te-toolchain-osmo-1.5.4-20161004010024.sh
Here libosmo-abis is fine with the libortp it finds, so far so good.
Sadly, this doesn't even do hickuped voice, only low noise on both ends.
So I decided to go back to the SDK that worked for me last time to bisect.
I will post another mail in case I found a regression.
(*)
For half a minute there I wondered why GPRS wasn't working until I remembered
our two-phase-access aka WAIT_ASSIGN problem in osmo-pcu and reverted
f1a7b8fc. With that, GPRS works fine with all of the above. phew ;)
(*)
Entirely unrelated to osmocom: I launch my CN programs from a script that
launches multiple terminals. I happen to use rxvt-unicode for that and always
have for a year. Turns out this time urxvt strips the LD_LIBRARY_PATH
when it is invoked. I still don't know how this changed, but when I drop the
suid that I find for unknown reasons sitting on the urxvt binary's group
('chmod g-s /usr/bin/urxvt'), it lets the LD_LIBRARY_PATH be, and the binaries
run. How did this change from the last time I ran my CN scripts?? No idea.
(*)
Same with sudo: LD_LIBRARY_PATH now all of a sudden gets stripped during my
sudo ggsn -f -c ggsn.conf
invocation. I use sudo for ggsn to allow establishing tunnels. Again I didn't
change anything about my scripts, just today it doesn't find the libraries in
/usr/local/lib anymore. I have to manually add it like
sudo LD_LIBRARY_PATH=/usr/local/lib ggsn ...
but then sudo tells me I'm not allowed to set the env. After searching around,
I add 'SETENV:' to my sudoers file:
neels ALL= NOPASSWD:SETENV: /usr/local/bin/ggsn *
This time ggsn starts again like it always used to. How did this change from
last time I ran ggsn this way?? No idea at all.
So my quick test took a bit longer than expected (hasn't started),
and the night has progressed at an alarming rate...
I'll write again when I found anything on the broken voice.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Today, I've taken a quick look at the coverity stuff, because so far I've only
seen coverity reports on the Iu code. I see now that actually all of the other
osmocom components are also tested by coverity.
So far I'm only seeing the "Osmocom" coverity project, which contains only the
iu build. In fact that's a bit of a misnomer -- I assumed that "Osmocom" would
contain all of the osmos, it should be more like 'Osmocom-3G' or 'Osmocom-Iu'.
The other osmos are in coverity projects named "libosmocore", "osmo-bts", etc:
https://scan.coverity.com/projects?utf8=%E2%9C%93&search=osmo
I see there are "add me to project" buttons e.g. here
https://scan.coverity.com/projects/libosmocore
so I'm trying that now.
Wouldn't it make sense to redirect all the coverity reports to a mailing list?
Probably best would be a new mailing list, to avoid noise on openbsc@, like the
gerrit-log@ list.
Are these coverity reports a matter of secrecy, to avoid publishing security
holes before we fixed them, in which case the coverity mailing list should be
invite-only?
~Neels
Hi,
While ruining osmo-bts and osmo-trx via VTY we tried to change parameter
like Band ,ARFCN MS max power.
We observed that once ARFCN is changed on VTY TRX does not switch to new
ARFCN.
Same behavior has been observed with Band and MS-Max-Power and RF-Locked
0/1 parameter.
Request someone who is running osmo-stack has controlled network ,please
reply or any document/pointer is appreciated.
BR
Dhananjay
