We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester.
I have run a tcpdump on the ntp port for the past days, and nothing is doing
ntp besides the actual ntp service.
Today I started ntp while an osmo-bts-trx run was active and what do you know,
the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx
shouldn't use wall clock time for precise timing needs.
Besides that, I have no idea what could cause the clock skews, except maybe
that the CPU or the USB are not fast enough?? I'm wondering, is there still
such a thing as a separate linux realtime kernel?
We will soon take to productive use another main unit which will be a cleanly
installed OS. If we see the same problems on that system and can't find a
software fix, we may need to reconsider the tester for osmo-bts-trx...
~N
I'd like to share a VTY config error analysis that has a tricky solution:
I started osmo-bsc -c osmo-bsc.cfg with, according to
openbsc/doc/examples/osmo-bsc:
net
[...]
bts 0
[...]
periodic location update 30
trx 0
[...]
and get this error:
There is no such command.
Error occurred during reading below line:
trx 0
what? 'net / bts / trx' is no command??
Solution: I'm on the vlr_3G branch (incorporating 2G via A-interface) and on
this branch, I've actually moved the 'periodic location update N' command a
level up, from net / bts / periodic to net / periodic (background: assuming
that OsmoMSC does not have individual BTS info, we moved some settings up to
network level; whether this makes sense for osmo-bsc is a different question,
it's just what happens to be on the vlr_3G branch now).
So there is no net / bts / periodic command.
Why do I get an error for net / bts / trx instead?
two reasons:
1. 'trx 0' was the line following the 'periodic' command,
2. since 'periodic' exists one level above, the vty code goes to the parent
node automatically.
About 2: we tend to indent our VTY config files, but in fact the indentation
has no effect whatsoever, it is just eye candy (very useful eye candy).
The code in question: If a command does not exist, try 'vty_go_parent()' and
see if the command exists there. That's what allows us to omit 'exit' in our
config files to go to the parent node explicitly:
libosmocore/src/vty/command.c:
int config_from_file(struct vty *vty, FILE * fp)
{
int ret;
vector vline;
while (fgets(vty->buf, VTY_BUFSIZ, fp)) {
vline = cmd_make_strvec(vty->buf);
/* In case of comment line */
if (vline == NULL)
continue;
/* Execute configuration command : this is strict match */
ret = cmd_execute_command_strict(vline, vty, NULL);
/* Try again with setting node to CONFIG_NODE */
while (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO
&& is_config_child(vty)) {
HERE -----> vty_go_parent(vty);
ret = cmd_execute_command_strict(vline, vty, NULL);
}
cmd_free_strvec(vline);
if (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO)
return ret;
}
return CMD_SUCCESS;
}
In this case the 'periodic...' command does in fact now exist one level above,
so the vty_go_parent() is successful and running that command works. But, the
vty config parsing then sits above on the 'network' level, is no longer in 'bts
0' and hence refuses to accept the following bts-level command, in this case
'trx 0'. Confusing!
So it's not a bug, it's a feature. But it's a feature we might see quite often
if we move the 'periodic' command up to network level and users attempt to use
their old config files.
Same goes for the 'timezone' command, BTW, so we might want to rename commands,
or re-consider moving commands one level up in the first place. Maybe we should
leave backward compat catchers in place that print a warning.
~N
--
- 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
Dear all,
I've started to implement some test cases that validate the accuracy of
OsmoBTS and OsmoBSC SYSTEM INFORMATION generation.
Those test cases are written in TTCN-3, which is a special programming
language specifically designed for testing and validation of protocol
stacks. For those present at OsmoDevCon, I've briefly presented about
it there.
In terms of general core infrastructure, I've written:
* Definition of GSM RR and some other commonly used GSM types using the
TTCN-3 type description language and the TITAN RAW (binary) encoder/decoder.
The beauty of this is that one can simply describe the message
structure without having to generate any code for encoding/decoding
the message. See
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_Types.ttcn
and
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_SystemInformation.…
* A GSMTAP Test Port, whcih is basically how a TTCN-3 testcase/testsuite
interacts with a given IUT (implementation under test). It is
implemented as dual-faced port on top of the TITAN IPL4asp (ip layer 4)
port and implements GSMTAP header encoding/decoding from/to TTCN-3
structured data types:
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_PortType.ttcn
which uses
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_Types.ttcn
describing the GSMTAP header format.
* Helper functions to emulate interactive use of the VTY based on the
existing TITAN TELNETasp Test Port:
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/Osmocom_VTY_Functions.…
* L1CTL type definition (again using auto-generated encoder/decoders!)
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_Types.ttcn
as well as an L1CTL Test Port at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_PortType.ttcn
Using the above one can easily interface from TTCN3 with L1CTL of
virtphy in order to e.g. sync to a BTS on a given ARFCN and establish
a dedicated radio channel. Here is where the beautoy of the TTCN3
type language, templates and matching can be seen. It's very easy to
perform something like "does this IMMEDIATE ASSIGNMENT match the RA +
FN of the RACH request that I sent?
Based on all of the above, there's two test suites:
== Test Suites
1) SYSTEM INFORMATION contents and scheduling validation
I've written some SI validation code which can be found at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo
SI scheduling is quite complex, particularly when you have many of the
2ter/2bis/2quater/13/2n/... enabled. At some point actually you will
overflow what's possible to comply with the rules in a BCCH Norm. and
you have to go to a BCCH Extd. (OsmoBTS doesn't implement the latter
yet, btw).
See e.g. function f_validate_si_scheduling() for validation of scheduling
constraints:
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn#n229
Later in the file you can find test cases TC_cellid() and below for the
individual test cases that validate that individual VTY configured
values such as BSIC, CellId, LAC, ... are actually broadcast in the SI
message. IT will update its internal matching template and then perform
a sequence of VTY commands to e.g. change the LAC followed by verifying
that the LAC of the decoded SI has actually changed.
The above tools have helped to discover (and fix) the following bugs:
* http://osmocom.org/issues/2368
* http://osmocom.org/issues/2367
* http://osmocom.org/issues/2365 (very critical, I believe)
and also the not-yet-fixed but low-importance
* http://osmocom.org/issues/2364
2) LAPDm testing
I've written some (early) LAPDm testing code at
http://git.osmocom.org/osmo-ttcn3-hacks/tree/lapdm
The idea here is to test for valid and invalid transactions on the Um
interface and see how OsmoBTS and the libosmcore lapdm code perform.
With very few lines, this has already uncovered the following issues:
* http://osmocom.org/issues/2370
* http://osmocom.org/issues/2380
Unfortunately my progress was severely affected over the weekend as I
spent about one working day wrapping my head around something that
turned out to be a bug in the Eclipse TITAN RAW coder, see
https://www.eclipse.org/forums/index.php/t/1087557/ - fortuantely the
Titan team has provided both a work-around and a fix today, which I
count as excellent service.
If you're curious about TTCN-3, I strongly recommend
http://www.ttcn-3.org/files/TTCN3_P.pdf as an introductory slide deck.
== Outlook
I want to add more test cases to the sysinfo and lapdm test suites and
get hands-on experience with the Junit XML output plugin. At that
point, a Debian 9 build slave of our jenkins should be able to
automatically build + run the latest test cases from
osmo-ttcn3-hacks.git and present the individual test case results inside
jenkins.
I also want to add test suites for validation of:
* proper generation + scheduling of of PAGING REQUEST in the BTS,
considering paging groups particularly in the context of different
BS_AG_BLKS_RES values
* CBCH validation
* proper generation of CCCH load indications by the BTS, i.e. generate a
certian load e.g. on uplink RACH and check the reports
* TA loop verification (add timing information to GSMTAP and then
dynamically change timing from MS side to see that BTS is compensating
as expected
* power control loop verification: GSMTAP already has a field for
transmitting RSSI in dBm. We can adjust this from the MS side to
validate the BTS will adjus the instructed transmit power level of the
virtual MS accordingly
* actually exhaust all channels of a multi-TRX virtual BTS in different
channel combinations, verify we can establish all existing logical
channels in each configuration
* combine the last topic with configurations that have dynamic PDCH/TCH
channels to verify we properly switch forward and backward
* various link failure conditions, i.e. does the BTS close the logical
channel in the expected timing after uplink loss?
Despite my current excitement about all of this, I'm not sure how much
time I will be able to spend on this, given that the sysmocom customer
priority is typically not the development of automatic test suites. But
I'll try my best.
If anyone wants to join: TITAN is just one "apt-get install eclipse-titan"
away!
== What's not good to test with TTCN-3 / TITAN:
While the existing infrastructure I've built is very suitable to test
low-level protocol topics, I think it's not particularly
useful/applicable in other areas:
* SI REST OCTETS and GPRS RLC/MAC, as they're defined in CSN.1 and TITAN
has no CSN.1 encoder/decoder. For easy mathing/generation of those
messages, we'd have to find something like an external
CSN.1-to-ASN.1-BER or CSN.1-to-XML converter which we could use. I'd
be happy to consider paying a reasonable amount for a proprietary
product, just as long as we are sure that it will provde the kind of
productivity that's useful here.
* full end-to-end tests with actual mobile phones, RF and BTSs in the
picture. We already have osmo-gsm-tester for this, and Titan with its
powerful type language, templates and matching capabilities doesn't
provide all that much benefit here over other languages/approaches
* higher-layer protocol testing. We do have OsmocomBB as a L2 + L3
MS-side implementation, and I don't think it makes sense to replicate
this. Even while the message encoding/decoding is super easy with
TITAN, we still have all the related state machines. So I'd rather
extend OsmocomBB where needed for automatic test cases than reinvent
the wheel here.
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’m not sure if this is a valid question but still I’m going to try.
I just updated from my old version of OSMOCOM to the latest one.
Upon trying to test the updated version, it seems that the ring back tone, the one that rings in the Caller (Anum/Mobile Originating) side if the call started to ring on the Callee (BNUM/Mobile Terminating) side, is missing.
Can anyone direct me to the right path where to check it?
Below are the configuration files used for each OSMOCOM elements.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
We are trying to setup this AP as part of the 3.5G Osmocom project.
We have the software stack operational and are now preparing the nano
for testing.
When we try to login via telnet at port 8090 we are getting a constant
refusal to connect:-
root@osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090
Trying 192.168.192.30...
telnet: Unable to connect to remote host: Connection refused
The device seems to be locked as indicated by the leds on the front panel.
We have tried resetting the nano to see if this would help but to no avail.
Any ideas as to how to access the device for initial configuration?.
Thanks
John
In the libosmo-sigtran cs7-instance vty scope, we have the same point-code
command on adjacent scopes:
cs7 instance 1
point-code 1.2.3 ! sets primary_pc
sccp-address msc
point-code 0.0.1
sccp-address sgsn
point-code 0.0.2
So if we reverse the order, we're in trouble:
cs7 instance 1
sccp-address msc
point-code 0.0.1
sccp-address sgsn
point-code 0.0.2
point-code 1.2.3 ! sets primary_pc
The parser interprets the last point-code to belong to the sgsn address scope,
not the outer cs7 scope.
We could rename the sccp-address one to 'pc', but...
This reinforces the idea to do strict parsing of leading spaces in all our vty
config files to interpret as explicit scope exit. That would break some running
configs with odd spacing, but would also fix all of these issues forever.
Given we're moving to a kind of Osmocom 2.0, now would be a good time to make
such a change.
If we from now on disallow tabs and enforce single-space indenting of child
scopes, the code for that should be rather simple: count leading spaces and
done. And we'd need to turn this off for interactive VTY shells.
~N
We are trying to setup this AP as part of the 3.5G Osmocom project.
We have the software stack operational and are now preparing the nano
for testing.
When we try to login via telnet at port 8090 we are getting a constant
refusal to connect:-
root@osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090
Trying 192.168.192.30...
telnet: Unable to connect to remote host: Connection refused
The device seems to be locked as indicated by the leds on the front panel.
We have tried resetting the nano to see if this would help but to no avail.
Any ideas as to how to access the device for initial configuration?.
Thanks
John
Some code that is disabled to be able to compile libmsc without libbsc is
related to communication to the BTS, that is replaced by the new A-interface.
However, the following bits are not; Any opinions about what to do with it:
- Report on which ARFCN and timeslot a silent call has occured.
I would simply drop the ARFCN and timeslot information, saying "silent call
successful". (same in two log messages)
static int scall_cbfn(unsigned int subsys, unsigned int signal,
void *handler_data, void *signal_data)
{
struct scall_signal_data *sigdata = signal_data;
struct vty *vty = sigdata->data;
switch (signal) {
case S_SCALL_SUCCESS:
vty_out(vty, "%% silent call on ARFCN %u timeslot %u%s",
sigdata->conn->lchan->ts->trx->arfcn, sigdata->conn->lchan->ts->nr,
VTY_NEWLINE);
break;
case S_SCALL_EXPIRED:
vty_out(vty, "%% silent call expired paging%s", VTY_NEWLINE);
break;
}
return 0;
}
- Add Osmocom specific TLVs to SMPP
/* Append the Osmocom vendor-specific additional TLVs to a SMPP msg */
static void append_osmo_tlvs(tlv_t **req_tlv, const struct gsm_lchan *lchan)
{
int idx = calc_initial_idx(ARRAY_SIZE(lchan->meas_rep),
lchan->meas_rep_idx, 1);
const struct gsm_meas_rep *mr = &lchan->meas_rep[idx];
const struct gsm_meas_rep_unidir *ul_meas = &mr->ul;
const struct gsm_meas_rep_unidir *dl_meas = &mr->dl;
/* Osmocom vendor-specific SMPP34 extensions */
append_tlv_u16(req_tlv, TLVID_osmo_arfcn, lchan->ts->trx->arfcn);
if (mr->flags & MEAS_REP_F_MS_L1) {
uint8_t ms_dbm;
append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_l1.ta);
ms_dbm = ms_pwr_dbm(lchan->ts->trx->bts->band, mr->ms_l1.pwr);
append_tlv_u8(req_tlv, TLVID_osmo_ms_l1_txpwr, ms_dbm);
} else if (mr->flags & MEAS_REP_F_MS_TO) /* Save Timing Offset field = MS Timing Offset + 63 */
append_tlv_u8(req_tlv, TLVID_osmo_ta, mr->ms_timing_offset + 63);
append_tlv_u16(req_tlv, TLVID_osmo_rxlev_ul,
rxlev2dbm(ul_meas->full.rx_lev));
append_tlv_u8(req_tlv, TLVID_osmo_rxqual_ul, ul_meas->full.rx_qual);
if (mr->flags & MEAS_REP_F_DL_VALID) {
append_tlv_u16(req_tlv, TLVID_osmo_rxlev_dl,
rxlev2dbm(dl_meas->full.rx_lev));
append_tlv_u8(req_tlv, TLVID_osmo_rxqual_dl,
dl_meas->full.rx_qual);
}
if (lchan->conn && lchan->conn->vsub) {
struct vlr_subscr *vsub = lchan->conn->vsub;
size_t imei_len = strlen(vsub->imei);
if (imei_len)
append_tlv(req_tlv, TLVID_osmo_imei,
(uint8_t *)vsub->imei, imei_len+1);
}
}
deliver_to_esme() {
[...]
if (esme->acl && esme->acl->osmocom_ext && conn->lchan)
append_osmo_tlvs(&deliver.tlv, conn->lchan);
[...]
}
- Siemens BS11 MRPCI
/* see mail on openbsc@ 9 Feb 2016 22:30:15 +0100
* We need to hook sending of MRPCI to Siemens BS11 somewhere else */
if (is_siemens_bts(conn->bts))
send_siemens_mrpci(msg->lchan, classmark2-1);
- Debug log: report bts - trx - ts - ti in mncc_rcvmsg()
(No BTS information available in OsmoMSC anymore)
- In gsm48_cc_rx_setup(), populate struct gsm_mncc setup with lchan type.
(lchan information is no longer available in OsmoMSC)
- In libmsc, gsm_04_08.c, we connect libbsc handle_abisip_signal(); the same is
done in osmo_bsc_audio.c in osmo_bsc_audio_init(), so I assume it can be
dropped from libmsc.
/*
* This will be run by the linker when loading the DSO. We use it to
* do system initialization, e.g. registration of signal handlers.
*/
static __attribute__((constructor)) void on_dso_load_0408(void)
{
osmo_signal_register_handler(SS_ABISIP, handle_abisip_signal, NULL);
}
~N
Hi,
> Error occurred during reading below line:
> timer t3103 0
I may be wrong, but it's probably related to recent change:
http://git.osmocom.org/openbsc/commit/?id=ab2454e776f1a4bc4977ef48ec2844600…
In short, it doesn't make sense to set '0' value to any timer.
So, updating the software, please also keep your configuration
updated ;)
With best regards,
Vadim Yanitskiy.
Hi All,
Requesting your help on this kind of issue. Upon running the osmo-nitb, we had received and error regarding the timer configuration.
osmo-nitb -C -c /root/osmocom_files/openbsc_1trx.conf -T -P -m
Sat Jul 22 18:28:18 2017 <0006> mncc_sock.c:316 MNCC socket at /tmp/bsc_mncc
There is no such command.
Error occurred during reading below line:
timer t3103 0
% Ignoring deprecated logging level everything
% Ignoring deprecated logging level everything
Sat Jul 22 18:28:18 2017 <0005> bsc_init.c:536 Failed to parse the config file: '/root/osmocom_files/openbsc_1trx.conf'
Reading config failed. Exiting.
But upon removing all the timer configured in the configuration file, osmo-nitb run as usual. Not sure if you guys removed it in purpose.
Kindly advice please.
osmo-nitb version used: 0.15.1.20170721
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
(Posting to the OpenBSC list because I figured that the set of people
who issue their own SIMs probably has a good overlap with the set of
people who operate their own physical GSM networks.)
I am shopping for some non-carrier-branded, non-carrier-issued SIM
cards for use in testing my FreeCalypso GSM MS devices (specifically,
testing of the SIM interface in isolation without bringing up radio,
as well as radio and full MS functionality testing with a base station
simulator like CMU200 instead of live networks), and the only product
I found so far is sysmoUSIM - if anyone else makes a similar product
("generic" SIM cards for tinkerers), I would like to know about it.
In the case of sysmo(U)SIM cards, it looks like 2FF-only cards are no
longer available, and the current choices are 2FF+3FF or 2FF+4FF. My
question is: if I only want 2FF and have no interest in 3FF or 4FF,
which variant should I buy? In other words, which variant is
mechanically stronger and less likely to break in 2FF-only usage in
various kinds in 2FF sockets?
TIA,
Mychaela
Hi there!
I've been trying to install some old releases using the build_2g.sh
script, but I'm having problems.
The releases are:
OpenBSC 0.14.0
opengssn 0.92
libosmo-abis 0.3.1
libosmo-netif 0.0.4
libosmo-sccp 0.0.6.3
libsmpp34 1.10
libosmocore 0.8.0
Here is the output, I just want to know if this script is not compatible
with those releases, because building one by one on Debian 9 has been a
real fight, lol.
Cheers!
openbsc@debian:~/osmo$ ./build_2g.sh
+ base=/home/openbsc/osmo
+ builddir=build-2G
+ echo ======================= libosmocore ======================
======================= libosmocore ======================
+ cd /home/openbsc/osmo/libosmocore
+ [ 1 = 1 ]
+ set +e
+ make distclean
make: *** No rule to make target 'distclean'. Stop.
+ rm -rf build-2G
+ set -e
+ autoreconf -fi
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:14: installing './compile'
configure.ac:16: installing './config.guess'
configure.ac:16: installing './config.sub'
configure.ac:5: installing './install-sh'
configure.ac:5: installing './missing'
src/Makefile.am: installing './depcomp'
src/gsm/Makefile.am:15: warning: source file 'milenage/aes-encblock.c'
is in a subdirectory,
src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the
'subdir-objects'
automake: automake option hasn't been enabled. For now, the
corresponding output
automake: object file(s) will be placed in the top-level directory.
However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option
throughout your
automake: project, to avoid future incompatibilities.
src/gsm/Makefile.am:15: warning: source file 'milenage/aes-internal.c'
is in a subdirectory,
src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled
src/gsm/Makefile.am:15: warning: source file
'milenage/aes-internal-enc.c' is in a subdirectory,
src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled
src/gsm/Makefile.am:15: warning: source file 'milenage/milenage.c' is in
a subdirectory,
src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled
src/sim/Makefile.am:5: warning: 'INCLUDES' is the old name for
'AM_CPPFLAGS' (or '*_CPPFLAGS')
tests/Makefile.am:21: warning: source file 'a5/a5_test.c' is in a
subdirectory,
tests/Makefile.am:21: but option 'subdir-objects' is disabled
tests/Makefile.am:30: warning: source file 'auth/milenage_test.c' is in
a subdirectory,
tests/Makefile.am:30: but option 'subdir-objects' is disabled
tests/Makefile.am:33: warning: source file 'bits/bitrev_test.c' is in a
subdirectory,
tests/Makefile.am:33: but option 'subdir-objects' is disabled
tests/Makefile.am:27: warning: source file 'comp128/comp128_test.c' is
in a subdirectory,
tests/Makefile.am:27: but option 'subdir-objects' is disabled
tests/Makefile.am:36: warning: source file 'conv/conv_test.c' is in a
subdirectory,
tests/Makefile.am:36: but option 'subdir-objects' is disabled
tests/Makefile.am:78: warning: source file 'fr/fr_test.c' is in a
subdirectory,
tests/Makefile.am:78: but option 'subdir-objects' is disabled
tests/Makefile.am:66: warning: source file 'gb/bssgp_fc_test.c' is in a
subdirectory,
tests/Makefile.am:66: but option 'subdir-objects' is disabled
tests/Makefile.am:69: warning: source file 'gb/gprs_bssgp_test.c' is in
a subdirectory,
tests/Makefile.am:69: but option 'subdir-objects' is disabled
tests/Makefile.am:72: warning: source file 'gb/gprs_ns_test.c' is in a
subdirectory,
tests/Makefile.am:72: but option 'subdir-objects' is disabled
tests/Makefile.am:42: warning: source file 'gsm0408/gsm0408_test.c' is
in a subdirectory,
tests/Makefile.am:42: but option 'subdir-objects' is disabled
tests/Makefile.am:39: warning: source file 'gsm0808/gsm0808_test.c' is
in a subdirectory,
tests/Makefile.am:39: but option 'subdir-objects' is disabled
tests/Makefile.am:24: warning: source file 'kasumi/kasumi_test.c' is in
a subdirectory,
tests/Makefile.am:24: but option 'subdir-objects' is disabled
tests/Makefile.am:24: warning: source file '../src/gsm/kasumi.c' is in a
subdirectory,
tests/Makefile.am:24: but option 'subdir-objects' is disabled
tests/Makefile.am:45: warning: source file 'lapd/lapd_test.c' is in a
subdirectory,
tests/Makefile.am:45: but option 'subdir-objects' is disabled
tests/Makefile.am:75: warning: source file 'logging/logging_test.c' is
in a subdirectory,
tests/Makefile.am:75: but option 'subdir-objects' is disabled
tests/Makefile.am:81: warning: source file 'logging/logging_test.c' is
in a subdirectory,
tests/Makefile.am:81: but option 'subdir-objects' is disabled
tests/Makefile.am:48: warning: source file 'msgfile/msgfile_test.c' is
in a subdirectory,
tests/Makefile.am:48: but option 'subdir-objects' is disabled
tests/Makefile.am:57: warning: source file 'sms/sms_test.c' is in a
subdirectory,
tests/Makefile.am:57: but option 'subdir-objects' is disabled
tests/Makefile.am:54: warning: source file 'smscb/gsm0341_test.c' is in
a subdirectory,
tests/Makefile.am:54: but option 'subdir-objects' is disabled
tests/Makefile.am:51: warning: source file 'smscb/smscb_test.c' is in a
subdirectory,
tests/Makefile.am:51: but option 'subdir-objects' is disabled
tests/Makefile.am:84: warning: source file 'strrb/strrb_test.c' is in a
subdirectory,
tests/Makefile.am:84: but option 'subdir-objects' is disabled
tests/Makefile.am:60: warning: source file 'timer/timer_test.c' is in a
subdirectory,
tests/Makefile.am:60: but option 'subdir-objects' is disabled
tests/Makefile.am:63: warning: source file 'ussd/ussd_test.c' is in a
subdirectory,
tests/Makefile.am:63: but option 'subdir-objects' is disabled
tests/Makefile.am:18: warning: source file 'utils/utils_test.c' is in a
subdirectory,
tests/Makefile.am:18: but option 'subdir-objects' is disabled
tests/Makefile.am:87: warning: source file 'vty/vty_test.c' is in a
subdirectory,
tests/Makefile.am:87: but option 'subdir-objects' is disabled
+ mkdir -p build-2G
+ cd build-2G
+ [ 1 = 1 ]
+ opt_enable=
+ [ libosmocore = openbsc/openbsc ]
+ ../configure --prefix=/home/openbsc/osmo
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... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make sets $(MAKE)... (cached) 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-pc-linux-gnu
checking host system type... x86_64-pc-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 how to convert x86_64-pc-linux-gnu file names to
x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-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 a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
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 ANSI C header files... (cached) yes
checking execinfo.h usability... yes
checking execinfo.h presence... yes
checking for execinfo.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking netinet/tcp.h usability... yes
checking netinet/tcp.h presence... yes
checking for netinet/tcp.h... yes
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for library containing dlopen... -ldl
checking for backtrace in -lexecinfo... no
checking for doxygen... false
checking if gcc supports -fvisibility=hidden... yes
checking whether struct tm has tm_gmtoff member... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for PCSC... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating libosmocore.pc
config.status: creating libosmocodec.pc
config.status: creating libosmovty.pc
config.status: creating libosmogsm.pc
config.status: creating libosmogb.pc
config.status: creating libosmoctrl.pc
config.status: creating libosmosim.pc
config.status: creating include/Makefile
config.status: creating src/Makefile
config.status: creating src/vty/Makefile
config.status: creating src/codec/Makefile
config.status: creating src/sim/Makefile
config.status: creating src/gsm/Makefile
config.status: creating src/gb/Makefile
config.status: creating src/ctrl/Makefile
config.status: creating tests/Makefile
config.status: creating utils/Makefile
config.status: creating Doxyfile.core
config.status: creating Doxyfile.gsm
config.status: creating Doxyfile.vty
config.status: creating Doxyfile.codec
config.status: creating Makefile
config.status: creating config.h
config.status: executing tests/atconfig commands
config.status: executing depfiles commands
config.status: executing libtool commands
+ set +e
+ make clean
Making clean in include
make[1]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/include'
rm -rf .libs _libs
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include'
Making clean in src
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src'
test -z "libosmocore.la" || rm -f libosmocore.la
rm -f ./so_locations
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src'
Making clean in src/vty
make[1]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/vty'
test -z "libosmovty.la" || rm -f libosmovty.la
rm -f ./so_locations
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty'
Making clean in src/codec
make[1]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
test -z "libosmocodec.la" || rm -f libosmocodec.la
rm -f ./so_locations
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make[1]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
Making clean in src/gsm
make[1]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
test -z "libosmogsm.la" || rm -f libosmogsm.la
rm -f ./so_locations
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
Making clean in src/gb
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
test -z "libosmogb.la" || rm -f libosmogb.la
rm -f ./so_locations
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
Making clean in src/ctrl
make[1]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
test -z "libosmoctrl.la" || rm -f libosmoctrl.la
rm -f ./so_locations
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make[1]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
Making clean in src/sim
make[1]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/sim'
test -z "libosmosim.la" || rm -f libosmosim.la
rm -f ./so_locations
rm -rf .libs _libs
rm -f *.o
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim'
Making clean in tests
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/tests'
rm -f timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test
bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test
lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test
gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test kasumi/kasumi_test
logging/logging_test fr/fr_test loggingrb/loggingrb_test
strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test
smscb/gsm0341_test msgfile/msgfile_test
rm -rf .libs _libs
rm -rf a5/.libs a5/_libs
rm -rf auth/.libs auth/_libs
rm -rf bits/.libs bits/_libs
rm -rf comp128/.libs comp128/_libs
rm -rf conv/.libs conv/_libs
rm -rf fr/.libs fr/_libs
rm -rf gb/.libs gb/_libs
rm -rf gsm0408/.libs gsm0408/_libs
rm -rf gsm0808/.libs gsm0808/_libs
rm -rf kasumi/.libs kasumi/_libs
rm -rf lapd/.libs lapd/_libs
rm -rf logging/.libs logging/_libs
rm -rf loggingrb/.libs loggingrb/_libs
rm -rf msgfile/.libs msgfile/_libs
rm -rf sms/.libs sms/_libs
rm -rf smscb/.libs smscb/_libs
rm -rf strrb/.libs strrb/_libs
rm -rf timer/.libs timer/_libs
rm -rf ussd/.libs ussd/_libs
rm -rf utils/.libs utils/_libs
rm -rf vty/.libs vty/_libs
test ! -f '../../tests/testsuite' || \
/bin/bash '../../tests/testsuite' --clean
rm -f *.o
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/tests'
Making clean in utils
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/utils'
rm -f osmo-arfcn osmo-auc-gen
rm -rf .libs _libs
rm -f osmo-sim-test
rm -f *.o
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/utils'
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G'
rm -rf .libs _libs
test -z "" || rm -f
rm -f *.lo
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G'
+ set -e
+ make -j
echo UNKNOWN > ../.version-t && mv ../.version-t ../.version
make all-recursive
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G'
Making all in include
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/include'
GEN osmocom/core/bit32gen.h
GEN osmocom/core/crc8gen.h
GEN osmocom/core/crc16gen.h
GEN osmocom/core/crc32gen.h
GEN osmocom/core/crc64gen.h
GEN osmocom/core/bit16gen.h
GEN osmocom/core/bit64gen.h
GEN osmocom/core/crc64gen.h
GEN osmocom/core/crc32gen.h
GEN osmocom/core/crc8gen.h
GEN osmocom/core/bit16gen.h
GEN osmocom/core/bit64gen.h
GEN osmocom/core/bit32gen.h
GEN osmocom/core/crc16gen.h
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include'
Making all in src
make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src'
GEN crc64gen.c
GEN crc32gen.c
GEN crc8gen.c
GEN crc16gen.c
make all-am
make[3]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src'
CC select.lo
CC bits.lo
CC signal.lo
CC timer.lo
CC write_queue.lo
CC socket.lo
CC statistics.lo
CC bitvec.lo
CC msgb.lo
CC utils.lo
CC logging.lo
CC gsmtap_util.lo
CC logging_syslog.lo
CC rate_ctr.lo
CC panic.lo
CC crc16.lo
CC application.lo
CC backtrace.lo
CC conv.lo
CC strrb.lo
CC rbtree.lo
CC crc16gen.lo
CC loggingrb.lo
CC crc8gen.lo
CC crc32gen.lo
CC crc64gen.lo
CC macaddr.lo
CC plugin.lo
CC msgfile.lo
CC talloc.lo
CC serial.lo
CCLD libosmocore.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[3]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src'
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src'
Making all in src/vty
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/vty'
CC command.lo
CC utils.lo
CC vector.lo
CC buffer.lo
CC telnet_interface.lo
CC vty.lo
CC logging_vty.lo
CCLD libosmovty.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty'
Making all in src/codec
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
CC gsm620.lo
CC gsm660.lo
CC gsm610.lo
CC gsm690.lo
CCLD libosmocodec.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
Making all in src/gsm
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
CC tlv_parser.lo
CC rxlev_stat.lo
CC comp128v23.lo
CC a5.lo
CC gsm48.lo
CC rsl.lo
CC gsm_utils.lo
CC comp128.lo
CC gsm48_ie.lo
CC gprs_cipher_core.lo
CC gsm0808.lo
CC sysinfo.lo
CC gsm0502.lo
CC abis_nm.lo
CC gsm0480.lo
CC gsm0411_smr.lo
CC gsm0411_utils.lo
CC gsm0411_smc.lo
CC lapd_core.lo
CC lapdm.lo
CC auth_comp128v1.lo
CC kasumi.lo
CC auth_milenage.lo
CC auth_comp128v23.lo
CC auth_core.lo
CC aes-encblock.lo
CC milenage.lo
CC aes-internal.lo
CC aes-internal-enc.lo
CC gsm0341.lo
CC gan.lo
CC ipa.lo
../../../src/gsm/gan.c:71:34: warning: ‘gan_pdisc_vals’ defined but not
used [-Wunused-const-variable=]
static const struct value_string gan_pdisc_vals[] = {
^~~~~~~~~~~~~~
CCLD libosmogsm.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
Making all in src/gb
make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
CC gprs_ns_vty.lo
CC gprs_ns_frgre.lo
CC gprs_bssgp.lo
CC gprs_bssgp_util.lo
CC gprs_bssgp_bss.lo
CC gprs_bssgp_vty.lo
CC gprs_ns.lo
CC common_vty.lo
../../../src/gb/gprs_bssgp_bss.c: In function ‘bssgp_rx_paging’:
../../../src/gb/gprs_bssgp_bss.c:542:2: warning: this ‘if’ clause does
not guard... [-Wmisleading-indentation]
if (TLVP_PRESENT(&tp, BSSGP_IE_TMSI) &&
^~
../../../src/gb/gprs_bssgp_bss.c:546:3: note: ...this statement, but the
latter is misleadingly indented as if it is guarded by the ‘if’
*(pinfo->ptmsi) = ntohl(*(uint32_t *)
^
../../../src/gb/gprs_bssgp_vty.c:47:34: warning: ‘gprs_bssgp_timer_strs’
defined but not used [-Wunused-const-variable=]
static const struct value_string gprs_bssgp_timer_strs[] = {
^~~~~~~~~~~~~~~~~~~~~
CCLD libosmogb.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
Making all in src/ctrl
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
CC control_cmd.lo
CC control_if.lo
../../../src/ctrl/control_if.c: In function ‘listen_fd_cb’:
../../../src/ctrl/control_if.c:365:15: warning: unused variable ‘on’
[-Wunused-variable]
int ret, fd, on;
^~
CCLD libosmoctrl.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[2]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
Making all in src/sim
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/sim'
CC reader_pcsc.lo
CC card_fs_usim.lo
CC card_fs_uicc.lo
CC card_fs_sim.lo
CC reader.lo
CC card_fs_isim.lo
CC core.lo
CC card_fs_tetra.lo
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/card_fs_uicc.c:24:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
Makefile:470: recipe for target 'card_fs_uicc.lo' failed
make[2]: *** [card_fs_uicc.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/card_fs_isim.c:27:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/core.c:29:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/reader_pcsc.c:30:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/card_fs_usim.c:27:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
compilation terminated.
compilation terminated.
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/card_fs_sim.c:26:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
Makefile:470: recipe for target 'card_fs_usim.lo' failed
make[2]: *** [card_fs_usim.lo] Error 1
Makefile:470: recipe for target 'reader_pcsc.lo' failed
make[2]: *** [reader_pcsc.lo] Error 1
Makefile:470: recipe for target 'card_fs_isim.lo' failed
make[2]: *** [card_fs_isim.lo] Error 1
Makefile:470: recipe for target 'card_fs_sim.lo' failed
make[2]: *** [card_fs_sim.lo] Error 1
Makefile:470: recipe for target 'core.lo' failed
make[2]: *** [core.lo] Error 1
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/card_fs_tetra.c:26:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../src/sim/reader.c:32:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
Makefile:470: recipe for target 'card_fs_tetra.lo' failed
make[2]: *** [card_fs_tetra.lo] Error 1
Makefile:470: recipe for target 'reader.lo' failed
make[2]: *** [reader.lo] Error 1
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim'
Makefile:518: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G'
Makefile:386: recipe for target 'all' failed
make: *** [all] Error 2
+ make
make all-recursive
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G'
Making all in include
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/include'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include'
Making all in src
make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src'
make all-am
make[3]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src'
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src'
Making all in src/vty
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/vty'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty'
Making all in src/codec
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
Making all in src/gsm
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
Making all in src/gb
make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
Making all in src/ctrl
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
Making all in src/sim
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/sim'
CC core.lo
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/core.c:29:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
Makefile:470: recipe for target 'core.lo' failed
make[2]: *** [core.lo] Error 1
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim'
Makefile:518: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G'
Makefile:386: recipe for target 'all' failed
make: *** [all] Error 2
+ make
make all-recursive
make[1]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G'
Making all in include
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/include'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/include'
Making all in src
make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src'
make all-am
make[3]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src'
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src'
Making all in src/vty
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/vty'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/vty'
Making all in src/codec
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/codec'
Making all in src/gsm
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gsm'
Making all in src/gb
make[2]: Entering directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/gb'
Making all in src/ctrl
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory
'/home/openbsc/osmo/libosmocore/build-2G/src/ctrl'
Making all in src/sim
make[2]: Entering directory
'/home/openbsc/osmo/libosmocore/build-2G/src/sim'
CC core.lo
In file included from ../../../include/osmocom/core/msgb.h:25:0,
from ../../../include/osmocom/sim/sim.h:4,
from ../../../src/sim/core.c:29:
../../../include/osmocom/core/bits.h:6:35: fatal error:
osmocom/core/bit16gen.h: No such file or directory
#include <osmocom/core/bit16gen.h>
^
compilation terminated.
Makefile:470: recipe for target 'core.lo' failed
make[2]: *** [core.lo] Error 1
make[2]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G/src/sim'
Makefile:518: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/openbsc/osmo/libosmocore/build-2G'
Makefile:386: recipe for target 'all' failed
make: *** [all] Error 2
btw, I apologize for the noise around the osmo-msc patch review, it's a
challenge to keep all the eggs in the basket. For once I added python tests as
well as the various --enable- flags to 'make distcheck', then tried to get the
patches to pass the build check, and only now am really taking care of the all
the remaining code review. Every time I think it's settled, something else pops
up. Hope to be done with the current batch today.
~N
Review at https://gerrit.osmocom.org/3322
Rename osmo_pcap_{client_server} executables to osmo-pcap-{client,server}
This naming is more in line with what all the other osmocom programs are
doing (e.g. osmo-pcu, osmo-bts-sysmo, osmo-bsc, ...). We don't
generally use osmo_ anywhere else, so I suggest to change it for more
uniformity.
Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1
---
M src/Makefile.am
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-pcap refs/changes/22/3322/1
diff --git a/src/Makefile.am b/src/Makefile.am
index 0532acf..17ed4e3 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -1,7 +1,7 @@
AM_CPPFLAGS = $(all_includes) -I$(top_srcdir)/include -I$(top_builddir)/
AM_CFLAGS = -Wall $(LIBOSMOCORE_CFLAGS) $(LIBOSMOVTY_CFLAGS) $(PCAP_CFLAGS) $(LIBGNUTLS_CFLAGS)
-bin_PROGRAMS = osmo_pcap_client osmo_pcap_server
+bin_PROGRAMS = osmo-pcap-client osmo-pcap-server
osmo_pcap_client_SOURCES = osmo_client_main.c osmo_common.c \
osmo_client_core.c osmo_client_vty.c \
--
To view, visit https://gerrit.osmocom.org/3322
To unsubscribe, visit https://gerrit.osmocom.org/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: If1e3ce76f93266e0f01c801204769432b571fdb1
Gerrit-PatchSet: 1
Gerrit-Project: osmo-pcap
Gerrit-Branch: master
Gerrit-Owner: Harald Welte <laforge(a)gnumonks.org>
Hi there! LaF0rge made me some suggestions for a better troubleshooting,
so here are the logs in .log format, since the previous email wasn't
readable.
I'm attaching the RSL+OML pcap file.
Please let me know if someone knows how to connect this nanobts =)
Cheers!
Hi!
Next to the announcement (http://osmocom.org/news/75) I've put together
some guide in the wiki as to how the Virtual Um interface can be used
with the osmo-bts-virtual, virtphy and mobile programs running all on
your local PC:
https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um
Feel free to try it out and/or improve the wiki page and/or let me know
if something is not sufficintly clear. I intentionally don't want to
repeat general information about configuring OsmoNITB or using
OsmocomBB. The above-mentioned page should only document those aspects
that are different from the classic setup with real hardware.
I'm now investigating some more of the bugs I'm starting to find with
using the VirtualUm interface from my related TTCN-3 testsuite, at this
time particularly https://osmocom.org/issues/2380
Will document that testsuite once it can actually run as expected.
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!
Some of you will have alrady noticed, over the last few days I reviewed,
cleaned up, submitted and merged the virtual Um interface support on
both the phone side (OsmocomBB) as well as on the BTS side (OsmoBTS).
Thanks to Sebastian Stumpf for working out most of the related code,
after my initial attempt on this got stalled more than 1.5 years ago.
This means that you can now run a complete circuit-switched GSM network
without posession of any real hardware or use of any radio waves. While
that takes away almost all the fun for some of us (I would typically
agree), it opens up possibilities, particularly in terms of testing.
If anyone wants to play with it, it's actually very easy:
* build osmo-bts and the rest of the network-side code (I don't think
osmo-bts-virtual is part of the nightly Osmocom packages yet, sorry)
* run osmo-bts-virtual with a config file (example included in osmo-bts.git)
* make sure you have matching unit_id, band, ... between BTS and
BSC/NITB, just like with real hardware
OsmoBTS will start to send downlink BCCH / CCCH frames to a multicast
IPv4 address (default: 239.193.23.1) to the usual GSMTAP port 4729. If
you don't have any specific multicast routing set up, this will be
visible with TTL=1 on the network device of your default route. You
should see the GSMTAP frames in wireshark.
On the OsmocomBB side, simply start the virt_phy binary. It replaces
your calypso based phoen and its firmware and offers the L1CTL socket to
the "layer23" programs like "mobile". Once virt_phy is running, you can
start "mobile" just like with real hardware. The phone will scan the
multicast frames for BCCH messages, build up a list of currently
received BTSs and then perform normal cell selection followed by
location update.
Everything from this point on is just normal. You cannot make voice
calls, but any signaling related transactions (LU, SMS, USSD, even call
signalling) should work. Voice is missing as there is no format
specified on how to transmit FR/EFR/HR/AMR frames over GSMTAP yet.
If somebody plays with this, I would really appreciate if they could
update the Osmocom wiki with a guide/howto on how to use such a setup.
My personal plans are to use this for verification/testing of those bits
that are difficult in a true end-to-end setup like osmo-gsm-tester.
That includes:
* simulation of massive amount of phones, more than one can easily set
up in a lab and connect to USB + RF cabling.
* verification of SYSTEM INFORMATION messages, particularly in response
to different config files, ensuring that all related bits are set
correctly at all times, even after making dynamic updates
* verification of the PAGING code, i.e. that paging load is correctly
reported, paging messages are structured correctly, ...
* exhausting all channels using simulated phones, verification of
IMM.ASS.REJECT being sent ins such cases
* verification of TA loop
* verification of uplink power control loop
* verification of radio link timeout
* testing of emergency calls, which is very critical with real phones as
there's always some possible leakage into real networks
* verification of correct CBCH messages
* verification of LAPDm contention resolution (two phones selecting same
RACH value and going both on same dedicated channel)
* verification of measurement reporting (Um vs. RSL)
* verification of downlink RF power ramping
This will of course take some time, but I'm already making good progress
implementing some SYSTEM INFORMATION test code.
In case somebody wants to join in on any of the above topics (or has
even more ideas on what kind of tests he would want to implement), feel
free to follow up so we can coordinate.
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'm using osmo-nitb in a testing environment and I've soon received a
request to enable SMS delivery reports.
After looking on the user manual, I couldn't find anything related to this.
I've also enabled debug logging and tried to grep for something like that
when sending a SMS between two handsets that have SMS delivery reports
enabled, without finding out anything. (SMS delivery reports tested and
worked on a public telephony system, for those two handsets)
Is there such an option available in osmo-nitb to enable delivery reports?
---
Thank you,
Stefan
Today I checked the new AoIP core network using an old Nokia 1100 handset,
which confronted me with codecs.
The Nokia 1100 says it is capable of FR2, FR1, HR1:
Channel Type - (Speech)
Element ID: 0x0b
Length: 5
0000 .... = Spare bit(s): 0x00
.... 0001 = Speech/Data Indicator: Speech (1)
Channel Rate and Type: Full rate TCH channel Bm. Prefer full rate TCH (8)
1... .... = Extension: Additional Octet
.001 0001 = Permitted speech version indication: GSM speech full rate version 2 (GSM EFR) (0x11)
1... .... = Extension: Additional Octet
.000 0001 = Permitted speech version indication: GSM speech full rate version 1 (GSM FR) (0x01)
0... .... = Extension: Last Octet
.000 0101 = Permitted speech version indication: GSM speech half rate version 1 (GSM HR) (0x05)
The "stock" osmo-bsc.cfg I was using so far had only HR3 configured. So I
naively thought, let's do:
codec-list hr3 fr2 hr1
But OsmoBSC says: "Can not have full-rate and half-rate codec." Curious, is
that a hard limitation? I'm not at all familiar with the reasons. Will we never
be able to mix FR and HR? Why then does TCH/F_TCH/H_PDCH exist?
Then I picked:
codec-list hr3 hr1
That worked, but no audio: the Samsung Galaxy got HR3 and the Nokia HR1 (the
BTS was configured for only TCH/F channels, so instead the Nokia actually got
assigned an FR1 channel). The call was established but no audio worked. I
believe in the OsmoNITB we used to complain in the log that we don't transcode
in such a situation, and the call was aborted...
When I pick
codec-list hr1
then the call works between the handsets. Again both get assigned FR1 on TCH/F;
if I configure the BTS to use TCH/H instead, both indeed get assigned HR1 as
expected.
All in all an interesting situation, which appears to mean that we practically
can't allow the newer codecs alone because older handsets would not work, and
we can't allow both because each side may pick a different one.
Should we wait until we know both sides' codecs and consolidate with each other
to pick matching ones before assigning? Is that a "late assignment" as in
issue "avoid mismatching TCH/F vs TCH/H pchan types"?
https://osmocom.org/issues/1778
But what if no match can be found? only MGW transcoding will solve all
situations I guess. Are we planning to do that, also with IuUP in mind?
https://osmocom.org/issues/1936https://osmocom.org/issues/1937
~N
I have created a fresh osmo-msc repository as a copy of openbsc.git, and pushed
the first few patches for gerrit review to move to our "new" Osmocom CN:
https://gerrit.osmocom.org/#/q/topic:vlr
As suggested before, osmo-msc will see code review and patches merged for VLR,
3G and AoIP, and so will form the basis for creating osmo-bsc, osmo-mgw and
osmo-sgsn, as distinct repositories replacing the current openbsc.git.
All further development happening in openbsc.git from now on will have to be
applied to the new repositories later. Keep that in mind, and maybe postpone
larger conflict prone efforts for later.
The review process could take some effort. Some of the commits are one
collapsed commit of fairly large development efforts. Normally, commits should
be small, but in the case of completely refactoring an entire section of the
code (VLR) or adding a completely new feature (IuCS, AoIP), it doesn't really
help to see incremental back-and-forth changes with intermediate errors and
fixes. I decided to collapse the errors with their fixes, and to save the
effort of logically plucking apart the large commits, since they anyway only
make sense as a whole. If necessary for review, we can still do so.
Despite the mass of changes, please do look closely. Parts of the new code have
possibly been hacked up in a preliminary fashion and were forgotten to
implement properly later -- this will become our new Osmocom master branches,
the stable releases and our main development arena, so do apply your scrutiny
and let's fix early what we can fix now.
The other repositories (osmo-{bsc,mgw,sgsn}) also exist already, and I am
preparing to make them work as separate entities after the code review, on
respective neels/split branches.
Each fresh repository contains the *full* openbsc.git history.
The option of relying on grafts to include the old openbsc.git history when
needed has been mentioned, but so far was more or less turned down. It is still
possible to change that. The openbsc.git history is about 9 Mb -- not too
large, so IMHO best to keep it with each separate repos to ease log browsing,
git blame and so forth. OTOH, we have it four times, which makes 36 Mb of
duplicated history. If anyone still prefers a flat snapshot migration with a
wiki page describing how to graft in the old history, we may discuss and change
that.
No branches have been migrated except the current aoip development branch that
is going to become the new master.
All tags are included, except: the signed '0.1.2' openbsc version tags are
replaced by 'openbsc/0.1.2' tags pointing at the same revisions, so that we
don't confuse them with the new version tags in each new project.
Preliminarily, the last openbsc.git master has been tagged as version 0.0.1 in
order to get *something* out from git-version-gen, useful for referencing a
version of the new libosmo-mgcp library in osmo-{msc,bsc} configure.ac.
We still need to decide whether to start versioning afresh or continue from the
openbsc.git version scheme. openbsc.git ended with 0.15.0. My personal choice
would be to bump the major and start from 1.0.0 in each new repository.
~N
Dear all,
I have one sysmo2050, with the GSM running fine. However, i would like to
test GPRS data transmission, I was following this setup page (
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS#Open…),
but i couldnt make it work. Anyone has done it before / can help me?
Thanks beforehand,
Marcus Dias
UFPA - Lasse - LaPS
Hi,
recently my modem with an already known SIM got a location update
reject, because the procedure timed out. So I looked more
into the location updates.
How openbsc location update works:
MS Network
LOC REQ ->
<- Identity Req IMSI
Identity Resp IMSI ->
<- Identity Req IMEI
Identity Resp IMEI ->
<- LOC ACCEPT
OpenBSC is using a Timeout (5 sec) for the completion of location
update.
So let's say we trigger for unknown reason the timeout (e.g. RF
problem).
MS Network
LOC REQ ->
<- Identity Req IMSI
(No response)
<- LOC Reject! cause 13 / No roaming allowed.
If the MS receive it, it will put our network on it's blacklist and
won't try it again until power cycled.
We could change reject cause to something different [1], but
we might want to reject foreign SIMs not to try our network again.
The problem here is that openBSC use the same configuration to reject
unknown SIMs as well for timeouts.
But I think this timeout should be removed. 04.08 doesn't
describe a timeout on location update request on network side. But it
describes other timeouts:
04.08 describes:
- T3260 auth req. sent, wait until response (12 sec)
- T3270 identity req. sent, wait until response (12 sec)
I think we should implement both timers and drop the RR connection if
it fires.
I'm unsure if it's needed: But OpenBSC could count un-successful
location update req. Reset counter if it's succeeded. After a certain
amount of failures we send a location update reject. (unsure which
cause)
best,
lynxis
Related Specs:
GSM 04.08 [1] Chapter 4.4 describing location update
GSM 04.08 [1] Chapter 11.2 Timers
GSM 04.08 [1] Chapter Annex G Reject Causes
[0] nitb.cfg: network: location updating reject cause
[1] ETSI TS 100 940
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
Hi.
So far releases of Osmocom project were rather rare and without any schedule. It
would be nice to change that but to do that we've got to make the process of making a
release as smooth as possible.
The ticket which tracks this activity: https://projects.osmocom.org/issues/1861
What we have right now:
https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
What I've implemented: https://gerrit.osmocom.org/#/c/3130/
The TLDR:
we type "make REL=minor release" and get:
* signed and tagged commit
* automated version bump
* updated debian/changelog
Longer explanation:
That's implemented as separate makefile which is installed as part of libosmocore-dev
and can be re-used by other projects in few lines (see
https://gerrit.osmocom.org/#/c/3131/ for example).
It treats libraries separately from non-library projects (we don't have to clean up
TODO-RELEASE in the latter case). Also, it does not update LIBVERSION automatically
(see
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info…"
for details) - I'm not quite sure how this can be automated.
Caveats:
- it does not push the committed result automatically - so far it's left as an
additional chance to inspect the changes before pushing them. Also I'm not sure if we
have to tweak our gerrit setup to allow for signed tags to go through and how will it
interact with auto-rebase.
- it does not replace human decision, it's still your job to adjust version
requirements for the libraries you use and properly bump LIBVERSION
- it enforces use of semantic versioning (see my previous email about semver and
http://semver.org/ for details)
Questions:
- does it make sense?
- what and, more importantly, how can we automate in addition to that?
The intention is to make release process easy enough so we could make releases more
frequently (maybe even have some schedule for it in a long run).
--
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
Hi.
I've noticed that we do not use check_PROGRAMS in any of our Makefile.am (happy to be
corrected :) so all the tests/ binaries are built during "make" step instead of "make
check".
Is this intentional? If so - why? Is this smth we'd rather fix?
--
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 am currently setting up separate repositories to replace openbsc.git.
Aspects:
- choice how to separate
- apply 3G and AoIP changes to do code review
My plan is to separate openbsc.git into these parts:
osmo-msc.git = OsmoMSC
osmo-bsc.git = OsmoBSC, OsmoBSCNAT
osmo-sgsn.git = OsmoSGSN, OsmoGTPHUB
osmo-mgw.git = new OsmoMGW, at first plain renamed from osmo-bsc_mgcp
+ libosmo-mgcp
Each of these will contain the full openbsc.git history to be able to follow
changes back in the log easily.
The libmgcp has so far been internal to openbsc.git. I intend to make it an
installed library from osmo-mgw.git (similar to libosmo-ranap from
osmo-iuh.git), as libosmo-mgcp. libmgcp is used by MSC and BSC to communicate
with osmo-mgw (osmo-bsc_mgcp). Also by osmo-bsc_nat, which I had actually not
been aware of until now.
libiu, shared between MSC and SGSN, has already moved to osmo-iuh.
The other thing the MSC and SGSN still share is the GSUP client. The GSUP
protocol code has already moved to libosmocore, but the gsup_client is still in
openbsc. I believe it is appropriate to move the gsup_client along to
libosmocore, even though the notion so far has been to keep it out of there.
Otherwise we either duplicate the gsup_client or need another separate
libosmo-gsupclient.
Possibly other code needs to be moved around similarly, but AFAICT "decreasing
in importance".
Code review:
We can review in various ways. I believe the least troublesome would be this:
- create osmo-msc git from the current openbsc.
- remove the top level 'openbsc' dir.
- go through all of the patches in gerrit to apply to 'master', which will
apply the VLR+HLR, then 3G and then AoIP, across all of MSC, BSC, SGSN and MGW,
all of these in osmo-msc.git.
- the state thus reached is the basis for the split. Copy this to osmo-*.git
- in each separate git, remove the files not needed for that particular project.
Remove possible remaining code duplication as we go.
openbsc.git
|
| copy
v
osmo-msc.git
|
| - `mv openbsc/* .`
v
| gerrit code review:
| +VLR
| +3G
| +AoIP
|
+-------------------------------
| |
v |
----------copy-------- |
| | | |
v v v |
osmo-bsc osmo-sgsn osmo-mgw osmo-msc
| | | |
| | | | clean unrelated files
v v v v
continue ongoing development from these new master HEADs
I'm currently playing through the separation, osmo-msc with top-level openbsc
removed is done, osmo-mgw and osmo-bsc pending. This means that I will need to
apply commits merged to openbsc from now on to the new separate gits until we
move over for good. That's fairly similar to keeping the 3G,AoIP branch rebased
onto openbsc master as we did previously. It may make sense to focus AoIP
development onto the new repositories soon.
So far I'm keeping the gits privately on a sysmocom office machine. We could
also open up new osmo-* repositories on gerrit and git.osmocom.org now.
~N
Hi all,
During experimenting with RACH requests in my virtual Um-interface
environment, I found an interesting issue in OpenBSC. According to
the specifications, every RACH request should contain BSIC value of
target base station, and if I understand correctly BSC (or BTS?)
should ignore such requests, where rach_bsic != bts_bsic (Ghost RACH).
Meanwhile, when I send all-zero sequence (just for testing) on RACH
lchan, BSC allocates me a channel despite bts_bsic != 0x00. It probably
also explains the reason, why sometimes in a real OpenBSC + OsmoBTS
setup I see channel requests, followed by channel allocation without
any further response from MS side.
So, do we have any BSIC matching functionality implemented somewhere?
If not, I could try to open an issue and implement it.
With best regards,
Vadim Yanitskiy.
Hey Osmocom,
I am trying to understand how to interact with the SGSN via the control
interface and do a few things that I can't find documentation for.
Hoping you can help explain how to:
1) Query(or push) CDRs for active data sessions
2) Terminate active PDP context (network initiated detach)
3) Manage the ACL for the PS domain (assuming via HLR?)
Thanks,
Omar
Hello Neels,
> (any reason to not discuss this on openbsc@?)
I put it on CC.
> Still missing in this proposal: how do you tell e.g. the MSC's A and
IuCS code
> to use a given SCCP instance, local SSN and remote SCCP address?
I would add a VTY command where the user has to tell on which ss7 instance
the A or IuCS interface should bind. When the IDs for both match up, we know
that we use the same SCCP instance, but I think we do not even have to check
that. Its implicit by the pointers. If the numbers are the same we will end
up with the same sccp instance pointer for both.
The SCCP-Addresses are defined by the addressbook. Which one is used will be
configured via a VTY command seperately. The SSNs are hardcoded, so this is
not a problem currently. If someone wants configurable SSNs and wants two
users with different SSNs but same local point codes (which is mandatory in
this case), then the user would have to define two addressbook entries where
only the SSN is different. Logically this is then a different address
and look
at postal addresses, there its the same. Two different houses next to each
other will have different addresses. The only difference is the number
(SSN).
At some point we have to make the cut.
We could think about unifying the osmo_sccp_user_bind() function as
well, so we
would get pointers for ready-to-go sccp-users as well, but I think this
is out
of scope right now. The solution would be similar to the addressbook. We
would
just define nodes which hold the parameters. The results end up in a
list and
after parsing is done. The user can call a function that only gets the
ID that
references the parameter set, the pointer to the sscp instance and the
function pointer for the SAP. e.g.:
osmo_sccp_user_bind_id(sscp,2,sccp_sap_up)
> A much simpler soultion to the problem would be to pack the configuration
> options into struct osmo_ss7_instance. Then when the config file parsing
> is done, the user must call a function e.g. "osmo_sscp_init()" or so to
> trigger the call to osmo_sccp_simple_client().
In struct osmo_ss7_instance we already have the .cfg sub struct. I think we
should add the items there instead of introducing something new. Also if
we do
so we would have to change it for the existing code too to have it
consistent.
Lets do some practical examples:
1) A and IuCS use the same sscp/ss7 instance
cs7 instance 1
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs_and_a
pc msc_local
prot M3UA
local-port 1234
remote-port 5678
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
cs7-inst-a 1
cs7-inst-iucs 1
local-addr msc_local
1) A and IuCS use separate sscp/ss7 instances
cs7 instance 1
sccp-address msc_local
point-code 0.0.1
routing-indicator PC
sccp
name a
pc msc_local
prot M3UA
local-port 1230
remote-port 5670
local-ip 1.1.1.4
remote-ip 2.2.2.4
cs7 instance 2
sccp-address msc_local
point-code 0.0.2
routing-indicator PC
sccp
name iucs
pc msc_local
prot M3UA
local-port 1234
remote-port 5678
local-ip 1.1.1.1
remote-ip 2.2.2.2
msc
cs7-inst-a 1
cs7-inst-iucs 2
local-addr msc_local
regards.
Philipp
--
Philipp Maier <pmaier(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 have a problem with VTY validation. When there is wrong command formatting,
we exit VTY parsing in error, which leads to a program exit in error.
However, if the format matches but the value is wrong in a way that the VTY
format description is unable to detect, the way to escalate an error up
the VTY call chain is a bit weird.
The concrete item in question is the SCCP address point code. The format is
like A.B.C, while ranges are variable depending on configuration.
point-code 0.0.1
If I write 'point-code 0.0.99', it exceeds the range and I want to immediately
abort the program, indicating the VTY config error.
If I return CMD_WARNING, it is merely ignored.
There are various CMD_ERR_* values to return, but there is no plain error like
CMD_ERR_INVALID_VALUE.
I can for example return CMD_ERR_AMBIGUOUS; then the code will try to parse the
same line a second time, to see whether the command succeeds on a child of the
parent node (we had this before, about implicit node 'exit').
DLSS7 <002d> ../../src/osmo_ss7.c:244 1: Error parsing Pointcode '0.42.99'
DLSS7 <002d> ../../src/osmo_ss7.c:244 1: Error parsing Pointcode '0.42.99'
There is no such command.
Error occurred during reading below line:
point-code 0.42.99
% Power 21 dB is not an even value
Invalid point code (0.42.99)
Invalid point code (0.42.99)
This result is rather curious.
I would like to have a CMD_ERROR return value that immediately exits VTY
parsing with a clear error return code.
(We can't abort with an assertion, because that would cause the program to exit
in case someone enters a wrong value on the telnet VTY.)
This is the function in question:
int config_from_file(struct vty *vty, FILE * fp)
{
int ret;
vector vline;
while (fgets(vty->buf, VTY_BUFSIZ, fp)) {
vline = cmd_make_strvec(vty->buf);
/* In case of comment line */
if (vline == NULL)
continue;
/* Execute configuration command : this is strict match */
ret = cmd_execute_command_strict(vline, vty, NULL);
// I would insert something like this:
// if (ret == CMD_ERROR)
// return ret;
/* Try again with setting node to CONFIG_NODE */
while (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO
&& is_config_child(vty)) {
vty_go_parent(vty);
ret = cmd_execute_command_strict(vline, vty, NULL);
// same here
}
cmd_free_strvec(vline);
if (ret != CMD_SUCCESS && ret != CMD_WARNING
&& ret != CMD_ERR_NOTHING_TODO)
return ret;
}
return CMD_SUCCESS;
}
Am I on the right track here, have I missed something?
~N
HI.
While working on smoothing out our release process (see
https://projects.osmocom.org/issues/1861 and gerrit 3130, 3131, 3143) I've noticed
that some of Osmocom projects follow semver [1] spec (OsmoBTS) while others don't
(Osmo-PCU).
Is this just "it happened this way" or there're other reasons for that? Shall we
enforce semver for all projects?
[1] http://semver.org/
--
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
Hello FreeCalypso and Osmocom communities,
I am in the process of creating an informal organisation representing
the interests of those members of the GSM universe whose interests are
not represented by GSMA etc, and I am inviting you to join me in this
venture. I propose that we name our informal organisation GSMUA,
standing for GSM Users Association, and my vision for this GSMUA is to
be a counter-body (antibody?) to the official GSMA. I just registered
the gsmua.org domain name, but there is no website or mailing list set
up yet. If someone from the Osmocom camp would like to host the
server infrastructure for gsmua.org, I will happily point the DNS to
you, otherwise the FreeCalypso family can host it on our server.
My vision for GSMUA is to represent the interests of GSM end users
(empowered end users who wish to fully own and control all aspects of
their user equipment while operating on public mobile networks in a
fully spec-compliant manner), small boutique manufacturers of GSM
devices (both MS/user equipment and network infrastructure), small
community network operators and others whose interests are not
represented by GSMA etc, especially in cases where our interests are
in direct conflict with the interests of big players such as giant
device manufacturers, giant commercial network operators and
governments.
A key goal of GSMUA is to be project-neutral, that is, every person
and every small company belonging to any of the categories listed
above (empowered end user, small boutique device manufacturer, small
community network operator etc) should be fully welcome regardless of
which specific project they are associated with. As of today there
are at least two different projects offering GSM MS implementations
(OsmocomBB and FreeCalypso) and at least two different projects
offering network-side GSM implementations (Osmocom and OpenBTS), and I
hope that this number of available alternatives will continue to grow:
freedom of choice is always a good thing. But at the present time
there exists no neutral soil on which members of different projects
with a common interest (GSM networks and devices serving the interests
of end users rather than big corporations and governments) and a
common enemy (just named) can meet, and this lack of neutral meeting
ground is the problem which GSMUA is meant to solve.
I also have one practical application for GSMUA in mind already: to
manage and legitimize recycling of wasted IMEI number ranges. By the
official rules of GSMA etc each different *type* of GSM mobile
equipment requires a different TAC, i.e., a range of at least 1 million
IMEI numbers. So if a small boutique GSM device manufacturer makes a
boutique MS device of which no more than 100 units will ever be made,
999900 IMEI numbers have to be wasted by the official rules. While I
don't know of any manufacturer who got a range of 1 million IMEIs and
only made 100 devices, we do have examples like Openmoko GTA01/02 and
Pirelli DP-L10. In the case of Openmoko GTA02 I've been told that
about 15 thousand units were made in total; in the case of Pirelli
DP-L10 it appears that the total number produced was somewhere under
100 thousand. In each case a full range of 1 million IMEIs was
allocated, and at least 900 thousand numbers out of each range are
currently unused and wasted.
If a small boutique manufacturer wishes to offer a boutique GSM MS
product to the general public and wishes to ship each unit with a
world-unique IMEI that stands a good chance of being accepted as valid
by common GSM networks, and the product in question does not qualify
for IMEI allocation by the official rules (e.g., the product is a
development board specifically intended for users to run their own
firmware and connect to live public networks with it, taking full
personal responsibility for their actions) - the situation I found
myself in with my GSM MS development board - I feel that the small
boutique manuf in question should be empowered to squat on a small
subrange of someone else's IMEI range if it is known beyond reasonable
doubt to be wasted and unused.
However, this recycling of wasted IMEI number ranges could be better
organized and given at least some aura of semi-legitimacy if there
were a community body set up to manage it, and this is where my
proposed GSMUA can come in. Once we get our GSMUA up and running and
assign a group of volunteers to be IMEI recycling managers, any small
GSM or 3G+ device manufacturer who needs a small range of IMEI numbers
will be able to request one from GSMUA, and we will allocate and
assign these small subranges out of whatever wasted range we decide to
squat on, ensuring that each requestor gets a different subrange.
So these are my ideas, and I would like to see them turn into reality.
We are going to need a simple website and a community mailing list at
gsmua.org, and for the IMEI recycling service we will need a small
group of volunteers to serve as its managers - I and Das Signal from
FreeCalypso will be happy to serve on that panel, but it would be nice
to also have someone from the Osmocom camp for better neutrality.
Bright Blessings,
Mychaela Falconia,
Mother of FreeCalypso