From mykola at pentonet.com  Wed Jul  3 09:09:25 2019
From: mykola at pentonet.com (Mykola Shchetinin)
Date: Wed, 3 Jul 2019 12:09:25 +0300
Subject: Samsung and PS problems
Message-ID: <CANm+Yg=mN-4EzX+0Djv36sLKHhMnOKCyFAPtLWkJZ4xCx9MhJA@mail.gmail.com>

Hello,

Has anybody tested PS (either 2G or 3G) with Samsung phones?

Have you experienced any problems? (like having no internet though at
the same time PDP is active and GTP traffic is flowing in both
directions)

Kind regards,
Mykola Shchetinin


From pespin at sysmocom.de  Wed Jul  3 17:41:19 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 3 Jul 2019 19:41:19 +0200
Subject: Missing git tags in osmo-pcap
Message-ID: <ec0a88dd-638a-8926-3a2e-231d10b8b45b@sysmocom.de>

Hi Holger,

I was planning to add osmo-pcap recipes to meta-telephony soon, and 
first of all I wanted to make a new release since last tag (0.0.6) 
looked quite old. But then I found in debian/changelog that actually a 
lot of new releases exists, but their git tags are missing in the 
osmo-pcap git repository.

So after making sure I updated my tag list from the server (gerrit). I got:
$ git tag
0.0.1
0.0.2
0.0.3
0.0.4
0.0.5
0.0.6

but according to git log from debian/changelog, releases 0.0.7-0.0.11 do 
exist.

Interestingly, tags 0.0.5 and 0.0.6 point to the same commit.

Commits adding new releases without tags, see for instance:
a316c9394aa27d25b3d7fba004563890a43ab1bc (0.0.7 added)
fbdcf593f80d4fe5330376674136fd76fcef5ea2 (0.0.8 added
c016b5d3824923c2b35c67cfb9930a30e564f07e (0.0.9 added)
fdebd88059df3a8f717614548dcd7247e8890f9a (0.0.10 added)
17f5b005066a15312525e53e7b4a574d40011f96 (0.0.11 added)
4776b2972e84ef75b3a1c884da19604d87fc7f68 (a new commit added to 0.11 
section?)

So, I want to ask if there's some explanation for those tags missing or 
you simply forgot to push them when creating the releases (or they got 
somehow lost in the server).

Do you happen to have the tags locally and can push them? or otherwise 
generate the tags now and push them. I can also do it if you want, I'll 
push tags on the commits from the list I wrote above.

BTW, in case you run into a Make error while building current master, it 
may be fixed here:
https://gerrit.osmocom.org/c/osmo-pcap/+/14666

Regards,
Pau

-- 
- Pau Espin Pedrol <pespin at 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


From holger at freyther.de  Thu Jul  4 10:55:04 2019
From: holger at freyther.de (Holger Freyther)
Date: Thu, 4 Jul 2019 18:55:04 +0800
Subject: Missing git tags in osmo-pcap
In-Reply-To: <ec0a88dd-638a-8926-3a2e-231d10b8b45b@sysmocom.de>
References: <ec0a88dd-638a-8926-3a2e-231d10b8b45b@sysmocom.de>
Message-ID: <2A7B02D3-9E28-42A4-9869-760EB5CBBB9E@freyther.de>



> On 4. Jul 2019, at 01:41, Pau Espin Pedrol <pespin at sysmocom.de> wrote:
> 
> Hi Holger,
> 

> So, I want to ask if there's some explanation for those tags missing or you simply forgot to push them when creating the releases (or they got somehow lost in the server).
> 
> Do you happen to have the tags locally and can push them? or otherwise generate the tags now and push them. I can also do it if you want, I'll push tags on the commits from the list I wrote above.

I don't have them locally either. Feel free to add them retro-actively.

holger

From pespin at sysmocom.de  Fri Jul  5 11:06:00 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 5 Jul 2019 13:06:00 +0200
Subject: Missing git tags in osmo-pcap
In-Reply-To: <2A7B02D3-9E28-42A4-9869-760EB5CBBB9E@freyther.de>
References: <ec0a88dd-638a-8926-3a2e-231d10b8b45b@sysmocom.de>
 <2A7B02D3-9E28-42A4-9869-760EB5CBBB9E@freyther.de>
Message-ID: <00864d84-b01b-7dea-2dc3-0a7988d28ee2@sysmocom.de>


On 7/4/19 12:55 PM, Holger Freyther wrote:
> I don't have them locally either. Feel free to add them retro-actively.


Done, I pushed tags 0.0.7 .. 0.0.11, and submitted a new release 0.1.0 
to gerrit.

https://gerrit.osmocom.org/c/osmo-pcap/+/14677



-- 
- Pau Espin Pedrol <pespin at 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


From holger at freyther.de  Sun Jul  7 11:57:04 2019
From: holger at freyther.de (Holger Freyther)
Date: Sun, 7 Jul 2019 19:57:04 +0800
Subject: Missing git tags in osmo-pcap
In-Reply-To: <00864d84-b01b-7dea-2dc3-0a7988d28ee2@sysmocom.de>
References: <ec0a88dd-638a-8926-3a2e-231d10b8b45b@sysmocom.de>
 <2A7B02D3-9E28-42A4-9869-760EB5CBBB9E@freyther.de>
 <00864d84-b01b-7dea-2dc3-0a7988d28ee2@sysmocom.de>
Message-ID: <009AB382-3EEF-45F6-ACD2-16E37E19BABC@freyther.de>


> On 5. Jul 2019, at 19:06, Pau Espin Pedrol <pespin at sysmocom.de> wrote:
> 
> 
> On 7/4/19 12:55 PM, Holger Freyther wrote:
>> I don't have them locally either. Feel free to add them retro-actively.
> 
> 
> Done, I pushed tags 0.0.7 .. 0.0.11, and submitted a new release 0.1.0 to gerrit.
> 
> https://gerrit.osmocom.org/c/osmo-pcap/+/14677


Thank you. The addition of IPIP is nice.

holger

From laforge at gnumonks.org  Tue Jul  9 11:50:26 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 9 Jul 2019 19:50:26 +0800
Subject: License for our test suites
Message-ID: <20190709115026.GA3429@nataraja>

Dear Osmocom community,

during recent years we have developed a quite extensive set of test suites
for virtually all interfaces on all protocol levels of our 2G stack, and
recently even extended at least with some 3G IuCS coverage.

Those test suites are considerably valuable for testing any kind of
implementation of 2G / 3G network elements, even beyond Osmocom.  I'm a
bit worried that they might be used to test proprietary implementations,
which would bring no value to growing FOSS in mobile communications.
Whether we license the test suites under GPL or AGPL doesn't actually
change much here: Imagine "EvilCorp" developing a BSC, using our test
suites against it.  They neither distribute the test suite, nor do they
provide "access over a network" to it, an hence they could keep any
modifications/extensions/derivatives private without having to
contribute those back.

I think this is problematic.  We develop those test suites because we
care about having well-tested FOSS in cellular communications, whether
Osmocom or other FOSS projects.  I certainly don't want to spend my
spare time, or invest sysmocom resources towards improving the test
coverage of any non-FOSS implementations.  If such users are out there,
they should at the very least contribute to the development effort in
one way (code) or another (funding).

For 2G/3G, I think this discussion is quite theoretical, as there is
unlikely anyone else implementing those old technologies in proprietary
systems - Osmocom is probably typically the latest player in the market
to do so.

However, as I'm currently working on a first set of TTCN3 tests for
testing a LTE MME (initially attacing to S1 and SGs), I'm wondering if
we should continue to release related code under traditional copyleft
licenses.

One idea would be to have a license that permits the use of the test
suites to test only FOSS software.  In theory, that would mean that all
projects we care about (such as currently srsLTE, nextepc, OAI EPC, ...)
could use the test suites to test their software.   On the other hand,
if some vendor of proprietary MME/EPC software would want to [legally]
use the tests, they would need to obtain a different (paid) license to
the test suite.  Of course they could simply ignore the license and we'd
have little chance to learn about it - but I would argue most proper
companies typically would obtain a license if they used some software
they knew they had to license.

This is a very double-edged sword.  Drafting such a new license would
cause license proliferation, which is always bad.  It also raises
quesetions of license compatibility with e.g. some of our common
existing 'library' code that would need to be investigated.  Finally, it
also means that we'd no longer be writing "free software" nor "open
source", as the respective relevant definitions always require "non
discriminatory use for any purpose", which would no longer be the case
here.

This is currently an early stage brainstorming.  Now is the right point
in time to talk about this, before we release any LTE/EPC related tests.

Let me know if you have any thoughts to share.  While I'm cross-posting
this to openbsc@ and nextepc@ lists, pleaes follow-up-to
openbsc at lists.osmocom.org, as that's the main Osmocom mailing list and
we don't have any specifically only for the test suites.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From osmith at sysmocom.de  Wed Jul 10 07:45:17 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Wed, 10 Jul 2019 09:45:17 +0200
Subject: Enable gsmtap logging for TTCN3 testsuites?
In-Reply-To: <2604c254-3b7b-f115-2705-3dbbd1c71412@sysmocom.de>
References: <2604c254-3b7b-f115-2705-3dbbd1c71412@sysmocom.de>
Message-ID: <e8d299da-9f0a-a874-6f70-29a4201fe981@sysmocom.de>

I have also brought this up in a recent meeting. Besides me, at least
Eric was in favor of introducing this change, and nobody was strictly
against it. Pau said, that he prefers to have no GSMTAP logs in the
pcaps, but it would be fine for him to filter them out.

Due the lack of replies on this thread, I went ahead and submitted a
patch: https://gerrit.osmocom.org/c/docker-playground/+/14712

Regards,
Oliver

On 6/24/19 9:19 AM, Oliver Smith wrote:
> Dear ML,
> 
> I'm wondering why we do not have gsmtap logging enabled for TTCN3
> testsuites, and if there are any reasons against doing that.
> 
> Personally I find it very useful to have gsmtap logs in pcap files,
> because then then there is no need to manually match the timestamps of
> the log file and interesting parts of the pcap dump.
> 
> Especially in the TTCN3 testsuites, where we generate a separate pcap
> file for each test, but have one big log file of the SUT (e.g. osmo-hlr)
> for the entire testsuite run.
> 
> Thoughts?
> 
> Thanks,
> Oliver
> 

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From stsp at stsp.name  Wed Jul 10 08:54:27 2019
From: stsp at stsp.name (Stefan Sperling)
Date: Wed, 10 Jul 2019 10:54:27 +0200
Subject: License for our test suites
In-Reply-To: <20190709115026.GA3429@nataraja>
References: <20190709115026.GA3429@nataraja>
Message-ID: <20190710085426.GF94250@ted.stsp.name>

On Tue, Jul 09, 2019 at 07:50:26PM +0800, Harald Welte wrote:
> We develop those test suites because we
> care about having well-tested FOSS in cellular communications, whether
> Osmocom or other FOSS projects.  I certainly don't want to spend my
> spare time, or invest sysmocom resources towards improving the test
> coverage of any non-FOSS implementations.  If such users are out there,
> they should at the very least contribute to the development effort in
> one way (code) or another (funding).

I understand your concern. But FOSS often ends up being used in places
and ways which the original authors of the software don't endorse for
moral or ethical reasons. This problem exists for all FOSS projects in
some form or another. There could be some useful "prior art"; have you
already looked for similar discussions elsewhere?

> Finally, it
> also means that we'd no longer be writing "free software" nor "open
> source", as the respective relevant definitions always require "non
> discriminatory use for any purpose", which would no longer be the case
> here.

Indeed. The best way to limit downstream consumers to a subset of "everyone"
would be a proprietary licence. I don't think Osmocom should adopt one.

The usual approach would be to accept the risks of inadvertently helping
proprietary competitors, stick to a well-known FOSS licence, and hope that
the benefits outweigh the risks in the long term.


From laforge at gnumonks.org  Wed Jul 10 11:47:59 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 10 Jul 2019 19:47:59 +0800
Subject: License for our test suites
In-Reply-To: <20190710085426.GF94250@ted.stsp.name>
References: <20190709115026.GA3429@nataraja>
 <20190710085426.GF94250@ted.stsp.name>
Message-ID: <20190710114759.GJ3429@nataraja>

Hi Stefan,

On Wed, Jul 10, 2019 at 10:54:27AM +0200, Stefan Sperling wrote:
> On Tue, Jul 09, 2019 at 07:50:26PM +0800, Harald Welte wrote:
> > We develop those test suites because we
> > care about having well-tested FOSS in cellular communications, whether
> > Osmocom or other FOSS projects.  I certainly don't want to spend my
> > spare time, or invest sysmocom resources towards improving the test
> > coverage of any non-FOSS implementations.  If such users are out there,
> > they should at the very least contribute to the development effort in
> > one way (code) or another (funding).
> 
> I understand your concern. But FOSS often ends up being used in places
> and ways which the original authors of the software don't endorse for
> moral or ethical reasons. This problem exists for all FOSS projects in
> some form or another. 

I agree. However, I still think that a test suite for "protocol/spec
conformance" to an industry standard is something different here.

1) the test suite is not the main "product" of Osmocom, but it is merely
   a tool to test our FOSS software.  Most projects don't face the
   problem that way, as most unit tests or other tests invariably cover
   very specific aspects of their software (APIs, data structures,
   custom interfaces of any sort), and hence the usefulness of those
   tests beyond the project is very limited.

2) I believe the fundamental reason why there's a lack of published test
   suites for most protocol specs out there is that all respective
   developing companies/entities keep them private.  There are even
   examples of companies developing [dual licensed] FOSS software but
   keeping the test suites private.  The only examples that come to mind
   in the cellular sphere are the ETSI conformance test suites published
   in TTCN-3, but mostly in a format that cannot be consumed directly by
   TITAN (or any other TTCN3 compiler/runtime) as larte parts about
   interfacing the test system are left for the user to implement. And
   they have restrictive/unclear licenses. But even outside the 3GPP
   world, I think there aren't many [FOSS] conformance/compliance tests out
   there for protocols.  I don't recall having seen any of those for
   the many protocols I worked with in the past, e.g.
   FTP/SMTP/POP3/IMAP/NNTP/PPTP - so the IETF world doesn't appear to be
   much different.

> There could be some useful "prior art"; have you
> already looked for similar discussions elsewhere?

I'm not aware of a discussion specifically for protocol
functional/conformance testing.  There are of course the various
discussions about licenses in the "cloud world" where even AGPL is
deemed insufficient by some entities.  I don't like that development in
general, as

