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)