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 all,
I've created a prototyp'ish JJB YAML file [1] that holds all current
gerrit verification jobs on jenkins.osomocom.org. Holger and Lynxis
suggested to explore this way of managing Jenkins jobs in the "jenkins
build slaves: Rationale for some builds in docker vs. some not?"
thread.
Following differences occurred, while clicking through all gerrit jobs
configurations:
- some jobs using gcc c compiler warnings v3, some v4
- some jobs are verifying drafts, some not
- only two gerrit jobs are allowing concurrent builds
Are these differences wanted? All job differences are commented in the
YAML file. The jobs are deployed on jenkins.blobb.me [2].
What do you think about this approach [1] in general?
Regards,
André
[1] https://gerrit.osmocom.org/#/c/3911/1
[2] https://jenkins.blobb.me/view/gerrit-JJB/
Dear all,
Holger and I (plus later the sysmocom team) had a discussion about whether
we should continue to keep the FreeBSD build testing.
Right now, jenkins is set up in a way to test build of a patch on Linux
(currently Debian 8) and FreeBSD (currently 10.3). Only if it builds
and passes "make check", the patch gets the magical "+V" so it can be
merged.
While in general it's of course good practise to write portable code and
to test building on multiple operating systems, this adds quite a bit of
extra effort:
* patches every so often don't build on FreeBSD due to include header
differences or the like, requiring extra iterations of a patch
* the build takes longer time as the build matrix is multiplied by two
operating systems
* we cannot easily/safely migrate the way we buld to docker, as docker
on FreeBSD is experimental
Particularly during my recent OpenGGSN developments (IPv6) support, this
was a big PITA and I'm sure I spent more time in debugging FreeBSD build
issues than actually writing the code in the first place.
Given that we arr not aware of anyone using the Osmocom stack on
FreeBSD, the suggestion is thus to focus our available time on actual GSM
related features rather than fixing up portability issues.
So unless we receive significant complains as a response to this e-mail,
we will disable the automatic build testing for patches on FreeBSD.
This doesn't mean we will drop related code from our projects. We still
appreciate build and other fixes for other platforms, but those would
have to come as contributions from users on those platforms, rather than
something that's actively maintained and tested by Osmocom upstream.
If we want to extend build testing, I think it's more useful to have e.g.
ARM/Linux builds, or clang builds on Linux than the FreeBSD builds.
Let me know what you think.
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 Max!
Since https://gerrit.osmocom.org/#/c/3148/
I am no longer able to individually control log levels in
the vty.
I used to use logging level all everything, then this
allowed me to do such as
logging level smpp fatal (get rid of annoying bind check
every 30 secs)
logging level [category i'm interested in] debug
Now, all I seem to be able to do is turn all categories to a
level with
logging level all debug or logging level all notice.
individual category directives such as logging level pag
fatal make no difference.
What am I missing?
Thanks!
BTW, I get the behaviour I need back by moving your check
below the check for "all"::
diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c
index 01480b1..fb2cab8 100644
--- a/src/vty/logging_vty.c
+++ b/src/vty/logging_vty.c
@@ -213,17 +213,18 @@ DEFUN(logging_level,
return CMD_WARNING;
}
- if (strcmp(argv[1], "everything") == 0) { /* FIXME:
remove this check once 'everything' is phased out */
- vty_out(vty, "%% Ignoring deprecated logging
level %s%s", argv[1], VTY_NEWLINE);
- return CMD_SUCCESS;
- }
-
/* Check for special case where we want to set
global log level */
if (!strcmp(argv[0], "all")) {
log_set_log_level(tgt, level);
return CMD_SUCCESS;
}
+ if (strcmp(argv[1], "everything") == 0) { /* FIXME:
remove this check once 'everything' is phased out */
+ vty_out(vty, "%% Ignoring deprecated logging
level %s%s", argv[1], VTY_NEWLINE);
+ return CMD_SUCCESS;
+ }
+
+
if (category < 0) {
vty_out(vty, "Invalid category `%s'%s",
argv[0], VTY_NEWLINE);
return CMD_WARNING;
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
Dear all,
Max has been pushing https://gerrit.osmocom.org/#/c/1526 for quite some
time, but there was still no conclusion in its review.
I guess after more than 8 months in limbo, it's about time we decide how
to move ahead with this.
In general, we *want* secure/safe identifiers like TMSIs that are not
easy to predict by an attacker. Using rand() or some other
pseudo-random generator with a predictible seed like the time of the
process start is probably not the best choice here.
Using the rather strong entropy pool of /dev/urandom or getrandom()
is apparently not a good choice either: We can exhaust the entropy pool
at whch point we would have to block/wait, which we of course cannot in
our architecture.
So what do we do? I think we first have to differentiate on the type of
randomness needed. Is it a random identifier like TMSI? Is it a random
challenge used in cryptographic authentication? Is it random data used
for a key? Those require different levels of randomness.
For TMSI allocation, my "cryptographic gut feeling"[tm] is that something
like rand() or any other pseudo-random generator of significantly large
period is sufficient *if* it is seeded by a non-predictable value. So
something like seeding with getrandom() result should be fine?
For random challenges in authentiation I would probably go for
direct use of urandom / getrandom(). If the entropy is exhausted, the
quality of the random numbers will get lower, but getrandom() will
always return up t 256 bytes.
For long-term stable key (Ki/Op) generation for provisioning SIM cards +
populating a HLR, I would certainly opt for using stronger randomness
sources. However, I don't think we actually implement that anywhere, do
we?
What do you guys think? Is there somebody on this list more
cryptographically qualified to give us proper guidance? If you know
somebody skilled who might want to help but is not on this list, would
you invite them to join this discussion?
--
- 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,
Is there a link on how to integration osmo-bsc to osmo-msc? or osmo-bsc_nat is required to integrate osmo-bsc to osmo-msc?
A config file for both osmo-bsc and osmo-msc that can be shared will be greatly appreciated.
TIA.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
another call for anyone aware of important branches on openbsc.git to please
name them, so that they can be migrated to the new repositories.
But foremost, please name them, thanks!
~N
HI Neels,
Thanks for provided answers and tips.
Femto wich I plane to use is Alcatel.
My primary target is Packet core, so femto-osmohnbgw-osmosgsn(osmo-hlr)-osmoggsn.
Alredy know this want be easy task, But I will try, I expect also problem with SIM authentication. In past I did protocol simulators in Python (Gb, S11, Gn, Gx, Gy), wich were used in production for testing.
When I hopfuly install osmo-iuh, I wll conect femto to it and try to configure it, will sniff trafic via wireshark between and check whats happening,
Now I will try to rebulid IuH again.
BR
Goran
The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.
HI,
My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with osmo-sccp library.
Also tried Vagrant IuH image, but there is issue with permisions,
Is there a way to get some help for solving this issues,
Thanks
Goran
-----Original Message-----
From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of openbsc-request(a)lists.osmocom.org
Sent: Thursday, September 28, 2017 4:36 AM
To: openbsc(a)lists.osmocom.org
Subject: OpenBSC Digest, Vol 35, Issue 30
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request(a)lists.osmocom.org
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: branches in openbsc.git (Harald Welte)
2. Re: randomness of identifiers (Harald Welte)
3. Re: Retrieve OP from OPc and Ki (Harald Welte)
4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)
----------------------------------------------------------------------
Message: 1
Date: Thu, 28 Sep 2017 07:05:09 +0800
From: Harald Welte <laforge(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: openbsc(a)lists.osmocom.org
Subject: Re: branches in openbsc.git
Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja>
Content-Type: text/plain; charset=us-ascii
On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
> another call for anyone aware of important branches on openbsc.git to
> please name them, so that they can be migrated to the new repositories.
> But foremost, please name them, thanks!
>From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn
* laforge/gprs-suspend -> osmo-bsc
* laforge/power_control -> osmo-bsc
--
- 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)
------------------------------
Message: 2
Date: Thu, 28 Sep 2017 07:15:01 +0800
From: Harald Welte <laforge(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: openbsc(a)lists.osmocom.org
Subject: Re: randomness of identifiers
Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Neels,
On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
> On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte wrote:
> > For TMSI allocation, my "cryptographic gut feeling"[tm] is that
> > something like rand() or any other pseudo-random generator of
> > significantly large period is sufficient *if* it is seeded by a
> > non-predictable value. So something like seeding with getrandom() result should be fine?
> Might also make sense to periodically re-seed from /dev/urandom /
> getrandom(), like every 100 TMSIs, or based on a timeout might be
> easier to implement.
I would try to avoid any predictability here. Having a fixed time interval would be known to an attackers. So if he was somehow able to reduce/exhaust the entropy at the known time for re-seeding, it would be bad.
Similar for "every 100 TMSIs", which is something under control of any attacker as he can control the number of location updates via the public radio interface [to some extent] and thus control the time at whcih re-seeding is done.
Maybe I'm going overboard here, but I think if you want to re-seed, you want to ideally do it at a non-predictable and non-controllable point in time. Like a random time interval ;)
> > For long-term stable key (Ki/Op) generation for provisioning SIM
> > cards + populating a HLR, I would certainly opt for using stronger
> > randomness sources. However, I don't think we actually implement
> > that anywhere, do we?
>
> what does openssh use for public/private keypair generation?
I'm not sure you can compare the requirements for generation of RSA public/private keys with those for generation of symmetric keys. You can find different recommendations in the literature. But I guess that's mainly due to the fact that people usually assume you have long-term stable public/private keys and short-lived symmetric session keys. In our case, it's long-lived symmetric keys.
But as indicated, I think our focus is to find a proper solution for generation of TMSIs and for random numbers used in authentication challenges. K/OPc pair generation is not supported in current Osmocom tools anyway, as we presume the SIM cards already have sufficiently random key material and those keys are entered into the HLR.
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)
------------------------------
Message: 3
Date: Thu, 28 Sep 2017 06:52:28 +0800
From: Harald Welte <laforge(a)gnumonks.org>
To: Kathryn Heckman <exuberant.kathryn.heckman(a)gmail.com>
Cc: "openbsc(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org>
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Kathryn,
On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
> Is there any way to retrieve the value of OP from OPc and Ki?
No, that defeats the entire purpose of having card-individual OPc values.
If you could just revert that operation, there would be no [security] advantage of card-individual OPc values over a global OP value, and hence that entire option could be dropped from the specifications altogether.
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)
------------------------------
Message: 4
Date: Thu, 28 Sep 2017 06:50:03 +0800
From: Harald Welte <laforge(a)gnumonks.org>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Cc: Holger Freyther <holger(a)freyther.de>, openbsc(a)lists.osmocom.org
Subject: Re: ctrl interface: GET a variable with parameter
Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja>
Content-Type: text/plain; charset="us-ascii"
Hi Neels,
On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
> Also we do have a concept of nesting CTRL nodes separated by dots in
> the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
correct.
> I notice though that we do still have open doors for a lot of nonsense
> being sent to it without proper validation or error messages.
>
> GET 42 existing-variable.trailing.names.ignored more nonsense
> following being ignored
>
> in effect is identical to:
>
> GET 42 existing-variable
>
> So we should probably enforce that there is no ignored nonsense...
I agree.
> Should we also enforce a numeric command ID?
I'm not following here. Where would that numeric command ID comning from?
> GET currently-any-id-is-possible-even-\t-\n-is-accepted my-command
this is also not intended, I'm quite sure.
> Going back to the OsmoHLR CTRL commands -- they are implemented in a
> way that doesn't match the CTRL interface ways. Let's collapse them.
>
> SET enable-ps <IMSI>
> SET disable-ps <IMSI>
> SET status-ps <IMSI>
indeed, this is not proper.
> SET subscriber.by-imsi.123456789098765.ps-enabled 1
> SET subscriber.by-imsi.123456789098765.ps-enabled 0
> GET subscriber.by-imsi.123456789098765.ps-enabled
makes a lot of sense to me.
> We can also expand this later to things like
>
> GET subscriber.by-imsi.123456789098765.status
> SET subscriber.by-imsi.123456789098765.msisdn 2345
> GET subscriber.by-msisdn.2342.status
> SET subscriber.by-msisdn.2342.ps-enabled 0
> GET subscriber.by-imei.987654321234565.imsi
looks good!
> We could leave the enable-ps, disable-ps, status-ps commands in place
> in case anyone is using it yet. I assume no-one is though.
I don't think we need to keep compatibility at this point.
--
- 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)
Yesterday I noticed that apparently we are unable to GET a variable with
argument, e.g. in OsmoHLR get the ps-enabled status of a subscriber and
passing the subscriber's IMSI along for the value we'd like to receive.
Experimenting a bit, I found that for GET commands, any tokens sent after
the variable name are ignored, dropped on the floor and cause neither an
error nor are evaluated.
With a tiny patch, we can make passing arguments to GET parameters
optional:
https://gerrit.osmocom.org/4069
But notably, by adding some CTRL parsing tests I found some interesting
behavior...
https://gerrit.osmocom.org/4067https://gerrit.osmocom.org/4068
In OsmoHLR, such a status request is so far implemented as a SET, since
SET takes an argument and also returns a result. See:
https://gerrit.osmocom.org/4062 (patch obsolete after 4069)
For that particular set of commands in OsmoHLR:
enable-ps <IMSI> (WO)
disable-ps <IMSI> (WO)
status-ps <IMSI> (semantically RO, nevertheless a SET, so technically WO)
I thought it would also make sense to just have one variable for the whole
lot, as in
subscriber-enable-ps <IMSI>,<val> (RW)
so that we reflect that single value with a single CTRL variable. After
all, that's how the CTRL API appears to be intended: GET and SET commands
on the same entity, instead of blowing up each variable by op * value range.
Or even a command to query and change various subscriber values:
subscriber <IMSI> <variable>[=<val>] [<variable>[=<val>] [...]] (RW)
e.g.
GET 1 subscriber 123456789087654 msisdn msc_nr imeisv
reply: subscriber 123456789087654 msisdn=12345 msc_nr=1 imeisv=123456789abcdef
SET 1 subscriber 123456789087654 msisdn=54321 msc_nr=4 imeisv=fab123434843823
reply: OK
or: "Cannot modify msc_nr, nothing changed"
or: "Unknown subscriber parameter: xyz"
One step further would be to pick an identification trait from imsi, msisdn or imei...
GET 1 subscriber imsi=123456789087654 msisdn imeisv
GET 1 subscriber msisdn=12345 imsi imeisv
GET 1 subscriber imeisv=12345abcdef123 imsi msisdn
(often a new subscriber in communal networks can easily find the phone's IMEI,
where the IMSI is unknown, so queries like this would be useful in general)
Would this be too much of a monster command? Rather:
GET 1 subscriber-by-imsi 123456789087654 msisdn imeisv
GET 1 subscriber-by-msisdn 12345 imsi imeisv
GET 1 subscriber-by-imeisv 12345abcdef123 imsi msisdn
Comments welcome!
~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
I have two SIM card I inheritted from a previous project that I've been told came from the same vendor. When I run `pcsc_scan` on them, I get the following output for both:
Reader 0: OMNIKEY CardMan (076B:3022) 3021 00 00
Card state: Card inserted,
ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
ATR: 3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
+ TS = 3B --> Direct Convention
+ T0 = 7D, Y(1): 0111, K: 13 (historical bytes)
TA(1) = 94 --> Fi=512, Di=8, 64 cycles/ETU
62500 bits/s at 4 MHz, fMax for Fi = 5 MHz => 78125 bits/s
TB(1) = 00 --> VPP is not electrically connected
TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
Category indicator byte: 55 (proprietary format)
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 7D 94 00 00 55 55 53 0A 74 86 93 0B 24 7C 4D 54 68
SIM from sysmocom sysmoSIM-GR2
When I try to program one of the SIMs, it works fine:
$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
Insert card now (or CTRL-C to cancel)
Generated card parameters :
> Name : Magic
> SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
> ICCID : 8901001010000000017
> MCC/MNC : 1/1
> IMSI : 001010000000001
> Ki : ffffffffffffffffffffffffffffffff
> OPC : f134b55cea2942ebbd213c82e084be62
> ACC : None
Programming ...
Done !
But on the other I get:
$ sudo ./pySim-prog.py -p 0 -i 001010000000001 -k ffffffffffffffffffffffffffffffff -t sysmoSIM-GR2 --num=1 --mcc=001 --mnc=01
Insert card now (or CTRL-C to cancel)
Generated card parameters :
> Name : Magic
> SMSP : e1ffffffffffffffffffffffff0581005155f5ffffffffffff000000
> ICCID : 8901001010000000017
> MCC/MNC : 1/1
> IMSI : 001010000000001
> Ki : ffffffffffffffffffffffffffffffff
> OPC : 53945a5223e299bf6cec05911922442c
> ACC : None
Programming ...
Traceback (most recent call last):
File "./pySim-prog.py", line 636, in <module>
card.program(cp)
File "/home/user/workspace/pysim/pySim/cards.py", line 382, in program
self._scc.verify_chv(0x05, pin)
File "/home/user/workspace/pysim/pySim/commands.py", line 111, in verify_chv
return self._tp.send_apdu_checksw(self.cla_byte + '2000' + ('%02X' % chv_no) + '08' + fc)
File "/home/user/workspace/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw
raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1]))
RuntimeError: SW match failed ! Expected 9000 and got 9840.
I also tried some of the other branches, as people on other forums had reported better luck with those, but I get the same error. Is there any documentation explaining the magic byte values that are sent back and forth to the card? I'm having a hard time understanding the spec by which the program is trying too communicate with the card.
Any help is greatly appreciated.
Thanks,
Billy
Hi.
There's clearly big difference between split BSC/MSC and NITB
(config files, support for SCCP-lite etc) which makes the transition rather lengthy.
What about SGSN and related stuff? It's been transitioned to libvlr at the time of
split as well, but does this transition have any user-visible consequences?
If not than we could transition gradually:
* make SGSN build optional (--enable-gprs?) in openbsc repo
* start building OsmoSGSN from osmo-sgsn repo instead of openbsc (both .deb and OE)
* test and make sure that it works the same way (both on sysmobts and on debian)
* disable SGSN build by default and announce that patches should be made against new repo
* remove gprs code from openbsc leaving placeholder readme with the link to new repo
All the steps above are unrelated to BSC/MSC items so it could be done independently.
--
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 All,
We installed osmo-bts-trx using Debian 9 OS through nightly package and encountered an error after running it.
As per checking, there is an existing bug in osmo-bts regarding the "osmobts-trx: error while loading shared libraries: libosmotrau.so.1: cannot open shared object file: No such file or directory” error.
https://osmocom.org/issues/2481
So we tried to install it through building it from source.
Upon installation, we encountered an error upon running ./configure. Error message:
checking whether to enable support for sysmoBTS L1/PHY support... no
checking whether to enable support for osmo-trx based L1/PHY support... no
checking whether to enable support for Octasic OCTPHY-2G... no
checking whether to enable NuRAN Wireless Litecell 1.5 hardware support... no
checking for openbsc/gsm_data_shared.h... no
configure: error: openbsc/gsm_data_shared.h can not be found in /root/osmo-bts/../openbsc/openbsc/include
So we tried to rename the gsm_data.h found in “~/osmo-bts/include/openbsc” folder to gsm_data_shared.h.
The ./configure goes through but has an error upon running "make”.
Is there another way to install osmo-bts?
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Hello,
I have gone through some of the documentations and now trying to install
osmoBSC i.e just the BSC part not the openBSC or osmoNITB. I am kind of
confused , can anyone please tell me if I can build just the BSC part and
in order to do that what are the packages that I have to configure.
Thanks
Anindya
To fix the osmo-msc preliminary debian package build of osmo-msc, I need these
patches in osmo-mgw to be merged:
https://gerrit.osmocom.org/3999https://gerrit.osmocom.org/4000https://gerrit.osmocom.org/4001https://gerrit.osmocom.org/4002https://gerrit.osmocom.org/4003https://gerrit.osmocom.org/4005
(topic 'new_mgw' less 4006 and 4007)
If review takes too long I am tempted to just merge it ahead to fix the state
of osmo-msc.deb in
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
If I do, it means that I would like to fix and improve those patches later, not
that I want to smuggle them past review. I just want to finally get the debian
builds working and off my mind again.
The osmo-msc currently fails because it needs a header file not included in
libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
which are of course not included in the libosmo-mgcp-client deb. I want them to
be separated completely to save us this kind of cumbersomeness in the future.
Only one of the above commits unties libosmo-mgcp-client from the other libs,
but small bits here and there make the change depend on the others in that
bunch. I could re-arrange, but that would take time. I'd rather just keep them
in that order, we want them merged anyway.
The large ones in the middle are dexter's work on the next generation MGW that
happened on a branch, being placed beside the legacy code. This way we can move
from legacy to new code in osmo-msc and osmo-bsc independently.
~N
It seems there are a lot more versionings around than I thought...
I am currently deciding on how we want to handle libtool API versions.
These are strings of the form
current:revision_of_current:compat_age
MGCP_LIBVERSION=5:23:4
means that
- We are in API version 5.
- This is the 23rd "small internal" modification of 5.
- We are backwards compatible to 4 previous API versions (1 thru 5).
This is not at all related to release versions of the major.minor.patch form.
For example, each small tweak of the code will bump the middle
'revision_of_current' number, whether it's a minor or patch release bump.
Now I had the plan to actually coincide the major release version with the API
current version. When we are in release 1.0.1 thru 1.23.42 and so forth, keep
the library API current version at 1. Once we do a major version bump to 2.0.0,
we can go on to API current version 2. Coinciding seems to make sense because
we anyway don't want to make API breaking changes unless we bump the major
release number.
BTW the API 'current' version number also appears in the debian package names
like libosmo-mgcp2.deb and the installed library files, like
libosmo-mgcp.so.2...
Keeping the API current the same as release major makes sense to me, but only
up to this point: when we add a new side feature to a library.
When all of the library stays the same and is backwards compatible, and all we
do is add a new function to it, someone linking against it may want to make
sure that this new function is included in the installed version. So even if
we don't bump a major release, don't break API and so forth, we may still want
to increase the API-current version and bump the names of the debian packages
as well as installed .so files.
Why? Because if we had libosmo-mgcp1 and added function mgcp_frobnicate(), and
we want to use mgcp_frobnicate() in osmo-msc.deb, we want to depend on a
libosmo-mgcp that has it added, i.e. we bump to libosmo-mgcp2.deb and depend on
that from osmo-msc.deb. All the while libosmo-mgcp's version tag still remains
at 1.0.23, only the API version changed.
This would be the libtool-intended way, and we'd see a lot of debian package
names' numbers bumping, not at all related to our major-release, whenever we
add any new function to our API.
Only in reality, if I see libosmo-mgcp5.deb, as a user I do expect it to be
libosmo-mgcp release 5.2.3, not release 1.0.23. Right?? Is that only me?
According to libtool, coinciding the API version with the release version is
abuse. OTOH it's what I actually expected for most of my life... :/
Will we have the discipline to bump API current for each addition?
And bump each depending projects' debian depends-clauses?
What do you guys think about this?
See https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info…
Thanks!
~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
Hi all,
we have recently merged a profound change to the inner workings of the VTY
configuration. We've hit some fallout due to that, hence I would like to let
you know that you might hit the same.
The VTY parsing of config files is now strict about indenting.
A child node *must* be indented below the parent node,
and indenting must be consistent.
For more details on the reason why and a definition of 'consistent', see the
commit log of
https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a04…
So, if you are in the near future faced with config files being rejected that
worked perfectly before, it is most probably because your indenting was wrong
all the time, and only now did we start checking it.
If the cause is hard to figure out, a good aid is the telnet VTY, where you may
either 'show running-config' or traverse the nodes manually to query which
command exists on which level. If your current config is broken, you may be
able to start the program with an empty or stripped down config file to make
its telnet available.
The above is about reading config files, but we have also dropped the implicit
'exit' to parent level on the telnet VTY console. This caused fallout where
nodes by plain omission lack the 'exit' command: one is unable to leave such a
node once it is entered. That is a fault in the program's VTY setup that was
not found before, because the VTY would often just find the parent node's exit
command instead. I have a patch to avoid all of these everywhere, by
installing the exit and end commands automatically for every VTY node that gets
created; it is not merged yet: https://gerrit.osmocom.org/3998
------ Config Fallout Example ------
For example, we hit a breakage with this osmo-bts-trx.cfg:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
Before, this worked perfectly. Now it says the command 'osmotrx rx-gain' does
not exist. The reason is that 'osmotrx rx-gain' is a child node of 'instance
0'. The first fix looked like this:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
But alas, this time it said the command 'osmotrx ip local' does not exist. I
suspected bugs in the new parsing, but indeed, 'osmotrx ip' is actually a
direct child of the 'phy 0' level. Before, the VTY would implicitly step out of
a child level if it found a matching command one parent above. That is
confusing in other situations (see above commit log), hence we now require
indenting to clarify the structure. This is the correct one:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
Or rephrased:
phy 0
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
To query the structure via telnet, I did:
$ ./osmo-bts/src/osmo-bts-trx/osmo-bts-trx -c osmo-bts/doc/examples/trx/osmo-bts.cfg
$ telnet localhost 4241
OsmoBTS> enable
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# list
[...]
osmotrx ip HOST
osmotrx ip (local|remote) A.B.C.D
[...]
OsmoBTS(phy)# inst
OsmoBTS(phy)# instance 0
OsmoBTS(phy-inst)# list
[...]
osmotrx rx-gain <0-50>
osmotrx tx-attenuation <0-50>
osmotrx tx-attenuation oml
[...]
------ No Exit Example ------
The same osmo-trx VTY nodes also show the exit failure:
$ telnet localhost 4241
OsmoBTS> enable
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# exit
% Unknown command.
OsmoBTS(phy)# instance 0
OsmoBTS(phy-inst)# exit
% Unknown command.
On the phy level, we would previously find the parent's 'exit' command, but in
the 'instance' level, 'exit' has never been available. Above patch should fix
all of these.
~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
Hi ,
i’m trying to build osmo-trx master branch .
What i’am doing :
autoreconf -i
./configure
make
In make step i get this error :
Evaluating ‘parse’ option: ‘(?P\d+).(?P\d+).(?P\d+)’ does not parse
current version 'P2.8TRUNK’
usage: bumpversion [-h] [–config-file FILE] [–verbose] [–list]
[–allow-dirty] [–parse REGEX] [–serialize FORMAT]
[–search SEARCH] [–replace REPLACE]
[–current-version VERSION] [–dry-run] --new-version
VERSION [–commit | --no-commit] [–tag | --no-tag]
[–tag-name TAG_NAME] [–message COMMIT_MSG]
part [file [file …]]
bumpversion: error: the following arguments are required: --new-version
make all-recursive
Hi All,
Good day.
If we are going to integrate OSMO-BSC to another MSC, for example, a Huawei MSC, what components do we need?
Is their a link that can help us do this task?
Thank you in advance.
BR,
Bob
Hi all,
I've been creating some test suites for various different interfaces
and Osmocom elements in osmo-ttcn3-hacks.git.
In case you want to use and/or extend them, here is some introduction
in how to build them and how to use them.
I've updated
https://osmocom.org/projects/cellular-infrastructure/wiki/Titan_TTCN3_Notes
with some information on how I build + execute + view the logs, maybe
this is useful to you. Let me know if you have any questions.
For sure this could be more automatized (like cloning the dependencies
or even using them as git-submodule), but so far I'm investing every
minute I have in increasing test coverage, rather than convenience
features.
Regards,
Harald
--
- 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 Directors: Holger Freyther, Harald Welte
Hi,
I’ve been looking into getting ussd working with an external application. I
found a branch from last year (fairwaves/sup-ussd) that looks like it has
implemented most of ussd sessions and possibly communicates with an
external application. Does anyone know if it was finished or what still
needs to be done?
I also found a python script called ussd_example.py which looks like it is
supposed to act as a gateway and receive used connections from openbsc. Is
this correct and did it work or am I misunderstanding its purpose?
Thanks!
- Rowan Phipps
I implemented https://gerrit.osmocom.org/3880 to use indenting for vty implicit
'exit'.
There's one thing I'm sneaking in there though which I'd like to mention before
I merge:
The patch is storing vty parent node state. This state not only stores previous
indenting, but it also stores the parent's 'node' id and 'priv' data (the
node's object), and puts these back in place after going to a parent.
So far our go_parent_cb()s set these, and AFAIK all of them simply put the
parent's exact node and priv pointer back in place. But technically, a
go_parent_cb() *could* do some magic like going to a completely different node,
or re-creating a new priv pointer. By overwriting from stored state, we will
override such behavior.
I think we want this to happen from stored state in the future, and drop most
of the go_parent_cb(). Does everyone agree?
~N
Hi All,
Is there a way to configure the “ms max power” to a dynamic value depending on the distance of the mobile phone to the base station?
For now, the default value is 12. Meaning, the base station is telling the mobile phone to transmit in the power of 12dBm either the phone is besides the base station or on the edge of the base station.
If not, is there a roadmap on configuring it with a dynamic or auto value?
TIA.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
Hi ,
OsmoBTS version 0.6.0.6-ae13
OpenBSC version 0.15.0.885-968a6
I flow the instructions from wiki page and create config files :
https://osmocom.org/projects/cellular-infrastructure/wiki/SDR_OsmoTRX_netwo…
but when i run :
osmo-nitb -c ~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -C
--debug=DRLL:DCC:DMM:DRR:DRSL:DNM
I got this error :
There is no such command.
Error occurred during reading the below line:
timer t3103 0
<0005> ../../../src/libbsc/bsc_init.c:536 Failed to parse the config
file: '/home/ashtum/.osmocom/open-bsc.cfg'
Reading config failed. Exiting.
Similarly when i run :
osmo-bts-trx -c ~/.osmocom/osmo-bts.cfg
I got :
((*))
|
/ \ OsmoBTS
There is no such command.
Error occurred during reading the below line:
fn-advance 20
% rtp bind-ip is now deprecated
Failed to parse the config file: '/home/ashtum/.osmocom/osmo-bts.cfg'
Hello,
I have installed the open openbsc.deb but when I am trying to run it using
the command "osmo-bsc" its giving me the following error
<0005> bsc_init.c:536 Failed to parse the config file: 'openbsc.cfg'
Bootstrapping the network failed. exiting.
full talloc report on 'sccp' (total 1 bytes in 1 blocks)
Please help me solve it.
Thanks
Anindya
Dear all,
for probably about a year (or longer) we have been putting up with VTY
tests which cause builds to break under unclear circumstances. I personally
believe the probability of a VTY test failing has recently increased again,
and this is barely tolerable anymore. Often, rebasing/cherry-picking the given
patch one or two times also doesn't work. Yet, the given patch-under-test
is not even touching anything related to VTY, like
In https://gerrit.osmocom.org/3899 which has failed in
https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2451/ and
https://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/2454/
I know Neels and others have spend already significant time in the past trying
to resolve this - unsuccessfully.
So I think the situation has reached a point where we should disable the vty
tests, or at least the specific part of the vty tests that is known to break
most frequently.
I definitely want us to have *more* testing, not less. However, when the test
itself is not stable yet - particularly after that much time - we cannot
have that buggy test delay our development.
I would vote for running those tests regularly (daily, every few hours, you name
it), but not as part of the mandatory build verification for gerrit V+1.
What do others think?
--
- 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)
On Mon, Sep 11, 2017 at 11:01:23AM +0200, Pau Espin Pedrol wrote:
> today I found the same issue again in prod (/sierra_2 -> /sierra_4).
> Interestingly, both /sierra_2 and /sierra_3 seem to be using the same
> firmware. dmesg shows again a disconnect from the usb port.
We have this idea of giving the same modem a persistent name on ofono, which
would solve the symptoms, but it's curious why this happens.
I had the watchdog script in place that power cycles the quad modem board and
restarts ofono as soon as the modem names mismatch what we expect. But lynxis
disabled it. The reasoning is that we won't catch ofono errors. That may be
true; my idea was to be able automatically recover ofono without manual
intervention. I guess it all depends on how closely you (lynxis) watch the gsm
testers for failures? Because my focus is not particularly on ofono, and when I
hit a broken situation and need to test things, I will restart ofono and rather
not in-depth investigate the failure; in a dismissive way "come on ofono, do
what I want now." What do you guys think about this?
> I guess only /sierra_2 crashes because it's the first modem in the
> resources.conf list and thus it is usually used in all tests (for instance,
> tests which require only 1 modem), and probably some of the steps done in
> one of those tests is crashing the modem.
Something I thought about before: we could implement a kind of random or round
robin to not always pick the first matching resources in the list. Advantage is
that we would cycle through the hardware and force us to precisely formulate
e.g. modem requirements. The disadvantage is that not every test is run exactly
the same, adding complexity that may obscure analysis. i.e. to reproduce a run
on a particular modem, we would have to somehow clamp that randomness, e.g.
log a random seed at the start and allow passing in a random seed on the
cmdline.
~N
Dear List
I am trying to run osmocomBB with motorola c118 with openbsc.I tried to get
openbsc network on my phone it works well and I am able to register on
openbsc network.
But when i try to run osmocomBB with openBSC i am not able to get network.
Also when i run rssi firmware on c118 phone i get network and its working
fine.
I am using default configuration file for OpenBSC and using NanoBTS with
1800Mhz support.
Is there any configuration change is needed in openBSC ?
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Dear guys,
anyone can help me, Im using osmo-gsm-tester osmo-bts.cfg and openbsc.cfg
also/
BTS is up and auth policy accept-all is set and even I add subscriber IMSI,
but my phone still cannot register on the network.
my setup is LimeSDR and using the latest osmo-bts and openbsc with OpenUSRP.
do you think its a hardware issue?
please help! Thanks
--
best regards,
DUO
Hi.
The OsmoBTS build depends (unfortunately) on OpenBSC because it uses
gsm_data_shared.h header. ATM this file is available in osmo-bsc and osmo-msc (maybe
other split repos as well). Which is the "canonical" one from OsmoBTS point of view?
Also, when would be the right time to move OsmoBTS' jenkins job to use one of the
split repos instead of old OpenBSC?
--
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 Blobb,
I'd like to probe your opinion on a discussion we had today about our
jenkins. So far our setup was manual, and we would like to (somewhat)
automate the process of providing build dependencies on slaves.
One solution that was discussed longer than others would be to use docker.
Each of our repositories that need a build would have their own docker
file, containing the complete setup of dependencies. The idea is that
anyone can easily setup an identical build on any new jenkins build slave
or even at home; no complex config of the jenkins build slave is needed.
The point being, if we adopt docker in such a way, it would be logical to
make use of the docker cache to save unnecessary rebuilds. It is a generic
solution instead our artifact store.
I feel a bit bad for accepting your contributions, doing review and
keeping you busy, just to then talk about docker to solve the problem
instead; I appreciate your presence and would like to keep you involved.
Interestingly enough, we are experimenting with the artifact store on that
one build job that has already been using docker for quite some time...
(It was for the separate network space, not really for artifacts.)
In any case, I would like to include you in the discussion, and maybe you
would also like to be involved in maturing the idea? Until now it is still
wild and no-one has taken actual steps.
An example to follow would be laforge's recently added
https://git.osmocom.org/docker-playground/tree/
One interesting bit is that it has a method to check whether a given git
branch has changed, and rebuilds the docker image only if it has:
https://git.osmocom.org/docker-playground/tree/osmo-ggsn-master/Dockerfile#…
ADD http://git.osmocom.org/openggsn/patch/?h=laforge/osmo-ggsn /tmp/commit
This line fetches the given URL (in this case the latest patch on that
branch) and considers the docker image as unchanged if that URL shows the
same as last time. As soon as a new patch shows, things are rebuilt.
In this sense we could have docker images cascading on top of each other,
adding individual dependencies and reusing identical states auto-detected
by docker. All build steps would be in the Dockerfile.
For builds that aren't used by other builds (like the "final" programs,
osmo-msc, osmo-sgsn, osmo-bsc,...) we don't need to store the result, so
don't need to include the program's build in the Dockerfile: on a docker
image with all dependencies, run the final build step by invoking 'docker
run', like we currently do for the OpenBSC-gerrit job, and then just
discard the changes.
Remotely related: we have the osmo-gsm-tester that is running binaries
produced by jenkins to do automated tests on real GSM hardware. Currently
we compile and tar the binaries, copy them over, extract, set
LD_LIBRARY_PATH and run: a bit tedious and problematic e.g. for
mismatching debian versions. This could be simplified by docker by
guaranteeing a fixed operating system around the binary, actually using
hub.docker.com (or maybe one day a private docker hub) instead of copying
over binary tars manually, sharing across any number of build slaves, and
with the added bonus of having the resulting binaries run in a separate
network space.
As I said, on the one hand I appreciate our work on the artifact store, on
the other hand the docker way undeniably makes for a good overall solution
to simplify things in general, with artifact re-use coming "for free"...
One advantage of the artifact store though is that the artifacts we manage
are not entire debian installations but just a few libs and executables in
a tiny tar.
What is your opinion?
~N
Hi all!
I just installed and configured osmo-bts-virtual and osmocom-bb with
virtphy.
Let me say - this is brilliant! It's so easy to do such things as
trigger IMSI Attach and Detach - so much easier than entering and
exiting airplane mode or power off/on.
Also, MO sms is a breeze.. I have a script to inject SMS regularly, so I
don't have to turn to the mobile and press buttons with each code change
in my SMS handler, I just make the change and wait for the next SMS to
hit it!
So thanks so much to those responsible for making this happen!
Now, one thing that is failing badly for me right "out-of-the-box" is MT
SMS.
As I am totally new to the osmocom-bb code, I guess the best would be a
ticket with some pcaps, but I thought I would ask first if it is a known
issue?
Basically, BSC is doing this:
DLSMS <0024> gsm_04_11.c:127 GSM4.11 TX [HEX of msg redacted]
DLSMS <0024> gsm0411_smc.c:247 SMC(954) TC1* timeout, retrying...
while on the mobile side:
<0005> gsm48_mm.c:3909 (ms 1) Received 'RR_EST_IND' from RR in state MM
idle (sapi 0)
<0005> gsm48_mm.c:912 new state MM IDLE, normal service -> wait for
network command
Then this repeats:
<0001> gsm48_rr.c:4775 Indicated ta 0 (actual ta 0)
<0001> gsm48_rr.c:4777 Indicated tx_power 19
<0001> gsm48_rr.c:4799 ACCH message type 0x00 unknown.
<0001> gsm48_rr.c:664 MON: f=56 lev=>=-47 snr= 0 ber= 63 LAI=262 42 0001
ID=0000 TA=0 pwr=19 TS=1/1
<0001> gsm48_rr.c:2866 MEAS REP: pwr=19 TA=0 meas-invalid=0
rxlev-full=-47 rxlev-sub=-47 rxqual-full=0 rxqual-sub=0 dtx 0 ba 0
no-ncell-n 7
<0001> gsm48_rr.c:2161 PAGING ignored, we are not camping.
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
Hi!
We have some builds that happen inside a docker, and some that happen natively
on the (Debian 8) build slave. Can somebody involved with this illustrate
why that is the case, and what's the rationale here?
Just looking at the setup, I'm unable to figure out whether there's any
particular reason for this, or whether it's simply "we started without and
then did some builds in docker but nobody migrated the other builds over"
>From my point of view, I would have assumed that building in different containers
would make sense to e.g. build on different distributions / versions, or
building against older libosmo* vs. building against libosmo* from nightly
package feeds vs. re-building all dependencies from master.
But it appears that only a single container is built, and that container is
used for some jobs (like osmo-msc-gerrit) but not for other jobs.
If I missed some wiki page or mailing list posts with related information,
a pointer would be helpful. Thanks in advance.
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 Neels,
Patchset for openBSC's jenkins.sh build script has been uploaded [1].
But a small change [2] of osmo-build.sh is necessarily pending,
because https://git.osmocom.org is down atm. Furthermore, the
osmo-build.sh script should probably not depend on cgit's
availability. :)
After [2] has been submitted following steps are necessary to verify
[1] via gerrit:
- trigger "update-osmo-ci-on-slaves"
- add ARTIFACT_STORE environment variable to all slaves/nodes e.g. [3]
- add following arguments to docker invocations of openBSC jobs [4]:
-e JOB_NAME="$JOB_NAME"
-e ARTIFACT_STORE="/ARTIFACT_STORE"
-v "$ARTIFACT_STORE:/ARTIFACT_STORE"
Afterwards, re-triggering [1] should result in a '+1 Jenkins Builder'.
I have sufficient permission to apply above stated steps, except
+2'ing [2] and you may want to suggest the absolute path for
ARTIFACT_STORE variable?
Regards,
André
[1] https://gerrit.osmocom.org/#/c/3823/
[2] https://gerrit.osmocom.org/#/c/3822/
[3] https://jenkins.osmocom.org/jenkins/computer/OsmocomBuild1/configure
[4] https://jenkins.osmocom.org/jenkins/view/Jenkins-Gerrit/job/OpenBSC-gerrit/
Just now I only got long waits and then "502 Bad Gateway" on
git.osmocom.org ... the cgit ezjail hit its root partition limit. I had to
re-figure out what I did last time, tried to find ezjail-admin options until
finally I ended up back in zfs and started remembering... I increased the zfs
quota for the cgit jail from 10G to 15G. Now it's working again.
For the record, resizing an ezjail goes like
# zfs list
# zfs get quota tank/jails/cgit
# zfs set quota=15G tank/jails/cgit
(so next time I can find it in my mail archive, and I guess it should go in a
wiki somewhere. On osmocom.org?)
Last time it was the jenkins jail hitting disc limits. Then I said
"We should probably set a refquota so that the live file system's quota is
somewhat independent from the quota used for snapshots."
I see the jenkins jail now has a 40G refquota, but the others seem not to.
How does it work, set a huge quota to allow space for snapshots, and limit the
fs itself by a refquota?
~N
Some time back we implemented OAP to add an authentication layer to the IPA,
IIRC aimed at osmo-bsc_nat <-> MAP proxy to do milenage mutual auth.
Now the oap protocol code is in libosmocore, but the oap_client code is dup'ed
in osmo-{bsc,sgsn}.git. I would move the oap_client to libosmocore as well.
But all the while I'm not really certain that it is indeed being used.
osmo-sgsn has vty config for it, but I'm certain osmo-hlr doesn't bother
to implement the OAP server part (there's code but in #if 0).
osmo-bsc_nat remains, and possibly a GSUP counter part to the osmo-sgsn that
I'm not using (presumably the MAP proxy)?
Is anyone using OAP and the oap_client and is it worth the effort to keep it?
Can we / should we just drop OAP instead?
Thanks,
~N
I'm reading through https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
and noting things as I go...
> library vs. non-library projects
This is not a thing and should disappear from the release process. We have many
projects that build programs as well as install libraries.
I see this is about the *_LIBVERSION, right? ... maybe we can say something
like "adjust *_LIBVERSION (not required if the project does not install any
libraries)" ?
> "adhere to RERO better"
RERO -- had to look it up, Eric's quote of "Release early, release often" :)
And lol, the PDF link there refers to papers written basically by the "private
club" of my former colleagues at the Subversion project :) Eric, Justin, Hyrum,
all Subversion folks.
Interesting side fact is that Subversion has never had time-based releases,
despite one hackathon vote accepting that as policy.
One detail though is that technically we do radical Release Early, because all
of our code is on public git immediately. I'm not sure that Eric's quote refers
to actual glorified "stable" releases, I understood as "make available early".
Anyhow, this paragraph seems unrelated to the tagging process, could be related
to the time-based package feed releases (see below).
> "Proposed policy:"
We already have what I'd call a loose bunch of accepted policies after
OsmoDevCon 2017 and mails following it.
It is first of all important to note a profound difference between two things
we're aming for: providing a package feed with a global glorified state
(time based), and the individual version tags in each git (feature based).
With this in mind, recall the thread starting with:
https://lists.osmocom.org/pipermail/openbsc/2017-April/010569.html
Let me summarize:
- "Global" package feeds
We are planning to provide package feeds in a time-based fashion, by pinning
code states and providing built packages. This is mostly a service to our user
base, so that they can easily communicate and update to versions.
They are to be called osmocom-cell-net / OsmocomCellNet and will have
year+month based version numbers, YY.MM like 17.03 17.06 17.09 17.12
and, quote:
> > I suggest that we follow a regular release schedule of: at the beginning
> > of March, June, September and December. (so that we don't need to roll a
> > release during/right after the festive season, i.e. not on 1st January)
At this point we might aim at an OsmocomCellNet-17.12 package feed to be out
on 1st of December.
These feeds will not wait for features or code-freeze ahead. We will simply pin
a certain point in time. If serious bugs arise we might choose to adjust, but
the advice is to then just use the previous / wait three months for the next.
- Individual git tree version numbers
In contrast to the global package feeds, each git tree has its own local
version with a git version tag. This does not follow the year+month scheme but
rather "1.2.3" major.minor.patch.
Compatibility is reflected in these version numbers, i.e. big incompatibilities
require a major version bump, mere internal fixes can bump the patch version.
(So far I understood the wiki page "Make a new release" referring to only these
individual git repository versions, but we must clarify the two different
concepts on that page and at least refer to a package feed wiki page.)
How do the global package feeds correspond to individual major-minor-patch
versions? For each of the global feeds, we should make sure that the precise
git trees that are packaged correspond 1:1 to local git version tags. I.e.
before we roll out a package feed, we make local version number tags to glorify
the current master branch in each repository (bumping versions according to
compatibility considerations) and actually use those precise version tags to
mark the state that will go out in the OsmocomCellNet-YY.MM feed.
So, while the time-based package feeds will be one driving force behind bumping
individual version numbers, we are technically still able to mark new local
version tags here and there independently from the time-based feeds.
To avoid confusion, rather than talking of "release" it could help to talk of
"package feed" versus "git version tag".
> master branch is expected to depend on latest master branches of depended-upon projects
The master branch HEADs are in constant flux, the requirement that each master
works with the other latest masters is more of a daily development requirement
enforced by our gerrit +V builds. For feeds and tags, we should not even
mention "master branch" anywhere. Rather, the entire process *must* refer to
specific version tags *everywhere*.
But I'm not entirely sure how to put it. It is possible that we already have
libosmo-foo 1.2.3 out, but osmo-bar also still builds fine with libosmo-foo
1.2.1.
I guess all we need is that configure.ac version requirements are accurate. We
will not always have to depend on the latest version number that's out, and if
older ones work, ./configure should *not* require the most recent version.
How to verify? I guess a version tag of osmo-X must verify
- that building with the precise minimal versions requested in configure.ac
works
AND
- that building with the currently latest tagged version of each depended-upon
project also works
AND
- that building with each intermittent version of each dependency also works???
That's turning out rather complex ... maybe verifying with only the oldest
required and the latest tagged versions is enough?
> make release of depended-upon projects if necessary before making non-library project release
So, are you saying, if foo needs bar which needs baz, releasing foo requires
also releasing bar, in turn needing a release of baz first?
... "if necessary" :)
To spell it out: this is not necessarily required; only when foo is using new
API of bar that is not available in a tagged version of bar yet are we forced
to make a version tag of bar and depend on it.
BTW, this is implicit by "it must build with the version requested by
configure.ac".
The text on that wiki page before your edits did say exactly that:
>> As soon as a feature is added to one Osmocom project that is needed for
>> another dependent project to compile, we should tag at least a minor-revision
>> bump in the depended-upon project and require it in the depend[ent] project's
>> configure.ac.
IMHO that's still exactly what it should say there.
For the global package feed we choose to tag a new version everywhere so that
we can pinpoint the current state that we want to glorify, but it is not
strictly required for a local version bump to also tag depended-upon gits.
> make sure that we have correct version dependencies before making non-library project release
IOW: make sure configure.ac reflects the version number of depended-upon gits
that are the minimum requirement to build. (scratch the "non-library")
Ok great, I've reviewed the first paragraph :)
Well, there was a lot of ground to cover, I hope I can do the rest less
verbosely...
> modify *_LIBVERSION in Makefile.am as necessary according to TODO-RELEASE file
would be good to clarify what you mean, e.g. by an example.
BTW, I find RANAP_LIBVERSION in osmo-iuh, ABIS_LIBVERSION and TRAU_LIBVERSION
in libosmo-abis and LEGACY_MGCP_LIBVERSION in osmo-mgw; that's all. Do we need
a lot more *_LIBVERSION everywhere, starting with libosmocore?
Also it would be good to embed this in the list of steps under "common steps"
... i.e. have just one list of steps standing out clearly; Ideally I can
start reading at the top and follow the steps one by one.
> The release helper is trying to be smart about it and prevent making new
> library release with non-empty TODO-RELEASE file if *_LIBVERSION is not
> adjusted beforehand.
Not sure I understand. I can either empty out TODO-RELEASE or change
*_LIBVERSION? If I modify *_LIBVERSION, I can make a release despite
TODO-RELEASE being nonempty?
> Use following guidelines when choosing release type:
I'd guess at
major: Previous API is no longer available, ABI has changed incompatibly.
minor: Additions to public API/ABI are present.
patch: API/ABI unchanged, internal changes only (like bugfixes).
> Deprecation policy
I think we should never remove deprecated functions unless it would cause us
inhumane pain to still include them. Dropping them would require a major
version bump.
> TODO-RELEASE file format and maintenance
would be excellent to provide an actual example there
> How to (re)tag a new release
Is tagging and re-tagging the same? Do I need to delete a tag first? A word to
clarify that would be good. Also, above it says re-sign, is that the same
thing?
Still unclear to me is, do I first tag a version, then do 'make release', and
then I need to re-tag / re-sign again? A clear sequential list of steps and/or
a complete screen dump example would be very helpful to grok it.
[I remember OpenBSD CD sets having a complete listing of the default
installation in the CD booklet :) ]
Finally, I tried to call 'make release' but face these problems:
▶ make release
/bin/bash: bumpversion: command not found
▶ apt-cache search bumpversion
(no results)
Though I find 'bumpversion' on packages.debian.org, I am unable to install it
with 'apt-get'.
https://packages.debian.org/buster/bumpversion
It says "Packages / buster (testing) / devel / bumpversion"
...do I need to add "devel" to my apt sources somehow?
Do we really need bumpversion? Can I instead bump the version manually?
Also:
▶ make release
/bin/bash: bumpversion: command not found
osmo-release.mk:13: *** Please fix versioning to match http://semver.org/ spec (current is 1.0.1.115-f7251) before proceeding.. Stop.
The intended version should be 1.0.2.
Is that because bumpversion is not available?
(Shouldn't it abort right away when bumpversion is missing?)
I tried to also tag a version first so that git-version-gen produces a clean
semver version:
▶ cat .version
1.0.2
but still get
▶ make release
/bin/bash: bumpversion: command not found
osmo-release.mk:13: *** Please fix versioning to match http://semver.org/ spec (current is 1.0.2) before proceeding.. Stop.
(i.e. now it complains about "1.0.2" not being semver, which is inaccurate)
Can you document these pitfalls on the wiki as well, please?
~N
(P.S.: "first .. then" and "if .. then" ... it's almost always "then" with "e".)
On some systems the ALSA output buffer is pretty big, and
if the audio samples are not being passed into the buffer
quickly enough, it becomes starved for data, resulting
in an error called underrun.
Previously, when it happenned, GAPK used to stop processing
with the following message (where X is a random number):
[+] PQ: Adding ALSA output (dev='default', blk_len=320)
[!] pq_execute(): abort, item returned -1
[+] Processed X frames
According to the ALSA documentation, the pcm_handle
changes its state when the problem happens, and should
be recovered using the snd_pcm_prepare() call. This change
actually does that.
---
src/pq_alsa.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/pq_alsa.c b/src/pq_alsa.c
index 9cee426..a3435dd 100644
--- a/src/pq_alsa.c
+++ b/src/pq_alsa.c
@@ -57,7 +57,15 @@ pq_cb_alsa_output(void *_state, uint8_t *out, const uint8_t *in, unsigned int in
struct pq_state_alsa *state = _state;
unsigned int num_samples = in_len/2;
int rv;
+
rv = snd_pcm_writei(state->pcm_handle, in, num_samples);
+ if (rv == -EPIPE) {
+ /* Recover from buffer underrun */
+ snd_pcm_prepare(state->pcm_handle);
+ /* Send a new sample again */
+ rv = snd_pcm_writei(state->pcm_handle, in, num_samples);
+ }
+
return rv == num_samples ? 0 : -1;
}
--
2.14.1
I would have welcomed more patience in merging https://gerrit.osmocom.org/3685,
"Use value string check from osmo-ci" in libosmocore.
(the commit log of which fails to indicate removal of the script, btw)
Moving to the new repositories, I have enough loose ends flapping in the wind,
and dropping the script from libosmocore has added yet another distraction,
while not being necessary to start using the one from osmo-ci.
Max clearly posted "N. B: this should be merged last, after all the repos
converted to check script from osmo-ci." -- which is not the case for the new
repositores split from openbsc.git.
In osmo-msc I have >50 patches waiting to be merged. The timing could hardly
have been worse, luckily only a few gerrit builds are affected. Will try to
sort out merging of the patches without needing a rebase and >50 rebuilds.
Thanks for you attention :)
~N
Hi.
I'd like to propose to switch from local (unmaintained?) copy of git-version-gen
script and use it directly from upstream gnulib package. It's available pretty-much
everywhere (including ancient Debian which we support for nightly). It's also
available in meta-oe: https://layers.openembedded.org/layerindex/recipe/47365/
It doesn't feel right to use copy-pasted code when we could offload the maintenance
work to packaging/dependency tools.
What do you think? Please contribute to https://osmocom.org/issues/2467 which I've
created to track this RFC.
--
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