a) those entities call their software still 'open source' when it should
   instead be 'source available'
b) the licenses are for the actual 'product' and not for a test suite
   around that product

> > Finally, it also means that we'd no longer be writing "free
> > software" nor "open source", as the respective relevant definitions
> > always require "non discriminatory use for any purpose", which would
> > no longer be the case here.
> 
> Indeed. The best way to limit downstream consumers to a subset of "everyone"
> would be a proprietary licence. I don't think Osmocom should adopt one.

Certainly I would never propose to use a non-FOSS license for the actual
Osmocom software, i.e. the 3GPP protocol and functional elements
implementations we're working on.  Osmocom *is* about open source
cellular implementations, and nothing else.

But I think for test suites it is something worth a debate.  I actually
started to have related thoughts already about osmo-gsm-tester and the
existing TTCN-3 test suites.  Those kind of test suites are rarely ever
executed by a user.  So it isn't relevant to the freedom of the end user
(typically a small commercial or non-commercial operator) if the actual
test suites are FOSS or not.  Availability of the test suites matters
most to developers, and I would argue that it mostly is about 'source
available', and not about 'open source'.

> The usual approach would be to accept the risks of inadvertently helping
> proprietary competitors, stick to a well-known FOSS licence, and hope that
> the benefits outweigh the risks in the long term.

Osmocom is a small speckle of dust in the world of cellular
communications, while virtually everyone, even the very smallest
proprietary player has more significance in terms of market adoption
as well as 'revenue' surrounding the project/product compared to
proprietary vendors.  (I'm talking about 'pure' proprietary vendors
here, not the likes of Range Networks, SRS, ...)

We're working on a seemingly insurmountable task in terms of both breadth
(all network elements of from PHY to CN in 2G/2.5/2.75G, CN for 3G/3.5G,
and now 4G) as well as complexity of the related technology, with
incredibly limited resources and a surprisingly small team.  We have to
make sure that the result of our work counts, and that those limited
resources are invested very wisely.

The amount of contributions outside of the relatively small and dedicated
community of developers and users has been small (but existant!) for the
actual Osmocom CNI programs, particularly in recent years.  But looking
at the osmo-ttcn3-hacks repository, I cannot find a single commit in the
tree that was not written either by somebody on sysmocom payroll or by
Vadim (yay! thanks!).

Meanwhile, the business model of the tradiditonal cellular industry is
very much anti-FOSS, if not only due to the fact that a (if not the)
largest revenue comes from licensing "essential patents" on what is
written in the 3GPP specs.  So I would not expect any significant change
in terms of contributions to related projects from the traditional
proprietary industry even in the forseeable future.

In the end, I think that proprietary vendors interested in the test
suites would actually not have a problem licensinge it under
proprietary/commercial terms - this is their normal business
irrespective of where they source that testsuite from.  Any related
resources help us to co-fund the development of the tests - and
FOSS projects can still use them.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From keith at rhizomatica.org  Wed Jul 10 12:48:27 2019
From: keith at rhizomatica.org (Keith)
Date: Wed, 10 Jul 2019 14:48:27 +0200
Subject: License for our test suites
In-Reply-To: <20190710114759.GJ3429@nataraja>
References: <20190709115026.GA3429@nataraja>
 <20190710085426.GF94250@ted.stsp.name> <20190710114759.GJ3429@nataraja>
Message-ID: <3333b882-d582-497e-cfa1-ee6925eb23cf@rhizomatica.org>

Hi Harald, Stefan.

I'd just chime in here to say that this is something I've been thinking
about recently and trying to discuss when I get a chance.

The topic of said discussion is whether the time may have come to revise
the FOSS "ethic";

Is there just too much "evilcorp" out there now to justify continuing to
hand them our labour on a plate? - A reference I sometimes use here is
the linux kernel as a base for a certain "evil" surplus collecting and
behaviour modifying robot that was first hawked to the world as a
"liberating" "open-source" project.

Once it had it's evil robot paw on our hearts and minds and those of our
children, it somehow felt the need to become somewhat less open. While I
myself have never added a single line of code or even submitted a bug
report on the linux kernel, I think I would feel somewhat strange about
the above if I had.

Of course, one could point to a lot of projects that retroactively
benefit from open development communities and developers in the pay of
some evilcorp or other have indeed contributed a lot of FOSS!

Still, evilcorp will work in evilcorp's interests and nobody else's.
Yes, there's a type mismatch in that sentence, ( type corp cannot be
compared with type person ), but the point is that as long as FOSS is
good for corp, corp will support it, but corp is getting VERY big these
days and so the days for FOSS (or maybe I should say FOSS that is not in
corp's interest) might be numbered.

So for what it's worth, in principal I'm with Harald, especially given
that I recognise that if I am to continue development on osmocom, I need
to start contributing to the test suites!

I have NO IDEA about the actual licensing issues or what the eventual
license would/should look like. Luckily there are people around here who
are quite expert in that field.

K.





From laforge at gnumonks.org  Thu Jul 11 01:54:51 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 11 Jul 2019 09:54:51 +0800
Subject: TITAN just gained basic CSN.1 support!
Message-ID: <20190711015450.GO3429@nataraja>

Dear all,

I'm very happy to have received the below attached news via the Eclipse
bugzilla.

This is great, as it permits us to have "real" SI rest octet as well as
RLC/MAC support in our TTCN3 test suites while still using declarative
RAW codec syntax.

Just to be clear there's no misunderstanding: This doesn't mean that
CSN.1 syntax can be parsed by TITAN.  It just means that we can use RAW
codec annotations to describe something that matches the CSN.1 encoding.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
An embedded message was scrubbed...
From: bugzilla-daemon at eclipse.org
Subject: [Bug 548969] CSN.1 L/H in the RAW codec
Date: Wed, 10 Jul 2019 15:38:38 +0000
Size: 3517
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190711/7b7b2132/attachment.eml>

From acetcom at gmail.com  Thu Jul 11 15:14:51 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Fri, 12 Jul 2019 00:14:51 +0900
Subject: CS Fallback in NextEPC
Message-ID: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>

Dear Osmocom & NextEPC Community,

Today I've added CS Fallback and released NextEPC v0.5.0

So, I'd just like to test this part with Osmocom project, but it seems to
be a difficult task. The reason is why I have little knowledge about 2G/3G.
Nevertheless, I will try to do it

BTW, I don't know if there is anyone who wants to integrate this big thing.
Even though I'm not sure if this will help, but let me introduce the
configuration of the NextEPC.

To use SGsAP, change the mme.conf as follows:

#
#  <sgsap>
#
#  o Single MSC/VLR
#    sgsap:
#      addr: 127.0.0.2
#      plmn_id:
#        mcc: 001
#        mnc: 01
#      tac: 4130
#      lac: 43690
#
#  o Multiple MSC/VLR
#    sgsap:
#      - addr: 127.0.0.2
#        plmn_id:
#          mcc: 001
#          mnc: 01
#        tac: 4131
#        lac: 43692
#      - addr
#         - 127.0.0.3
#         - fe80::2%lo0
#        plmn_id:
#          mcc: 001
#          mnc: 01
#        tac: 4132
#        lac: 43692
#      - name: msc.open5gs.org
#        plmn_id:
#          mcc: 001
#          mnc: 01
#        tac: 4133
#        lac: 43693
#

FYI, I also attach the pcap that I run with nextepc simulator as below.

$ ./tests/testcsfb
mo-idle-test        : SUCCESS
mt-idle-test        : SUCCESS
mo-active-test      : SUCCESS
mt-active-test      : SUCCESS
All tests passed.

Feel free to raise any questions about this things.

Best Regards,
    Sukchan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190712/ace18aeb/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nextepc_csfb.pcapng
Type: application/octet-stream
Size: 57524 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190712/ace18aeb/attachment.obj>

From laforge at gnumonks.org  Thu Jul 11 16:47:09 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 12 Jul 2019 00:47:09 +0800
Subject: CS Fallback in NextEPC
In-Reply-To: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
Message-ID: <20190711164709.GI3429@nataraja>

Hi Sukchan,

On Fri, Jul 12, 2019 at 12:14:51AM +0900, Sukchan Lee wrote:
> Today I've added CS Fallback and released NextEPC v0.5.0

Thanks a lot!

> So, I'd just like to test this part with Osmocom project, but it seems to
> be a difficult task. The reason is why I have little knowledge about 2G/3G.
> Nevertheless, I will try to do it

I advise you to not spend too much time on it until we can provide you
with a set of configuration and instructions on how to configure this,
instead of spending a lot of time in trial and error.  I think we can
save you some time there.

A good starting point would be to use the nightly builds for Ubuntu or Debian,
(see https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds)
and try to follow the general instructions of https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box.  The goal would be to create a network with two phones/IMSIs
where you can have a 2G-to-2G voice call first.   Only once that works, the
LTE neighbor cell information and SGs configuration can be added.

You will need the following parts for a minimal 2G setup:

* osmo-trx + osmo-bts-trx (if using SDR like B2x0)
* osmo-bsc (RR)
* osmo-msc (MM + CC)
* osmo-hlr
* osmo-stp (for SS7/SIGTRAN between BSC and MSC)
* osmo-mgw (for RTP audio streams; one instance can be shared between BSC and MSC)

All of the above can run on a single machine

> BTW, I don't know if there is anyone who wants to integrate this big thing.

For sure we want to, and we also know there are users out there who want to.

> Even though I'm not sure if this will help, but let me introduce the
> configuration of the NextEPC.

Thanks, this is useful.  We'll try to to set this up accordingly, but it may
take some time.

Philipp (Cc) has been developing most of the SGs interface on the Osmocom
side, he can help you (here on this list and by direct e-mail) with any related
issues.

> FYI, I also attach the pcap that I run with nextepc simulator as below.

Thanks, I'd like to ask Philipp to review this and report if it reflects his
expectations about the SGs interface procedures.

btw/unrelated: I've been hacking a lot on TTCN-3 tests for the MME, and
I've managed to get the way into NAS (EMM/ESM) and am getting all the
way up to a Attach Reject (see attached pcap).  As I'm only simulating
S1AP and SGsAP so far (and not diameter), it's expected that the attach
will be rejected.  I guess I'll start with using nextepc-hss first, and
add diameter support to the tests only in a later step.

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From rafael at rhizomatica.org  Thu Jul 11 20:16:41 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Thu, 11 Jul 2019 17:16:41 -0300
Subject: CS Fallback in NextEPC
In-Reply-To: <20190711164709.GI3429@nataraja>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <20190711164709.GI3429@nataraja>
Message-ID: <0ebcdcb0-29cc-6e15-9e67-dd4ef90e7827@rhizomatica.org>

Rhizomatica is very much interested in testing such setup with CS voice
fallback for LTE to GSM.

Cheers!
Rafael Diniz

On 7/11/19 1:47 PM, Harald Welte wrote:
> Hi Sukchan,
> 
> On Fri, Jul 12, 2019 at 12:14:51AM +0900, Sukchan Lee wrote:
>> Today I've added CS Fallback and released NextEPC v0.5.0
> 
> Thanks a lot!
> 
>> So, I'd just like to test this part with Osmocom project, but it seems to
>> be a difficult task. The reason is why I have little knowledge about 2G/3G.
>> Nevertheless, I will try to do it
> 
> I advise you to not spend too much time on it until we can provide you
> with a set of configuration and instructions on how to configure this,
> instead of spending a lot of time in trial and error.  I think we can
> save you some time there.
> 
> A good starting point would be to use the nightly builds for Ubuntu or Debian,
> (see https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds)
> and try to follow the general instructions of https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box.  The goal would be to create a network with two phones/IMSIs
> where you can have a 2G-to-2G voice call first.   Only once that works, the
> LTE neighbor cell information and SGs configuration can be added.
> 
> You will need the following parts for a minimal 2G setup:
> 
> * osmo-trx + osmo-bts-trx (if using SDR like B2x0)
> * osmo-bsc (RR)
> * osmo-msc (MM + CC)
> * osmo-hlr
> * osmo-stp (for SS7/SIGTRAN between BSC and MSC)
> * osmo-mgw (for RTP audio streams; one instance can be shared between BSC and MSC)
> 
> All of the above can run on a single machine
> 
>> BTW, I don't know if there is anyone who wants to integrate this big thing.
> 
> For sure we want to, and we also know there are users out there who want to.
> 
>> Even though I'm not sure if this will help, but let me introduce the
>> configuration of the NextEPC.
> 
> Thanks, this is useful.  We'll try to to set this up accordingly, but it may
> take some time.
> 
> Philipp (Cc) has been developing most of the SGs interface on the Osmocom
> side, he can help you (here on this list and by direct e-mail) with any related
> issues.
> 
>> FYI, I also attach the pcap that I run with nextepc simulator as below.
> 
> Thanks, I'd like to ask Philipp to review this and report if it reflects his
> expectations about the SGs interface procedures.
> 
> btw/unrelated: I've been hacking a lot on TTCN-3 tests for the MME, and
> I've managed to get the way into NAS (EMM/ESM) and am getting all the
> way up to a Attach Reject (see attached pcap).  As I'm only simulating
> S1AP and SGsAP so far (and not diameter), it's expected that the attach
> will be rejected.  I guess I'll start with using nextepc-hss first, and
> add diameter support to the tests only in a later step.
> 
> Regards,
> 	Harald
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190711/f44f31ab/attachment.bin>

From acetcom at gmail.com  Thu Jul 11 22:19:35 2019
From: acetcom at gmail.com (=?utf-8?B?7J207ISd7LCs?=)
Date: Fri, 12 Jul 2019 07:19:35 +0900
Subject: CS Fallback in NextEPC
In-Reply-To: <20190711164709.GI3429@nataraja>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <20190711164709.GI3429@nataraja>
Message-ID: <C75E84A2-F127-427A-92B2-08BDEAACEE20@gmail.com>

Hi Harald,

There is no pcap file. Could you attach it?
Thanks!

Best Regards,
    Sukchan


2019. 7. 12. ?? 1:47, Harald Welte <laforge at gnumonks.org> ??:

> Hi Sukchan,
> 
>> On Fri, Jul 12, 2019 at 12:14:51AM +0900, Sukchan Lee wrote:
>> Today I've added CS Fallback and released NextEPC v0.5.0
> 
> Thanks a lot!
> 
>> So, I'd just like to test this part with Osmocom project, but it seems to
>> be a difficult task. The reason is why I have little knowledge about 2G/3G.
>> Nevertheless, I will try to do it
> 
> I advise you to not spend too much time on it until we can provide you
> with a set of configuration and instructions on how to configure this,
> instead of spending a lot of time in trial and error.  I think we can
> save you some time there.
> 
> A good starting point would be to use the nightly builds for Ubuntu or Debian,
> (see https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds)
> and try to follow the general instructions of https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box.  The goal would be to create a network with two phones/IMSIs
> where you can have a 2G-to-2G voice call first.   Only once that works, the
> LTE neighbor cell information and SGs configuration can be added.
> 
> You will need the following parts for a minimal 2G setup:
> 
> * osmo-trx + osmo-bts-trx (if using SDR like B2x0)
> * osmo-bsc (RR)
> * osmo-msc (MM + CC)
> * osmo-hlr
> * osmo-stp (for SS7/SIGTRAN between BSC and MSC)
> * osmo-mgw (for RTP audio streams; one instance can be shared between BSC and MSC)
> 
> All of the above can run on a single machine
> 
>> BTW, I don't know if there is anyone who wants to integrate this big thing.
> 
> For sure we want to, and we also know there are users out there who want to.
> 
>> Even though I'm not sure if this will help, but let me introduce the
>> configuration of the NextEPC.
> 
> Thanks, this is useful.  We'll try to to set this up accordingly, but it may
> take some time.
> 
> Philipp (Cc) has been developing most of the SGs interface on the Osmocom
> side, he can help you (here on this list and by direct e-mail) with any related
> issues.
> 
>> FYI, I also attach the pcap that I run with nextepc simulator as below.
> 
> Thanks, I'd like to ask Philipp to review this and report if it reflects his
> expectations about the SGs interface procedures.
> 
> btw/unrelated: I've been hacking a lot on TTCN-3 tests for the MME, and
> I've managed to get the way into NAS (EMM/ESM) and am getting all the
> way up to a Attach Reject (see attached pcap).  As I'm only simulating
> S1AP and SGsAP so far (and not diameter), it's expected that the attach
> will be rejected.  I guess I'll start with using nextepc-hss first, and
> add diameter support to the tests only in a later step.
> 
> Regards,
>    Harald
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Fri Jul 12 09:32:27 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 12 Jul 2019 17:32:27 +0800
Subject: SNOW-3G / ZUC implementation under FOSS license?
Message-ID: <20190712093227.GU3429@nataraja>

Hi!

I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for
NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME.

However, it seems there is no real FOSS implementation of the SNOW-3G algoritm
around?  All I could find was:

* https://github.com/mitshell/CryptoMobile with unclear source of the code,
  without a copyright statement or license annotation

* https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main.c
  without a copyright statement or license annotation

* https://github.com/Jadson27101/SNOW_3G in go,
  without a copyright statement or license annotation

* https://github.com/KsirbJ/SNOW-3G
  without a copyright statement or license annotation

* https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c
  without a copyright statement or license annotation. Looks rather similar
  to CryptoMobile.  Possible just copy+pasted from ETSI reference implementation?

* https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc
  also contains no coypright statement or license, but might be construed
  to be AGPLv3 like all of srsLTE.  However, it states it is "adapted"
  from ETSI/SAGE specifications.  Does that mean it is an independent
  implementation of the algorithm by just reading the specs, or does it
  contain actual ETSI-copyrighted code?

It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement)
don't contain any actual information but all just point to the ETSI SAGE specification
which can be found (at the very least) here:
https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf
and interestingly doesn't contain any copyright statement whatsoever.

