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.
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.
Dear all,
starting from today, we're packaging LimeSuite and (as needed) other
dependencies required for using osmo-trx/osmo-bts-trx with LimeSDR in
the network:osmocom:nightly and network:osmocom:latest feeds.
The package versions are fixed and are not tracking "master" of e.g.
limesuite. Only the Osmocom packages are tracking master.
Due to the unfortunate fact that the first LimeSuite with osmo-trx
support (17.09.0) requiring a cmake later than what Debian 8 ships,
LimeSDR support is not working with all of the Distributions/Versions
that the rest of the Osmocom stack supports.
It appears that LimeSuite also has some build issues on ARM
architectures, about which I've submitted an upstream bug report at
https://github.com/myriadrf/LimeSuite/issues/151
But at least for x86_64 and i586 architecture, LimeSDR should be
supported by the Osmocom package feeds , on Debian 9.0, Ubuntu 16.04,
16.10, 17.04 and 17.10.
We will shortly use those packages as part of our osmo-gsm-tester setup
at the sysmocom lab, at which point they should receive extensive
testing.
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 all,
I've mentioned this many months before, but Ericsson has now (well, a
month ago) finally made a public announcement about the public release
of their SS7/SIGTRAN core protocols in TTCN-3. You can read more about
it at https://www.eclipse.org/forums/index.php/t/1089686/ - where they
actually even refer to us as being the trigger to release them.
There are still many tests to write beyond those currently existing.
Most recently I wrote a set of MGCP tests for our new osmo-mgw, which
Philipp is now using to iron out some kinks in the codebase.
The past week I've been working on simulating the minimal subset of N
numbers of BSCs and N numbers of MSCs from a single test suite in order
to test osmo-bsc_nat, and specifically the "IMSI-based routing to
different MSCs" feature that Daniel has been working on. It's still
work in progress, but definitely the by far most complex TTCN-3 project
that I've written so far.
After completing that, I would like to spend some more time on OsmoBTS
and OsmoBSC related tests. The difficulty here is that the more we get
to the RAN / air interface, the less existing prtoocols / codecs exist,
so e.g. A-bis RSL would first have to be implemented. The good part is
that it's actually super easy using the expressive syntax of the TITAN
"raw" codec. Basically you define the structure of the data in files
like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn
and you don't have to write a single line for encoding/parsing :)
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)
2017년 11월 23일 목요일 오후 10시 34분 47초 CET에 Harald Welte 님이 쓴 글:
> On Thu, Nov 23, 2017 at 09:47:25PM +0100, Martin Heusse wrote:
> > Harald, Shinjo,
> > please find below is a tiny patch to add
> > #define GSMTAP_TYPE_LTE_NAS 0x12
> > to packet-gsmtap.h
> > and the corresponding code that uses it.
>
> great, feel free to push this to the wireshark gerrit.
>
> I've made a corresponding change in libosmocore, see
> https://gerrit.osmocom.org/5018
>
Forwarding the discussion at Wireshark gerrit at https://code.wireshark.org/
review/#/c/24554/4:
Devices dumping NAS messages can give both encrypted and plain messages. At
least for Qualcomm LTE basebands it is true. Therefore using sub_type for
differentiating encrypted and plain NAS messages were discussed there. This
will likely introduce another modifications to gsmtap.h, and therefore want to
discuss more about this topic also here.
Shinjo
--
Shinjo Park <pshinjo(a)sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272
Hello,
I heard that it's possible to connect to a femtocell without knowing Ki and Opc... of the sim-card like the conferences of Nico Golde and Ranvinshar on the poisoning the femtocell.My question is , is it possible to make the same with the osmo-iuh on the future !?
Chears,
Hi Jolly,
my current task is to implement load based handover between BTS, and in old
tradition of adopting your code to implement dynamic timeslots on
osmo-{bts,bsc}, I am now looking at the openbsc.git jolly/new_handover branch.
I notice that, on that branch, there are improvements on the "old" handover,
followed by a new elaborate handover_2 algorithm, which looks very sane at
first sight, paired with an elaborate test suite.
So my question is whether handover_2.c has some obvious shortcomings or open
issues that need to be resolved before I can consider merging that to OsmoBSC's
master branch.
Should we still keep the "old" handover decision code around as well for
particular reasons, or would it make sense to adopt handover_2.c by default?
Is one better than the other in particular situations?
And ... do you remember any high level conclusions from when you implemented
the branch, things I should be aware of when testing and adopting the code? Did
it work out as expected? How well tested is it?
Thanks!
~N
Looking at https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
OsmoMSC currently uses 0.23.1 for A-and-Iu,
and 0.23.2 for Iu only if Iu is on a different cs7 instance than A (i.e.
practically never).
Either way that doesn't really make sense to me. If OsmoMSC is connecting to
the same STP for A and Iu, it is sufficient to have one point-code for the two
SSNs for A (BSSAP) and Iu (RANAP) and hence use one cs7 instance for both.
If it is connecting to two different STPs, the point codes do not collide
anyway, and it makes no sense to use a different one for Iu. It only confuses
the defaults, e.g. the wiki page was wrong until I fixed it just now.
I would rather have just 0.23.1 for the MSC for all SSNs.
See ss7_setup() in msc_main.c.
Agreed?
~N
Hello!
I got this problem:
*root@pc:~/osmocom# osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg((*)) | / \
OsmoBTS<0017> control_if.c:828 CTRL at 127.0.0.1 4238<0010>
telnet_interface.c:104 telnet at 127.0.0.1 4241<0012> input/ipaccess.c:886
enabling ipaccess BTS mode, OML connecting to 127.0.0.1:3002
<http://127.0.0.1:3002><000b> trx_if.c:595 Open transceiver for
phy0.0<0012> input/ipa.c:129 connection done.<0012> input/ipaccess.c:707
received ID get<0001> oml.c:229 O&M Get Attributes [0], Manufacturer
Dependent State is unsupported by TRX.<0001> oml.c:680 Ignoring T200[0]
(150 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680
Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug!<0001>
oml.c:680 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm
bug!<0001> oml.c:680 Ignoring T200[3] (1680 ms) as sent by BSC due to
suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[4] (520 ms) as sent by
BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[5] (165 ms)
as sent by BSC due to suspected LAPDm bug!<0001> oml.c:680 Ignoring T200[6]
(1680 ms) as sent by BSC due to suspected LAPDm bug!<0001> oml.c:1049 ADM
state already was Unlocked<0012> input/ipa.c:129 connection done.<0012>
input/ipaccess.c:707 received ID get*
*<000b> trx_if.c:409 transceiver (phy0.0) rejected TRX command with
response: 'RSP SETTSC -1'*
*<0001> bts.c:210 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL*
*<0007> l1sap.c:462 Invalid condition detected: Frame difference is
2452951-0 > 1!*
*Shutdown timer expired*
What is the problem and how can fix it?
I used 1 phone and cfg files (from this tutorial
https://osmocom.org/projects/baseband/wiki/CalypsoBTS):
- OsmoNITB: 'doc/examples/osmo-nitb/sysmobts/openbsc.cfg'
- OsmoBTS: 'doc/examples/trx/osmo-bts.cfg'
thanks!
Hi list,
While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add
NAS/EPS as a new payload type for gsmtap.h.
Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and
RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS
security had been activated only encrypted NAS messages are available at RRC
layer. This is reflected into the baseband diagnostics of various makers:
Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and
plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this
issue. I can submit a patch if this looks positive.
Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN
is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making
14-bits available for raw value. This causes some problem in LTE:
1) EARFCNs for uplink are starting from 18000, which is larger than 2^14
2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies)
3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network
Also in UMTS, there are overlapping UARFCNs between bands, which necessitates
a separate field for band indicator. Changes regarding these will break the
GSMTAP header structure, therefore I want to discuss about how these could be
addressed.
Best Regards,
Shinjo
--
Shinjo Park <pshinjo(a)sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272
Hi,
working on a diagnostic interface, I also ran into the lack of a gsmtap type for LTE NAS plain messages.
So I am supporting Shinzo's request for a new GSMTAP_TYPE_LTE_NAS (or GSMTAP_TYPE_LTE_UU) type in packet-gsmtap.h.
This type would play a similar role to that of GSMTAP_TYPE_UM for GSM, if my understanding is correct.
Best regards,
Martin
> Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and
> RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS
> security had been activated only encrypted NAS messages are available at RRC
> layer. This is reflected into the baseband diagnostics of various makers:
> Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and
> plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this
> issue. I can submit a patch if this looks positive.
>
>
Hi,
> I read a tutorial called "CalypsoBTS"
The tutorial has been updated. Check out a new version please.
https://osmocom.org/projects/baseband/wiki/CalypsoBTS
> *There is no such command. Error occurred during reading
> the below line: fn-advance 30*". How to fix it? Are there
> any tutorials for beginners how configure these
> "Osmo-bts.cfg" "Open-bsc.cfg" files?
The configuration suggested by the previous version of this
tutorial is obsolete. I may find the actual configuration
examples in 'doc/examples/' of almost each project.
With best regards,
Vadim Yanitskiy.
Hello! I read a tutorial called "CalypsoBTS" (
http://osmocom.org/projects/baseband/wiki/CalypsoBTS). Everything was good
before I ran "Osmo-bts.cfg".
I got a error : "
*There is no such command. Error occurred during reading the below line:
fn-advance 30*". How to fix it? Are there any tutorials for beginners how
configure these "Osmo-bts.cfg" "Open-bsc.cfg" files? I need just to run
"fake base station" for testing android app. Is there any another ways to
run it with motorola?
Thanks!
Hi,
We have a Litecell 1.5 unit. It is updated to the latest packages on the nightly build and configured to an osmo-bsc set up on an another machine.
On mobile phones, the network does not show the short or long name set, instead it shows just numbers "09070" and calls can not be made.
This has happened to us before when there was problem with the clock calibration on the BTS.
A GPS device is attached to the BTS, and when running cgps, there is a 3D Fix and a correct GPS location coordinates show up.
The lc15 bts should be able to calibrate automatically using the lc15bts-mgr package, however, it seems like it is failing to do so.
When we tried stopping the lc15bts-mgr service and start it manually to log the output by running:
/usr/bin/lc15bts-mgr -s -c /etc/osmocom/lc15bts-mgr.cfg
We notice the following errors:
```
Failed to open /mnt/storage/var/run/lc15bts-mgr/volt-supply-max due to 'No such file or directory' error
<0000> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_misc.c:315 Total hours of Operation: 393
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system.
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002e,m:0x000000000000007f
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:271 Going to calibrate the system.
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:121 Last GPS 3D fix can not read (-2). Last GPS 3D fix sets to zero
<0003> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_mgr_calib.c:126 GPS has no fix
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:126 Going to check for watchdog notification.
<0004> ../../../git/src/osmo-bts-litecell15/misc/lc15bts_swd.c:67 Missing watchdog events: e:0x000000000000002f,m:0x000000000000007f
```
It seems the lc15bts_mgr service can not read the values from the GPS device for some reason, can someone please advise what might be causing this issue?
Best Regards,
Rayan
Hi All,
Was trying to build osmocom 3g system.
Its failing in running test on osmo-hlr, any clues?
## --------------------------------- #### osmo-hlr 0.1.0.7-8db4 test suite. #### --------------------------------- ##
Regression tests.
1: auc ok 2: auc_ts_55_205_test_sets ok 3: gsup_server ok 4: db FAILED (testsuite.at:30)
## ------------- #### Test results. #### ------------- ##
ERROR: All 4 tests were run,1 failed unexpectedly.
Ever since I upgraded to debian 9, osmo-hnbgw failed to link in my build:
/usr/bin/ld: hnbgw.o: undefined reference to symbol 'sctp_send@@VERS_1'
I noticed that adding -lsctp to the build fixed that, yet noticed that no build
slaves nor anyone else seemed to need that.
Some events coincided my re-install of deb9:
- There has always been an -lsctp in the Makefile.am for osmo-hnbgw, but it was
recently dropped in
http://git.osmocom.org/osmo-iuh/commit/?id=7235ea02d78299471d58f4202d8c8d68…
- I adopted the jenkins.sh -Werror flags in some builds to get fatal warnings.
Passed by './configure CFLAGS=-Werror'. Someone else added this in jenkins.sh
and I assumed that was a good way to do things.
- I noticed that I couldn't see debug symbols in gdb, so added 'CLFAGS=-g' in
my builds. read on...
Comparing with a docker build kindly provided by laforge, I noticed that a
plain 'clone; ./configure; make' does actually succeed on my system!
It is a convolution of CFLAGS causing the error.
By passing a 'CFLAGS=foo' to the osmo-iuh configure script, not only do I add
'foo', but I override CFLAGS defaults, and actually *remove* other CFLAGS.
Turns out, whether I pass CFLAGS=-g or not, -g is always part of the build
command lines: '-g -O2' is the default. Funnily enough, with CFLAGS=-g
passed, I end up removing the -O2 option.
A conclusion here is that in jenkins.sh, we should *not* pass CFLAGS to
configure, so that we don't override any default CFLAGS. A configure option
like --with-strict-warnings can add to CFLAGS in configure.ac instead
So now I guess because I added CFLAGS=-Werror before, I ended up removing -g.
Hence I saw a need to add -g again, goof. Did so in all builds while I was at
it, hence -g ended up in osmo-iuh as well.
The -g stuck around, and building osmo-iuh with CFLAGS=-g does, as I already
said, effectively remove the -O2 option for all things built in osmo-iuh.
Now I'm confused. Why does a lack of -O2 break a linkage.
It's not the osmo-hnbgw linkage per se that seems to be the cause. I can link
that last step with or without -O2 successfully. It must be a combination of
building a depending library without -O2 and then linking that to osmo-iuh.
I diffed the entire build log between a succeeding and a failing build of
osmo-iuh, and really the only difference everywhere is that the succeeding
build uses -O2 everywhere.
The only differences in config.log are the same: most conftest programs have
-O2 removed, few have a -g added. The conftest conclusions are all identical.
My big question now is: sctp_send() is actually called from hnbgw.c directly.
So IIUC, we should in fact be required to pass -lsctp to the linker for
osmo-hnbgw. If that is correct, how am I allowed to skip that by passing -O2?
That's all I figured out so far. I still would like to find out why this can
happen, any ideas would be appreciated.
Anyone should be able to reproduce this by building osmo-iuh with
./configure CFLAGS=-g
~N
Hi dexter,
I just noticed this patch that is merged, with the lines
+ LOGPFSML(reset->fsm, LOGL_NOTICE, "fsm-state (msc-reset): %s, fsm-event: %s\n",
get_value_string(fsm_state_names, ST_CONN), get_value_string(fsm_evt_names, event));
If you take a look at the log output this produces, you should see that LOGPFSM
already contains information that it is an FSM, which state it is in, and that
just before that an FSM event has fired. This log statement seems obsolete?
Here's an example where you did everything right, just add a message to the FSM
logging:
+ LOGPFSML(reset->fsm, LOGL_NOTICE, "SIGTRAN connection down, reconnecting...\n");
I marked in the (merged) patch those logging lines that seem to merely
duplicate what we already see in the logs: https://gerrit.osmocom.org/4754
~N
Hi all,
we recently had some (verbal) discussions on how to handle endpoint
allocations in a scenario where a single osmo-mgw shall be used by both
osmo-bsc and osmo-msc (in a "NITB style" setup).
There was some thinking about whether we should somehow divide fixed
ranges of the rtp-bridge endpoints between the BSC and the MSC and how
to avoid having to manually configure those.
I think I now found the proper solution for this: The call agent must
not even fully qualify the endpoint, but it can ask the MGW to allocate
one! To quote from the MGCP RFC:
EndpointId is the identifier for the connection endpoint in the
gateway where CreateConnection executes. The EndpointId can be
fully-specified by assigning a value to the parameter EndpointId in
the function call or it may be under-specified by using the "any of"
wildcard convention. If the endpoint is underspecified, the endpoint
identifier SHALL be assigned by the gateway and its complete value
returned in the SpecificEndPointId parameter of the response. When
the "any of" wildcard is used, the endpoint assigned MUST be in-
service and MUST NOT already have any connections on it. If no such
endpoint is available, error code 410 (no endpoint available) SHOULD
be returned. The "all of" wildcard MUST NOT be used.
So in our concrete example, the BSC (or MSC) could simply ask for
"rtpbridge/*@mgw" as end-point name in CRCX, and the MGW would then
dynamically allocate a suitable free rtpbridge endpoint type and return
it in the call agent in the BSC (or MSC). No shared knowledge about
endpoint number allocations / ranges or the like required.
Now we only need to implement this in osmo-mgw ;)
Related: https://osmocom.org/issues/2631
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.
I've stumbled upon awesome hack which seems to be relevant:
https://ha.cking.ch/s8_data_line_locator/
It uses Simtrace to check how hw implant communicates with its sim. The guy also
tried to sniff GPRS traffic but failed (because he've used OpenBTS, he-he :) - I
wonder if it would work better with OsmoBTS.
Anyone else played with similar device already?
--
Max Suraev <msuraev(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
* Geschaeftsfuehrer / Managing Director: Harald Welte
I recently found sanitizer build failures, for example in libosmocore, which
our gerrit build job doesn't catch. At first I thought something was amiss and
maybe our gerrit sanitizer build were broken.
Instead, it turns out my debian9 gcc -fsanitize=address -fsanitize=undefined
finds many more issues that the debian8 one does not.
https://jenkins.osmocom.org/jenkins/job/gerrit-libosmocore/36/a2=default,a3…
I already have a long series for mem leak fixes for libosmocore, mostly in the
regression testing code, but I count three real mem leak fixes in libosmocore
production code.
My plan is to merge the fixes and then actually move the libosmocore-gerrit to
debian 9 (or at least add debian 9) to make sure we don't add insanities that
the debian 9 build would find.
See https://gerrit.osmocom.org/4861 to https://gerrit.osmocom.org/4875.
I'm also taking a look at the other CellNet builds. The root motivation was to
find out why osmo-hnbgw doesn't work for me anymore currently.
~N
I'm finding heap use after free related to osmo_fsm:
- When dispatching a timer_cb event, we want to set fi->T back to 0. (see fsm_tmr_cb())
- So that we know which timer fired, we leave fi->T at its current value for
the timer_cb to be able to make decisions based on that. This is used for
example in fsm_timeout_cb() in osmo-bsc/osmo_bsc_mgcp.c.
- In other code, the timer_cb event may decide to fire events or call functions
which effect an FSM instance teardown and deallocation, meaning that in
fsm_tmr_cb(), we are *not* allowed to generally assume the fi still exists.
If we set fi->T = 0 after the timer_cb() was called, we may write to freed
mem.
- Also, if the timer_cb effects events with their own timeout, we will also
overwrite the fi->T value with zero after another timer has set its value in
T, causing failures to evaluate that timer later on.
Solutions so far:
- set fi->T = 0 first, and pass T to the timer_cb as arg instead. I think this
is the best and cleanest, but also the hardest in terms of backwards compat.
I have a patch that adds timer_cb2() that features a T arg; we need to submit
that, move all code that wants to use T to that timer_cb2(), and then we can
move the fi->T = 0 to before the timer_cb(). Actually, this is not being
backwards compatible at all, because all code trying to use fi->T as usual
will need adjustment, we break API either way and might as well add T to the
timer_cb directly instead... :/
- Actually not set fi->T = 0 at all. We will have T holding the value of the
timer that fired last, all old code will still find this T in fi->T, and
after the cb, we just leave it as it was. Does it really need to be cleared?
This has no compatibility issues and solves the use after free as well as
setting a new T from timer_cb() issues. Going for this one so far.
Thoughts?
~N
I am receiving a lot of build failure mails every day for quite a while now ...
not finding any time to look at them, I hope you guys are onto those?
~N
Dear Osmocom Community,
I've spent some time the least few days to handle SCCPlite in osmo-stp,
and to do some initial testing of interoperability of osmo-bsc-sccplite
with osmo-msc.
The result are a few commits to osmo-sccp.git and openbsc.git which I'll
push into gerrit as soon as I'm on land again (sitting in an airplane
right now). Once those commits are merged, we can run osmo-bsc-sccplite
with osmo-msc via osmo-stp.
Why is this needed? While we don't want to see or support any new
osmo-bsc-sccplite deployments, we still have existing users that we need
to continue to support. Supporting them is easier if we can test it
better, and as Osmocom now has a MSc, it would be logical to have some
[manual, automatic] testing setups this way. It also means that we
hopefully can create testing setups for osmo-bsc_nat, which could so far
only be tested (like osmo-bsc-sccplite) with live access to a "real" MSC
at an operator.
Right now, this of course only handles signaling, i.e. we should be
able to test LU, SMS and call signaling, including hand-over. Voice
stream handling between SCCPlite and M3UA-AoIP is unfortunately quite
different and will need further code in osmo-msc as well as osmo-stp.
But still this should be rather straight-forward as a later next step
for full interoperability.
== How to configure this
=== osmo-bsc-sccplite side
On the osmo-bsc-sccplite side, the config file looks like this
----
msc
dest 127.0.0.1 5000 0 <1>
token mahlzeit <2>
----
<1> the IP address and port must be the IP:Port of where osmo-stp listens for IPA
<2> this 'token' must be identical to the AS configured on osmo-stp
=== osmo-stp side
On the osmo-stp side, the config file looks like this:
----
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
as mahlzeit ipa <1>
routing-key 0 0.23.4 <2>
point-code override dpc 0.23.1 <3>
route-table system
listen m3ua 2905
accept-asp-connections dynamic-permitted
listen ipa 5000 <4>
accept-asp-connections dynamic-permitted
----
<1> This defines an AS with the name 'mahlzeit' matching the osmo-bsc-sccplite token
<2> The point-code on the BSC side is set to 0.23.4
<3> The point-code of the MSC side is set to 0.23.1 (the compile-time default of osmo-msc)
<4> Bind IPA protocol to TCP port 5000
Please note that no point code information is configured on the BSC side
in the case of SCCPlite. The SCCP calling/called party address in
SCCPlite don't contain a PC but only SSN, and there is no M3UA/MTP3
label with point code information either. Hence, OsmoSTP will insert
the point code information into both the SCCP level as well as the
stp-internal routing label of each message. The MSC will receive a
SCCP message with PC+SSN in a M3UA message with OPC and DPC in a
way that enables the STP to route any responses back to the BSC.
If you have multiple osmo-bsc-sccplite in such a configuration, they
will all need to have a different point code, just like an AoIP speaking
osmo-bsc. The difference is only that in SCCPlite the point-codes are
configured on the STP side, while in the AoIP they are configured on the
BSC side.
=== osmo-msc side
No special configuration is required on osmo-msc at this point. In
order to properly handle voice channels, we likely have to introduce
some additional per-BSC configuration statements at a later point.
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)
I found the interesting situation while trying to find the minimal
network-in-the-box installation with the new split components:
For CS, the MSC/VLR happily accept a subscriber that has no auth tokens in the
HLR, as long as the IMSI is present in the HLR and authentication is set to
optional.
For PS, the SGSN on auth policy remote naturally asks the HLR for auth tuples
for the subscriber. The HLR then finds the IMSI allright, but no 2G nor 3G auth
tokens, and says so to the SGSN. That leads to total rejection:
HLR:
DLINP <0006> ../../../src/libosmo-abis/src/input/ipa.c:383 connected read/write
DLINP <0006> ../../../src/libosmo-abis/src/input/ipa.c:338 message received
DAUC <0003> ../../../src/osmo-hlr/src/db_auc.c:127 IMSI='901700000014701': No 2G Auth Data
DAUC <0003> ../../../src/osmo-hlr/src/db_auc.c:163 IMSI='901700000014701': No 3G Auth Data
SGSN:
<000f> ../../../../src/osmo-sgsn/src/gprs/gprs_subscriber.c:493 SUBSCR(901700000014701) GPRS send auth info req failed, GMM cause = 'Network failure' (17)
<0002> ../../../../src/osmo-sgsn/src/gprs/sgsn_auth.c:236 MM(901700000014701/ccb050ce) Missing auth tuples, authorization not possible
<0002> ../../../../src/osmo-sgsn/src/gprs/gprs_gmm.c:1140 MM(901700000014701/ccb050ce) Not authorized, rejecting ATTACH REQUEST with cause 'Network failure' (17)
<0002> ../../../../src/osmo-sgsn/src/gprs/gprs_gmm.c:491 MM(901700000014701/ccb050ce) <- GPRS ATTACH REJECT: Network failure
It appears that in the SGSN, I either have to accept all IMSIs or also have
auth tokens for each IMSI in the HLR. There's apparently no way to just accept
IMSIs (without cryptographic auth) as long as the IMSIs exists in the HLR.
In production networks, we usually have auth tokens for each SIM, but in open /
community networks, IIUC operating without auth+ciph is an important option in
Osmocom. It appears to me that we should support this case.
Or do we already support it by issuing accept-all policy, and rely on the
subscriber being rejected by the MSC before establishing GMM? (In that case we
can't use the HLR at all, i.e. not for other IMSIs where we'd know auth tokens.)
What do you guys think? Should we open an issue on it?
Related: I'm often confused by the SGSN auth code and have wished before that
it were a well-defined FSM instead... like the libvlr...
~N
I'm just now looking through osmo-bsc libfilter, and I would have expected a
kind of top-down behavior like for firewalls:
imsi-deny .*
imsi-allow 12345.*
imsi-deny 1234567.*
imsi-allow 123456789.*
imsi-deny .*[13579]
i.e. start out denying everything.
Except allow IMSIs starting with 12345.
Except deny those that continue with 67.
Unless they continue with 6789, allow those.
Finally only service even-numbered IMSIs here.
That would be quite powerful.
Instead, what I see is that first, we go through the entire access list
regarding only the allow-imsi entries. If any one of them matches, break the
loop and return acceptance *right away*.
If no accept rule matched, go through the list again, and see if any deny rule
matches. If there is one, break and return failure right away.
This was for the "local" per-msc rules, we also have a "global" rule set on the
bsc level, which follows after that. For that, we currently actually completely
ignore all allow rules, and only return error if any deny rule matches.
In the end, if nothing matched, return acceptance.
A code comment says that for the "global" rules, we want to deny first and
accept second, so precisely reverse from the "local" level, but as a user I
would find that rather confusing. See auth_imsi() in bsc_msg_filter.c.
So in short, to get the intended behavior outlined above, you are forced to
cram all rules into a single regex, sort of like
imsi-allow 12345\(<not>67\|6789\).*[02468]
imsi-deny .*
which I don't actually know how to express as you can see... or maybe
imsi-allow 12345[^6].*[02468]
imsi-allow 123456[^7].*[02468]
imsi-deny .*
My questions are:
- Is it implemented this way for performance considerations?
- Are we not going to change this, even assuming that we regard changes being
useful, because we don't want to break with previous configs?
- When looking in auth_imsi(), the access list names are:
auth_imsi() name | comments | osmo-bsc passes
bsc_lst "local" vty 'msc' level access rules
nat_lst "global" vty 'bsc' level access rules
Needless to say that "local", "global", "nat", "bsc" and "msc" are quite
hard to follow.
From the osmo-bsc filter code's perspective, there may be multiple MSCs
configured, and per-msc config could be seen as more specific ("local") than
bsc level, which applies to all MSCs ("global")... Was that the intention or
is the local/global actually swapped by accident?
(I notice that this feature seems to be intended for osmo-bsc-nat, and
there's also a concept of a super-global blacklist that is always NULL in
osmo-bsc.)
Here's a patch to add imsi-allow evaluation on the "global" level; other
than the comment says, I use the same order of 'allow' first and 'deny'
second to be consistent: https://gerrit.osmocom.org/4750
Otherwise I believe this could benefit from some refactoring, but probably we
don't have time/funding to care about that, do we...
~N
There has been a profound change in RTP handling by OsmoBSC: we now require an
OsmoMGW to run alongside it to manage RTP streams, and to be able to provide
intra-BSC handover. Kindly refer to https://osmocom.org/news/80
~N
Hi List!
As there isn't so much about GPRS on here, I though I might
write something about experiments over the last couple of
weeks with data inside and outside of the lab.
I've installed up to date versions of osmo-bts and osmo-pcu
on sysmobts 2050 hardware and it's working great!
Dynamic channels are really nice, with half rate TCH and AMR
working perfectly. Thanks for all that work!
The question for this experiment was if it was going to be
feasible to actually do anything with several hundred data
hungry spying devices.... I mean mobile phones on the network.
For the traffic control, I setup a local blacklisting or
whitelisting dns server.
I've tried both. Blacklisting the worst culprits would be
nice, but in practice I think I'll have to go for
whitelisting only the intended permitted services.
I configured pcodns1 in the ggsn to point to this DNS
server, AND I setup a port 53 redirect to catch quite a lot
of traffic from android that likes to just talk directly to
8.8.8.8 anyway.
In the wild, some dns request analysis reveals the worst
culprits (this is a very basic analysis) appear to be all
the google update stuff, play store etc, facebook iCloud,
(all to be expected) , and certain CDNs. Some research shows
that these CDN companys specialize in delivery of
advertising content inside apps such as mobile platform
games. Such is the sad state of affairs on today's internet.
Fortunately, we have iptables and ip sets and we have AS
blocks assigned to certain bandwidth hungry corporations :-)
So turns out it seems quite feasible to supply service for
text messages with certain popular IM services to many phones.
Short voice clips worked quite well in the lab tests,
although support for media such as pictures and videos was
not so great. I have yet to successfully send an image
(sourced via device camera within the app) over a "secret"
chat with Telegram messenger.
As this is not a very low level report, rather intended as
some light reading :) I also have a question in a similar
light vein.
I'm still getting to grips with the log messages available
in the pcu , the sgsn and not so much the ggsn, and I'm
observing and learning the sequence of events, so at some
point I should be able to present a better report about this
with some relevant traces and better analysis.
For now, In the lab tests I am constantly monitoring the RF
uplink; I observe that a phone will attach and then go
quiet. A foreground running app may report that it is
"connecting" or some such, and the little arrows may be
flashing to show that apparently we are transmitting data,
but there is nothing on the uplink. My guess here is the OS
has sent something and the baseband is saying yes yes doing
it.. but the baseband at the same time is waiting for
something from the network (and not getting it)?
This situation can persist for some time.. several minutes.
I have observed that if I initiate any data transfer from
the network side then the uplink is established. By the same
token, If I transfer a file from the network (http download
or some such), the same applies. The link stays active and
the IM chat session is very responsive alongside the file
transfer. Shortly after the file transfer completes, the
uplink is quiet again and the latency in the IM session
becomes a problem.
>From a UX point of view.. Let me put it this way.. I can
start an IM chat, send a message.. but then we get to this
quiet uplink sitation and the messages stop sending.. so
from the user's point of view it's frustrating. the phone
looks like it's transmitting.. until there are timeouts and
disconnections and the app may show some indication to the
user that it is having trouble connecting to the network.
However if I run something on the network side like a script
that sends one ping to the phone every ten seconds, this
keeps the connection 'alive' and the IM session is much more
satisfactory for the user.
I should note I believe I observe this also on commercial
networks in some places like certain Berlin U-bahn stations
where you can still find (only) GPRS data coverage. Also, a
more scientific report is needed, but I seem to observe some
phones behaving "better" than others, as in being a little
more active on the uplink. Maybe it is related to power
saving configuration?
The not very low level and scientific question here is: Is
this kind of thing tunable with gprs parameters?
Any tips on which ones to play with? ( Quite happy to wait
until I can send a more useful report too! )
Thanks!
Keith.
Hi,
I see the range for ipa unit-d site_id range of values is 0-65534 as
configured in the VTY:
osmo-bts/src/common/vty.c
397: "ipa unit-id <0-65534> <0-255>",
However, being it a uint16_t having 2^16=65536 values, I would expect
the range to be 0-65535 (finished in 5, not 4). The only reason I can
think of is that the last address is somehow reserved and must not be
used. Does somebody know if that's the case? I couldn't find any
documentation and as far as I can tell our code doesn't seem to handle
the site_id=65535 case specially. If it is not reserved, then I can send
a patch to change the range to be 0-65535.
I actually see the same range pattern in lots of places around osmocom
vty parameters, which makes me think somebody may have initially
introduced the wrong number and then people have been copy-pasting the
same number over and over again when adding new parameters:
$ ag "0-65534"
libosmocore/src/gb/gprs_ns_vty.c
269: "nse <0-65535> nsvci <0-65534>",
libosmo-sccp/src/osmo_ss7_vty.c
420: "listen " XUA_VAR_STR " <0-65534>",
442: "no listen " XUA_VAR_STR " <0-65534>",
osmo-sgsn/src/gprs/gb_proxy_vty.c
149: "sgsn nsei <0-65534>",
364: "secondary-sgsn nsei <0-65534>",
532: "delete-gbproxy-peer <0-65534> bvci <2-65534>",
553: "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]",
626: "delete-gbproxy-link <0-65534> (tlli|imsi|sgsn-nsei) IDENT",
698: "delete-gbproxy-link <0-65534> (stale|de-registered)",
osmo-bsc/src/libbsc/bsc_vty.c
1850: "ip.access unit_id <0-65534> <0-255>",
openbsc/openbsc/src/libmgcp/mgcp_vty.c
294: "bind port <0-65534>",
337: "rtp bts-base <0-65534>",
350: "rtp bts-range <0-65534> <0-65534>",
360: "rtp net-range <0-65534> <0-65534>",
370: "rtp net-base <0-65534>",
378: "rtp base <0-65534>",
383: "rtp transcoder-range <0-65534> <0-65534>",
393: "rtp transcoder-base <0-65534>",
596: "number endpoints <0-65534>",
755: "transcoder-remote-base <0-65534>",
1119: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out)
A.B.C.D <0-65534>",
openbsc/openbsc/src/libbsc/bsc_vty.c
1803: "ip.access unit_id <0-65534> <0-255>",
osmo-mgw/src/libosmo-mgcp-client/mgcp_client_vty.c
130: "mgw bts-base <0-65534>",
140: "mgcpgw bts-base <0-65534>",
osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c
294: "bind port <0-65534>",
337: "rtp bts-base <0-65534>",
350: "rtp bts-range <0-65534> <0-65534>",
360: "rtp net-range <0-65534> <0-65534>",
370: "rtp net-base <0-65534>",
378: "rtp base <0-65534>",
383: "rtp transcoder-range <0-65534> <0-65534>",
393: "rtp transcoder-base <0-65534>",
606: "number endpoints <0-65534>",
765: "transcoder-remote-base <0-65534>",
1130: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out)
A.B.C.D <0-65534>",
osmo-mgw/src/libosmo-mgcp/mgcp_vty.c
264: "bind port <0-65534>",
297: "rtp net-range <0-65534> <0-65534>",
509: "number endpoints <0-65534>",
947: "tap-rtp <0-64> ENDPOINT CONN (in|out) A.B.C.D <0-65534>",
osmo-bts/src/common/vty.c
397: "ipa unit-id <0-65534> <0-255>",
Regards,
--
- Pau Espin Pedrol <pespin(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
* Geschaeftsfuehrer / Managing Director: Harald Welte
Just now the gerrit disk quota filled up. It hit the limit at 7.6G disk usage.
I gave it 10G of space via zfs to not get pulled in too deeply, we may want to
investigate whether anything filled it up unintendedly/erratically.
When I look at the listing I made when writing
https://osmocom.org/projects/osmocom-servers/wiki/Osmocomorg_Web_Servers gerrit
already had 7.19 G disk usage then. It seems some snapshot may have filled up
the rest now, and the remaining 400Mb are from new commit objects / repos repack?
It's too late now for me to wait for a du to complete...
~N
I've recently upgraded my OS to debian 9 and suddenly have difficulty building
osmo-iuh: the osmo-hnbgw linking step complains about a missing sctp_send,
which is resolved by adding -lsctp to LDADD. But I'm puzzled why this comes
from a system upgrade and not a code change. Does anyone have an idea what
could cause this, or what would have hidden the linking error before?
What's the proper way to add -lsctp? The dependency comes from libosmo-ranap
using libosmo-sigtran
- should the libosmo-sigtran.pc include -lsctp?
- should we add a libsctp detection to osmo-iuh's configure.ac (copy from
libosmo-sccp) and use $(SCTP_LIBS) constants in Makefile.am LDADD?
- is everything correct and my OS has a problem instead?
Thanks for any input...
~N
Hi All,
May we request on how to allow specific number of IMSI in OSMO-BSC?
We tried the following using the REGEXP below, but all kinds of IMSIs are still able to camp.
First try:
auth policy regexp
authorized-regexp ^12312\d{10}$
Second try:
auth policy regexp
authorized-regexp 12312\d{10}
We also tried to used the access-list imsi-allow under BSC and then declare it under MSC configuration but still has the same behavior. All kinds of IMSIs are still allowed.
First try:
bsc
access-list TEST imsi-allow ^12312\d{10}$
access-list-name TEST
msc 0
access-list-name TEST
Second try:
bsc
access-list TEST imsi-allow 12312\d{10}
access-list-name TEST
msc 0
access-list-name TEST
We also tried to to used the access-list imsi-deny using the same regular expressions, unfortunately, still have the same outcome. All IMSIs are still allowed.
First try:
bsc
access-list TEST imsi-deny ^12312\d{10}$ 16 16
access-list-name TEST
msc 0
access-list-name TEST
Second try:
bsc
access-list TEST imsi-deny ^12312\d{10}$ 16 16
access-list-name TEST
msc 0
access-list-name TEST
But using access-list imsi-deny to a specific IMSI, we successfully block it.
Is there a way to block a number of different IMSIs only?
What regular expression format is used by OSMO-BSC?
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
See <http://jenkins.osmocom.org/jenkins/job/Coverity-Upload/label=linux_amd64_de…>
------------------------------------------
[...truncated 1.84 MB...]
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here
test_apps/Makefile.am:17: warning: source file '$(TESTAPPS_SOURCE_DIR)/esme.c' is in a subdirectory,
test_apps/Makefile.am:17: but option 'subdir-objects' is disabled
binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:72: warning: source file '$(TESTPDU_SOURCE_DIR)/generic_nack_test.c' is in a subdirectory,
test_pdu/Makefile.am:72: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:76: warning: source file '$(TESTPDU_SOURCE_DIR)/outbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:76: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:80: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:80: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:84: warning: source file '$(TESTPDU_SOURCE_DIR)/query_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:84: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:88: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:88: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:92: warning: source file '$(TESTPDU_SOURCE_DIR)/replace_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:92: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/tcp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/smpp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here
test_apps/Makefile.am:4: warning: source file '$(TESTAPPS_SOURCE_DIR)/sendwp.c' is in a subdirectory,
test_apps/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:9: 'test_apps/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:4: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:4: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:8: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_multi_test.c' is in a subdirectory,
test_pdu/Makefile.am:8: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:96: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:96: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:100: warning: source file '$(TESTPDU_SOURCE_DIR)/submit_sm_test.c' is in a subdirectory,
test_pdu/Makefile.am:100: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:104: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_resp_test.c' is in a subdirectory,
test_pdu/Makefile.am:104: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/core.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
test_pdu/Makefile.am:108: warning: source file '$(TESTPDU_SOURCE_DIR)/unbind_test.c' is in a subdirectory,
test_pdu/Makefile.am:108: but option 'subdir-objects' is disabled
binaries/Makefile.am:8: 'test_pdu/Makefile.am' included from here
binaries/Makefile.am: installing 'aux_config/depcomp'
test_apps/Makefile.am:26: warning: variable 'analizer_SOURCES' is defined but no program or
test_apps/Makefile.am:26: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:17: warning: variable 'esme_SOURCES' is defined but no program or
test_apps/Makefile.am:17: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:4: warning: variable 'sendwp_SOURCES' is defined but no program or
test_apps/Makefile.am:4: library has 'sendwp' as canonical name (possible typo)
test_apps/Makefile.am:30: warning: variable 'analizer_LDFLAGS' is defined but no program or
test_apps/Makefile.am:30: library has 'analizer' as canonical name (possible typo)
test_apps/Makefile.am:24: warning: variable 'esme_LDFLAGS' is defined but no program or
test_apps/Makefile.am:24: library has 'esme' as canonical name (possible typo)
test_apps/Makefile.am:11: warning: variable 'sendwp_LDFLAGS' is defined but no program or
test_apps/Makefile.am:11: library has 'sendwp' as canonical name (possible typo)
+ ./configure --prefix=/home/osmocom-build/osmo-ci/coverity/install-Osmocom
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
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 ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking for stdint.h... (cached) yes
checking for string.h... (cached) yes
checking for LIBXML2... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for memset... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating def_frame/Makefile
config.status: creating def_list/Makefile
config.status: creating binaries/Makefile
config.status: creating test_apps/Makefile
config.status: creating libsmpp34.pc
config.status: creating aux_config/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
+ make -j 3
echo 1.12.10-05bc > .version-t && mv .version-t .version
make all-recursive
make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Making all in binaries
make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c -o libsmpp34_la-smpp34_dumpBuf.lo `test -f '../src/smpp34_dumpBuf.c' || echo './'`../src/smpp34_dumpBuf.c
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c -o libsmpp34_la-smpp34_dumpPdu.lo `test -f '../src/smpp34_dumpPdu.c' || echo './'`../src/smpp34_dumpPdu.c
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c -o libsmpp34_la-smpp34_pack.lo `test -f '../src/smpp34_pack.c' || echo './'`../src/smpp34_pack.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpBuf.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_pack.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_dumpPdu.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpBuf.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpBuf.Tpo -c ../src/smpp34_dumpBuf.c -o libsmpp34_la-smpp34_dumpBuf.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_dumpBuf.Tpo .deps/libsmpp34_la-smpp34_dumpBuf.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c -o libsmpp34_la-smpp34_unpack.lo `test -f '../src/smpp34_unpack.c' || echo './'`../src/smpp34_unpack.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_unpack.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_pack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_pack.Tpo -c ../src/smpp34_pack.c -o libsmpp34_la-smpp34_pack.o >/dev/null 2>&1
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_dumpPdu.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_dumpPdu.Tpo -c ../src/smpp34_dumpPdu.c -o libsmpp34_la-smpp34_dumpPdu.o >/dev/null 2>&1
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_unpack.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_unpack.Tpo -c ../src/smpp34_unpack.c -o libsmpp34_la-smpp34_unpack.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_pack.Tpo .deps/libsmpp34_la-smpp34_pack.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c -o libsmpp34_la-smpp34_structs.lo `test -f '../src/smpp34_structs.c' || echo './'`../src/smpp34_structs.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_structs.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_structs.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_structs.Tpo -c ../src/smpp34_structs.c -o libsmpp34_la-smpp34_structs.o >/dev/null 2>&1
mv -f .deps/libsmpp34_la-smpp34_structs.Tpo .deps/libsmpp34_la-smpp34_structs.Plo
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c -o libsmpp34_la-smpp34_params.lo `test -f '../src/smpp34_params.c' || echo './'`../src/smpp34_params.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -fPIC -DPIC -o .libs/libsmpp34_la-smpp34_params.o
mv -f .deps/libsmpp34_la-smpp34_unpack.Tpo .deps/libsmpp34_la-smpp34_unpack.Plo
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT core.o -MD -MP -MF .deps/core.Tpo -c -o core.o `test -f '../test_pdu/core.c' || echo './'`../test_pdu/core.c
mv -f .deps/core.Tpo .deps/core.Po
gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -fPIC -g -O2 -MT submit_multi_resp_test.o -MD -MP -MF .deps/submit_multi_resp_test.Tpo -c -o submit_multi_resp_test.o `test -f '../test_pdu/submit_multi_resp_test.c' || echo './'`../test_pdu/submit_multi_resp_test.c
make[2]: *** No rule to make target '../binaries/libsmpp34.la', needed by 'submit_multi_resp_test'. Stop.
make[2]: *** Waiting for unfinished jobs....
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../aux_config -I../src -I.. -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -Wall -D_REENTRANT -DBSD_COMP -D_POSIX_PTHREAD_SEMANTICS -g -O2 -MT libsmpp34_la-smpp34_params.lo -MD -MP -MF .deps/libsmpp34_la-smpp34_params.Tpo -c ../src/smpp34_params.c -o libsmpp34_la-smpp34_params.o >/dev/null 2>&1
mv -f .deps/submit_multi_resp_test.Tpo .deps/submit_multi_resp_test.Po
mv -f .deps/libsmpp34_la-smpp34_dumpPdu.Tpo .deps/libsmpp34_la-smpp34_dumpPdu.Plo
mv -f .deps/libsmpp34_la-smpp34_params.Tpo .deps/libsmpp34_la-smpp34_params.Plo
make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34/binaries'
Makefile:460: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libsmpp34'
Makefile:368: 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 454 C/C++ compilation units (100%) successfully
454 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
Dear Osmocom community,
since the NITB-split has completed, and we have integrated 3G fully
into master, and also merged nitb-split and nitb packages in one
feed, the next step on the agenda was to create packages/feeds that
are more stable than "nightly".
After a long day of "release engineering" work and related fixes,
starting from today, Osmocom not only has the "osmocom:nightly" feed
tracking the "master of the day" of all repositories.
We now also have a "osmocom:latest" feed for various Debian and Ubuntu
GNU/Linux distributions which contains packages for the last tagged
version of each source code repository.
The setup is fairly similar to that of the "osmocom:nightly" packages
and is described at
https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds
I've also removed all known references to Nightly_Builds on the wiki and
replaced it with a reference to the new Binary_Packages page explaining
the differences between Nightly_Builds and Latest_Builds:
https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
As you can see at
https://build.opensuse.org/project/monitor/network:osmocom:latest
almost all the packages are building already. I intend to fix the
remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly.
--
- Harald Welte <hwelte(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
* Geschaeftsfuehrer / Managing Director: Harald Welte
We currently do gerrit verifications on debian8-amd64 only. Only osmo-hlr has
also deb9 set as build slave to test.
I'd move over to deb9 now and no longer build on deb8.
What do you guys think, should we build on both deb8 and deb9?
~N
Hi.
For quite some time Osmocom packages are available in Debian [1] and Ubuntu [2]
repositories. That's a really nice thing although there're only minor distro-specific
updates between different releases so far.
In addition to usual "fix old bugs, add new features (and bugs :)" progress, there're
bigger changes happening in Osmocom [3] projects.
Most notably: we now have multiple repositories for BSC/MSC/SGSN instead of single
OpenBSC repo. The process is not finished yet (doc/manuals update is still under way
for example) but I think it's already a good time to discuss how can we bring those
changes into Debian/Ubuntu repositories. We already have nightly builds for all
packages from new repositories [4] as well as old ones [5].
The basic question is - what shall we do to get the packages built from new
repositories into Debian/Ubuntu?
Is there something we (upstream) can do, to facilitate the process?
Are there some notable .deb-specific patches you'd like to see merged?
Should I have used some other channel to communicate instead of emails I've fetched
from changelogs?
[1]
https://packages.debian.org/search?keywords=osmocom&searchon=names&suite=st…
[2]
https://packages.ubuntu.com/search?suite=all§ion=all&arch=amd64&keyword…
[3] https://osmocom.org/issues/2257
[4] https://build.opensuse.org/project/monitor/network:osmocom:nitb-split:night…
[5] https://build.opensuse.org/project/monitor/network:osmocom:nightly
--
Max Suraev <msuraev(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
* Geschaeftsfuehrer / Managing Director: Harald Welte
I just noticed that osmo-iuh is not able to generate Iu protocols from ASN.1
sources anymore. This has probably been the case for a while, but it was
uncovered by the osmo-clean-workspace.sh scripts recently introduced.
There are some .h and .c files missing that sed wants to modify. I get:
sed -i '6i#include <constr_CHOICE.h>' RANAP_ChosenEncryptionAlgorithm.h RANAP_ChosenIntegrityProtectionAlgorithm.h RANAP_IMSI.h RANAP_PLMNidentity.h RANAP_RAB-ReleaseFailedList.c RANAP_RAB-ReleaseList.c RANAP_RAB-SetupOrModifyList.c RANAP_ResetResourceList.c RANAP_ResetResourceAckList.c
sed: can't read RANAP_ChosenEncryptionAlgorithm.h: No such file or directory
sed: can't read RANAP_ChosenIntegrityProtectionAlgorithm.h: No such file or directory
sed: can't read RANAP_IMSI.h: No such file or directory
sed: can't read RANAP_PLMNidentity.h: No such file or directory
sed: can't read RANAP_RAB-ReleaseFailedList.c: No such file or directory
sed: can't read RANAP_RAB-ReleaseList.c: No such file or directory
sed: can't read RANAP_RAB-SetupOrModifyList.c: No such file or directory
sed: can't read RANAP_ResetResourceList.c: No such file or directory
sed: can't read RANAP_ResetResourceAckList.c: No such file or directory
Makefile:2711: recipe for target 'regenerate-from-asn1-source' failed
make[1]: *** [regenerate-from-asn1-source] Error 2
make[1]: Leaving directory '/n/s/osmo/make-3G/osmo-iuh/src/ranap'
Notably, jenkins produces slightly different output, see
https://jenkins.osmocom.org/jenkins/job/osmo-iuh/34/label=linux_amd64_debia…https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-iuh/1/a1=default,a2=def…
Does anyone know what could have caused this?
~N