Hi everyone,
I few days ago, during some usual R&D process, I noticed the following
messages, appearing in the log output of OsmocomBB/mobile application:
"ACCH message type 0xXX unknown."
The network, a phone was connected to, was may own and based on more
or less recent versions of OsmoNiTB, OsmoBTS, and OsmoTRX. Despite I
used to see such messages before, I didn't pay too much attention.
But this time I've decided to figure out, what's wrong there...
The source of such messages is the gsm48_rr.c / gsm48_rr_rx_acch():
static int gsm48_rr_rx_acch(struct osmocom_ms *ms, struct msgb *msg)
{
// ...
struct gsm48_system_information_type_header *sih = msgb_l3(msg);
// ...
switch (sih->system_information) {
case GSM48_MT_RR_SYSINFO_5:
return gsm48_rr_rx_sysinfo5(ms, msg);
case GSM48_MT_RR_SYSINFO_5bis:
return gsm48_rr_rx_sysinfo5bis(ms, msg);
case GSM48_MT_RR_SYSINFO_5ter:
return gsm48_rr_rx_sysinfo5ter(ms, msg);
case GSM48_MT_RR_SYSINFO_6:
return gsm48_rr_rx_sysinfo6(ms, msg);
default:
LOGP(DRR, LOGL_NOTICE, "ACCH message type 0x%02x unknown.\n",
sih->system_information);
return -EINVAL;
}
}
To get I bit more details, I modified this function to print the
whole L3 payload, and got some interesting results. As it turned
out, the payloads were shifted one byte left - there was no
'l2_plen', which is assumed by:
/* Section 9.1.3x System information Type header */
struct gsm48_system_information_type_header {
uint8_t l2_plen;
uint8_t rr_protocol_discriminator :4,
skip_indicator:4;
uint8_t system_information;
} __attribute__ ((packed));
So, my first idea was that this is a bug of OsmocomBB, that
would be fairly easy to fix, so after a quick look at the
GSM 04.08 specification I wrote (and merged :/) this:
https://gerrit.osmocom.org/#/c/5204/
And everything was great, until I connected a 'patched' mobile to
a commercial mobile network... And all SI messages during a
dedicated connection were false-identified as SI5ter. This seemed
strange to me, so I decided to compare a SI message from commercial
network with a message captured in my own one:
https://habrastorage.org/webt/t8/zs/vv/t8zsvvjjglzfisnjqlnnsy4kgas.png
And this confused me even more, then I've expected. Why there is 0x49?
Wireshark false-identified this message as something related to SMS...
What if this is exactly the 'l2_plen' assumed in OsmocomBB before?
I looked at the specifications again, and found out that initially I
refered an outdated 5.3.0 version, which was the first link in Google:
http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p…
while the latest one is 7.21.0:
http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100…
So, I compared the 9.1.37-40 sections of both versions, and bingo!
In the higher version ACCH System Information messages do have the
'L2 Pseudo Length' (10.5.2.19) field.
Finally, what I've learned:
- OsmocomBB / mobile follows the new version here (with l2_plen);
- OsmoNiTB generates the ACCH SI messages without the l2_plen;
- Recent Wireshark versions fail to decode the ACCH SI messages
with l2_plen, while older ones are able to do that;
- I should not merge the changes so quick.
My questions are:
- Which way of composing the SI messages is correct?
- If both are correct, how to parse them correctly?
- Should we change OsmoNiTB / OsmoBSC to follow the latest specs?
And of course, I have to revert the change I've merged.
With best regards,
Vadim Yanitskiy.
Hi!
I played with osmo-trx today and tried to run it with a USRP1 that I
have laying around, though to no avail.
osmo-trx supports two kinds of devices, USRP1 via libusrp and UHD.
libusrp was last included in gnuradio 3.4.2[1] from Dec 2013, it
unsurprisingly does not build on a recent Linux distribution, due to API
incompatibilities with boost.
The USRP1 would theoretically be supported by UHD, though the device
initialization code in osmo-trx explicitly treats it differently, see
[2,3].
I found an old ML post[4] from 2015 that pretty much asks the same
question but did not get an answer.
Supposedly there is a simple reason why USRP1 is not driven via UHD in
osmo-trx, but I don't know.
Can somebody please enlighten me? Tom, maybe you?
I would like to understand whether it is feasible to use an USRP1 with
UHD for osmo-trx or one would have to go down the rabbit hole to build
libusrp on a modern system.
Kind regards,
-Alex
[1] https://gnuradio.org/releases/gnuradio/
[2] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/UHDDevice.cpp#n512
[3] https://git.osmocom.org/osmo-trx/tree/Transceiver52M/USRPDevice.cpp
[4] https://lists.osmocom.org/pipermail/openbsc/2015-January/000058.html
A recent patch to libosmocore refuses to allocate a rate counter group with an
index that already exists. Per se that's a good thing, but it needs fixes in a
whole range of callers.
Numerous callers wrongly just pass 0 as rate counter group, so as soon as a
second <thing> shows up, the application may deny service; that's unacceptable.
For example, OsmoSGSN now crashes with the second subscriber showing up!
causing patch: https://gerrit.osmocom.org/5418
my proposed change: https://gerrit.osmocom.org/5516
I'd like to request everyone to refrain from submitting patches that are
insufficiently tested, in general of course, but in particular until after
congress, please ;)
~N
When I run pysim ,I cannot read the card ,and always tell me this:
lab434@lab434-OptiPlex-7050:~/pysim$ ./pySim-read.py -p0
Reading ...
ICCID:
Traceback (most recent call last):
File "./pySim-read.py", line 99, in <module>
print("IMSI: %s" % (dec_imsi(res),))
File "/home/lab434/pysim/pySim/utils.py", line 57, in dec_imsi
l = int(ef[0:2]) * 2 # Length of the IMSI string
ValueError: invalid literal for int() with base 10: 'ff'
Anything you know may help me ,thank you !
I noticed that gerrit places constant load on the server.
When I first checked, it was between 30 and 60% CPU load, now is more like
10-15%, but still it is constant load.
I'm pretty sure we're not all clicking around in gerrit all the time, so
what would it be:
Gerrit does things in the background, like checking whether unmerged
patches have merge conflicts to the current master. I'm not perfectly sure
how often this happens, but my guess is that it happens a lot.
We have around 150 open patches on gerrit. If not for sanity, maybe the
CPU load on the gerrit server could be another reason to reduce that
number.
Related: I notice that the sync of gerrit's git repositories takes longer
than it used to. It would be a minute max, while just now I got >10min,
and I remember Pau noting something similar recently.
I think we should plain abandon patches that have been idling around for
more than 3 months. That would discard about 30, so not that many.
Then we have quite a number that are currently in Merge Conflict...
Seems that we don't get around looking at each one and deciding to kick it
or keep it.
~N
Hello, I would like to use openbsc to do a fake base station and osmocombb to do an attack cell phone, to implement a man-in-the-middle attack.
I have two questions:
1. How do I send location updates and authentication information between openbsc and osmocombb,
2. How to modify the code
thank you very much
Dear all,
I'm seeing plenty of branches which I believe were forgotten to clean up:
gerrit/lynxis/pre_release
gerrit/neels/client_vty
gerrit/neels/new_mgw
gerrit/neels/osmo-mgw
gerrit/neels/pending
gerrit/neels/pmaier/mgw2
gerrit/neels/pmaier_mgw
gerrit/neels/pmaier_mgw6
gerrit/neels/split
gerrit/neels/wip
gerrit/pmaier/aoip2
gerrit/pmaier/mgw
gerrit/pmaier/mgw2
gerrit/pmaier/mgw3
gerrit/pmaier/mgw4
gerrit/pmaier/mgw5
gerrit/pmaier/mgw6
gerrit/pre_release
I would appreciate if the respective authors could have a look and remove
them if the respective branch is confirmed to be no longer needed. Thanks!
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)
This is most probably related to / fixed by https://gerrit.osmocom.org/5516 :
[ 142s] [0;m<001e> rate_ctr.c:195 counter group 'msc' already exists for index 0
[ 142s] [0;m/usr/src/packages/BUILD/openbsc/tests/testsuite.dir/at-groups/1/test-source: line 25: 20213 Segmentation fault $abs_top_builddir/tests/gsm0408/gsm0408_test
On Tue, Dec 19, 2017 at 08:14:06PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o…
I recently saw this video / post in which Osmocom had be used to create a GSM Base Station with a LimeSDR mini and a Raspberry PI.
https://www.crowdsupply.com/lime-micro/limesdr-mini/updates/gsm-base-statio…
I was very interested in this, because I need to be able to test cellular broadcast messages, and this seemed to provide a way to do this.. CB seems to be supported in Osmocom.
I am a bit overwhelmed about what I need to install, to get a minimal, but functioning ‘system’ running, so I can test some features.. I ordered a LimeSDR and it hopefully will arrive sometime after the new year
But I wanted to get a jump start on it now. Is there some instructions in the wiki, I just did’tn know which ones to follow.
Kind Regards
Hi,
I want to setup a BTS where only a few subscribers (about 10) are allowed to connect but I do not want any other IMSI/IMEI to be stored in the DB as I have noticed that when the number of subscribers in the database reaches a few thousands the network starts to crash more frequently. Is there an option to prevent all undesired subscribers from being stored in the DB or should I modify the code.
best regards,
Robert
Hi!
As some other developers are starting to work with (and on) the test suites
in the osmo-ttcn3-hacks repository, I migrated it to gerrit today for future
code / patch reviews. I also worked on building the codebase without
having to rely on some out-of-tree clones of upstream titan
repositories. Rather, the makefiles now ensure that all dependencies
are cloned + linked from within the osmo-ttcn3-hacks repository.
I also added jenkins build testing, i.e. we will not get any future
patches into the repository which would break TTCN-3 compiletion. So
far, it validates only on Debian9 with TITAN 6.1.0. As I've already
seen a lot of code that compiles on 9.3.0 (my developent system) but not
on 6.1.0, we will likely add build validation for 6.3.0 soon.
The first patch that has succesfully passed compilation is at
https://gerrit.osmocom.org/#/c/5302/6
Please note that right now we only test the TTCN3->C++ compilation, and
not the compilation of the resulting C++ code for performance reasons.
It would be easy to add if we're willing to wait for the compile time,
but I think it's not really needed. I so far have not yet managed to
make ttcn3_compiler generate any C++ which would then later not pass the
g++ compilation - at least not on a clean build environment.
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)
enum osmo_auth_algo features OSMO_AUTH_ALG_XOR, but now that I'm trying to use
it, I notice that we have no code actually implementing OSMO_AUTH_ALG_XOR.
We have xor as algorithm exposed as a VTY option in the osmo-hlr DB, but when I
choose it, I must notice that libosmocore doesn't osmo_auth_register() any xor
implementation.
Another detail is that I happen to remember that XOR is set as algorithm on the
SIM cards we have in the osmo-gsm-tester, at least in the RnD unit.
How should we deal with it? Implement xor, or remove it from osmo-hlr?
Or am I missing something?
~N
Hi all developers,
I'd like to briefly review the decision for 120 chars line width we've
taken some time ago. To make this clear, I don't want us to re-raise this
issue on a weekly basis. But let's recap on what 120 has brought us?
I know of three developers not finding 120 chars appropriate.
One of them is me, I still think more than 80 would help a lot and remove
the cumbersome need for wrapping lines in many places, but I would prefer
100 chars to 120. I end up getting wrapped lines and have to enlarge
terminals such that only one fits on the screen at my preferred font size.
I used to easily have two.
One objective argument against 120 is the gerrit website: scrolling
left/right there is annoying, because for once there is the overall page
scroll left/right if the window doesn't have enough space (on smaller
screens), and then there's the side-scroll in the individual columns in
the side-by-side view. So UI wise it is beneficial to minimize the need to
scroll on the gerrit website.
For some time I have actually set my local line wrap to 105 and submitted
a number of patches like that, but recently decided it's stupid if each of
us chooses their own favorite, and set it to 120; hence the mail.
My guess is that I'm not the only one who picked his own local favorite,
and if that is so we might as well re-assess the common average favorite,
so that we can all use & enforce the same width.
In case we change this again: about the lines already merged in 120 width,
I wouldn't want us to edit them and just live with a few 120 wide lines
here and there.
What do you guys think?
Would it make sense to have a "pick your favorite <= 120" rule?
Rather re-negotiate one common width? Keep it at 120?
~N
Hello,
we are trying to setup a splitted gsm 2g network, all services are on
different vm's,
e.g. one machine for bsc ,one for bts ...!
At all we have 6 different vm's on a local subnet 192.168.192.X:
osmo-bts-trx (IP = .12) with osmo-trx to support N210 (192.168.10.6) with
TRX IP 127.0.0.1
osmo-bsc - IP = .41
osmo-msc - IP = .42
osmo-hlr IP= .43
osmo-stp IP = .44
and also osmo-mgw (IP=.45) with 2 instances, one for osmo-bsc and the other
for osmo-msc.
If I'm try to call from mobile a to mobile b, I able to see that the call
is incoming but a connection won't establish, the other mobile is ringing,
if I pick up the call on mobile b, mobile a is still trying to connect.
On osmo-bts-trx I get some errors:
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 320 vs 160
(1937437->1937446)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 0 vs 160
(1937446->1937446)
On osmo-mgw at bsc-side the output looks like:
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:15 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x15 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x15 connection successfully
created
<0011> mgcp_protocol.c:676 MDCX: modifying existing connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 26360, payload 255
(unknown), duration 20, addr 192.168.192.12
<0011> mgcp_protocol.c:805 MDCX: endpoint:0x15 connection successfully
modified
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 4002, payload 255
(unknown), duration 20, addr 192.168.192.45
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x15 connection successfully
created
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:16 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x16 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x16 connection successfully
created
<0011> mgcp_protocol.c:676 MDCX: modifying existing connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 64810, payload 255
(unknown), duration 20, addr 192.168.192.12
<0011> mgcp_protocol.c:805 MDCX: endpoint:0x16 connection successfully
modified
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 4004, payload 255
(unknown), duration 20, addr 192.168.192.45
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x16 connection successfully
created
However, the osmo-mgw msc side reports following:
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:1 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x1 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x1 connection successfully
created
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:2 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x2 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x2 connection successfully
created
Best Regards
Sebastian
hello,
I would like to ask some question, like , what kind of hardware should I have if i would like to install and doing some demo with osmo-ss7 !?
Chears,
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
Like every year in early December, it is time to discuss as schedule for
OsmoDevCon in the upcoming year.
Note: Ths is about OsmoDevCon, the more private meeting of developers,
*NOT* about OsmoCon, the public conference.
== When, Who, Where ==
I propose the following date for OsmoDevCon 2018:
April 20 - April 23rd, 2018
* Who: Active developers/contributors of Osmocom projects (as usual)
* Where: IN-Berlin, Berlin (as usual)
Please let me know ASAP if that proposed date works for everyone who'd
want to attend. We can still change it now, but I would want to nail
down the date pretty soon.
== Format ==
After the experiment of reducing from 4 to 3 days last year (due to
OsmoCon), we will again go for *four days* in 2018.
However, we should clearly divide the days in a way that e.g. "GSM/3G"
topics are on two days, while SDR+Other topics are on the other days, so
people not interested in some topics can skip one or two days, as
needed.
We could even divide it further like:
* 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...)
* 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.)
* 2 days misc
Regards, and looking forward to meeting you [again] in 2018,
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)
I'd like to re-raise this patch I merged for discussion, it's about whether or
not OsmoMGW endpoint identifiers are in hex. My patch might have gone in the
wrong direction after all.
https://gerrit.osmocom.org/4780
~N
On Sat, Dec 02, 2017 at 06:53:39PM +0000, Neels Hofmeyr wrote:
>
> Patch Set 2:
>
> elsewhere it seems we are confirming the hex nature of endpoint IDs (or was that a connection identifier?) ... Possibly this needs to be fixed the other way, by libosmo-mgcp-client translating the number-of-endpoints to a hex representation?
>
> --
> To view, visit https://gerrit.osmocom.org/4780
> To unsubscribe, visit https://gerrit.osmocom.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Ic18608ff23303c1564548a86d5f6bfa539fe555e
> Gerrit-PatchSet: 2
> Gerrit-Project: osmo-mgw
> Gerrit-Branch: master
> Gerrit-Owner: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
> Gerrit-Reviewer: Harald Welte <laforge(a)gnumonks.org>
> Gerrit-Reviewer: Holger Freyther <holger(a)freyther.de>
> Gerrit-Reviewer: Jenkins Builder
> Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
> Gerrit-HasComments: No
Dear Osmocom community,
I have been working on GAPK (GSM Audio Packet Knife) for some
time, and now I would like to share some achievements.
Previously GAPK was represented as a single binary that
could be called with some command line arguments in order
to perform required operations. This is only handy for
humans, but not for other programs, which may also need
to perform some format / codec conversations or audio
capture / playback.
One of such programs is the mobile from OsmocomBB project.
Currently, when you're making a voice call, both audio
capture and playback are only possible on the L1 side,
i.e. on a Calypso based phone. Of course, the audio stream
can be redirected via MNCC socket, but this is not what
a regular OsmocomBB user would like to do. Moreover, there
is a lack of AMR codec support.
Also, there is another GNURadio based project named GR-GSM.
In short, this is a set of blocks for GSM signal reception,
demodulation and further processing. At the moment, one has
TCH Full Rate decoding capabilities only. Audio playback is
not supported yet.
Having these projects in my mind, I have got an idea of
creating a shared library from the GAPK source code. And,
a few days ago I was managed to get the audio playback
working in OsmocomBB. I hope, this library will be also
usable for other projects.
Brief list of changes were made:
- Composed a shared library named libosmogapk
- All exposed symbols have got an 'osmo_gapk' prefix
- Added a pkg-config manifest and a symbol export map
- Integrated the Osmocom logging framework
- Benchmarking is now disabled by default
- Processing queue now based on the linuxlist
- Fixed program exit due to ALSA buffer underrun
- Fixed ALSA audio playback from file
- Old gapk application was renamed to 'osmo-gapk'
and linked against the library
- Adjusted verbosity level (normal / debug)
- Fixed I/O combinations (ALSA, RTP, file...) check
All changes could be found at the fixeria/lib branch of GAPK.
I hope to see them merged, and open for discussions ;)
With best regards,
Vadim Yanitskiy.
See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_de…>
------------------------------------------
[...truncated 2.05 MB...]
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for pkg-config... /usr/bin/pkg-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.20... yes
checking for library containing dlopen... -ldl
checking for LIBOSMOCORE... yes
checking for LIBOSMOVTY... yes
checking for LIBOSMOCTRL... yes
checking for LIBOSMOGSM... yes
checking for LIBOSMOABIS... yes
checking for LIBOSMONETIF... yes
checking for LIBOSMOSIGTRAN... yes
checking for LIBOSMOSCCP... yes
checking for LIBCRYPTO... yes
checking for LIBOSMOMGCPCLIENT... yes
checking for ANSI C header files... (cached) yes
checking dbi/dbd.h usability... yes
checking dbi/dbd.h presence... yes
checking for dbi/dbd.h... yes
checking pcap/pcap.h usability... yes
checking pcap/pcap.h presence... yes
checking for pcap/pcap.h... yes
checking cdk/cdk.h usability... no
checking cdk/cdk.h presence... no
checking for cdk/cdk.h... no
checking for SQLITE3... yes
checking if gcc supports -fvisibility=hidden... yes
checking whether C compiler accepts -Werror=implicit... yes
checking whether C compiler accepts -Werror=maybe-uninitialized... yes
checking whether C compiler accepts -Werror=memset-transposed-args... yes
checking whether C compiler accepts -Werror=null-dereference... no
checking whether C compiler accepts -Werror=sizeof-array-argument... no
checking whether C compiler accepts -Werror=sizeof-pointer-memaccess... yes
checking whether to enable code coverage support... no
checking whether struct tm has tm_gmtoff member... yes
checking whether to enable VTY/CTRL tests... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating include/Makefile
config.status: creating include/osmocom/Makefile
config.status: creating include/osmocom/msc/Makefile
config.status: creating src/Makefile
config.status: creating src/libmsc/Makefile
config.status: creating src/libvlr/Makefile
config.status: creating src/libcommon/Makefile
config.status: creating src/libcommon-cs/Makefile
config.status: creating src/osmo-msc/Makefile
config.status: creating src/utils/Makefile
config.status: creating tests/Makefile
config.status: creating tests/atlocal
config.status: creating tests/smpp/Makefile
config.status: creating tests/sms_queue/Makefile
config.status: creating tests/msc_vlr/Makefile
config.status: creating doc/Makefile
config.status: creating doc/examples/Makefile
config.status: creating contrib/Makefile
config.status: creating Makefile
config.status: creating bscconfig.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 3
echo 1.1.2.37-b8acdc > .version-t && mv .version-t .version
make all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc'
Making all in doc
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/doc'
Making all in examples
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/doc/examples'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/doc/examples'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/doc'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/doc'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/doc'
Making all in include
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include'
Making all in osmocom
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include/osmocom'
Making all in msc
make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include/osmocom/msc'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include/osmocom/msc'
make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include/osmocom'
make[4]: Nothing to be done for 'all-am'.
make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include/osmocom'
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include/osmocom'
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include'
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/include'
Making all in src
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src'
Making all in libcommon
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src/libcommon'
CC bsc_version.o
CC common_vty.o
CC debug.o
CC gsm_data.o
CC gsm_data_shared.o
CC gsup_client.o
CC oap_client.o
CC socket.o
CC talloc_ctx.o
CC gsm_subscriber_base.o
CC gsup_test_client.o
AR libcommon.a
CCLD gsup_test_client
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src/libcommon'
Making all in libvlr
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src/libvlr'
CC vlr.o
CC vlr_auth_fsm.o
CC vlr_access_req_fsm.o
CC vlr_lu_fsm.o
AR libvlr.a
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src/libvlr'
Making all in libmsc
make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src/libmsc'
CC a_iface.o
CC a_iface_bssap.o
CC auth.o
a_iface_bssap.c: In function ‘bssmap_rx_l3_compl’:
a_iface_bssap.c:328:11: warning: assignment discards ‘const’ qualifier from pointer target type
msg->l3h = TLVP_VAL(&tp, GSM0808_IE_LAYER_3_INFORMATION);
^
a_iface_bssap.c: In function ‘bssmap_rx_ciph_compl’:
a_iface_bssap.c:424:12: warning: assignment discards ‘const’ qualifier from pointer target type
msg->l3h = TLVP_VAL(&tp, GSM0808_IE_LAYER_3_MESSAGE_CONTENTS);
^
CC msc_vty.o
CC db.o
CC gsm_04_08.o
db.c: In function ‘db_init’:
db.c:607:2: warning: ‘dbi_initialize’ is deprecated (declared at /usr/include/dbi/dbi.h:169) [-Wdeprecated-declarations]
dbi_initialize(NULL);
^
db.c:609:2: warning: ‘dbi_conn_new’ is deprecated (declared at /usr/include/dbi/dbi.h:199) [-Wdeprecated-declarations]
conn = dbi_conn_new("sqlite3");
^
db.c: In function ‘db_fini’:
db.c:673:2: warning: ‘dbi_shutdown’ is deprecated (declared at /usr/include/dbi/dbi.h:171) [-Wdeprecated-declarations]
dbi_shutdown();
^
CC gsm_04_11.o
CC gsm_04_14.o
CC gsm_04_80.o
CC gsm_subscriber.o
CC mncc.o
CC mncc_builtin.o
CC mncc_sock.o
CC msc_ifaces.o
CC rrlp.o
msc_ifaces.c: In function ‘msc_call_assignment’:
msc_ifaces.c:255:42: error: ‘struct mgcp_client_conf’ has no member named ‘bts_base’
bts_base = mgcp_client_conf_actual(mgcp)->bts_base;
^
msc_ifaces.c:261:2: warning: ‘mgcp_msg_crcx’ is deprecated (declared at /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mgcp_client/mgcp_client.h:98): Use mgcp_msg_gen() instead [-Wdeprecated-declarations]
msg = mgcp_msg_crcx(mgcp, conn->rtp.mgcp_rtp_endpoint,
^
msc_ifaces.c: In function ‘mgcp_bridge’:
msc_ifaces.c:286:2: warning: ‘mgcp_msg_mdcx’ is deprecated (declared at /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mgcp_client/mgcp_client.h:103): Use mgcp_msg_gen() instead [-Wdeprecated-declarations]
msg = mgcp_msg_mdcx(mgcp,
^
msc_ifaces.c: In function ‘msc_call_connect’:
msc_ifaces.c:371:2: warning: ‘mgcp_msg_mdcx’ is deprecated (declared at /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mgcp_client/mgcp_client.h:103): Use mgcp_msg_gen() instead [-Wdeprecated-declarations]
msg = mgcp_msg_mdcx(mgcp,
^
msc_ifaces.c: In function ‘msc_call_release’:
msc_ifaces.c:417:2: warning: ‘mgcp_msg_dlcx’ is deprecated (declared at /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mgcp_client/mgcp_client.h:108): Use mgcp_msg_gen() instead [-Wdeprecated-declarations]
msg = mgcp_msg_dlcx(mgcp, conn->rtp.mgcp_rtp_endpoint,
^
Makefile:492: recipe for target 'msc_ifaces.o' failed
make[3]: *** [msc_ifaces.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src/libmsc'
Makefile:412: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc/src'
Makefile:448: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-msc'
Makefile:379: recipe for target 'all' failed
make: *** [all] Error 2
[WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully.
Emitted 956 C/C++ compilation units (100%) successfully
956 C/C++ compilation units (100%) are ready for analysis
For more details, please look at:
/home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt
Build step 'Execute shell' marked build as failure
Hi,
> <000b> trx_if.c:409 transceiver (phy0.0) rejected TRX command
> with response: 'RSP SETTSC -1'
>
> What is the problem and how can fix it?
The OsmocomBB transceiver is a legacy transceiver, so please add
the following line to your 'osmo-bts.cfg':
osmotrx legacy-setbsic
And please let me know about the results, I'll correct the wiki.
With best regards,
Vadim Yanitskiy.
These osmo-msc failures are inadvertently caused by
https://gerrit.osmocom.org/4701, which is a good change once
https://gerrit.osmocom.org/4980 is ready. But until then, I decided to revert
it in https://gerrit.osmocom.org/5126. We shall re-apply it as soon as 4980 is
merged.
I wasn't expecting osmo-msc to use the new client library but needing the old
bts_base config -- which I probably applied myself of course, but that detail
was lost to me in the meantime.
~N
On Fri, Dec 01, 2017 at 08:19:16PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o…
>
> Package network:osmocom:nightly/osmo-msc failed to build in Debian_9.0/x86_64
>
> Check out the package for editing:
> osc checkout network:osmocom:nightly osmo-msc
>
> Last lines of build log:
> [ 136s] from msc_ifaces.c:24:
> [ 136s] /usr/include/osmocom/mgcp_client/mgcp_client.h:108:14: note: declared here
> [ 136s] struct msgb *mgcp_msg_dlcx(struct mgcp_client *mgcp, uint16_t rtp_endpoint,
> [ 136s] ^~~~~~~~~~~~~
> [ 136s] Makefile:508: recipe for target 'msc_ifaces.o' failed
> [ 136s] make[4]: *** [msc_ifaces.o] Error 1
> [ 136s] make[4]: Leaving directory '/usr/src/packages/BUILD/src/libmsc'
> [ 136s] Makefile:424: recipe for target 'all-recursive' failed
> [ 136s] make[3]: *** [all-recursive] Error 1
> [ 136s] make[3]: Leaving directory '/usr/src/packages/BUILD/src'
> [ 136s] Makefile:460: recipe for target 'all-recursive' failed
> [ 136s] make[2]: *** [all-recursive] Error 1
> [ 136s] make[2]: Leaving directory '/usr/src/packages/BUILD'
> [ 136s] Makefile:392: recipe for target 'all' failed
> [ 136s] make[1]: *** [all] Error 2
> [ 136s] make[1]: Leaving directory '/usr/src/packages/BUILD'
> [ 136s] dh_auto_build: make -j1 returned exit code 2
> [ 136s] debian/rules:45: recipe for target 'build' failed
> [ 136s] make: *** [build] Error 2
> [ 136s] dpkg-buildpackage: error: debian/rules build gave error exit status 2
> [ 136s]
> [ 136s] cloud120 failed "build osmo-msc_1.1.2.20171201.dsc" at Fri Dec 1 20:19:10 UTC 2017.
> [ 136s]
> [ 136s] ### VM INTERACTION START ###
> [ 140s] [ 111.258730] reboot: Power down
> [ 141s] ### VM INTERACTION END ###
> [ 141s]
> [ 141s] cloud120 failed "build osmo-msc_1.1.2.20171201.dsc" at Fri Dec 1 20:19:14 UTC 2017.
> [ 141s]
>
> --
> Configure notifications at https://build.opensuse.org/user/notifications
> openSUSE Build Service (https://build.opensuse.org/)
--
- 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