This discussion is not about any potentially 'essential patents' that may or may
not apply in some jurisdictions on the algorithm itself.  I'm currently only interested
in a "clean copyright" implementation of any of the EIA/EEA implementations used
on the LTE NAS layer.

I'd appreciate any useful comments. Thanks!

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From rafael at rhizomatica.org  Fri Jul 12 13:26:04 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Fri, 12 Jul 2019 10:26:04 -0300
Subject: Sample configs for reproducing osmo-nitb behaviour with the split
 stack
Message-ID: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>

Hi all,
Today I'm working on updating my NuRAN unit with the new osmo stack in
order to try to reproduce the same behavior of old osmo-nitb we use in
production in Rhizomatica (with subscriber_create_on_demand feature on).

I'm writing just in case someone already put online a set of config
files with the parameters needed by such behavior set?
; )

ps: I have the new splip stack working fine here, I just need to modify
my setup with new features to support subscriber_create_on_demand.

Best regards,
Rafael Diniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190712/d7c6a206/attachment.bin>

From domi at tomcsanyi.net  Fri Jul 12 13:54:37 2019
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Fri, 12 Jul 2019 15:54:37 +0200 (CEST)
Subject: SNOW-3G / ZUC implementation under FOSS license?
In-Reply-To: <20190712093227.GU3429@nataraja>
References: <20190712093227.GU3429@nataraja>
Message-ID: <392D91FA-6C25-4E66-AD0A-2EBD94BA0C71@tomcsanyi.net>

Hi Harald!

CryptoMobile was created by Benoit Michau, so I added him in Cc, maybe he could clarify the license situation.

Encryption support for srsLTE was, I think, mainly worked on by David Rupprecht, whom I also added in Cc.

I hope these people are going to be able to help you.

Kind regards,
Domi

2019. j?l. 12. d?tummal, 11:32 id?pontban Harald Welte <laforge at gnumonks.org> ?rta:

> Hi!
> 
> I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for
> NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME.
> 
> However, it seems there is no real FOSS implementation of the SNOW-3G algoritm
> around?  All I could find was:
> 
> * https://github.com/mitshell/CryptoMobile with unclear source of the code,
>  without a copyright statement or license annotation
> 
> * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main.c
>  without a copyright statement or license annotation
> 
> * https://github.com/Jadson27101/SNOW_3G in go,
>  without a copyright statement or license annotation
> 
> * https://github.com/KsirbJ/SNOW-3G
>  without a copyright statement or license annotation
> 
> * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c
>  without a copyright statement or license annotation. Looks rather similar
>  to CryptoMobile.  Possible just copy+pasted from ETSI reference implementation?
> 
> * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc
>  also contains no coypright statement or license, but might be construed
>  to be AGPLv3 like all of srsLTE.  However, it states it is "adapted"
>  from ETSI/SAGE specifications.  Does that mean it is an independent
>  implementation of the algorithm by just reading the specs, or does it
>  contain actual ETSI-copyrighted code?
> 
> It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement)
> don't contain any actual information but all just point to the ETSI SAGE specification
> which can be found (at the very least) here:
> https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf
> and interestingly doesn't contain any copyright statement whatsoever.
> 
> This discussion is not about any potentially 'essential patents' that may or may
> not apply in some jurisdictions on the algorithm itself.  I'm currently only interested
> in a "clean copyright" implementation of any of the EIA/EEA implementations used
> on the LTE NAS layer.
> 
> I'd appreciate any useful comments. Thanks!
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)

From admin at manateeshome.com  Fri Jul 12 17:07:00 2019
From: admin at manateeshome.com (Pierre Kim)
Date: Sat, 13 Jul 2019 02:07:00 +0900
Subject: CS Fallback in NextEPC
In-Reply-To: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
Message-ID: <7a5d191f-8704-2f50-1708-fa30dc4f21b2@manateeshome.com>

Hello,

Thanks for keeping up the great work.

If you are based in Korea I could provide some support with setting up
Osmocom based 2G/3G network.

Feel free to hit me up.


Regards,

Pierre

On 2019-07-12 ?? 12:14, Sukchan Lee wrote:
> Dear Osmocom & NextEPC Community,
>
> Today I've added CS Fallback and released NextEPC v0.5.0
>
> So, I'd just like to test this part with Osmocom project, but it seems
> to be a difficult task. The reason is why I have little knowledge
> about 2G/3G. Nevertheless, I will try to do it
>
> BTW, I don't know if there is anyone who wants to integrate this big
> thing.
> Even though I'm not sure if this will help, but let me introduce the
> configuration of the NextEPC.
>
> To use SGsAP, change the mme.conf as follows:
>
> #
> # ?<sgsap>
> #
> # ?o Single MSC/VLR
> # ? ?sgsap:
> # ? ? ?addr: 127.0.0.2
> # ? ? ?plmn_id:
> # ? ? ? ?mcc: 001
> # ? ? ? ?mnc: 01
> # ? ? ?tac: 4130
> # ? ? ?lac: 43690
> #
> # ?o Multiple MSC/VLR
> # ? ?sgsap:
> # ? ? ?- addr: 127.0.0.2
> # ? ? ? ?plmn_id:
> # ? ? ? ? ?mcc: 001
> # ? ? ? ? ?mnc: 01
> # ? ? ? ?tac: 4131
> # ? ? ? ?lac: 43692
> # ? ? ?- addr
> # ? ? ? ? - 127.0.0.3
> # ? ? ? ? - fe80::2%lo0
> # ? ? ? ?plmn_id:
> # ? ? ? ? ?mcc: 001
> # ? ? ? ? ?mnc: 01
> # ? ? ? ?tac: 4132
> # ? ? ? ?lac: 43692
> # ? ? ?- name: msc.open5gs.org <http://msc.open5gs.org>
> # ? ? ? ?plmn_id:
> # ? ? ? ? ?mcc: 001
> # ? ? ? ? ?mnc: 01
> # ? ? ? ?tac: 4133
> # ? ? ? ?lac: 43693
> #
>
> FYI, I also attach the pcap that I run with nextepc simulator as below.
>
> $ ./tests/testcsfb
> mo-idle-test ? ? ? ?: SUCCESS
> mt-idle-test ? ? ? ?: SUCCESS
> mo-active-test ? ? ?: SUCCESS
> mt-active-test ? ? ?: SUCCESS
> All tests passed.
>
> Feel free to raise any questions about this things.
>
> Best Regards,
> ? ? Sukchan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190713/91a7f9d0/attachment.htm>

From acetcom at gmail.com  Sat Jul 13 01:32:34 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Sat, 13 Jul 2019 10:32:34 +0900
Subject: CS Fallback in NextEPC
In-Reply-To: <7a5d191f-8704-2f50-1708-fa30dc4f21b2@manateeshome.com>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <7a5d191f-8704-2f50-1708-fa30dc4f21b2@manateeshome.com>
Message-ID: <CAKoHG8AuqbNGqr7Va__35vYtPOda_ydYweO3+h=R3+QcyZep_A@mail.gmail.com>

Hi Pierre,

I'm so glad to meet Korean people here. I'm in Seoul, Korea
If I have some problem, I'll try to contact you.

And also, feel free to contact me If you have any question about nextepc or
other things,

Thanks a lot!

Best Regards,
    Sukchan

On Sat, Jul 13, 2019 at 3:09 AM Pierre Kim <admin at manateeshome.com> wrote:

> Hello,
>
> Thanks for keeping up the great work.
>
> If you are based in Korea I could provide some support with setting up
> Osmocom based 2G/3G network.
>
> Feel free to hit me up.
>
>
> Regards,
>
> Pierre
> On 2019-07-12 ?? 12:14, Sukchan Lee wrote:
>
> Dear Osmocom & NextEPC Community,
>
> Today I've added CS Fallback and released NextEPC v0.5.0
>
> So, I'd just like to test this part with Osmocom project, but it seems to
> be a difficult task. The reason is why I have little knowledge about 2G/3G.
> Nevertheless, I will try to do it
>
> BTW, I don't know if there is anyone who wants to integrate this big thing.
> Even though I'm not sure if this will help, but let me introduce the
> configuration of the NextEPC.
>
> To use SGsAP, change the mme.conf as follows:
>
> #
> #  <sgsap>
> #
> #  o Single MSC/VLR
> #    sgsap:
> #      addr: 127.0.0.2
> #      plmn_id:
> #        mcc: 001
> #        mnc: 01
> #      tac: 4130
> #      lac: 43690
> #
> #  o Multiple MSC/VLR
> #    sgsap:
> #      - addr: 127.0.0.2
> #        plmn_id:
> #          mcc: 001
> #          mnc: 01
> #        tac: 4131
> #        lac: 43692
> #      - addr
> #         - 127.0.0.3
> #         - fe80::2%lo0
> #        plmn_id:
> #          mcc: 001
> #          mnc: 01
> #        tac: 4132
> #        lac: 43692
> #      - name: msc.open5gs.org
> #        plmn_id:
> #          mcc: 001
> #          mnc: 01
> #        tac: 4133
> #        lac: 43693
> #
>
> FYI, I also attach the pcap that I run with nextepc simulator as below.
>
> $ ./tests/testcsfb
> mo-idle-test        : SUCCESS
> mt-idle-test        : SUCCESS
> mo-active-test      : SUCCESS
> mt-active-test      : SUCCESS
> All tests passed.
>
> Feel free to raise any questions about this things.
>
> Best Regards,
>     Sukchan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190713/1ac65a4e/attachment.htm>

From laforge at gnumonks.org  Sat Jul 13 01:42:03 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 13 Jul 2019 09:42:03 +0800
Subject: Sample configs for reproducing osmo-nitb behaviour with the
 split stack
In-Reply-To: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
Message-ID: <20190713014203.GX3429@nataraja>

Hi Rafael,

On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
> Today I'm working on updating my NuRAN unit with the new osmo stack 

Can you clarify which particular model/unit that is?

I would assume that the 'nightly' OE packages sysmocom provides should have
all related features.

> I'm writing just in case someone already put online a set of config
> files with the parameters needed by such behavior set?
> ; )

I would be careful with full configuration files, as they contain all kinds
of settings which may or may not do what you want.  The settings for
subcsriber-create-on-demand are only 2-3, AFAIR.

> ps: I have the new splip stack working fine here, I just need to modify
> my setup with new features to support subscriber_create_on_demand.

Then please simply use the config files you have and not start with
something else just because you need to modify one or very few lines...

See https://osmocom.org/issues/2542 where Oliver actually also points to
a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf

If yo have more specific questions, feel free to raise them here :)

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From rafael at rhizomatica.org  Sat Jul 13 15:55:28 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Sat, 13 Jul 2019 12:55:28 -0300
Subject: Sample configs for reproducing osmo-nitb behaviour with the split
 stack
In-Reply-To: <20190713014203.GX3429@nataraja>
References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
 <20190713014203.GX3429@nataraja>
Message-ID: <eedd5819-f7d0-3815-972a-a4c6c75cbb9d@rhizomatica.org>

Hi Harald,

> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
>> Today I'm working on updating my NuRAN unit with the new osmo stack 
> 
> Can you clarify which particular model/unit that is?
> 
> I would assume that the 'nightly' OE packages sysmocom provides should have
> all related features.

It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by
hand the BTS and PCU against LC 1.5 headers.

>> I'm writing just in case someone already put online a set of config
>> files with the parameters needed by such behavior set?
>> ; )
> 
> I would be careful with full configuration files, as they contain all kinds
> of settings which may or may not do what you want.  The settings for
> subcsriber-create-on-demand are only 2-3, AFAIR.
> 
>> ps: I have the new splip stack working fine here, I just need to modify
>> my setup with new features to support subscriber_create_on_demand.
> 
> Then please simply use the config files you have and not start with
> something else just because you need to modify one or very few lines...
> 
> See https://osmocom.org/issues/2542 where Oliver actually also points to
> a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
> 
> If yo have more specific questions, feel free to raise them here :)

Fine, I'll just adapt my config - Thanks!!

Cheers,
Rafael Diniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190713/11cd6b29/attachment.bin>

From osmith at sysmocom.de  Mon Jul 15 08:05:23 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Mon, 15 Jul 2019 10:05:23 +0200
Subject: Sample configs for reproducing osmo-nitb behaviour with the split
 stack
In-Reply-To: <eedd5819-f7d0-3815-972a-a4c6c75cbb9d@rhizomatica.org>
References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
 <20190713014203.GX3429@nataraja>
 <eedd5819-f7d0-3815-972a-a4c6c75cbb9d@rhizomatica.org>
Message-ID: <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de>

Hey Rafael,

On 7/13/19 5:55 PM, Rafael Diniz wrote:
> Hi Harald,
> 
>> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
>>> Today I'm working on updating my NuRAN unit with the new osmo stack 
>>
>> Can you clarify which particular model/unit that is?
>>
>> I would assume that the 'nightly' OE packages sysmocom provides should have
>> all related features.
> 
> It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by
> hand the BTS and PCU against LC 1.5 headers.
> 
>>> I'm writing just in case someone already put online a set of config
>>> files with the parameters needed by such behavior set?
>>> ; )
>>
>> I would be careful with full configuration files, as they contain all kinds
>> of settings which may or may not do what you want.  The settings for
>> subcsriber-create-on-demand are only 2-3, AFAIR.
>>
>>> ps: I have the new splip stack working fine here, I just need to modify
>>> my setup with new features to support subscriber_create_on_demand.
>>
>> Then please simply use the config files you have and not start with
>> something else just because you need to modify one or very few lines...
>>
>> See https://osmocom.org/issues/2542 where Oliver actually also points to
>> a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
>>
>> If yo have more specific questions, feel free to raise them here :)
> 
> Fine, I'll just adapt my config - Thanks!!

As Harald pointed out, the documentation could use some more examples.
I'll update the docs accordingly, but to make your life easier, here are
the configuration options relevant for your use case (with sending the
IMEI to the HLR).

osmo-msc.cfg:
msc
 check-imei early

osmo-hlr.cfg:
hlr
 subscriber-create-on-demand 5 none
 store-imei


This will create 5 digit MSISDNs for the subscribers, and disable CS NAM
and PS NAM by default (circuit switched and packet switched network
access modes). Subscribers can't make phone calls or use cellular data,
so their phones will not connect to the network, but the entry in the
HLR will be created.

After a new subscriber was created, it will look like this in the VTY
(I've replaced the real IMEI and IMSI with zeros):

OsmoHLR> enable
OsmoHLR# subscriber imei 00000000000000 show
    ID: 1
    IMSI: 000000000000000
    MSISDN: 58192           <- randomly generated
    IMEI: 000000000000000
    CS disabled
    PS disabled

The idea is now to enable CS and PS for the IMEIs that you know. Right
now, the documentation says:

> In order to do that, one can set the default NAM to none and manually
> approve new subscribers by enabling their nam_cs and nam_ps parameters
> (e.g. over the VTY).

But as I was about to create an example of how these commands look like,
I realized that VTY commands for changing nam_cs and nam_ps don't
actually exist yet :\ So for now, these flags have to be changed
manually in the sqlite database... change nam_cs and nam_ps to 1 in the
subscriber table. Maybe this is still useful for testing. I will add the
missing VTY commands shortly.

> 
> Cheers,
> Rafael Diniz
> 

Cheers,
Oliver

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From osmith at sysmocom.de  Mon Jul 15 08:08:10 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Mon, 15 Jul 2019 10:08:10 +0200
Subject: Sample configs for reproducing osmo-nitb behaviour with the split
 stack
In-Reply-To: <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de>
References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
 <20190713014203.GX3429@nataraja>
 <eedd5819-f7d0-3815-972a-a4c6c75cbb9d@rhizomatica.org>
 <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de>
Message-ID: <cce63ae1-20dd-a055-7d28-0ee80df98e4c@sysmocom.de>

"check-imei-rqd early", not "check-imei early"

On 7/15/19 10:05 AM, Oliver Smith wrote:
> Hey Rafael,
> 
> On 7/13/19 5:55 PM, Rafael Diniz wrote:
>> Hi Harald,
>>
>>> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
>>>> Today I'm working on updating my NuRAN unit with the new osmo stack 
>>>
>>> Can you clarify which particular model/unit that is?
>>>
>>> I would assume that the 'nightly' OE packages sysmocom provides should have
>>> all related features.
>>
>> It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by
>> hand the BTS and PCU against LC 1.5 headers.
>>
>>>> I'm writing just in case someone already put online a set of config
>>>> files with the parameters needed by such behavior set?
>>>> ; )
>>>
>>> I would be careful with full configuration files, as they contain all kinds
>>> of settings which may or may not do what you want.  The settings for
>>> subcsriber-create-on-demand are only 2-3, AFAIR.
>>>
>>>> ps: I have the new splip stack working fine here, I just need to modify
>>>> my setup with new features to support subscriber_create_on_demand.
>>>
>>> Then please simply use the config files you have and not start with
>>> something else just because you need to modify one or very few lines...
>>>
>>> See https://osmocom.org/issues/2542 where Oliver actually also points to
>>> a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
>>>
>>> If yo have more specific questions, feel free to raise them here :)
>>
>> Fine, I'll just adapt my config - Thanks!!
> 
> As Harald pointed out, the documentation could use some more examples.
> I'll update the docs accordingly, but to make your life easier, here are
> the configuration options relevant for your use case (with sending the
> IMEI to the HLR).
> 
> osmo-msc.cfg:
> msc
>  check-imei early
> 
> osmo-hlr.cfg:
> hlr
>  subscriber-create-on-demand 5 none
>  store-imei
> 
> 
> This will create 5 digit MSISDNs for the subscribers, and disable CS NAM
> and PS NAM by default (circuit switched and packet switched network
> access modes). Subscribers can't make phone calls or use cellular data,
> so their phones will not connect to the network, but the entry in the
> HLR will be created.
> 
> After a new subscriber was created, it will look like this in the VTY
> (I've replaced the real IMEI and IMSI with zeros):
> 
> OsmoHLR> enable
> OsmoHLR# subscriber imei 00000000000000 show
>     ID: 1
>     IMSI: 000000000000000
>     MSISDN: 58192           <- randomly generated
>     IMEI: 000000000000000
>     CS disabled
>     PS disabled
> 
> The idea is now to enable CS and PS for the IMEIs that you know. Right
> now, the documentation says:
> 
>> In order to do that, one can set the default NAM to none and manually
>> approve new subscribers by enabling their nam_cs and nam_ps parameters
>> (e.g. over the VTY).
> 
> But as I was about to create an example of how these commands look like,
> I realized that VTY commands for changing nam_cs and nam_ps don't
> actually exist yet :\ So for now, these flags have to be changed
> manually in the sqlite database... change nam_cs and nam_ps to 1 in the
> subscriber table. Maybe this is still useful for testing. I will add the
> missing VTY commands shortly.
> 
>>
>> Cheers,
>> Rafael Diniz
>>
> 
> Cheers,
> Oliver
> 

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From paul at softwareradiosystems.com  Mon Jul 15 11:58:08 2019
From: paul at softwareradiosystems.com (Paul Sutton)
Date: Mon, 15 Jul 2019 12:58:08 +0100
Subject: SNOW-3G / ZUC implementation under FOSS license?
Message-ID: <796d2296-36e9-daa1-ddc4-f10f35f778e5@softwareradiosystems.com>

Hi Harald,

The srsLTE implementation is taken from the ETSI specs simulation program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf
https://www.etsi.org/intellectual-property-rights#mytoc3 and https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the copyright licensing details for software incorporated in ETSI standards however I have not taken legal advice on compatibility of this license with AGPLv3.

>From a quick review, it looks like the CryptoMobile and NextEPC versions have taken the same approach.
It would be good as you say to have a "clean copyright" implementation - perhaps this is something we could help with.

Best regards,
Paul

> Hi!
>
> I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for
> NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME.
>
> However, it seems there is no real FOSS implementation of the SNOW-3G algoritm
> around?  All I could find was:
>
> * https://github.com/mitshell/CryptoMobile with unclear source of the code,
>   without a copyright statement or license annotation
>
> * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main.c
>   without a copyright statement or license annotation
>
> * https://github.com/Jadson27101/SNOW_3G in go,
>   without a copyright statement or license annotation
>
> * https://github.com/KsirbJ/SNOW-3G
>   without a copyright statement or license annotation
>
> * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c
>   without a copyright statement or license annotation. Looks rather similar
>   to CryptoMobile.  Possible just copy+pasted from ETSI reference implementation?
>
> * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc
>   also contains no coypright statement or license, but might be construed
>   to be AGPLv3 like all of srsLTE.  However, it states it is "adapted"
>   from ETSI/SAGE specifications.  Does that mean it is an independent
>   implementation of the algorithm by just reading the specs, or does it
>   contain actual ETSI-copyrighted code?
>
> It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement)
> don't contain any actual information but all just point to the ETSI SAGE specification
> which can be found (at the very least) here:
> https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf
> and interestingly doesn't contain any copyright statement whatsoever.
>
> This discussion is not about any potentially 'essential patents' that may or may
> not apply in some jurisdictions on the algorithm itself.  I'm currently only interested
> in a "clean copyright" implementation of any of the EIA/EEA implementations used
> on the LTE NAS layer.
>
> I'd appreciate any useful comments. Thanks!
>
> -- 
> - Harald Welte <laforge at gnumonks.org <https://lists.osmocom.org/mailman/listinfo/openbsc>>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)

-- 
________________________________________________________________
Paul Sutton Ph.D.

Software Radio Systems (SRS)
http://www.softwareradiosystems.com
paul at softwareradiosystems.com

PGP Key ID: 3B4A5292
Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292
________________________________________________________________ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190715/99d694bf/attachment.htm>

From rafael at rhizomatica.org  Mon Jul 15 13:26:14 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Mon, 15 Jul 2019 10:26:14 -0300
Subject: Sample configs for reproducing osmo-nitb behaviour with the split
 stack
In-Reply-To: <cce63ae1-20dd-a055-7d28-0ee80df98e4c@sysmocom.de>
References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
 <20190713014203.GX3429@nataraja>
 <eedd5819-f7d0-3815-972a-a4c6c75cbb9d@rhizomatica.org>
 <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de>
 <cce63ae1-20dd-a055-7d28-0ee80df98e4c@sysmocom.de>
Message-ID: <f1a1afd8-19e6-6dff-8940-2af2e58efa54@rhizomatica.org>

Thanks a lot, Oliver!

The VTY commands for changing nam_cs and nam_ps will be useful.
; )

Any problems I let you know!

Cheers,
Rafael Diniz

On 7/15/19 5:08 AM, Oliver Smith wrote:
> "check-imei-rqd early", not "check-imei early"
> 
> On 7/15/19 10:05 AM, Oliver Smith wrote:
>> Hey Rafael,
>>
>> On 7/13/19 5:55 PM, Rafael Diniz wrote:
>>> Hi Harald,
>>>
>>>> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
>>>>> Today I'm working on updating my NuRAN unit with the new osmo stack 
>>>>
>>>> Can you clarify which particular model/unit that is?
>>>>
>>>> I would assume that the 'nightly' OE packages sysmocom provides should have
>>>> all related features.
>>>
>>> It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by
>>> hand the BTS and PCU against LC 1.5 headers.
>>>
>>>>> I'm writing just in case someone already put online a set of config
>>>>> files with the parameters needed by such behavior set?
>>>>> ; )
>>>>
>>>> I would be careful with full configuration files, as they contain all kinds
>>>> of settings which may or may not do what you want.  The settings for
>>>> subcsriber-create-on-demand are only 2-3, AFAIR.
>>>>
>>>>> ps: I have the new splip stack working fine here, I just need to modify
>>>>> my setup with new features to support subscriber_create_on_demand.
>>>>
>>>> Then please simply use the config files you have and not start with
>>>> something else just because you need to modify one or very few lines...
>>>>
>>>> See https://osmocom.org/issues/2542 where Oliver actually also points to
>>>> a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
>>>>
>>>> If yo have more specific questions, feel free to raise them here :)
>>>
>>> Fine, I'll just adapt my config - Thanks!!
>>
>> As Harald pointed out, the documentation could use some more examples.
>> I'll update the docs accordingly, but to make your life easier, here are
>> the configuration options relevant for your use case (with sending the
>> IMEI to the HLR).
>>
>> osmo-msc.cfg:
>> msc
>>  check-imei early
>>
>> osmo-hlr.cfg:
>> hlr
>>  subscriber-create-on-demand 5 none
>>  store-imei
>>
>>
>> This will create 5 digit MSISDNs for the subscribers, and disable CS NAM
>> and PS NAM by default (circuit switched and packet switched network
>> access modes). Subscribers can't make phone calls or use cellular data,
>> so their phones will not connect to the network, but the entry in the
>> HLR will be created.
>>
>> After a new subscriber was created, it will look like this in the VTY
>> (I've replaced the real IMEI and IMSI with zeros):
>>
>> OsmoHLR> enable
>> OsmoHLR# subscriber imei 00000000000000 show
>>     ID: 1
>>     IMSI: 000000000000000
>>     MSISDN: 58192           <- randomly generated
>>     IMEI: 000000000000000
>>     CS disabled
>>     PS disabled
>>
>> The idea is now to enable CS and PS for the IMEIs that you know. Right
>> now, the documentation says:
>>
>>> In order to do that, one can set the default NAM to none and manually
>>> approve new subscribers by enabling their nam_cs and nam_ps parameters
>>> (e.g. over the VTY).
>>
>> But as I was about to create an example of how these commands look like,
>> I realized that VTY commands for changing nam_cs and nam_ps don't
>> actually exist yet :\ So for now, these flags have to be changed
>> manually in the sqlite database... change nam_cs and nam_ps to 1 in the
>> subscriber table. Maybe this is still useful for testing. I will add the
>> missing VTY commands shortly.
>>
>>>
>>> Cheers,
>>> Rafael Diniz
>>>
>>
>> Cheers,
>> Oliver
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190715/3ab57c22/attachment.bin>

From osmith at sysmocom.de  Tue Jul 16 07:27:55 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Tue, 16 Jul 2019 09:27:55 +0200
Subject: Sample configs for reproducing osmo-nitb behaviour with the split
 stack
In-Reply-To: <f1a1afd8-19e6-6dff-8940-2af2e58efa54@rhizomatica.org>
References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
 <20190713014203.GX3429@nataraja>
 <eedd5819-f7d0-3815-972a-a4c6c75cbb9d@rhizomatica.org>
 <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de>
 <cce63ae1-20dd-a055-7d28-0ee80df98e4c@sysmocom.de>
 <f1a1afd8-19e6-6dff-8940-2af2e58efa54@rhizomatica.org>
Message-ID: <202c6769-8f1d-c5f5-2938-f22f549c4105@sysmocom.de>

Hello Rafael,

you're welcome. I've just merged the new VTY command and manuals update
to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual

So if you rebuild your osmo-hlr packages from master, you should have
the command (if I understood correctly that you are building the
packages yourself, otherwise it will be in the nightly packages tomorrow).

After a subscriber has been created on demand, with network access mode
set to "none", you can give the subscriber access to circuit and packet
switched services as follows:

OsmoHLR> enable
OsmoHLR# subscriber imei 35761300444848 show
    ID: 1
    IMSI: 123456789023000
    MSISDN: 58192
    IMEI: 35761300444848
    CS disabled
    PS disabled
OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps
OsmoHLR# subscriber imei 35761300444848 show
    ID: 1
    IMSI: 123456789023000
    MSISDN: 58192
    IMEI: 35761300444848

Cheers,
Oliver

On 7/15/19 3:26 PM, Rafael Diniz wrote:
> Thanks a lot, Oliver!
> 
> The VTY commands for changing nam_cs and nam_ps will be useful.
> ; )
> 
> Any problems I let you know!
> 
> Cheers,
> Rafael Diniz
> 
> On 7/15/19 5:08 AM, Oliver Smith wrote:
>> "check-imei-rqd early", not "check-imei early"
>>
>> On 7/15/19 10:05 AM, Oliver Smith wrote:
>>> Hey Rafael,
>>>
>>> On 7/13/19 5:55 PM, Rafael Diniz wrote:
>>>> Hi Harald,
>>>>
>>>>> On Fri, Jul 12, 2019 at 10:26:04AM -0300, Rafael Diniz wrote:
>>>>>> Today I'm working on updating my NuRAN unit with the new osmo stack 
>>>>>
>>>>> Can you clarify which particular model/unit that is?
>>>>>
>>>>> I would assume that the 'nightly' OE packages sysmocom provides should have
>>>>> all related features.
>>>>
>>>> It's a Nuran LC 1.5. I'm using debian 9 armhf packages and compiling by
>>>> hand the BTS and PCU against LC 1.5 headers.
>>>>
>>>>>> I'm writing just in case someone already put online a set of config
>>>>>> files with the parameters needed by such behavior set?
>>>>>> ; )
>>>>>
>>>>> I would be careful with full configuration files, as they contain all kinds
>>>>> of settings which may or may not do what you want.  The settings for
>>>>> subcsriber-create-on-demand are only 2-3, AFAIR.
>>>>>
>>>>>> ps: I have the new splip stack working fine here, I just need to modify
>>>>>> my setup with new features to support subscriber_create_on_demand.
>>>>>
>>>>> Then please simply use the config files you have and not start with
>>>>> something else just because you need to modify one or very few lines...
>>>>>
>>>>> See https://osmocom.org/issues/2542 where Oliver actually also points to
>>>>> a short new chapter in the manual at https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
>>>>>
>>>>> If yo have more specific questions, feel free to raise them here :)
>>>>
>>>> Fine, I'll just adapt my config - Thanks!!
>>>
>>> As Harald pointed out, the documentation could use some more examples.
>>> I'll update the docs accordingly, but to make your life easier, here are
>>> the configuration options relevant for your use case (with sending the
>>> IMEI to the HLR).
>>>
>>> osmo-msc.cfg:
>>> msc
>>>  check-imei early
>>>
>>> osmo-hlr.cfg:
>>> hlr
>>>  subscriber-create-on-demand 5 none
>>>  store-imei
>>>
>>>
>>> This will create 5 digit MSISDNs for the subscribers, and disable CS NAM
>>> and PS NAM by default (circuit switched and packet switched network
>>> access modes). Subscribers can't make phone calls or use cellular data,
>>> so their phones will not connect to the network, but the entry in the
>>> HLR will be created.
>>>
>>> After a new subscriber was created, it will look like this in the VTY
>>> (I've replaced the real IMEI and IMSI with zeros):
>>>
>>> OsmoHLR> enable
>>> OsmoHLR# subscriber imei 00000000000000 show
>>>     ID: 1
>>>     IMSI: 000000000000000
>>>     MSISDN: 58192           <- randomly generated
>>>     IMEI: 000000000000000
>>>     CS disabled
>>>     PS disabled
>>>
>>> The idea is now to enable CS and PS for the IMEIs that you know. Right
>>> now, the documentation says:
>>>
>>>> In order to do that, one can set the default NAM to none and manually
>>>> approve new subscribers by enabling their nam_cs and nam_ps parameters
>>>> (e.g. over the VTY).
>>>
>>> But as I was about to create an example of how these commands look like,
>>> I realized that VTY commands for changing nam_cs and nam_ps don't
>>> actually exist yet :\ So for now, these flags have to be changed
>>> manually in the sqlite database... change nam_cs and nam_ps to 1 in the
>>> subscriber table. Maybe this is still useful for testing. I will add the
>>> missing VTY commands shortly.
>>>
>>>>
>>>> Cheers,
>>>> Rafael Diniz
>>>>
>>>
>>> Cheers,
>>> Oliver
>>>
>>
> 

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From laforge at gnumonks.org  Tue Jul 16 11:05:53 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 16 Jul 2019 20:05:53 +0900
Subject: SNOW-3G / ZUC implementation under FOSS license?
In-Reply-To: <796d2296-36e9-daa1-ddc4-f10f35f778e5@softwareradiosystems.com>
References: <796d2296-36e9-daa1-ddc4-f10f35f778e5@softwareradiosystems.com>
Message-ID: <20190716110553.GE3325@nataraja>

Hi Paul,

On Mon, Jul 15, 2019 at 12:58:08PM +0100, Paul Sutton wrote:
> The srsLTE implementation is taken from the ETSI specs simulation
> program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf
> and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf

thanks for your feedback.

> https://www.etsi.org/intellectual-property-rights#mytoc3 and
> https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the
> copyright licensing details for software incorporated in ETSI
> standards however I have not taken legal advice on compatibility of
> this license with AGPLv3.

I personally find all I found so far on the the ETSI "IP policy" quite
shady, to be honest. It's weird how the "restricted usage undertaking"
and related documents appear to be devoid of any information about what
kind of rights or license they are talking about. "intellectual
property" is a marketing term. It could refer to anything from
trademarks, patents to copyright.

It's a bit of a surprise that the industry doesn't appear to have
developed more legal clarity around this.   This is not only true for
those crypto systems, but equally true e.g. of the reference voice codec
implementations.  The specs requires a bit-exact match to what is
released as their source code - yet that source code comes without
copyright statement or any indication of license terms.  The big
question is how realistically one could write an independent
implementation which  renders the bit-exact results without writing code
that looks identical.  Also, there's typically always some collections
of constants / tables, which you have to copy 1:1.  Sure, there's some
flexibility in the details of an implementation, but to me it's somewhat
questionable how that would look from a copyright point of view.  Guess
I'll have to have that discussion within the FOSS legal circles I
happen to have found my way into.

It would be great to have a discussion around all of this with ETSI,
but I somehow fear they will not really have anyone on the table with
a deep understanding how FOSS works both legally and technically.

> It would be good as you say to have a "clean copyright" implementation
> - perhaps this is something we could help with.

I'd very much like that idea.  If you have capacity to work on that:
great!

Maybe it's also something where one could convince some FOSS-friendly
academics that it would be worth having e.g.  some students work on it.
I don't really have much day-to-day contacts to academic cryptographers,
but I know quite a few and can try to ask around.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From rafael at rhizomatica.org  Wed Jul 17 20:05:41 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Wed, 17 Jul 2019 17:05:41 -0300
Subject: Sample configs for reproducing osmo-nitb behaviour with the split
 stack
In-Reply-To: <202c6769-8f1d-c5f5-2938-f22f549c4105@sysmocom.de>
References: <15d3273d-19cc-2ae0-8628-6bc6fe676970@rhizomatica.org>
 <20190713014203.GX3429@nataraja>
 <eedd5819-f7d0-3815-972a-a4c6c75cbb9d@rhizomatica.org>
 <60461c27-2bac-9c08-fc62-6b9ffcd34885@sysmocom.de>
 <cce63ae1-20dd-a055-7d28-0ee80df98e4c@sysmocom.de>
 <f1a1afd8-19e6-6dff-8940-2af2e58efa54@rhizomatica.org>
 <202c6769-8f1d-c5f5-2938-f22f549c4105@sysmocom.de>
Message-ID: <4e79c7a8-1f98-740d-4586-abdda609a847@rhizomatica.org>

Hi Oliver,

> you're welcome. I've just merged the new VTY command and manuals update
> to master: https://gerrit.osmocom.org/q/topic:subscr-on-demand-manual

thanks!

> So if you rebuild your osmo-hlr packages from master, you should have
> the command (if I understood correctly that you are building the
> packages yourself, otherwise it will be in the nightly packages tomorrow).

I'm using the armhf nightly builds (running on the cpu of the bts unit),
except for the bts and pcu which needs appropriate lc15 flags so I
compile by hand from git master.

> After a subscriber has been created on demand, with network access mode
> set to "none", you can give the subscriber access to circuit and packet
> switched services as follows:
> 
> OsmoHLR> enable
> OsmoHLR# subscriber imei 35761300444848 show
>     ID: 1
>     IMSI: 123456789023000
>     MSISDN: 58192
>     IMEI: 35761300444848
>     CS disabled
>     PS disabled
> OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps
> OsmoHLR# subscriber imei 35761300444848 show
>     ID: 1
>     IMSI: 123456789023000
>     MSISDN: 58192
>     IMEI: 35761300444848

That is what I need for testing, perfect.

Cheers,
Rafael Diniz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190717/0acdf94c/attachment.bin>

From rafael at rhizomatica.org  Fri Jul 19 16:29:59 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Fri, 19 Jul 2019 13:29:59 -0300
Subject: CS Fallback in NextEPC
In-Reply-To: <CAL=AzhqPxsFUD5To4bvha0ro-7t=qLXA0zKL-3Qs4Ci2y+Vdtg@mail.gmail.com>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <CAL=AzhqPxsFUD5To4bvha0ro-7t=qLXA0zKL-3Qs4Ci2y+Vdtg@mail.gmail.com>
Message-ID: <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org>

Hi all,

I'd also like to test SMS and CSFB in LTE. I have some experience with
the Osmocom GSM stack, but not much with the NextEPC LTE. Could you
point me which fields should I set in the configuration files?

Thanks,
Rafael Diniz

On 7/13/19 6:35 PM, Romeu Medeiros wrote:
> Hello?Sukchan and friends.
> 
> I'm trying to use the CSFB in test lab, and every time that nextepc send
> the UEContextModificationRequest, the UE respond with an
> UEContextModificationFaliure [ Protocol-cause=semantic-error ].
> 
> image.png
> 
> I'm looking why I'm getting this. Someone have any idea?
> 
> Thanks
> 
> Romeu Medeiros
> 
> On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee <acetcom at gmail.com
> <mailto:acetcom at gmail.com>> wrote:
> 
>     Dear Osmocom & NextEPC Community,
> 
>     Today I've added CS Fallback and released NextEPC v0.5.0
> 
>     So, I'd just like to test this part with Osmocom project, but it
>     seems to be a difficult task. The reason is why I have little
>     knowledge about 2G/3G. Nevertheless, I will try to do it
> 
>     BTW, I don't know if there is anyone who wants to integrate this big
>     thing.
>     Even though I'm not sure if this will help, but let me introduce the
>     configuration of the NextEPC.
> 
>     To use SGsAP, change the mme.conf as follows:
> 
>     #
>     # ?<sgsap>
>     #
>     # ?o Single MSC/VLR
>     # ? ?sgsap:
>     # ? ? ?addr: 127.0.0.2
>     # ? ? ?plmn_id:
>     # ? ? ? ?mcc: 001
>     # ? ? ? ?mnc: 01
>     # ? ? ?tac: 4130
>     # ? ? ?lac: 43690
>     #
>     # ?o Multiple MSC/VLR
>     # ? ?sgsap:
>     # ? ? ?- addr: 127.0.0.2
>     # ? ? ? ?plmn_id:
>     # ? ? ? ? ?mcc: 001
>     # ? ? ? ? ?mnc: 01
>     # ? ? ? ?tac: 4131
>     # ? ? ? ?lac: 43692
>     # ? ? ?- addr
>     # ? ? ? ? - 127.0.0.3
>     # ? ? ? ? - fe80::2%lo0
>     # ? ? ? ?plmn_id:
>     # ? ? ? ? ?mcc: 001
>     # ? ? ? ? ?mnc: 01
>     # ? ? ? ?tac: 4132
>     # ? ? ? ?lac: 43692
>     # ? ? ?- name: msc.open5gs.org <http://msc.open5gs.org>
>     # ? ? ? ?plmn_id:
>     # ? ? ? ? ?mcc: 001
>     # ? ? ? ? ?mnc: 01
>     # ? ? ? ?tac: 4133
>     # ? ? ? ?lac: 43693
>     #
> 
>     FYI, I also attach the pcap that I run with nextepc simulator as below.
> 
>     $ ./tests/testcsfb
>     mo-idle-test ? ? ? ?: SUCCESS
>     mt-idle-test ? ? ? ?: SUCCESS
>     mo-active-test ? ? ?: SUCCESS
>     mt-active-test ? ? ?: SUCCESS
>     All tests passed.
> 
>     Feel free to raise any questions about this things.
> 
>     Best Regards,
>     ? ? Sukchan
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190719/6dd4bafa/attachment.bin>

From rafael at rhizomatica.org  Fri Jul 19 20:51:23 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Fri, 19 Jul 2019 17:51:23 -0300
Subject: CS Fallback in NextEPC
In-Reply-To: <CAL=Azhr7_f1vV1g5vALj3dxJLBNHoFhZcv3bfmco8Xqic=ScPg@mail.gmail.com>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <CAL=AzhqPxsFUD5To4bvha0ro-7t=qLXA0zKL-3Qs4Ci2y+Vdtg@mail.gmail.com>
 <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org>
 <CAL=Azhr7_f1vV1g5vALj3dxJLBNHoFhZcv3bfmco8Xqic=ScPg@mail.gmail.com>
Message-ID: <dd8d7a36-f6fa-eeca-fbf8-b97e02c097d0@rhizomatica.org>

Obrigado Romeu!

On 7/19/19 4:58 PM, Romeu Medeiros wrote:
> Hello Rafael
> 
> I just configure the NextEPC to connect via SGS to OSMO-MSC, like this:
> 
> ? ? sgsap:
> ? ? ? ? addr: 127.0.0.1
> ? ? ? ? port: 29118
> ? ? ? ? name: vlr.example.net <http://vlr.example.net>
> ? ? ? ? tai:
> ? ? ? ? ? ?plmn_id:
> ? ? ? ? ? ? ?mcc: 724
> ? ? ? ? ? ? ?mnc: 21
> ? ? ? ? ? ?tac: 12345
> ? ? ? ? lai:
> ? ? ? ? ? ?plmn_id:
> ? ? ? ? ? ? ?mcc: 724
> ? ? ? ? ? ? ?mnc: 4
> ? ? ? ? ? ?lac: 51544
> 
> And the configuration in the MSC:
> 
> sgs
> ?local-port 29118
> ?local-ip 0.0.0.0
> ?vlr-name vlr.example.net <http://vlr.example.net>
> 
> And configure the IMSI in the Osmo-HLR and NextEPC-HSS
> 
> If you need more help tell me.
> 
> 
> Thanks
> 
> Romeu Medeiros
> 
> 
> And?
> 
> On Fri, Jul 19, 2019 at 1:31 PM Rafael Diniz <rafael at rhizomatica.org
> <mailto:rafael at rhizomatica.org>> wrote:
> 
>     Hi all,
> 
>     I'd also like to test SMS and CSFB in LTE. I have some experience with
>     the Osmocom GSM stack, but not much with the NextEPC LTE. Could you
>     point me which fields should I set in the configuration files?
> 
>     Thanks,
>     Rafael Diniz
> 
>     On 7/13/19 6:35 PM, Romeu Medeiros wrote:
>     > Hello?Sukchan and friends.
>     >
>     > I'm trying to use the CSFB in test lab, and every time that
>     nextepc send
>     > the UEContextModificationRequest, the UE respond with an
>     > UEContextModificationFaliure [ Protocol-cause=semantic-error ].
>     >
>     > image.png
>     >
>     > I'm looking why I'm getting this. Someone have any idea?
>     >
>     > Thanks
>     >
>     > Romeu Medeiros
>     >
>     > On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee <acetcom at gmail.com
>     <mailto:acetcom at gmail.com>
>     > <mailto:acetcom at gmail.com <mailto:acetcom at gmail.com>>> wrote:
>     >
>     >? ? ?Dear Osmocom & NextEPC Community,
>     >
>     >? ? ?Today I've added CS Fallback and released NextEPC v0.5.0
>     >
>     >? ? ?So, I'd just like to test this part with Osmocom project, but it
>     >? ? ?seems to be a difficult task. The reason is why I have little
>     >? ? ?knowledge about 2G/3G. Nevertheless, I will try to do it
>     >
>     >? ? ?BTW, I don't know if there is anyone who wants to integrate
>     this big
>     >? ? ?thing.
>     >? ? ?Even though I'm not sure if this will help, but let me
>     introduce the
>     >? ? ?configuration of the NextEPC.
>     >
>     >? ? ?To use SGsAP, change the mme.conf as follows:
>     >
>     >? ? ?#
>     >? ? ?# ?<sgsap>
>     >? ? ?#
>     >? ? ?# ?o Single MSC/VLR
>     >? ? ?# ? ?sgsap:
>     >? ? ?# ? ? ?addr: 127.0.0.2
>     >? ? ?# ? ? ?plmn_id:
>     >? ? ?# ? ? ? ?mcc: 001
>     >? ? ?# ? ? ? ?mnc: 01
>     >? ? ?# ? ? ?tac: 4130
>     >? ? ?# ? ? ?lac: 43690
>     >? ? ?#
>     >? ? ?# ?o Multiple MSC/VLR
>     >? ? ?# ? ?sgsap:
>     >? ? ?# ? ? ?- addr: 127.0.0.2
>     >? ? ?# ? ? ? ?plmn_id:
>     >? ? ?# ? ? ? ? ?mcc: 001
>     >? ? ?# ? ? ? ? ?mnc: 01
>     >? ? ?# ? ? ? ?tac: 4131
>     >? ? ?# ? ? ? ?lac: 43692
>     >? ? ?# ? ? ?- addr
>     >? ? ?# ? ? ? ? - 127.0.0.3
>     >? ? ?# ? ? ? ? - fe80::2%lo0
>     >? ? ?# ? ? ? ?plmn_id:
>     >? ? ?# ? ? ? ? ?mcc: 001
>     >? ? ?# ? ? ? ? ?mnc: 01
>     >? ? ?# ? ? ? ?tac: 4132
>     >? ? ?# ? ? ? ?lac: 43692
>     >? ? ?# ? ? ?- name: msc.open5gs.org <http://msc.open5gs.org>
>     <http://msc.open5gs.org>
>     >? ? ?# ? ? ? ?plmn_id:
>     >? ? ?# ? ? ? ? ?mcc: 001
>     >? ? ?# ? ? ? ? ?mnc: 01
>     >? ? ?# ? ? ? ?tac: 4133
>     >? ? ?# ? ? ? ?lac: 43693
>     >? ? ?#
>     >
>     >? ? ?FYI, I also attach the pcap that I run with nextepc simulator
>     as below.
>     >
>     >? ? ?$ ./tests/testcsfb
>     >? ? ?mo-idle-test ? ? ? ?: SUCCESS
>     >? ? ?mt-idle-test ? ? ? ?: SUCCESS
>     >? ? ?mo-active-test ? ? ?: SUCCESS
>     >? ? ?mt-active-test ? ? ?: SUCCESS
>     >? ? ?All tests passed.
>     >
>     >? ? ?Feel free to raise any questions about this things.
>     >
>     >? ? ?Best Regards,
>     >? ? ?? ? Sukchan
>     >
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190719/e77a164d/attachment.bin>

From tylerwood_7 at live.com  Mon Jul 22 20:57:04 2019
From: tylerwood_7 at live.com (tyler wood)
Date: Mon, 22 Jul 2019 20:57:04 +0000
Subject: OpenBSC inquiry 
Message-ID: <DM5PR1201MB01552DAB66C7E2E6FD80E958AEC40@DM5PR1201MB0155.namprd12.prod.outlook.com>

Good evening,

My name is Tyler Wood, I was wondering how much yall would charge to create a dongle with OpenBSC on it and mail it to me. If I have contacted the wrong emails please let me know who I need to contact. Thank you for your time.

Very Respectfully,


Tyler Wood


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190722/9906db3d/attachment.htm>

From axilirator at gmail.com  Wed Jul 24 15:50:38 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 24 Jul 2019 22:50:38 +0700
Subject: OpenBSC inquiry
In-Reply-To: <DM5PR1201MB01552DAB66C7E2E6FD80E958AEC40@DM5PR1201MB0155.namprd12.prod.outlook.com>
References: <DM5PR1201MB01552DAB66C7E2E6FD80E958AEC40@DM5PR1201MB0155.namprd12.prod.outlook.com>
Message-ID: <CAPEnp=b+p6TKwwpE67B73TfKVXwwmG94-dS+S1g0th1BQprs5w@mail.gmail.com>

Hello Tyler,

> [...] to create a dongle with OpenBSC on it [...]

what do you mean by that?

Do you need to get the source code of OpenBSC? I guess no, because
if you can mail and create tickets (https://osmocom.org/issues/4127),
you could just download it from http://git.osmocom.org/.

Maybe you meant a working set up, kind of Live USB?
Please be more concrete. Also, please note that OpenBSC
has been deprecated, and is not actively maintained anymore...

Personally, I am not going to send anything, I just want to clarify
since this is not the first time you're asking this question...

With best regards,
Vadim Yanitskiy.


From rafael at rhizomatica.org  Wed Jul 24 20:38:00 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Wed, 24 Jul 2019 17:38:00 -0300
Subject: libosmocore for multi-threaded software
Message-ID: <9c057dcc-f439-2226-eda9-26101877200f@rhizomatica.org>

Hi all,

I'm writing some tools for using with HF radio and SDR modems [1], and
I'm using multi-threaded architecture. Do you know the status and/or
which branch should I use of libosmocore in a multi-threaded application?

Regards,
Rafael Diniz

[1] https://github.com/DigitalHERMES/rhizo-uuardop

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190724/d1f08ceb/attachment.bin>

From pespin at sysmocom.de  Wed Jul 24 21:43:22 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 24 Jul 2019 23:43:22 +0200
Subject: libosmocore for multi-threaded software
In-Reply-To: <9c057dcc-f439-2226-eda9-26101877200f@rhizomatica.org>
References: <9c057dcc-f439-2226-eda9-26101877200f@rhizomatica.org>
Message-ID: <9d56c24f-6910-de74-51f7-16a83179aa96@sysmocom.de>

Hi Rafael,

libosmocore master (which will be released over next weeks) should have 
enough multithread support for most known generic needs. Logging, main 
loop and as far a I known FSM are prepared to work in a multithreaded 
environment. In FSM case, you may need to use your own mutex to protect 
structures. Same goes for CTRL interface. For VTY, it will always happen 
on the same thread (main thread) handling the socket, so it should be 
pretty OK.

Some known issues with VTY and logging still exist, but they are really 
scoped:
https://osmocom.org/issues/4088

Remember to avoid using APIs which contain static buffers. Most of them 
don't make use of static buffers, and for the ones that do then there's 
usually a _buf() alternative which allows you to pass a stack or heap 
buffer.

If you find any function in libosmocore using an internal static buffer 
or finding possible bugs when on multi-thread environment, please open a 
ticket or send a patch.

Don't hesitate to ping me on IRC or over here if you have more questions 
about this topic.

Regards,
Pau

-- 
- Pau Espin Pedrol <pespin at 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


From laforge at gnumonks.org  Fri Jul 26 05:56:25 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 26 Jul 2019 07:56:25 +0200
Subject: massive regressions in osmo-bts
Message-ID: <20190726055624.GM29137@nataraja>

Hi!

Four builds ago, from build 585 onwards, we are seeing massive regressions
in the BTS_Tests.ttcn test suite on osmo-bts master:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_results_analyzer/

I think this matches roughly when the TRXDv1 protocol changes were merged,
it would be great if anyone making changes to osmo-bts or the test suite around
July 21/22nd could investigate what's happening here.

Tests against osmo-bts-latest are doing fine, so I think we can exclude a bug
in the test suite.

Thanks + Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From infibiti16 at gmail.com  Fri Jul 26 06:39:12 2019
From: infibiti16 at gmail.com (BT Infinite)
Date: Fri, 26 Jul 2019 14:39:12 +0800
Subject: Unsubscribe
Message-ID: <5d3aa015.1c69fb81.62114.c464@mx.google.com>

I Want to unsubscribe this email. There is an error on website. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190726/d720a2ca/attachment.htm>

From axilirator at gmail.com  Fri Jul 26 09:03:04 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 26 Jul 2019 16:03:04 +0700
Subject: massive regressions in osmo-bts
In-Reply-To: <20190726055624.GM29137@nataraja>
References: <20190726055624.GM29137@nataraja>
Message-ID: <CAPEnp=brH2CjFH1sVVOA625rOOK6oistxYywt6wwoY-3wSRxEg@mail.gmail.com>

Hi Harald,

I did a quick investigation, and it seems I found the problem:

https://git.osmocom.org/osmo-ttcn3-hacks/tree/bts/BTS_Tests.ttcn#n425

Since [1] we additionally filter Access Bursts by the link quality C/I in L1SAP,
and since [2] we do provide the actual C/I values for osmo-bts-trx, as was
received from the transceiver.

[1] https://gerrit.osmocom.org/r/I893ec9c6c2ebad71ea68b2dc5f9f5094dfc43b78
[2] https://gerrit.osmocom.org/r/I8d86dec7ebc039cbfd038c4342ff328b11281865

The default minimum C/I for Access Bursts in OsmoBTS is 50 cB or 5 dB, while
the TTCN-3 test cases configure fake_trx.py to send 0 cB, so of course such
Access Bursts are getting dropped, as expected. I'll send a fix soon.

For Normal Bursts, the minimum C/I value is -5 cB, so they pass
without problems.

With best regards,
Vadim Yanitskiy.


From osmith at sysmocom.de  Fri Jul 26 12:23:42 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Fri, 26 Jul 2019 14:23:42 +0200
Subject: Using trxcon/fake_trx with PDCH for TTCN3 tests
Message-ID: <a945e5b4-c24c-192e-33af-f3b0a25d6724@sysmocom.de>

Hello Vadim,

I'm working on the TTCN3 tests for OsmoPCU. Harald told me, that there
are a few tests existing tests (such as TC_ul_tbf), that had been
developed with osmo-bts-virtual/virt_phy.

He also said that since there is trxcon/fake_trx nowadays, it would be
better to use that instead, if it supports PDCH. From a quick "git
grep", it looks like PDCH is supported in trxcon.

What do you think, should it work well enough to do the switch?

Thanks,
Oliver

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From axilirator at gmail.com  Fri Jul 26 13:44:47 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 26 Jul 2019 20:44:47 +0700
Subject: Using trxcon/fake_trx with PDCH for TTCN3 tests
In-Reply-To: <a945e5b4-c24c-192e-33af-f3b0a25d6724@sysmocom.de>
References: <a945e5b4-c24c-192e-33af-f3b0a25d6724@sysmocom.de>
Message-ID: <CAPEnp=Z+q9Fr7LpAoZUL0hmKH=XG+azXRtez7xrcKWRhe0N1Zw@mail.gmail.com>

Hi Oliver,

> I'm working on the TTCN3 tests for OsmoPCU.

great!

> He also said that since there is trxcon/fake_trx nowadays,
> it would be better to use that instead, if it supports PDCH.

Well, I wouldn't say better. It depends what do you need to test.
With the virt_phy, you can test the higher layers of OsmoBTS, so
you are not affected by potential problems / bugs of particular
L1 implementation, such as osmo-bts-trx.

With fake_trx.py and trxcon you can test the whole stack, including
the L1 implementation (scheduling, convolutional coding, etc.). As
a bonus, you can simulate different parameters of the virtual radio
interface, including RSSI, ToA256, C/I, and even BER.

> From a quick "git grep", it looks like PDCH is supported in trxcon.

Yep, it does. You can find the multiframe layout of PDCH:

https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_mframe.c#n1811

which contains two logical channels:

  PDTCH - Packet Data Traffic Channel, and
  PTCCH - Packet Timing advance Control Channel.

Neither in OsmoBTS nor in trxcon PTCCH is handled correctly:

https://osmocom.org/issues/4102

but PDTCH is implemented, please see:

https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_lchan_desc.c#n501
https://git.osmocom.org/osmocom-bb/tree/src/host/trxcon/sched_lchan_pdtch.c

Currently there is only one TTCN-3 test case that uses PDTCH
support in trxcon - f_TC_pcu_data_ind_lqual_cb:

https://git.osmocom.org/osmo-ttcn3-hacks/tree/bts/BTS_Tests.ttcn#n4320

The main problem is that trxcon has a bit different philosophy
when it comes to packet data and PDCH in particular. Its early
development was mostly influenced by OsmoBTS, and at that time
I knew almost nothing about GPRS and its PHY.

One big difference from virt_phy is that trxcon uses different
L1CTL messages: L1CTL_TRAFFIC_{REQ,CONF,IND} instead of
L1CTL_DATA_{REQ,CONF,IND}. I don't insist on this, but IMHO
this kind of message is better for PDTCH.

Another important detail is that there is no such thing as TBF flow
in trxcon. Everything that was received on PDTCH will be forwarded
to the higher layers, so they need to do TBF filtering themselves.

Ideally, we need to be able to configure one or more TBFs (using TFI),
so trxcon would filter received packets. In virt_phy this can be done
using L1CTL_TBF_CFG_{REQ,CONF}. At the same time, I would like to
keep the possibility to receive everything for sniffing ;)

Finally, there is no way to ask trxcon to send a given Uplink
block on particular TDMA frame number. Instead, a queued block
will be sent almost immediately.

Resuming the above, we need to solve at least three problems:

1) L1CTL_TRAFFIC_{REQ,CONF,IND} vs L1CTL_DATA_{REQ,CONF,IND};
2) Downlink TBF flow control: L1CTL_TBF_CFG_{REQ,CONF};
3) Uplink TBF flow control: L1CTL_DATA_TBF_{REQ,CONF}.

While writing this mail, I've got an idea about a potential solution
of the 1st one. We can just keep L1CTL_TRAFFIC_{REQ,CONF,IND} for
the 'flowless' control (i.e. Rx/Tx everything regardless of TBFs),
and implement L1CTL_DATA_{REQ,CONF,IND} handling for selective
reception and transmission. Switching between the both modes
can be done one reception of L1CTL_TBF_CFG_REQ.

I am open for the further discussion. Added Harald to CC.

With best regards,
Vadim Yanitskiy.


From osmith at sysmocom.de  Mon Jul 29 08:50:12 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Mon, 29 Jul 2019 10:50:12 +0200
Subject: Using trxcon/fake_trx with PDCH for TTCN3 tests
In-Reply-To: <CAPEnp=Z+q9Fr7LpAoZUL0hmKH=XG+azXRtez7xrcKWRhe0N1Zw@mail.gmail.com>
References: <a945e5b4-c24c-192e-33af-f3b0a25d6724@sysmocom.de>
 <CAPEnp=Z+q9Fr7LpAoZUL0hmKH=XG+azXRtez7xrcKWRhe0N1Zw@mail.gmail.com>
Message-ID: <8284416a-79f9-d768-ce7b-cffaf2375c0e@sysmocom.de>

Hi Vadim,

thank you very much for your in-depth answer!

> Well, I wouldn't say better. It depends what do you need to test.

It is planned to test the following:
* UL TBF
* DL TBF
* Paging
* Timing Advance
* Link Adaptation
* Timer (Idle/Ready/...)

But as I'm just diving into this, I'll get the existing but disabled
(probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests
running first. I'll start with virt_phy for now, and then see how far I
can get with it.

Cheers,
Oliver

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From nhofmeyr at sysmocom.de  Mon Jul 29 14:49:19 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 29 Jul 2019 16:49:19 +0200
Subject: FW: OpenBSC on 3rd party MSC
In-Reply-To: <000801d4fa17$8d882a50$a8987ef0$@corrections.com>
References: <000d01d4f0a1$2cdb08a0$869119e0$@corrections.com>
 <20190413095056.GI24451@nataraja>
 <001c01d4f46d$bcd909a0$368b1ce0$@corrections.com>
 <000801d4fa17$8d882a50$a8987ef0$@corrections.com>
Message-ID: <20190729144919.GA8364@my.box>

Related: https://osmocom.org/issues/3476
"osmo-bsc manual needs to explain the AoIP config 'cs7 instance'"

Note that the osmo-msc manual has a similar section: http://ftp.osmocom.org/docs/latest/osmomsc-usermanual.pdf
"See OsmoMSC manual 'Running OsmoMSC' / 'Configure primary links' -- the OsmoBSC manual needs a similar section"

A cs7 section I found in one of my test setups is:

cs7 instance 0
 point-code 0.23.3
 asp asp-clnt-msc-0 2905 0 m3ua

If you're using SCCPlite, it could look something like


cs7 instance 0
 sccp-timer ias 90
 point-code format 24
 point-code 1196
 asp asp-clnt-msc-0 5000 0 ipa
  remote-ip 123.45.0.200
  local-ip 123.45.49.100
 as as-clnt-msc-0 ipa
  asp asp-clnt-msc-0
  routing-key 0 1196
  point-code override dpc 100
 sccp-address remote_msc
  point-code 100
msc 0
 msc-addr remote_msc


I hope that helps? Configuring cs7 is not trivial, maybe would make sense to
book some support hours and provide direct access so that developers can help
you directly...

~N

On Tue, Apr 23, 2019 at 05:00:15PM -0400, wyao at corrections.com wrote:
> Hello everyone,
> 
> I am still not be able to figure out how to configure the A interface on the
> OsmoBSC side to talk to MSC, I will really appreciated if someone could
> share a similar configuration. Or if someone could point me to the right
> document, I looked through the OsmoBSC user
> manual(http://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf) and could
> not find the A interfaces config section.
> 
> Thanks,
> Weiqi
> 
> -----Original Message-----
> From: wyao at corrections.com <wyao at corrections.com> 
> Sent: Tuesday, April 16, 2019 12:02 PM
> To: 'Harald Welte' <laforge at gnumonks.org>
> Cc: OpenBSC at lists.osmocom.org
> Subject: RE: OpenBSC on 3rd party MSC
> 
> Thanks Harald for your reply,
> 
> Looks like the issue is the connection between OsmoBSC and my MSC.
> 
> I checked again on my MSC side, looks like it interfaces with softBSC on
> AoIP, connect to BSC port 2427 and 5000. So basically it just require a
> softBSC IP address to be able to connect. 
> 
> I found an example cfg called osmo-bsc-mgcp.cfg under the OpenBSC folder,
> but I have no clue if this is the right one to modify. I will appreciate if
> you can provide some example BSC configuration like this. Also, Should I
> still keep the OsmoSTP?
> Thanks again!
> 
> Regards,
> Weiqi
> 
> -----Original Message-----
> From: Harald Welte <laforge at gnumonks.org>
> Sent: Saturday, April 13, 2019 5:51 AM
> To: wyao at corrections.com
> Cc: OpenBSC at lists.osmocom.org
> Subject: Re: OpenBSC on 3rd party MSC
> 
> Hi Weiqi,
> 
> On Thu, Apr 11, 2019 at 04:00:08PM -0400, wyao at corrections.com wrote:
> > I am working on get OpenBSC connected to a 3rd party MSC, I read from 
> > the Osmo document that I can use the bsc only mode and the osm-bsc 
> > instead of the osmo-nitb.
> 
> This is correct.  However, the terminology is a bit messed-up.  So it's best
> to not use OpenBSC anymore but alsways call it OsmoBSC.
> 
> > Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp 
> > configured and and running,
> 
> sidenote: You will have to add osmo-mgw for handling voice calls later on,
> but that is irrelevant until you get the signalling plane up and running.
> 
> > but I see a lot of below error logs in the osmo-stp console:
> > 
> > DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): 
> > sctp_recvmsg() returned 56 (flags=0x80) DLM3UA <000f> m3ua.c:722
> > asp-asp-dyn-0: Received M3UA Message (XFER:DATA) DLM3UA <000f>
> > m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer DLM3UA <000f> m3ua.c:580
> > asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1
> > dpc=185=0.23.1
> > DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): 
> > dpc=185=0.23.1 not local, message is for routing
> > DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route!
> 
> Your SS7 routing seems to be misconfigured.  The STP receives SCCP from
> OsmoBSC, but there's no (currently active/working) route for the MSC.  Hence
> the message cannot be routed and is discarded.
> 
> > <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending 
> > BSSMAP
> RESET message...
> > <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: 
> > RI=SSN_PC,PC=0.23.1,SSN=BSSAP
> 
> The BSC is trying to send a BSSMAP RESET to the MSC, but there's no
> response.
> 
> > Can anyone identify what is the issue here? 
> 
> It's a SS7 routing / SIGTRAN configuration issue.  You need to make sure the
> osmo-stp and osmo-bsc SS7 related configuration exactly matches the
> configuration on the MSC side.
> 
> Also, depending on your SIGTRAN network setup, you may not even need
> osmo-stp.
> That would be the case e.g. if the MSC or an existing STP in your core
> network would already provide a M3UA SGW functionality to which the AS/ASP
> of OsmoBSC can connect to.
> 
> It's really not possible to give you an easy answer without fully
> understanding your core networks SS7/SIGTRAN configuration, routing,
> addresses, point codes, etc.
> 
> SIGTRAN and SS7 are rather complex protocol stacks themselves.  There's
> little we can do on the Osmocom side to avoid that.  We can just provide all
> the possible settings/options so you can configure it to match your network
> topology.
> 
> Regards,
> 	Harald
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)
> 
> 

-- 
- Neels Hofmeyr <nhofmeyr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190729/3d096528/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Jul 29 15:12:11 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 29 Jul 2019 17:12:11 +0200
Subject: Osmocom Village at CCC Camp 2019
In-Reply-To: <20190621165404.GU25425@nataraja>
References: <20190621165404.GU25425@nataraja>
Message-ID: <20190729151211.GB8364@my.box>

I am noting possible duplication in effort preparing the camp as well as
digital infrastructure.  Apparently bibor and lynxis aim to manage wiki etc on
code.fe80.eu and the event-orga ML, and Osmocom to be part of the Singularity
City. In contrast, this Osmocom Village mail seems to suggest a separate
village and wiki+ML. I also at some point noted separate efforts made by
different people for setting up a large Osmocom tent, IIUC.

I'm not sure how to consolidate, but I get the strong feeling that bibor,
lynxis and laforge should talk about the camp preparations to avoid "aneinander
vorbeireden", confusion and redundant efforts ... ?

~N

On Fri, Jun 21, 2019 at 06:54:04PM +0200, Harald Welte wrote:
> Dear all,
> 
> I've been asked by a number of pepole about a possible Osmocom village at the
> CCC Camp 2019.  I personally didn't really have any plans, but given related
> e-mails and "encouragement" I went ahead and registered an "Osmocom Village",
> see
> 	https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3
> 
> I also created a wiki page (as nobody else did, despite earlier discussion on IRC,
> SCNR) for coordinating related efforts at
> 	https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019
> 
> One of the bigger questions is about having a tent as well as some tables/benches
> to sit on and work.  The Camp orga team nas been negotiating rates with a tent
> rental company, but to be honest I'm rather surprised by the extremely steep
> pricing.  The smallest possible tent (6m x 3m) would cost 825 EUR.  I'm not
> sure we want to raise that amount of money?  Even if we'd be 10 people sharing
> it, its still 82.50 EUR per person.  And that excludes any tables/chairs.
> 
> I'm attaching the relevant parts of a mail from the assemblies orga team FYI.
> 
> Please note there also is some kind of fragmentation / overlap with the
> team planning to run the GSM/3G networks at the camp, see Lynxis'
> related post at
> https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/000362.html
> 
> It's questionable whether it makes sense to have tow distinct
> 'villages', but given that e.g. I don't know anyone of that singularity
> city, I'm not sure if we'd either be welcome there, nor whether we'd
> want to associate us with them?  Also, while the GSM network operation
> for sure has good reasons to mingle with the POC and whatever facilities
> they have, I'm not sure if the wider Osmocom community attendees
> unrelated to the GSM network operation wouldn't just be a
> disturbance/nuisance.
> 
> In the end, to be honest, I personally do not feel I have the time and
> mental capacity to take on any additional tasks in terms of organizing
> anything.  I just created the entry in c3assemblies as I was asked to,
> and I similarly created the related mailing list and wiki page.
> 
> So please, anyone interested in making an Osmocom village happen one way
> or another, step up [and continue this discussion on the
> camp2019-village at lists.osmocom.org mailing list, without crossposting
> everywhere else :)
> 
> Regards,
> 	Harald
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)

> Ticket sale is over. There are no more tickets available. There will be no ticket sale on site. That means
> you should know how many will join your village. In the next days we start planning the placing of the
> assemblies, we need your help.
> 
> Please update your village registration at [3] https://signup.c3assemblies.de/ with the number of people
> who will join, extra space you require, power requirements, and such. Please write all information to be
> considered in the village registration form.
> 
> There have been some frequently asked questions in the last weeks. So we want to address some topics here:
> 
> Tents/Tables/Benches/Construction Wood:
> Prebuilt tents, tables, benches and wood can be borrowed or bought via the presale system: [4]
> https://tickets.events.ccc.de/camp2019hw/. For now there are only tents because we need to order them
> soon. The rest will follow and can be bought with the same voucher. You will recieve a voucher with this
> email (see below). The earlier you order your stuff, the more likely we can provide what you want.
> Especially tents might be in short supply. Please remember bringing cash for the mandatory deposit of ?
> 100,- for renting tables and benches.
> 
> Water:
> We want to remind you, if you bring cooking equipment, there will be no direct fresh water and waste water
> supply for your kitchen. We will have some central places with fresh water supply and where you can wash
> your kitchen utensiles and dishes.
> 
> Power:
> Power will be generated from diesel with power generators. All engergy you'll use will have to be
> generated. Think about our environment and use as little power as possible. For that reason, there is no
> possibility to fulfill high power demands for pizza ovens, saunas and alike. If you need cooling for your
> food supplies, please think about your refrigeration requirements. Less is more. And please bring enough
> outdoor and rain proof extension cables to connect your tents and equipment.
> 
> Fire:
> Open wood or coal fire is not allowed at any time. That applies for anything that needs heat for kitchen
> usage. If you need heat, please bring your own safe gas-based camping heaters.
> 
> Waste:
> Of course there will be containers for waste, paper and glass on the camp site. But the camp tries to be
> as sustainable and ecological as possible. So please consider bringing reusable dishes and cutlery. Also
> think about bringing a refillable water bottle for this is the more ecological alternative to bottled
> water. The tap water is perfectly drinkable.
> 
> Wiki:
> There will be no automatic transfer of your data from the village registration tool to the wiki. Please
> create your own Wiki page using the form at [5] https://events.ccc.de/camp/2019/wiki/Form:Village if you
> want your village appear in the wiki. Please be aware that the only valid place for village registration
> is [6] https://signup.c3assemblies.de/
> 
> Timeline:
> 14.8: Buildup: Only for angels who help with buildup and registered at the orga- or angelsystem with their dates
> 16.8: People can start to build up their villages, no power or network yet
> 19.8: Power is probably(!) available from now
> 21.8: Offical start of the CCCamp19 \o/
> 25.8: Last day of the CCCamp19, start of disassembly in the evening
> 28.8: Last day of disassembly, all must be finished no later than this day. If you stay 27th/28th, you are
> expected to help out!
> 
> Please see [7] https://events.ccc.de/camp/2019/wiki/Timeline for recent updates.
> 
> [1] https://signup.c3assemblies.de/
> [2] https://tickets.events.ccc.de/camp2019hw/
> [3] https://signup.c3assemblies.de/
> [4] https://tickets.events.ccc.de/camp2019hw/
> [5] https://events.ccc.de/camp/2019/wiki/Form:Village
> [6] https://signup.c3assemblies.de/
> [7] https://events.ccc.de/camp/2019/wiki/Timeline
> 


-- 
- Neels Hofmeyr <nhofmeyr at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190729/43d0d368/attachment.bin>

From laforge at gnumonks.org  Mon Jul 29 18:42:25 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 29 Jul 2019 20:42:25 +0200
Subject: Using trxcon/fake_trx with PDCH for TTCN3 tests
In-Reply-To: <8284416a-79f9-d768-ce7b-cffaf2375c0e@sysmocom.de>
References: <a945e5b4-c24c-192e-33af-f3b0a25d6724@sysmocom.de>
 <CAPEnp=Z+q9Fr7LpAoZUL0hmKH=XG+azXRtez7xrcKWRhe0N1Zw@mail.gmail.com>
 <8284416a-79f9-d768-ce7b-cffaf2375c0e@sysmocom.de>
Message-ID: <20190729184225.GG23630@nataraja>

On Mon, Jul 29, 2019 at 10:50:12AM +0200, Oliver Smith wrote:
> Hi Vadim,
> 
> thank you very much for your in-depth answer!

Thanks also from my side.  Given that the amount of resources we have
for writing PCU tests is rather limited, I would suggest Oliver to stay
with virt_phy for now and focus on the actual PCU tests and not on
building required infrastructure.

In general, I still believe that for a "normal" MS behavior (whether
in a test case or not), it is best to have some TBF state inside the
L1 and filter the TFI there.  Otherwise L2 just gets swamped with lots
of messages that aren't interesting for it, and will just clog up logs,
consume CPU (thinking of a real MS), ...

> But as I'm just diving into this, I'll get the existing but disabled
> (probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests
> running first. I'll start with virt_phy for now, and then see how far I
> can get with it.

The tests you mentioned were passing at some point.  Of course our
TTCN-3 infrastructure and OsmoBTS as well as OsmoPCU have evolved since,
so there may be some fall-out :(

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Mon Jul 29 18:55:29 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 29 Jul 2019 20:55:29 +0200
Subject: Osmocom Village at CCC Camp 2019
In-Reply-To: <20190729151211.GB8364@my.box>
References: <20190621165404.GU25425@nataraja>
 <20190729151211.GB8364@my.box>
Message-ID: <20190729185528.GH23630@nataraja>

Hi Neels,

On Mon, Jul 29, 2019 at 05:12:11PM +0200, Neels Hofmeyr wrote:
> I am noting possible duplication in effort preparing the camp as well as
> digital infrastructure.  Apparently bibor and lynxis aim to manage wiki etc on
> code.fe80.eu and the event-orga ML, and Osmocom to be part of the Singularity
> City. In contrast, this Osmocom Village mail seems to suggest a separate
> village and wiki+ML. I also at some point noted separate efforts made by
> different people for setting up a large Osmocom tent, IIUC.

I think the "problem" here is that we have two disjunct communities:

1) The wider "Osmocom and friends" community, consisting of people related to
   Osmocom projects unrelated to GSM/cellular, but even reaching into the gnuradio
   crowd, who had historically also been sharing the Osmocom village.  This is about
   bringing together people working on various SDR / communications related topics
   for "hanging out, chatting, ...".  As I wrote before, people have reached out to
   me about this for months.

2) The "post LaF0rge" team operating the 2G/3G network at CCC events.  I see that
   as a rather "production oriented" team which has to work closely with the POC,
   etc. and which shouldn't be bothered/distracted by people who are not
   involved in that.

> I'm not sure how to consolidate, but I get the strong feeling that bibor,
> lynxis and laforge should talk about the camp preparations to avoid "aneinander
> vorbeireden", confusion and redundant efforts ... ?

I'm always open to discuss, but after months of public posts on this
ando ther mailing lists, I'm not sure what there is to add.  In short:

* both villages are now part of Singularity City
* Osmocom Village has no separate tent/infrastructure but people will
  hang out at the singularity city hackcenter.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From osmith at sysmocom.de  Tue Jul 30 08:23:45 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Tue, 30 Jul 2019 10:23:45 +0200
Subject: Using trxcon/fake_trx with PDCH for TTCN3 tests
In-Reply-To: <20190729184225.GG23630@nataraja>
References: <a945e5b4-c24c-192e-33af-f3b0a25d6724@sysmocom.de>
 <CAPEnp=Z+q9Fr7LpAoZUL0hmKH=XG+azXRtez7xrcKWRhe0N1Zw@mail.gmail.com>
 <8284416a-79f9-d768-ce7b-cffaf2375c0e@sysmocom.de>
 <20190729184225.GG23630@nataraja>
Message-ID: <4bcc3180-50b9-aeff-3732-cdedf6f867ea@sysmocom.de>

Hello Harald and Vadim,

On 7/29/19 8:42 PM, Harald Welte wrote:
> Thanks also from my side.  Given that the amount of resources we have
> for writing PCU tests is rather limited, I would suggest Oliver to stay
> with virt_phy for now and focus on the actual PCU tests and not on
> building required infrastructure.

Sounds good.

>> But as I'm just diving into this, I'll get the existing but disabled
>> (probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests
>> running first. I'll start with virt_phy for now, and then see how far I
>> can get with it.
> 
> The tests you mentioned were passing at some point.  Of course our
> TTCN-3 infrastructure and OsmoBTS as well as OsmoPCU have evolved since,
> so there may be some fall-out :(

It is great that they were already passing in the past. Harald, do you
happen to still have the configs around for running these two tests?

I am trying to piece it together, and so far I have the following. It
would be great if you could point out any misconceptions I have.

The raw PCU tests, that are currently running in Jenkins, only start
OsmoPCU and the testsuite. When doing the same for TC_ul_tbf and
TC_ul_tbf_single_llc_sizes, the testsuite fails to establish the BSSGP
connection:

> MTC at gsmdevel: Test case TC_ul_tbf finished. Verdict: fail reason: Timeout establishing BSSGP connection

(This is confusing me a bit, isn't the Gp connection between the SGSN
and GGSN according to [1]? But I am assuming, that this means the Gb
connection towards the PCU.)

Looking at the osmo-pcu log, I find that it won't do anything (not
accept connections) until it successfully connects to /tmp/pcu_bts.

I am starting osmo-bts-virtual in order to provide /tmp/pcu_bts. The
socket appears, but it will also not properly start up until it connects
to something via A-bis OML. So I am also starting osmo-bsc to provide
that (I have looked at ttcn3-bts-test, which does it the same way).

Now osmo-bts-virtual is connecting to osmo-bsc, but osmo-bsc is dropping
the connection immediately for some reason. Probably a mismatch in the
configs, though at least the unit id is matching.

My current understanding is, that the following components need to run:

osmo-pcu
|
| /tmp/pcu_bts
|
osmo-bts-virtual ---A-bis OML--- osmo-bsc
|
| ?
|
virt_phy
|
| /tmp/osmocom_l2
|
testsuite


Is that accurate?
How does the connection between osmo-bts-virtual and virt_phy work?

Thanks,
Oliver

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From osmith at sysmocom.de  Tue Jul 30 08:29:58 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Tue, 30 Jul 2019 10:29:58 +0200
Subject: Using trxcon/fake_trx with PDCH for TTCN3 tests
In-Reply-To: <4bcc3180-50b9-aeff-3732-cdedf6f867ea@sysmocom.de>
References: <a945e5b4-c24c-192e-33af-f3b0a25d6724@sysmocom.de>
 <CAPEnp=Z+q9Fr7LpAoZUL0hmKH=XG+azXRtez7xrcKWRhe0N1Zw@mail.gmail.com>
 <8284416a-79f9-d768-ce7b-cffaf2375c0e@sysmocom.de>
 <20190729184225.GG23630@nataraja>
 <4bcc3180-50b9-aeff-3732-cdedf6f867ea@sysmocom.de>
Message-ID: <5e35165a-b706-672c-2de4-c514c3471cf5@sysmocom.de>

Forgot to add the link for [1]:

> https://osmocom.org/projects/osmopcu/wiki/OsmoPCU#Position-in-a-typical-Osmocom-network

On 7/30/19 10:23 AM, Oliver Smith wrote:
> Hello Harald and Vadim,
> 
> On 7/29/19 8:42 PM, Harald Welte wrote:
>> Thanks also from my side.  Given that the amount of resources we have
>> for writing PCU tests is rather limited, I would suggest Oliver to stay
>> with virt_phy for now and focus on the actual PCU tests and not on
>> building required infrastructure.
> 
> Sounds good.
> 
>>> But as I'm just diving into this, I'll get the existing but disabled
>>> (probably incomplete?) TC_ul_tbf and TC_ul_tbf_single_llc_sizes tests
>>> running first. I'll start with virt_phy for now, and then see how far I
>>> can get with it.
>>
>> The tests you mentioned were passing at some point.  Of course our
>> TTCN-3 infrastructure and OsmoBTS as well as OsmoPCU have evolved since,
>> so there may be some fall-out :(
> 
> It is great that they were already passing in the past. Harald, do you
> happen to still have the configs around for running these two tests?
> 
> I am trying to piece it together, and so far I have the following. It
> would be great if you could point out any misconceptions I have.
> 
> The raw PCU tests, that are currently running in Jenkins, only start
> OsmoPCU and the testsuite. When doing the same for TC_ul_tbf and
> TC_ul_tbf_single_llc_sizes, the testsuite fails to establish the BSSGP
> connection:
> 
>> MTC at gsmdevel: Test case TC_ul_tbf finished. Verdict: fail reason: Timeout establishing BSSGP connection
> 
> (This is confusing me a bit, isn't the Gp connection between the SGSN
> and GGSN according to [1]? But I am assuming, that this means the Gb
> connection towards the PCU.)
> 
> Looking at the osmo-pcu log, I find that it won't do anything (not
> accept connections) until it successfully connects to /tmp/pcu_bts.
> 
> I am starting osmo-bts-virtual in order to provide /tmp/pcu_bts. The
> socket appears, but it will also not properly start up until it connects
> to something via A-bis OML. So I am also starting osmo-bsc to provide
> that (I have looked at ttcn3-bts-test, which does it the same way).
> 
> Now osmo-bts-virtual is connecting to osmo-bsc, but osmo-bsc is dropping
> the connection immediately for some reason. Probably a mismatch in the
> configs, though at least the unit id is matching.
> 
> My current understanding is, that the following components need to run:
> 
> osmo-pcu
> |
> | /tmp/pcu_bts
> |
> osmo-bts-virtual ---A-bis OML--- osmo-bsc
> |
> | ?
> |
> virt_phy
> |
> | /tmp/osmocom_l2
> |
> testsuite
> 
> 
> Is that accurate?
> How does the connection between osmo-bts-virtual and virt_phy work?
> 
> Thanks,
> Oliver
> 

-- 
- Oliver Smith <osmith at sysmocom.de>            https://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


From lynxis at fe80.eu  Wed Jul 31 16:02:42 2019
From: lynxis at fe80.eu (Alexander Couzens)
Date: Wed, 31 Jul 2019 18:02:42 +0200
Subject: [osmocom-event-orga] Osmocom Village at CCC Camp 2019
In-Reply-To: <20190729185528.GH23630@nataraja>
References: <20190621165404.GU25425@nataraja> <20190729151211.GB8364@my.box>
 <20190729185528.GH23630@nataraja>
Message-ID: <20190731180242.6db0a0f9@lazus.yip>

Hi Neels,

> * both villages are now part of Singularity City
> * Osmocom Village has no separate tent/infrastructure but people will
>   hang out at the singularity city hackcenter.

I agree with Harald that both villages have different needs.

The GSM/3G village needs place and time to build the network up and tear
down. If the network doesn't work, we like to have a quiet tent to fix
everything. But if everything works, we also like to hack and chill.

IMHO: The main reason for 2 villages was the lack of time to organize
it together, at least I can say it for my side.

I hope we will be at the same table hacking, drinking mate and
having fun! I see the GSM/3G team as part of the osmocom community and
hope everybody feels invited to join the GSM/3G team.

Have a nice camp,
lynxis
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190731/6bd40847/attachment.bin>