From raji.oshin at hotmail.com  Sat May  5 06:05:03 2018
From: raji.oshin at hotmail.com (Rajitha peiris)
Date: Sat, 5 May 2018 06:05:03 +0000
Subject: Connect two nanobts with lcr
Message-ID: <SG2PR0302MB24798EAACF98F1DBE2365D7382850@SG2PR0302MB2479.apcprd03.prod.outlook.com>

Hello everyone
Can anyone help me to connect two nanobts via Linux call router.I have tested with multitrx mode .but my problem is to connect two nanobts in different locations

Thanks
Regards
Rajitha

Sent from my iPhone

From laforge at gnumonks.org  Thu May 10 21:36:03 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 10 May 2018 23:36:03 +0200
Subject: expected osmocom.org downtime on Sunday, 2018-05-13
Message-ID: <20180510213603.GO9313@nataraja>

Dear Osmocom community,

this sunday (May 13), I'm planning to do some of the pending migration of
osmocom.org services from our old server to a new machine.

This will cause some downtime.  Hopefully it will be minimal, but I'm sure
there will be unexpected events that will mean some of the osmocom.org services
will be unavailable at some point during Sunday.

In terms of priorities, gerrit is high up on the list, so this will be my primary
focus.  If that goes well, redmine is the next on the list.

In case you're interested in the gory details, https://osmocom.org/issues/3076
is the overview ticket.

-- 
- 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 nbalkanas at gmail.com  Fri May 11 09:28:47 2018
From: nbalkanas at gmail.com (Nikos Balkanas)
Date: Fri, 11 May 2018 12:28:47 +0300
Subject: osmocom-bb installation problems
Message-ID: <CAAxXO2HtW=fzHbcHkHr+Dxk89VCyfpiK8ODXm6LFbXmpSVG1cA@mail.gmail.com>

Hi,

I am new to this list.
I use ubuntu 14.04.02. I am trying to configure/compile osmocom-bb.
I have a few questions and problems:
According to the src/README.building file, I should get the arm toolchain
from gnuarm.com
This should be updated, gnuarm.com doesn't have any downloads any more.
Instead I installed gcc-arm-linux-gnueabi from ubuntu reps
1) normal gcc seems to support x-compiling for arm CPUs. Why not use that?
2) Your stock Makefile tests for CROSS_HOST against arm-elf-gcc. This
should be updated to test also against arm-linux-gnueabi-gcc from
gcc-arm-linux-gnueabi package
3) configure warnings:
configure: WARNING: unrecognized options: --disable-tests, --disable-tests.
Should be disabled if not supported any more
checking for arm-linux-gnueabi-mt... no
checking for mt... mt
configure: WARNING: using cross tools not prefixed with host triplet
Is this a problem?
4) configure asks for libosmovty. Despite listed, couldn't find it under
osmocom libraries any more:(
Where can i download it from?

TIA,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180511/be7c0998/attachment.htm>

From nbalkanas at gmail.com  Fri May 11 19:45:00 2018
From: nbalkanas at gmail.com (Nikos Balkanas)
Date: Fri, 11 May 2018 22:45:00 +0300
Subject: osmocom-bb installation problems
In-Reply-To: <CAAxXO2HtW=fzHbcHkHr+Dxk89VCyfpiK8ODXm6LFbXmpSVG1cA@mail.gmail.com>
References: <CAAxXO2HtW=fzHbcHkHr+Dxk89VCyfpiK8ODXm6LFbXmpSVG1cA@mail.gmail.com>
Message-ID: <CAAxXO2FSS-whFCeFHAETfYiWHTsyMyPra_PEymV6nccEodL7GA@mail.gmail.com>

(4) Correction:
Seems libosmovty is now part of libosmocore. Should be listed as such.
Problem is that latest osmocom-bb asks for libosmovty 0.10.0, while latest
libosmocore master provides libosmovty 0.9.0.16-abc4 :-(
These 2 should really be synchronized. Where can I find more recent
libosmocore or older osmocom-bb?

TIA
Nikos

On Fri, May 11, 2018 at 12:28 PM, Nikos Balkanas <nbalkanas at gmail.com>
wrote:

> Hi,
>
> I am new to this list.
> I use ubuntu 14.04.02. I am trying to configure/compile osmocom-bb.
> I have a few questions and problems:
> According to the src/README.building file, I should get the arm toolchain
> from gnuarm.com
> This should be updated, gnuarm.com doesn't have any downloads any more.
> Instead I installed gcc-arm-linux-gnueabi from ubuntu reps
> 1) normal gcc seems to support x-compiling for arm CPUs. Why not use that?
> 2) Your stock Makefile tests for CROSS_HOST against arm-elf-gcc. This
> should be updated to test also against arm-linux-gnueabi-gcc from
> gcc-arm-linux-gnueabi package
> 3) configure warnings:
> configure: WARNING: unrecognized options: --disable-tests,
> --disable-tests. Should be disabled if not supported any more
> checking for arm-linux-gnueabi-mt... no
> checking for mt... mt
> configure: WARNING: using cross tools not prefixed with host triplet
> Is this a problem?
> 4) configure asks for libosmovty. Despite listed, couldn't find it under
> osmocom libraries any more:(
> Where can i download it from?
>
> TIA,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180511/95a69c2f/attachment.htm>

From laforge at gnumonks.org  Sat May 12 08:23:42 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 12 May 2018 10:23:42 +0200
Subject: osmocom-bb installation problems
In-Reply-To: <CAAxXO2FSS-whFCeFHAETfYiWHTsyMyPra_PEymV6nccEodL7GA@mail.gmail.com>
References: <CAAxXO2HtW=fzHbcHkHr+Dxk89VCyfpiK8ODXm6LFbXmpSVG1cA@mail.gmail.com>
 <CAAxXO2FSS-whFCeFHAETfYiWHTsyMyPra_PEymV6nccEodL7GA@mail.gmail.com>
Message-ID: <20180512082342.GG9313@nataraja>

Dear Nikos,

you are at the OpenBSC mailing list, please post osmocom-bb related questions
to baseband-devel at lists.osmocom.org

On Fri, May 11, 2018 at 10:45:00PM +0300, Nikos Balkanas wrote:
> (4) Correction:
> Seems libosmovty is now part of libosmocore. Should be listed as such.
> Problem is that latest osmocom-bb asks for libosmovty 0.10.0, 

> while latest libosmocore master provides libosmovty 0.9.0.16-abc4 :-(

I'm not sure why you arrive at this conclusion. At http://git.osmocom.org/libosmocore/
you can clearly see that 0.11.0 is the latest tag.  Even 0.10.0 was
released already half a year ago.

Let's continue the conversation at baseband-devel.  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 nbalkanas at gmail.com  Sat May 12 08:35:51 2018
From: nbalkanas at gmail.com (Nikos Balkanas)
Date: Sat, 12 May 2018 11:35:51 +0300
Subject: osmocom-bb installation problems
In-Reply-To: <20180512082342.GG9313@nataraja>
References: <CAAxXO2HtW=fzHbcHkHr+Dxk89VCyfpiK8ODXm6LFbXmpSVG1cA@mail.gmail.com>
 <CAAxXO2FSS-whFCeFHAETfYiWHTsyMyPra_PEymV6nccEodL7GA@mail.gmail.com>
 <20180512082342.GG9313@nataraja>
Message-ID: <CAAxXO2Hepq-56Wk3B1xO5xwqm+2a-3m=Nv_w3eBFBCy0ou-LAA@mail.gmail.com>

Dear Harald,

It was already pointed out to me, by Craig, that I was using the wrong
list:(?
I was using this list, because osmocom-bb configure told me so, in each
warning:(
Already have moved thread to baseband-devel.
I arrived at this conclusion probably because git clone libosmocore (master
branch),
gives me libosmovty 0.9.0.16:(
Will check out your link.

Thx
Nikos

On Sat, May 12, 2018 at 11:23 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Dear Nikos,
>
> you are at the OpenBSC mailing list, please post osmocom-bb related
> questions
> to baseband-devel at lists.osmocom.org
>
> On Fri, May 11, 2018 at 10:45:00PM +0300, Nikos Balkanas wrote:
> > (4) Correction:
> > Seems libosmovty is now part of libosmocore. Should be listed as such.
> > Problem is that latest osmocom-bb asks for libosmovty 0.10.0,
>
> > while latest libosmocore master provides libosmovty 0.9.0.16-abc4 :-(
>
> I'm not sure why you arrive at this conclusion. At http://git.osmocom.org/
> libosmocore/
> you can clearly see that 0.11.0 is the latest tag.  Even 0.10.0 was
> released already half a year ago.
>
> Let's continue the conversation at baseband-devel.  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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180512/4ed39b98/attachment.htm>

From ng91 at glonti.com  Sun May 13 18:08:55 2018
From: ng91 at glonti.com (NG)
Date: Sun, 13 May 2018 20:08:55 +0200
Subject: Huawei BBU3900
Message-ID: <32dd2a29-5ff1-4bdb-6848-57dc9e7c8ae0@glonti.com>

Hello everybody,

My name is Niko, and it's my first post on mailing list.
Is it possible to use OpenBSC together with Huawei BBU3900, or Ericsson
RBS6601?

Thanks in advice
Niko



From laforge at gnumonks.org  Mon May 14 07:11:42 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 14 May 2018 09:11:42 +0200
Subject: Huawei BBU3900
In-Reply-To: <32dd2a29-5ff1-4bdb-6848-57dc9e7c8ae0@glonti.com>
References: <32dd2a29-5ff1-4bdb-6848-57dc9e7c8ae0@glonti.com>
Message-ID: <20180514071142.GK9313@nataraja>

Hi Niko,

On Sun, May 13, 2018 at 08:08:55PM +0200, NG wrote:
> My name is Niko, and it's my first post on mailing list.
> Is it possible to use OpenBSC together with Huawei BBU3900, or Ericsson
> RBS6601?

In general, it is possible.  However, each BTS vendor has its own protocol
dialect, and within that dialect, every firmware generation and/or BTS model
might need some extra tweaking.

Osmocom is an open source project that lives off contribution.  If you have protocol
traces of the Abis interface of some BTS models when they speak to their normal
BSC, then this is a very good basis for re-implemeneting that protocol from OpenBSC
(or rather, OsmoBSC these days).

I am not aware of anyone having worked on/with Huawei Abis so far, so that would
be completely new if you'd like to work on that.

For Ericsson, we do have OM2000 support, which is the Ericsson OML protocol.
So far, we only have tested this with somem members of the RBS2000 family, and
not with RBS6000.  But we're very hapy for any help in development and testing.

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  Mon May 14 10:25:17 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 14 May 2018 12:25:17 +0200
Subject: expected osmocom.org downtime on Sunday, 2018-05-13
In-Reply-To: <20180510213603.GO9313@nataraja>
References: <20180510213603.GO9313@nataraja>
Message-ID: <20180514102517.GV9313@nataraja>

Dear all,

On Thu, May 10, 2018 at 11:36:03PM +0200, Harald Welte wrote:
> this sunday (May 13), I'm planning to do some of the pending migration of
> osmocom.org services from our old server to a new machine.

just a quick update:

* gerrit is migrated from old machine to new machine, and meanwhile
** update to gerrit 2.15.1 was performed
** migration from FreeBSD Jail to docker container on Linux

I've also migrated the old patchwork.osmocom.org in similar fashion.

redmine was migrated, but then rolled back to the old machine due to an
OpenID related regression, see OS#3081.

As part of the migration, DNS records have been updated for some of the
osmocom.org hostnames.

Holge also used the opportunity for a FreeBSD 10.4 upgrade of
rita.osmocom.org (the old machine).

If you see any problems or thing something is odd, please report to the
"osmocom.org servers"  redmine project or by e-mail to me.

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 mykola at razormaker.com  Mon May 14 12:08:04 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Mon, 14 May 2018 15:08:04 +0300
Subject: OsmoHLR understanding/documentation/testing
Message-ID: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>

Good day, ladies and gentlemen

that's a great community you have. Mobile communications programming is a
demanding field requiring best developers.

I would be extremely grateful if you find time to answer a couple of my
simple questions.

I found myself reading the code of OsmoHLR project in order to understand
how it works and how the GSUP protocol works (it seems that the only
example of the GSUP-server is OsmoHLR).
How do you understand the code when you need to modify it or accomplish
other things that programmers usually do? It seems to not be documented
much.

Though I feel fluent in C, I find it hard to understand what is going on
there.
I've come up with an idea of running the OsmoHLR with a debugger. But in
order to see what actually happens in the code when the location update is
being performed (for example) I need to have the real phone and the real
BTS, don't I? How do you check that the code is working as intended?

Thank you very much!

Kind regards,
Mykola Shchetinin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180514/ebf5b2a7/attachment.htm>

From domi at tomcsanyi.net  Mon May 14 13:30:23 2018
From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=)
Date: Mon, 14 May 2018 15:30:23 +0200
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
Message-ID: <722379FD-9F17-4B8B-B285-8FF6C8CD1FF5@tomcsanyi.net>

Hi Mykola,

As far as I followed the mailing list it looks like there is complete testing done with virtualized components, e.g. virtual phone or virtual BTS.
Maybe check into those topics to see if you can run stuff without any equipment.

Cheers,
Domi

> 2018. m?j. 14. d?tummal, 14:08 id?pontban Mykola Shchetinin <mykola at razormaker.com> ?rta:
> 
> Good day, ladies and gentlemen
> 
> that's a great community you have. Mobile communications programming is a demanding field requiring best developers.
> 
> I would be extremely grateful if you find time to answer a couple of my simple questions.
> 
> I found myself reading the code of OsmoHLR project in order to understand how it works and how the GSUP protocol works (it seems that the only example of the GSUP-server is OsmoHLR).
> How do you understand the code when you need to modify it or accomplish other things that programmers usually do? It seems to not be documented much.
> 
> Though I feel fluent in C, I find it hard to understand what is going on there.
> I've come up with an idea of running the OsmoHLR with a debugger. But in order to see what actually happens in the code when the location update is being performed (for example) I need to have the real phone and the real BTS, don't I? How do you check that the code is working as intended?
> 
> Thank you very much!
> 
> Kind regards,
> Mykola Shchetinin

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

From mykola at razormaker.com  Mon May 14 15:35:46 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Mon, 14 May 2018 18:35:46 +0300
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <722379FD-9F17-4B8B-B285-8FF6C8CD1FF5@tomcsanyi.net>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <722379FD-9F17-4B8B-B285-8FF6C8CD1FF5@tomcsanyi.net>
Message-ID: <CANm+YgmBYBK=Avheo44U5ss=2XBr0egLoN-0h0tQiCg2+nvv=A@mail.gmail.com>

Hello Domi,

> As far as I followed the mailing list it looks like there is complete testing done with virtualized components, e.g. virtual phone or virtual BTS.

Are you sure it was on this mailing list? I have looked through the
mails for this year and haven't managed to find any mail on this
topic.

Kind regards,
Mykola


From mykola at razormaker.com  Mon May 14 15:55:24 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Mon, 14 May 2018 18:55:24 +0300
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+YgmBYBK=Avheo44U5ss=2XBr0egLoN-0h0tQiCg2+nvv=A@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <722379FD-9F17-4B8B-B285-8FF6C8CD1FF5@tomcsanyi.net>
 <CANm+YgmBYBK=Avheo44U5ss=2XBr0egLoN-0h0tQiCg2+nvv=A@mail.gmail.com>
Message-ID: <CANm+YgkkzCOrZzNB_+V5osuXQchiFDddZ7qF5RAOe-Wuy3efYA@mail.gmail.com>

It seems like I found the software I can use to test this stuff - Virtual Um.

Links for osmo-newbies like me:
https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um
https://osmocom.org/projects/baseband/wiki/Mobile

Kind regards,
Mykola

On Mon, May 14, 2018 at 6:35 PM, Mykola Shchetinin
<mykola at razormaker.com> wrote:
> Hello Domi,
>
>> As far as I followed the mailing list it looks like there is complete testing done with virtualized components, e.g. virtual phone or virtual BTS.
>
> Are you sure it was on this mailing list? I have looked through the
> mails for this year and haven't managed to find any mail on this
> topic.
>
> Kind regards,
> Mykola


From vvvelichkov at gmail.com  Mon May 14 15:57:45 2018
From: vvvelichkov at gmail.com (Vasil Velichkov)
Date: Mon, 14 May 2018 18:57:45 +0300
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+YgmBYBK=Avheo44U5ss=2XBr0egLoN-0h0tQiCg2+nvv=A@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <722379FD-9F17-4B8B-B285-8FF6C8CD1FF5@tomcsanyi.net>
 <CANm+YgmBYBK=Avheo44U5ss=2XBr0egLoN-0h0tQiCg2+nvv=A@mail.gmail.com>
Message-ID: <6dbd3769-e0a3-6ad2-0c0b-09ed29b27c35@gmail.com>

Hi Mykola,

Here is the announcement 
http://lists.osmocom.org/pipermail/baseband-devel/2017-July/005341.html

See also:

https://osmocom.org/projects/cellular-infrastructure/wiki/Virtual_Um
https://osmocom.org/projects/baseband/wiki/FakeTRX
http://blog.ptsecurity.com/2018/03/how-to-assemble-gsm-phone-based-on-sdr.html

Regards
Vasil


?? 14.05.2018 ? 18:35, Mykola Shchetinin ??????:
> Hello Domi,
>
>> As far as I followed the mailing list it looks like there is complete testing done with virtualized components, e.g. virtual phone or virtual BTS.
> Are you sure it was on this mailing list? I have looked through the
> mails for this year and haven't managed to find any mail on this
> topic.
>
> Kind regards,
> Mykola



From laforge at gnumonks.org  Mon May 14 19:14:50 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 14 May 2018 21:14:50 +0200
Subject: Huawei BBU3900
In-Reply-To: <CAOWPEt=+a1XfSTiB9uAt0u7J8uVgrU0xSQdd5Q3mFcaq6v0jHg@mail.gmail.com>
References: <32dd2a29-5ff1-4bdb-6848-57dc9e7c8ae0@glonti.com>
 <20180514071142.GK9313@nataraja>
 <CAOWPEt=+a1XfSTiB9uAt0u7J8uVgrU0xSQdd5Q3mFcaq6v0jHg@mail.gmail.com>
Message-ID: <20180514191450.GY9313@nataraja>

Hi Shingy,

On Mon, May 14, 2018 at 07:51:28PM +0200, Shingirai Simba wrote:
> My name is shingy and like Nico it's my first post on mailing list.

welcome!

> I have access to both the Huawei BBU3900 and Old ZTE BTS at my
> university.(Not sure of model as yet). Would love to do that on my
> masters degree.

We would be more than happy to integrate any code for supporting more vendors
in OsmoBSC.

> Does anyone have an idea how we can get our hands on protocol traces.

I would expect your university has some BSC/network simulator or a core network+BSC
to get those BTSs up and running?  How were they used so far?

If you have some kind of environment where the BTSs can be brought up, and you
have some additional E1 interface cards so you can trace the interface between
BSC and BTS, a significant step forward is made.

However, if you don't have protocol-level documentation from Huawei or ZTE,
and you cannot get any Abis protocol traces of BTS bring-up, it is almost
impossible to get them ever supported from Osmocom, sorry.

-- 
- 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 nhofmeyr at sysmocom.de  Tue May 15 13:25:12 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 15 May 2018 15:25:12 +0200
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
Message-ID: <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>

On Mon, May 14, 2018 at 03:08:04PM +0300, Mykola Shchetinin wrote:
> Though I feel fluent in C, I find it hard to understand what is going on
> there.

osmo-hlr is receiving GSUP requests and replies to them.
In hlr.c you will see osmo_gsup_server_create() putting in place the
read_cb() you'll find in the same file, the main entry point. The read_cb
will be invoked by the osmo_select_main() loop whenever a GSUP client
connects and sends a request. That should get you started with the code.

Testing wise, we have
https://git.osmocom.org/osmo-ttcn3-hacks/tree/hlr/HLR_Tests.ttcn
which you can run from
https://git.osmocom.org/docker-playground/tree/ttcn3-hlr-test
in docker images with fairly minimal effort and without any cellular
hardware.

You can also look at the real-hardware tests at
https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/
which have detailed logs and network traces taken with actual modems and
BTS equipent, e.g. at
https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod/ws/trial-1254/last_run/aoip_sms:sysmo/mo_mt_sms.py/

Of course really understanding in depth what is going on is not trivial;
osmo-hlr is but a tiny component of a cellular network. Why are you
particularly interested in the HLR?

~N

-------------- 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/20180515/cde46e31/attachment.bin>

From mykola at razormaker.com  Tue May 15 13:49:01 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Tue, 15 May 2018 16:49:01 +0300
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
Message-ID: <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>

Dear Neels,

Thank you very much for the links.

> osmo-hlr is receiving GSUP requests and replies to them.
> In hlr.c you will see osmo_gsup_server_create() putting in place the
> read_cb() you'll find in the same file, the main entry point. The read_cb
> will be invoked by the osmo_select_main() loop whenever a GSUP client
> connects and sends a request. That should get you started with the code.

Thank you. The thing that made me confused at first is the linked list
(g_lu_ops)
which contains lu_operations. But it seems I am gradually beginning to
understand what is going on. Currently, I am compiling Osmocom-BB to test
all the stuff with Virtual Um. I am going to set a few breakpoints in
OsmoHLR to see how it goes :)


> Why are you particularly interested in the HLR?

We are going to write a simple proxy which converts from GSUP to MAP
and vice versa.
While that is not going to be easy, we have enough time and motivation for that.

King regards,
Mykola


From laforge at gnumonks.org  Tue May 15 20:05:20 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 May 2018 22:05:20 +0200
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
 <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
Message-ID: <20180515200520.GT4369@nataraja>

Hi Mykola,

On Tue, May 15, 2018 at 04:49:01PM +0300, Mykola Shchetinin wrote:

> We are going to write a simple proxy which converts from GSUP to MAP
> and vice versa.
> While that is not going to be easy, we have enough time and motivation for that.

Great! I sincerely hope you will be releasing related software as free / open source
software.  Osmocom can only live if people contribute to it.  We have a severe
shortage of contributions, and a project with an enormously wide scope.

-- 
- 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 holger at freyther.de  Wed May 16 11:02:42 2018
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 May 2018 19:02:42 +0800
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
 <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
Message-ID: <DA339986-4C1E-4B28-AAAC-DECF71FE3BD0@freyther.de>



> On 15. May 2018, at 21:49, Mykola Shchetinin <mykola at razormaker.com> wrote:
> 
>> Why are you particularly interested in the HLR?
> 
> We are going to write a simple proxy which converts from GSUP to MAP
> and vice versa.
> While that is not going to be easy, we have enough time and motivation for that.

https://github.com/moiji-mobile/sgsn-mapproxy. It is for osmo-sgsn to HLR, has a reasonable amount of tests and is used in production (normal usage and ireg tests).




From mykola at razormaker.com  Wed May 16 11:17:54 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Wed, 16 May 2018 14:17:54 +0300
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <DA339986-4C1E-4B28-AAAC-DECF71FE3BD0@freyther.de>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
 <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
 <DA339986-4C1E-4B28-AAAC-DECF71FE3BD0@freyther.de>
Message-ID: <CANm+Yg=JHuZ8GknRwgzjXKr8UUGfwed2D3hLSBTceA8h4JiFjQ@mail.gmail.com>

> Great! I sincerely hope you will be releasing related software as free / open source
> software.  Osmocom can only live if people contribute to it.  We have a severe
> shortage of contributions, and a project with an enormously wide scope.

Anyway, if we reuse the osmocom code, then we have to use the same license :)

> https://github.com/moiji-mobile/sgsn-mapproxy. It is for osmo-sgsn to HLR, has a reasonable amount of tests and is used in production (normal usage and ireg tests).

Wow, thank you very much. Actually, I thought that Smalltalk is dead
(Or I was narrow-minded?). But it seems to be alive! :)

On Wed, May 16, 2018 at 2:02 PM, Holger Freyther <holger at freyther.de> wrote:
>
>
>> On 15. May 2018, at 21:49, Mykola Shchetinin <mykola at razormaker.com> wrote:
>>
>>> Why are you particularly interested in the HLR?
>>
>> We are going to write a simple proxy which converts from GSUP to MAP
>> and vice versa.
>> While that is not going to be easy, we have enough time and motivation for that.
>
> https://github.com/moiji-mobile/sgsn-mapproxy. It is for osmo-sgsn to HLR, has a reasonable amount of tests and is used in production (normal usage and ireg tests).
>
>


From nhofmeyr at sysmocom.de  Wed May 16 12:17:38 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 16 May 2018 14:17:38 +0200
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
 <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
Message-ID: <20180516121738.GA29604@my.box>

On Tue, May 15, 2018 at 04:49:01PM +0300, Mykola Shchetinin wrote:
> We are going to write a simple proxy which converts from GSUP to MAP
> and vice versa.

GSUP was/is specifically intended to be a simpler subset of MAP that should be
easily compatible with MAP. An Open Source MAP proxy to SGSN exists, if that is
of interest to you: https://github.com/moiji-mobile/sgsn-mapproxy

Anecdotal: GSUP came about because we wanted to connect osmo-sgsn to a 3rd
party MAP. I wasn't around at the time, but as far as I understand, we invented
GSUP to have a less complex C implementation that talks a leaner protocol over
an expensive/slow link, and to convert to MAP closer to the core network and
talk to the third party HLR. It was first called "GPRS Subscriber Update
Protocol".  Now we've started to use the same to talk between osmo-msc and
osmo-hlr, and interface osmo-sgsn directly to osmo-hlr, hence now we renamed it
to "General Subscriber Update Protocol".

So your plan indeed matches what above sgsn-mapproxy was intended for. I'm
personally not familiar with MAP though, not sure what effort might be required
to proxy for CS as well. And it's written in SmallTalk.

...just thought I'd mention this.

Is your MAP proxy going to be Free Software? Since Osmocom lives from
contribution, we would highly welcome you sharing your progress and code base
with the Osmocom community. (It might even be hosted by osmocom.org??)

~N
-------------- 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/20180516/5f038970/attachment.bin>

From holger at freyther.de  Wed May 16 13:48:19 2018
From: holger at freyther.de (Holger Freyther)
Date: Wed, 16 May 2018 21:48:19 +0800
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <CANm+Yg=JHuZ8GknRwgzjXKr8UUGfwed2D3hLSBTceA8h4JiFjQ@mail.gmail.com>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
 <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
 <DA339986-4C1E-4B28-AAAC-DECF71FE3BD0@freyther.de>
 <CANm+Yg=JHuZ8GknRwgzjXKr8UUGfwed2D3hLSBTceA8h4JiFjQ@mail.gmail.com>
Message-ID: <4BF844C3-12EB-4E6F-884A-778F7223A5EF@freyther.de>



> On 16. May 2018, at 19:17, Mykola Shchetinin <mykola at razormaker.com> wrote:


> Wow, thank you very much. Actually, I thought that Smalltalk is dead
> (Or I was narrow-minded?). But it seems to be alive! :)

Hehe. Well, it is not as hyped as PHP or NodeJS but that is not a bad thing. ;)

From mykola at razormaker.com  Wed May 16 14:30:29 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Wed, 16 May 2018 17:30:29 +0300
Subject: OsmoHLR understanding/documentation/testing
In-Reply-To: <4BF844C3-12EB-4E6F-884A-778F7223A5EF@freyther.de>
References: <CANm+YgnHQk9Zg3rdcoUnCLOb2hAHEegp6FzM9HucZzCwU7=hag@mail.gmail.com>
 <20180515132512.ewj6a74o6m7ovsvw@ass40.sysmocom.de>
 <CANm+YgmK0H35HjZrZL5YG7cWR_CWJJyVHL04saLds9gz68xpaw@mail.gmail.com>
 <DA339986-4C1E-4B28-AAAC-DECF71FE3BD0@freyther.de>
 <CANm+Yg=JHuZ8GknRwgzjXKr8UUGfwed2D3hLSBTceA8h4JiFjQ@mail.gmail.com>
 <4BF844C3-12EB-4E6F-884A-778F7223A5EF@freyther.de>
Message-ID: <CANm+YgmmguHQjM2nSgjRf6su0saUszWmYGuCEdtjRu8iB-5KAA@mail.gmail.com>

> From Harald:
> Great! I sincerely hope you will be releasing related software as free / open source
> software.  Osmocom can only live if people contribute to it.  We have a severe
> shortage of contributions, and a project with an enormously wide scope.

> From Neels:
> Is your MAP proxy going to be Free Software? Since Osmocom lives from
> contribution, we would highly welcome you sharing your progress and code base
> with the Osmocom community. (It might even be hosted by osmocom.org??)

We have such plans indeed. I forgot to mention that it is related to
Pentonet. I guess some of you've already had a conversation about this
project with some of our guys.


From osmocom at alteholz.de  Wed May 16 14:25:10 2018
From: osmocom at alteholz.de (Thorsten Alteholz)
Date: Wed, 16 May 2018 16:25:10 +0200 (CEST)
Subject: LIBVERSION of libsmpp34
Message-ID: <alpine.DEB.2.02.1805161618520.827@jupiter.server.alteholz.net>

Hi,

I stumbled upon LIBVERSION in src/Makefile.am of libsmpp34.
Is there a reason why it changed from 0:1:0 to 1:0:0? At least the names 
of all exported symbols did not change!?

  Thorsten



From pespin at sysmocom.de  Wed May 16 15:43:36 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 16 May 2018 17:43:36 +0200
Subject: LIBVERSION of libsmpp34
In-Reply-To: <alpine.DEB.2.02.1805161618520.827@jupiter.server.alteholz.net>
References: <alpine.DEB.2.02.1805161618520.827@jupiter.server.alteholz.net>
Message-ID: <72f49a34-ad84-7852-1185-12abb4fefcc9@sysmocom.de>

Hi Thorsten,

I'm the one to blame here, I did the last release and bumped the 
LIBVERSION in there.

For libsmpp34 I had no abi-checker result since 1.12 didn't build fine 
with the script I use to generate the reports which help me decide on 
LIBVERSION bumps.

I saw several commits changing stuff in header files. As you may know, 
libsmpp34 is not the easy-to-follow lib that one would like. There's 
tones of macros and defines creating code and structures, so it's 
difficult to follow if some header file change has actually an impact on 
the ABI/API, so I decided to bump LIBVERSION to be on the safe side.

See for instance:
cad0cc552f9956af3fa90d12de443dabe5c7c320
c63971fab0d67bc52d7fd455529b844009aa8565

The commit bumping LIBVERSION: a637c3c9fe5d512b04e7fbf3957702cef5149be3

-- 
- 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 toby at disroot.org  Fri May 18 12:45:52 2018
From: toby at disroot.org (toby)
Date: Fri, 18 May 2018 15:45:52 +0300
Subject: requesting working demo config files for 2g setup osmomsc, osmobsc,
 osmostp,osmohlr, osmomgw
Message-ID: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>

Dear All,

I was wondering whether anyone could please provide me a set of fully 
working configuration files for a network-in-the-box setup with msc, 
bsc, stp, hlr, mgw parts (not osmo-nitb). I have successfully compiled 
all the required software from source, however, the migration guide is 
incomplete and I cannot seem to find a simple tutorial for building an 
osmo network from scratch using all the new components. I want to set up 
a 2g network for calls/sms, i don't need gprs though.

Thanks!


Sincerely,
Toby M.


From rafael at riseup.net  Fri May 18 13:33:17 2018
From: rafael at riseup.net (Rafael Diniz)
Date: Fri, 18 May 2018 10:33:17 -0300
Subject: libsmpp34 C code sample to receive SMS
Message-ID: <275a763a-a94a-8d99-201e-b3a03a6456a9@riseup.net>

Hi all,
In libsmpp34 git there are examples on how to send an SMS (esme in
test_app directory, for example), but none to receive on SMS (from
osmo-nitb / osmo-msc tcp smpp port). In case anyone has some sample C
code to receive SMS using libsmpp34... it will help me.
; )

Thanks,
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/20180518/b691bef2/attachment.bin>

From pespin at sysmocom.de  Fri May 18 15:28:46 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 18 May 2018 17:28:46 +0200
Subject: requesting working demo config files for 2g setup osmomsc,
 osmobsc, osmostp,osmohlr, osmomgw
In-Reply-To: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>
References: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>
Message-ID: <078af83c-60ae-f6f8-a57b-7f89e8c2a3b5@sysmocom.de>

Hi Toby,

find attached my set of config files I use almost daily.

It assumes your PC (Core Network) ip addr is 192.168.30.1, and the 
address of the BTS is 192.168.30.100.

Take into account I'm running only 1 osmo-mgw and I make both osmo-msc 
and osmo-bsc connect to that one, in order to get rid of one more extra 
process.

These are the commands I use to run the components:

ggsn="sudo LD_LIBRARY_PATH=$mylibdir gdb -ex run --args 
$mybindir/osmo-ggsn -c $myconfdir/osmo-ggsn.cfg"
sgsn="gdb -ex run --args $mybindir/osmo-sgsn -c $myconfdir/osmo-sgsn.cfg"
msc="gdb -ex run --args $mybindir/osmo-msc -c $myconfdir/osmo-msc.cfg"
hlr="gdb -ex run --args $mybindir/osmo-hlr -c $myconfdir/osmo-hlr.cfg 
--database $myconfdir/hlr.db"
stp="gdb -ex run --args $mybindir/osmo-stp -c $myconfdir/osmo-stp.cfg"
bsc="gdb -ex run --arg $mybindir/osmo-bsc -c $myconfdir/osmo-bsc.cfg -s"
mgcp="gdb -ex run --arg $mybindir/osmo-bsc_mgcp -c 
$myconfdir/osmo-bsc-mgcp.cfg"
mgw="gdb -ex run --arg $mybindir/osmo-mgw -c $myconfdir/osmo-mgw.cfg"
bts_trx="gdb -ex run --args $mybindir/osmo-bts-trx -c 
$myconfdir/osmo-bts-trx.cfg -i 127.0.0.1 -r 1"
pcu="$mybindir/osmo-pcu -c $myconfdir/osmo-pcu.cfg"


-- 
- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conf.tar.gz
Type: application/gzip
Size: 3184 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180518/68c09e81/attachment.bin>

From loay.razek at gmail.com  Sun May 20 07:52:55 2018
From: loay.razek at gmail.com (loay abdelrazek)
Date: Sun, 20 May 2018 03:52:55 -0400
Subject: The reason why you see paging by IMSI in real-world GSM networks
Message-ID: <CALJt=69waM8KLCLC5Er3F9t=02-F2Asn2-ZmEcTDbKMSMZjS1g@mail.gmail.com>

Hello All

I wanted to ask your about something regarding user privacy leakage in the
broadcast channels.  As i have been sniffing and testing myself and i found
that on the paging requests type 1 IMSI along with TMSI is sent.

I have came to understand that first sending two identifications is the
norm, but what i dont understand the high rate of sending IMSI as mobile
identification, and as per specification its noted that either TMSI OR IMSI
are sent,  so does that by any mean could be a configuration issues from
the MSC/VLR side that should be changed, is this the norm? if its the norm,
then why using TMSI.

>From your experience what are the countermeasures you think that should be
taken from the operator side to protect against such information leaks, or
there is nothing that an operator can do much for this ?What could be the
different cases where the IMSI could be sent ?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180520/4853d7c8/attachment.htm>

From laforge at gnumonks.org  Sun May 20 08:08:01 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 20 May 2018 10:08:01 +0200
Subject: The reason why you see paging by IMSI in real-world GSM networks
In-Reply-To: <CALJt=69waM8KLCLC5Er3F9t=02-F2Asn2-ZmEcTDbKMSMZjS1g@mail.gmail.com>
References: <CALJt=69waM8KLCLC5Er3F9t=02-F2Asn2-ZmEcTDbKMSMZjS1g@mail.gmail.com>
Message-ID: <20180520080801.GC3639@nataraja>

Hi Loay,

On Sun, May 20, 2018 at 03:52:55AM -0400, loay abdelrazek wrote:
> I wanted to ask your about something regarding user privacy leakage in the
> broadcast channels.  As i have been sniffing and testing myself and i found
> that on the paging requests type 1 IMSI along with TMSI is sent.

Please note that those two identities in one paging request message have no
relation to each other.  There are simply Paging message types that allow
combination of multiple (I think up to 4x TMSI), for example.

So the important observation is that IMSIs are present in PCH messages at
all, and not that they're alongside TMSI.

> I have came to understand that first sending two identifications is the
> norm, 

a paging request can contain 1..4 identities. See above.

> but what i dont understand the high rate of sending IMSI as mobile
> identification, and as per specification its noted that either TMSI OR IMSI
> are sent,  so does that by any mean could be a configuration issues from
> the MSC/VLR side that should be changed, is this the norm? if its the norm,
> then why using TMSI.

We have limited insight into what kind of equipment operators use at the MSC/VLR,
and why that equipment behaves in certain ways.

In general, paging by IMSI _can_ be an indication that the VLR has a fixed
number of IMSI/TMSI mappings that it can store, and that this fixed limit
is overflowing, causing the VLR to "forget" older mappings.  This in turn
forces the network to page by IMSI.  Such limitations could actually be
limitations of physical resources (memory), but they could also very well
be licensing related (you might pay for the number of concurrent subscriber records).

> From your experience what are the countermeasures you think that should be
> taken from the operator side to protect against such information leaks, or
> there is nothing that an operator can do much for this ?What could be the
> different cases where the IMSI could be sent ?

I don't think there's anything more specific than:
* look at your paging channel
* check for ratio of IMSI vs. TMSI pages
* ensure your VLR doesn't overflow
* keep debugging if you can find a valid reason for this. If not, work
  with your VLR supplier to discover what's wrong.

-- 
- 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 loay.razek at gmail.com  Sun May 20 09:14:41 2018
From: loay.razek at gmail.com (loay abdelrazek)
Date: Sun, 20 May 2018 05:14:41 -0400
Subject: The reason why you see paging by IMSI in real-world GSM networks
In-Reply-To: <20180520080801.GC3639@nataraja>
References: <CALJt=69waM8KLCLC5Er3F9t=02-F2Asn2-ZmEcTDbKMSMZjS1g@mail.gmail.com>
 <20180520080801.GC3639@nataraja>
Message-ID: <CALJt=69dWxNFSfQrQ0bCgQSPpOV6tM_Jn1uF4jwerGWomB4hwQ@mail.gmail.com>

Hi Harald

Yes yes I totally understand , so what could be the cases for sending the
IMSI and what would be the possible remediation for such thing

On Sunday, 20 May 2018, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Loay,
>
> On Sun, May 20, 2018 at 03:52:55AM -0400, loay abdelrazek wrote:
> > I wanted to ask your about something regarding user privacy leakage in
> the
> > broadcast channels.  As i have been sniffing and testing myself and i
> found
> > that on the paging requests type 1 IMSI along with TMSI is sent.
>
> Please note that those two identities in one paging request message have no
> relation to each other.  There are simply Paging message types that allow
> combination of multiple (I think up to 4x TMSI), for example.
>
> So the important observation is that IMSIs are present in PCH messages at
> all, and not that they're alongside TMSI.
>
> > I have came to understand that first sending two identifications is the
> > norm,
>
> a paging request can contain 1..4 identities. See above.
>
> > but what i dont understand the high rate of sending IMSI as mobile
> > identification, and as per specification its noted that either TMSI OR
> IMSI
> > are sent,  so does that by any mean could be a configuration issues from
> > the MSC/VLR side that should be changed, is this the norm? if its the
> norm,
> > then why using TMSI.
>
> We have limited insight into what kind of equipment operators use at the
> MSC/VLR,
> and why that equipment behaves in certain ways.
>
> In general, paging by IMSI _can_ be an indication that the VLR has a fixed
> number of IMSI/TMSI mappings that it can store, and that this fixed limit
> is overflowing, causing the VLR to "forget" older mappings.  This in turn
> forces the network to page by IMSI.  Such limitations could actually be
> limitations of physical resources (memory), but they could also very well
> be licensing related (you might pay for the number of concurrent
> subscriber records).
>
> > From your experience what are the countermeasures you think that should
> be
> > taken from the operator side to protect against such information leaks,
> or
> > there is nothing that an operator can do much for this ?What could be the
> > different cases where the IMSI could be sent ?
>
> I don't think there's anything more specific than:
> * look at your paging channel
> * check for ratio of IMSI vs. TMSI pages
> * ensure your VLR doesn't overflow
> * keep debugging if you can find a valid reason for this. If not, work
>   with your VLR supplier to discover what's wrong.
>
> --
> - 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 HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180520/34cf0bd9/attachment.htm>

From djks74 at gmail.com  Sun May 20 18:53:27 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 21 May 2018 01:53:27 +0700
Subject: requesting working demo config files for 2g setup osmomsc,
 osmobsc, osmostp,osmohlr, osmomgw
In-Reply-To: <078af83c-60ae-f6f8-a57b-7f89e8c2a3b5@sysmocom.de>
References: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>
 <078af83c-60ae-f6f8-a57b-7f89e8c2a3b5@sysmocom.de>
Message-ID: <CANWiJYj3uYP1QjiaZgq-r6ogwdqWyYUvSGs-=coM6DwRRsq3Zg@mail.gmail.com>

Dear Pespin,
Does the osmo-bsc_mgcp.cfg has forgoten include on tar.gz you sent?

Can you send it that one please? Thanks.

best,
DUO

On Fri, May 18, 2018 at 10:28 PM, Pau Espin Pedrol <pespin at sysmocom.de>
wrote:

> Hi Toby,
>
> find attached my set of config files I use almost daily.
>
> It assumes your PC (Core Network) ip addr is 192.168.30.1, and the address
> of the BTS is 192.168.30.100.
>
> Take into account I'm running only 1 osmo-mgw and I make both osmo-msc and
> osmo-bsc connect to that one, in order to get rid of one more extra process.
>
> These are the commands I use to run the components:
>
> ggsn="sudo LD_LIBRARY_PATH=$mylibdir gdb -ex run --args
> $mybindir/osmo-ggsn -c $myconfdir/osmo-ggsn.cfg"
> sgsn="gdb -ex run --args $mybindir/osmo-sgsn -c $myconfdir/osmo-sgsn.cfg"
> msc="gdb -ex run --args $mybindir/osmo-msc -c $myconfdir/osmo-msc.cfg"
> hlr="gdb -ex run --args $mybindir/osmo-hlr -c $myconfdir/osmo-hlr.cfg
> --database $myconfdir/hlr.db"
> stp="gdb -ex run --args $mybindir/osmo-stp -c $myconfdir/osmo-stp.cfg"
> bsc="gdb -ex run --arg $mybindir/osmo-bsc -c $myconfdir/osmo-bsc.cfg -s"
> mgcp="gdb -ex run --arg $mybindir/osmo-bsc_mgcp -c
> $myconfdir/osmo-bsc-mgcp.cfg"
> mgw="gdb -ex run --arg $mybindir/osmo-mgw -c $myconfdir/osmo-mgw.cfg"
> bts_trx="gdb -ex run --args $mybindir/osmo-bts-trx -c
> $myconfdir/osmo-bts-trx.cfg -i 127.0.0.1 -r 1"
> pcu="$mybindir/osmo-pcu -c $myconfdir/osmo-pcu.cfg"
>
>
> --
> - 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
>



-- 
Best Regards,
Sandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180521/4f309fee/attachment.htm>

From pespin at sysmocom.de  Mon May 21 09:49:36 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 21 May 2018 11:49:36 +0200
Subject: requesting working demo config files for 2g setup osmomsc,
 osmobsc, osmostp,osmohlr, osmomgw
In-Reply-To: <CANWiJYj3uYP1QjiaZgq-r6ogwdqWyYUvSGs-=coM6DwRRsq3Zg@mail.gmail.com>
References: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>
 <078af83c-60ae-f6f8-a57b-7f89e8c2a3b5@sysmocom.de>
 <CANWiJYj3uYP1QjiaZgq-r6ogwdqWyYUvSGs-=coM6DwRRsq3Zg@mail.gmail.com>
Message-ID: <4bc53cc8-738c-45fe-6484-b462b01bcded@sysmocom.de>


On 20/05/18 20:53, Sandi Suhendro wrote:
> Dear Pespin,
> Does the osmo-bsc_mgcp.cfg has forgoten include on tar.gz you sent?

osmo-bsc_mgcp is obsolte and you should not be using that together with 
split components. You should use osmo-mgw instead, for which I already 
provided a config file.

-- 
- 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 djks74 at gmail.com  Mon May 21 10:28:59 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 21 May 2018 17:28:59 +0700
Subject: requesting working demo config files for 2g setup osmomsc,
 osmobsc, osmostp,osmohlr, osmomgw
In-Reply-To: <4bc53cc8-738c-45fe-6484-b462b01bcded@sysmocom.de>
References: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>
 <078af83c-60ae-f6f8-a57b-7f89e8c2a3b5@sysmocom.de>
 <CANWiJYj3uYP1QjiaZgq-r6ogwdqWyYUvSGs-=coM6DwRRsq3Zg@mail.gmail.com>
 <4bc53cc8-738c-45fe-6484-b462b01bcded@sysmocom.de>
Message-ID: <CANWiJYgdkUYem9TYcp-tizn+pfsx5SFfViyE2tPwYWb+vqW+Ng@mail.gmail.com>

Dear Pespin,
Thanks for explanation.
So i did use osmo-mgw only on the config you sent, but i still facing the
1st phone only hear voices and the 2nd phone not hear any voice. (It looks
like 1st phone not transnit or block by wrong configuration on my setup.

Then other problem is when i make call from 2nd phone to 1st phone, the
ring is only 1 sec then closed the connection but the caller still calling
mode.

Do you know what im facing of you think?

Thanks for any tips.

Regards,
DUO

On Mon, May 21, 2018, 16:49 Pau Espin Pedrol <pespin at sysmocom.de> wrote:

>
> On 20/05/18 20:53, Sandi Suhendro wrote:
> > Dear Pespin,
> > Does the osmo-bsc_mgcp.cfg has forgoten include on tar.gz you sent?
>
> osmo-bsc_mgcp is obsolte and you should not be using that together with
> split components. You should use osmo-mgw instead, for which I already
> provided a config file.
>
> --
> - 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180521/3a099c9e/attachment.htm>

From nhofmeyr at sysmocom.de  Tue May 22 14:52:47 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 22 May 2018 16:52:47 +0200
Subject: requesting working demo config files for 2g setup osmomsc,
 osmobsc, osmostp,osmohlr, osmomgw
In-Reply-To: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>
References: <44c64855-59b0-3a5f-625a-ef0fc3901cfe@disroot.org>
Message-ID: <20180522145247.GB24899@my.box>

On Fri, May 18, 2018 at 03:45:52PM +0300, toby wrote:
> Dear All,
> 
> I was wondering whether anyone could please provide me a set of fully
> working configuration files for a network-in-the-box setup with msc, bsc,
> stp, hlr, mgw parts (not osmo-nitb). I have successfully compiled all the
> required software from source, however, the migration guide is incomplete
> and I cannot seem to find a simple tutorial for building an osmo network
> from scratch using all the new components. I want to set up a 2g network for
> calls/sms, i don't need gprs though.

How about
http://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box
which the migration guide points at, btw.

If the migration guide is incomplete, let's complete it; start by creating a
ticket with the list of missing parts.

~N
-------------- 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/20180522/51c82e5d/attachment.bin>

From nhofmeyr at sysmocom.de  Tue May 22 15:18:32 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 22 May 2018 17:18:32 +0200
Subject: The reason why you see paging by IMSI in real-world GSM networks
In-Reply-To: <CALJt=69dWxNFSfQrQ0bCgQSPpOV6tM_Jn1uF4jwerGWomB4hwQ@mail.gmail.com>
References: <CALJt=69waM8KLCLC5Er3F9t=02-F2Asn2-ZmEcTDbKMSMZjS1g@mail.gmail.com>
 <20180520080801.GC3639@nataraja>
 <CALJt=69dWxNFSfQrQ0bCgQSPpOV6tM_Jn1uF4jwerGWomB4hwQ@mail.gmail.com>
Message-ID: <20180522151832.GC24899@my.box>

On Sun, May 20, 2018 at 05:14:41AM -0400, loay abdelrazek wrote:
> Hi Harald
> 
> Yes yes I totally understand , so what could be the cases for sending the
> IMSI and what would be the possible remediation for such thing

It sounds like you actually don't "totally" understand and are asking for a 101
on IMSI and TMSI?

The subscriber is identified to the network by its IMSI, which stays constant.

A new TMSI is given on every Location Update, meaning it changes all the time,
which is good for privacy. The network does its best to remember the last TMSI
the phone has been given.

But before the network can know who that subscriber is, things have to start
out with the IMSI. That's normally when the phone asks for a Location Update
for the first time. Usually the new TMSI is sent to the phone ciphered, so that
the IMSI <-> TMSI mapping is essentially secret.

A TMSI is short-lived and an MSC may decide not to store IMSI<->TMSI mappings
forever, for various/unknown reasons. So as soon as there is no TMSI left in
the MSC's subscriber state, the only way to page is by IMSI.

Also, the phone may have forgotten its TMSI, e.g. after roaming to a different
network.

But: AFAICT, under "proper" operations, a subscriber should have a TMSI after a
Location Update, and either detach when it leaves or be implicitly detached by
timeout. So as long as it is Page-able by the MSC, it should have a TMSI as
well. In other words, the MSC should either have a TMSI to page for, or the
subscriber's state should be "not attached", i.e. can't page anyway. Bottom
line, whenever paging goes out by IMSI, the MSC has actively decided to not
bother about privacy (by implementation, config or by licensing details).

IIRC, the only way to get an IMSI paging out of osmo-msc is to globally switch
off TMSI allocation.

~N
-------------- 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/20180522/1478524c/attachment.bin>

From loay.razek at gmail.com  Tue May 22 15:37:10 2018
From: loay.razek at gmail.com (loay abdelrazek)
Date: Tue, 22 May 2018 11:37:10 -0400
Subject: The reason why you see paging by IMSI in real-world GSM networks
In-Reply-To: <20180522151832.GC24899@my.box>
References: <CALJt=69waM8KLCLC5Er3F9t=02-F2Asn2-ZmEcTDbKMSMZjS1g@mail.gmail.com>
 <20180520080801.GC3639@nataraja>
 <CALJt=69dWxNFSfQrQ0bCgQSPpOV6tM_Jn1uF4jwerGWomB4hwQ@mail.gmail.com>
 <20180522151832.GC24899@my.box>
Message-ID: <CALJt=69sOKy2-0+TKUceHjdzwNQCAe_qFJLcfMVv-YdyhR+WMA@mail.gmail.com>

Thanks Neels, that was informative

On Tuesday, 22 May 2018, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

> On Sun, May 20, 2018 at 05:14:41AM -0400, loay abdelrazek wrote:
> > Hi Harald
> >
> > Yes yes I totally understand , so what could be the cases for sending the
> > IMSI and what would be the possible remediation for such thing
>
> It sounds like you actually don't "totally" understand and are asking for
> a 101
> on IMSI and TMSI?
>
> The subscriber is identified to the network by its IMSI, which stays
> constant.
>
> A new TMSI is given on every Location Update, meaning it changes all the
> time,
> which is good for privacy. The network does its best to remember the last
> TMSI
> the phone has been given.
>
> But before the network can know who that subscriber is, things have to
> start
> out with the IMSI. That's normally when the phone asks for a Location
> Update
> for the first time. Usually the new TMSI is sent to the phone ciphered, so
> that
> the IMSI <-> TMSI mapping is essentially secret.
>
> A TMSI is short-lived and an MSC may decide not to store IMSI<->TMSI
> mappings
> forever, for various/unknown reasons. So as soon as there is no TMSI left
> in
> the MSC's subscriber state, the only way to page is by IMSI.
>
> Also, the phone may have forgotten its TMSI, e.g. after roaming to a
> different
> network.
>
> But: AFAICT, under "proper" operations, a subscriber should have a TMSI
> after a
> Location Update, and either detach when it leaves or be implicitly
> detached by
> timeout. So as long as it is Page-able by the MSC, it should have a TMSI as
> well. In other words, the MSC should either have a TMSI to page for, or the
> subscriber's state should be "not attached", i.e. can't page anyway. Bottom
> line, whenever paging goes out by IMSI, the MSC has actively decided to not
> bother about privacy (by implementation, config or by licensing details).
>
> IIRC, the only way to get an IMSI paging out of osmo-msc is to globally
> switch
> off TMSI allocation.
>
> ~N
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180522/bee0b0bd/attachment.htm>

From loay.razek at gmail.com  Tue May 22 15:42:07 2018
From: loay.razek at gmail.com (loay abdelrazek)
Date: Tue, 22 May 2018 11:42:07 -0400
Subject: The reason why you see paging by IMSI in real-world GSM networks
In-Reply-To: <20180520080801.GC3639@nataraja>
References: <CALJt=69waM8KLCLC5Er3F9t=02-F2Asn2-ZmEcTDbKMSMZjS1g@mail.gmail.com>
 <20180520080801.GC3639@nataraja>
Message-ID: <CALJt=69YRrRqAadc5Ri_v7YpvTEVZEJt1m2Sv-Pfb7xTubzt+w@mail.gmail.com>

Thanks Harald, my bad I didn?t go through your reply throughly

Much appreciated

On Sunday, 20 May 2018, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Loay,
>
> On Sun, May 20, 2018 at 03:52:55AM -0400, loay abdelrazek wrote:
> > I wanted to ask your about something regarding user privacy leakage in
> the
> > broadcast channels.  As i have been sniffing and testing myself and i
> found
> > that on the paging requests type 1 IMSI along with TMSI is sent.
>
> Please note that those two identities in one paging request message have no
> relation to each other.  There are simply Paging message types that allow
> combination of multiple (I think up to 4x TMSI), for example.
>
> So the important observation is that IMSIs are present in PCH messages at
> all, and not that they're alongside TMSI.
>
> > I have came to understand that first sending two identifications is the
> > norm,
>
> a paging request can contain 1..4 identities. See above.
>
> > but what i dont understand the high rate of sending IMSI as mobile
> > identification, and as per specification its noted that either TMSI OR
> IMSI
> > are sent,  so does that by any mean could be a configuration issues from
> > the MSC/VLR side that should be changed, is this the norm? if its the
> norm,
> > then why using TMSI.
>
> We have limited insight into what kind of equipment operators use at the
> MSC/VLR,
> and why that equipment behaves in certain ways.
>
> In general, paging by IMSI _can_ be an indication that the VLR has a fixed
> number of IMSI/TMSI mappings that it can store, and that this fixed limit
> is overflowing, causing the VLR to "forget" older mappings.  This in turn
> forces the network to page by IMSI.  Such limitations could actually be
> limitations of physical resources (memory), but they could also very well
> be licensing related (you might pay for the number of concurrent
> subscriber records).
>
> > From your experience what are the countermeasures you think that should
> be
> > taken from the operator side to protect against such information leaks,
> or
> > there is nothing that an operator can do much for this ?What could be the
> > different cases where the IMSI could be sent ?
>
> I don't think there's anything more specific than:
> * look at your paging channel
> * check for ratio of IMSI vs. TMSI pages
> * ensure your VLR doesn't overflow
> * keep debugging if you can find a valid reason for this. If not, work
>   with your VLR supplier to discover what's wrong.
>
> --
> - 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 HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180522/7ea6d086/attachment.htm>

From keith at rhizomatica.org  Wed May 23 10:38:43 2018
From: keith at rhizomatica.org (Keith Whyte)
Date: Wed, 23 May 2018 12:38:43 +0200
Subject: React to IMSI Attach but not PERIODIC
Message-ID: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>

Hi All,

I have a use case where I'd like to react to MS connecting to the
network, that is on initial IMSI ATTACH.

We already have the SMPP alert notification mechanism which can be used,
but unfortunately in SMPP the ms_availability_status only has 3 posible
values in the spec:

0: Available

1: Denied

2: Unavailable.

So currently if I react to status 0, this would also happen on periodic LURs

I could keep state separately but that sounds prone to errors.

The external process reacting to the alert notification could try
somehow to get the previous status from HLR or database, but that sounds
like a race condition.

One possibility might be to extend this with a further custom value 3:
Available (Initial Attach) or some such?

Any thoughts?





From nhofmeyr at sysmocom.de  Wed May 23 12:34:07 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 23 May 2018 14:34:07 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
Message-ID: <20180523123407.GA17213@my.box>

On Wed, May 23, 2018 at 12:38:43PM +0200, Keith Whyte wrote:
> 0: Available
> 
> 1: Denied
> 
> 2: Unavailable.
>
> So currently if I react to status 0, this would also happen on periodic LURs

Sounds a bit like SMPP isn't actually intended to be notified of periodic LU?
After all, those are "just" a GSM implementation detail to say "yes, I'm still
here, don't implicitly detach me".

I don't know it for a fact, but my gut feel says we should simply not alert
SMPP on periodic LU at all, but only on a change of subscriber availability?

~N
-------------- 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/20180523/d68c8d62/attachment.bin>

From laforge at gnumonks.org  Wed May 23 14:55:49 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 23 May 2018 16:55:49 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <20180523123407.GA17213@my.box>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box>
Message-ID: <20180523145549.GT3639@nataraja>

Hi Keith, Neels,

On Wed, May 23, 2018 at 02:34:07PM +0200, Neels Hofmeyr wrote:

> Sounds a bit like SMPP isn't actually intended to be notified of periodic LU?
> After all, those are "just" a GSM implementation detail to say "yes, I'm still
> here, don't implicitly detach me".

SMPP alert is simply notifying the EXME that a given subscrier [again] is reachable.

So *if* the periodic LU really is periodic, and the MSC/VLR already contained
state about this imsi at the time the periodic LU arrives, then I agree we could
remove the SMPP ALERT.

However, the decision would have to be based on whether or not we have just created
new state in this VLR/MSC, and not [only] based on which LU Type the MS was requesting.

For example, I'm not sure if we'd actually reject a periodic LU at a
time where that IMSI is not marked as attached already before.  Do we
reject such a LU and somehow force the MS to perform an "IMSI ATTACH"
type LU, or doe we accept it as an implicit attach?

For "Normal" LU (LAC change), the same rules apply.  If we actually have state for
this IMSI in the VLR already, we can suppress the SMPP ALERT.  If we are
tolerating such a LU to actually create a new subscriber record in the
VLR despite not being IMSI ATTACH, then we would have to generate SMPP
ALERT.

> I don't know it for a fact, but my gut feel says we should simply not alert
> SMPP on periodic LU at all, but only on a change of subscriber availability?

ACK, with implications as stated above.

-- 
- 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 May 23 20:08:13 2018
From: keith at rhizomatica.org (Keith Whyte)
Date: Wed, 23 May 2018 22:08:13 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <20180523123407.GA17213@my.box>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box>
Message-ID: <6a7ddea2-40fd-ff62-3af0-c91a9aa75607@rhizomatica.org>



On 23/05/18 14:34, Neels Hofmeyr wrote:
>
> I don't know it for a fact, but my gut feel says we should simply not alert
> SMPP on periodic LU at all, but only on a change of subscriber availability?
I came to the same conclusion mulling it over while AFK this afternoon.
And, what's more , should we also send an "Unavailable" SMPP Alert on
subscriber expiration?




From keith at rhizomatica.org  Wed May 23 20:27:38 2018
From: keith at rhizomatica.org (Keith Whyte)
Date: Wed, 23 May 2018 22:27:38 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <20180523145549.GT3639@nataraja>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box> <20180523145549.GT3639@nataraja>
Message-ID: <08e1ea59-18a8-9a65-32df-1e1a7483222c@rhizomatica.org>


On 23/05/18 16:55, Harald Welte wrote:
> For example, I'm not sure if we'd actually reject a periodic LU at a
> time where that IMSI is not marked as attached already before.  Do we
> reject such a LU and somehow force the MS to perform an "IMSI ATTACH"
> type LU, or doe we accept it as an implicit attach?
From quick observation on legacy openBSC, we just accept the PERIODIC
LUR for a "detached" MS and update the LAC in the HLR.
So maybe the easiest thing to do is maintain this state somewhere else -
with the processing of the alert on the ESME side.

This is about Search and Rescue use, where the aim is to send
informative SMS to an MS that connects 1st time, but not on every
periodic LUR.
Not necessarily on every IMSI Attach either, although that would be
acceptable. But best to store an "intro sent" state in the ESME, even if
only in memory.
Another way to do it might be to connect something to the
subscriber-create-on-demand routine that generate an SMS, but then if
the phone was disconnected, changed hands, and reconnected, the new
owner would not be informed..




From babarbuttgrt at yahoo.com  Wed May 23 22:23:48 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Wed, 23 May 2018 22:23:48 +0000 (UTC)
Subject: Compiler Error OsmocomTRX
In-Reply-To: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
Message-ID: <919359332.4725750.1527114228097@mail.yahoo.com>

I?received?following error while compling osmo-trx on rasbian, i have already build libosmocore-0-11-0 from source and?installed but despite this still unable to compile osmo-trx, any?one can help to resolve the issue!
configure: error: Package requirements (libosmocore >= 0.11.0) were not met:
Requested ?libosmocore >= 0.11.0? but version of Osmocom Core Library is UNKNOWN
Consider adjusting the PKG_CONFIG_PATH environment variable if you?installed software in a non-standard prefix.?

I have already build following components on Rasbian from source successfully
LimeSuite?SoapySDR?SoapyUHD?libosmocore-0.11.0/ libosmocore-0.96.0
RegardsBabar



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180523/120e5163/attachment.htm>

From laforge at gnumonks.org  Thu May 24 06:47:26 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 May 2018 08:47:26 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <919359332.4725750.1527114228097@mail.yahoo.com>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
Message-ID: <20180524064726.GY3639@nataraja>

Hi Babar,

On Wed, May 23, 2018 at 10:23:48PM +0000, Babar Ali wrote:
> I?received?following error while compling osmo-trx on rasbian, i have already build libosmocore-0-11-0 from source and?installed but despite this still unable to compile osmo-trx, any?one can help to resolve the issue!

You must have been doing something wrong either during building that version, or
during installation.

The problem you are describing is a rather generic problem when building FOSS from
source using autotools and pkg-config, nothing that really seems to related to
a problem with the Osmocom stack.

> configure: error: Package requirements (libosmocore >= 0.11.0) were not met:

I can assure you that if you actually built a 0.11.0 version, the dependency check
will work.  We have automatic compile tests of every single change we make,
and we're automatically building debian packages every night in Osmocom, and there
have not been any issues with missed dependencies or wrong versions.

Please thoroughly check your local system or start from a clean system.

> Requested ?libosmocore >= 0.11.0? but version of Osmocom Core Library is UNKNOWN

This clearly shows that you have somehow messed up the compilation/installation
process, and that the pkg-config file for libosmocore was generated wrongly.

-- 
- 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 akibsayyed at gmail.com  Thu May 24 10:02:39 2018
From: akibsayyed at gmail.com (Akib Sayyed)
Date: Thu, 24 May 2018 14:02:39 +0400
Subject: IPAccess Nanobts error
Message-ID: <CAMG-S93R-A6M1POYnrKCmfSwCzBUZSwKokCtPgT_SLuj2pgArg@mail.gmail.com>

Dear list

I am trying to register IPAccess NanotBTS using OsmoNiTB after some time
BTS gives error and restarts. I have attached log of osmonitb.

Here is some part of log

ERROR <0004> (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Abis RSL rx IPACC:
mismatching chan_nr=0x08
ERROR <0004> (bts=0,trx=0,ts=1,pchan=SDCCH8) Abis RSL rx IPACC: mismatching
chan_nr=0x09
BTS 0: Failure Event Report: Type=processing failure, Severity=warning
level failure, Probable cause=Manufacturer specific values: Software
warning, Additional Text=9105:WARN:OAM_RES:res_trx_status.c#209:TRX is not
responding - reinitialising t.
BTS 0: Failure Event Report: Type=processing failure, Severity=warning
level failure, Probable cause=Manufacturer specific values: Software
warning, Additional Text=FSM Unhandled Event class=Baseband Transceiver
inst=0 ev="DISABLED RSP" st=ini.
BTS 0: Failure Event Report: Type=processing failure, Severity=warning
level failure, Probable cause=Manufacturer specific values: Software
warning, Additional Text=FSM Unhandled Event class=Channel inst=0
ev="DISABLED RSP" st=initial


-- 
Akib Sayyed
Matrix-Shell
akibsayyed at gmail.com
akibsayyed at matrixshell.com
Mob:- +91-966-514-2243
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180524/d9c5a14f/attachment.htm>
-------------- next part --------------
NOTICE <0004> bootstrapping RSL for BTS/TRX (0/0) on ARFCN 514 using MCC-MNC 001-01 LAC=1 CID=0 BSIC=63
ERROR <0004> (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Abis RSL rx IPACC: mismatching chan_nr=0x08
ERROR <0004> (bts=0,trx=0,ts=1,pchan=SDCCH8) Abis RSL rx IPACC: mismatching chan_nr=0x09
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=9105:WARN:OAM_RES:res_trx_status.c#209:TRX is not responding - reinitialising t. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Baseband Transceiver inst=0 ev="DISABLED RSP" st=ini. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=0 ev="DISABLED RSP" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=1 ev="DISABLED RSP" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=2 ev="DISABLED RSP" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=3 ev="DISABLED RSP" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=4 ev="DISABLED RSP" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=5 ev="DISABLED RSP" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Radio Carrier inst=0 ev="DISABLED RSP" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Baseband Transceiver inst=0 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=0 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=1 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=6 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=7 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=2 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=3 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=4 ev="OFF REQ" st=initial
. 
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=FSM Unhandled Event class=Channel inst=5 ev="OFF REQ" st=initial
. 
ERROR <0005> Got SET CHANNEL ATTRIBUTE NACK going to drop the OML links.
ERROR <0022> Lost some E1 TEI link: 1 0x7fab37450070
ERROR <0022> Lost some E1 TEI link: 2 0x7fab37450070

From nhofmeyr at sysmocom.de  Thu May 24 13:47:57 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 24 May 2018 15:47:57 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <08e1ea59-18a8-9a65-32df-1e1a7483222c@rhizomatica.org>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box> <20180523145549.GT3639@nataraja>
 <08e1ea59-18a8-9a65-32df-1e1a7483222c@rhizomatica.org>
Message-ID: <20180524134757.GA1529@my.box>

On Wed, May 23, 2018 at 10:27:38PM +0200, Keith Whyte wrote:
> From quick observation on legacy openBSC, we just accept the PERIODIC
> LUR for a "detached" MS and update the LAC in the HLR.

Perodic LU applies to attached MS, not detached ones.
Have you got the logic reversed, or is that a bug?

And the legacy OpenBSC has no osmo-hlr, you're referring to the sqlite db?

~N
-------------- 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/20180524/16fd0636/attachment.bin>

From nhofmeyr at sysmocom.de  Thu May 24 13:54:40 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 24 May 2018 15:54:40 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180524064726.GY3639@nataraja>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja>
Message-ID: <20180524135440.GC1529@my.box>

On Thu, May 24, 2018 at 08:47:26AM +0200, Harald Welte wrote:
> > Requested ?libosmocore >= 0.11.0? but version of Osmocom Core Library is UNKNOWN

An idea here is that we determine the version from git, or otherwise put a
.version file in a tar when generating a tar. If you were to take the source
code and autoconf/configure it without either of those, you should get UNKNOWN.

HTH
~N
-------------- 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/20180524/fe6be9a6/attachment.bin>

From nhofmeyr at sysmocom.de  Thu May 24 14:04:27 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 24 May 2018 16:04:27 +0200
Subject: IPAccess Nanobts error
In-Reply-To: <CAMG-S93R-A6M1POYnrKCmfSwCzBUZSwKokCtPgT_SLuj2pgArg@mail.gmail.com>
References: <CAMG-S93R-A6M1POYnrKCmfSwCzBUZSwKokCtPgT_SLuj2pgArg@mail.gmail.com>
Message-ID: <20180524140427.GD1529@my.box>

On Thu, May 24, 2018 at 02:02:39PM +0400, Akib Sayyed wrote:
> Dear list
> 
> I am trying to register IPAccess NanotBTS using OsmoNiTB after some time
> BTS gives error and restarts. I have attached log of osmonitb.
> 
> Here is some part of log
> 
> ERROR <0004> (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Abis RSL rx IPACC:
> mismatching chan_nr=0x08

Can confirm that for CCCH+SDCCH4, chan_nr should not be 0x08 but 0x20.

> ERROR <0004> (bts=0,trx=0,ts=1,pchan=SDCCH8) Abis RSL rx IPACC: mismatching
> chan_nr=0x09

For SDDCH8, chan_nr should be 0x41

So something is definitely amiss, maybe you need to work around some of the
quirks of the nanoBTS I've heard about? Like, what was it, you need to send the
config twice? You need to send some parts of the config separately? Reboot
after configuring? Not sure exactly, but that are the things I've overheard
here and there. Maybe someone else has a pointer or a hint...

~N

-------------- 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/20180524/90413ea2/attachment.bin>

From laforge at gnumonks.org  Thu May 24 14:07:06 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 May 2018 16:07:06 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180524135440.GC1529@my.box>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
Message-ID: <20180524140706.GJ3639@nataraja>

On Thu, May 24, 2018 at 03:54:40PM +0200, Neels Hofmeyr wrote:
> On Thu, May 24, 2018 at 08:47:26AM +0200, Harald Welte wrote:
> > > Requested ?libosmocore >= 0.11.0? but version of Osmocom Core Library is UNKNOWN
> 
> An idea here is that we determine the version from git, or otherwise put a
> .version file in a tar when generating a tar. If you were to take the source
> code and autoconf/configure it without either of those, you should get UNKNOWN.

yes, but where would you "take" related source code from?
* git repository contains .git and thus git-version-gen works
* "make dist" generates a tarball with .version (just verified)

Where else would you get the source code from?

-- 
- 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 babarbuttgrt at yahoo.com  Thu May 24 15:14:32 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Thu, 24 May 2018 15:14:32 +0000 (UTC)
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180524140706.GJ3639@nataraja>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
Message-ID: <769075290.4981204.1527174872822@mail.yahoo.com>

Hi Neels & Harald
Thanks your for your help & support, i just grabbed tar file direct using wget
wget?https://github.com/osmocom/libosmocore/archive/0.11.0.tar.gz
and extracted and build
Regards

Babar Ali
 

    On Thursday, 24 May 2018, 7:10:06 PM GMT+5, Harald Welte <laforge at gnumonks.org> wrote:  
 
 On Thu, May 24, 2018 at 03:54:40PM +0200, Neels Hofmeyr wrote:
> On Thu, May 24, 2018 at 08:47:26AM +0200, Harald Welte wrote:
> > > Requested ?libosmocore >= 0.11.0? but version of Osmocom Core Library is UNKNOWN
> 
> An idea here is that we determine the version from git, or otherwise put a
> .version file in a tar when generating a tar. If you were to take the source
> code and autoconf/configure it without either of those, you should get UNKNOWN.

yes, but where would you "take" related source code from?
* git repository contains .git and thus git-version-gen works
* "make dist" generates a tarball with .version (just verified)

Where else would you get the source code from?

-- 
- 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 HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180524/ad07c1a3/attachment.htm>

From laforge at gnumonks.org  Thu May 24 15:26:36 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 24 May 2018 17:26:36 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <769075290.4981204.1527174872822@mail.yahoo.com>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
Message-ID: <20180524152636.GM3639@nataraja>

Hi Babar,

On Thu, May 24, 2018 at 03:14:32PM +0000, Babar Ali wrote:
> Thanks your for your help & support, i just grabbed tar file direct using wget
> wget?https://github.com/osmocom/libosmocore/archive/0.11.0.tar.gz

Where did you find instructions that this would work?

-- 
- 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 babarbuttgrt at yahoo.com  Thu May 24 15:39:49 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Thu, 24 May 2018 15:39:49 +0000 (UTC)
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180524152636.GM3639@nataraja>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
Message-ID: <2017265492.1085139.1527176389308@mail.yahoo.com>

Hi Harald?
i just tired myself, no one has suggested to compile this way, I am newbie in this radio world, and much eager to learn about gsm,
Would you please suggest me the right way to dig into this world, as i have no prerequisite knowledge about this world, but just and little much I've just searched on internet and tried to start learning.

Regards

Babar Ali
 

    On Thursday, 24 May 2018, 8:30:09 PM GMT+5, Harald Welte <laforge at gnumonks.org> wrote:  
 
 Hi Babar,

On Thu, May 24, 2018 at 03:14:32PM +0000, Babar Ali wrote:
> Thanks your for your help & support, i just grabbed tar file direct using wget
> wget?https://github.com/osmocom/libosmocore/archive/0.11.0.tar.gz

Where did you find instructions that this would work?

-- 
- 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 HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180524/ef0c4a3a/attachment.htm>

From babarbuttgrt at yahoo.com  Thu May 24 16:10:17 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Thu, 24 May 2018 16:10:17 +0000 (UTC)
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180524152636.GM3639@nataraja>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
Message-ID: <2018140242.4999729.1527178217593@mail.yahoo.com>

hi harald?
i am still unable complie & install osmotrx here attached complete compile log, would you please point out where is mistake.

Regards

Babar Ali
 

    On Thursday, 24 May 2018, 8:30:09 PM GMT+5, Harald Welte <laforge at gnumonks.org> wrote:  
 
 Hi Babar,

On Thu, May 24, 2018 at 03:14:32PM +0000, Babar Ali wrote:
> Thanks your for your help & support, i just grabbed tar file direct using wget
> wget?https://github.com/osmocom/libosmocore/archive/0.11.0.tar.gz

Where did you find instructions that this would work?

-- 
- 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 HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180524/a36b3bcd/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: complie log.txt
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180524/a36b3bcd/attachment.txt>

From djks74 at gmail.com  Fri May 25 02:51:32 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Fri, 25 May 2018 09:51:32 +0700
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180524152636.GM3639@nataraja>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja>
 <20180524135440.GC1529@my.box> <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
Message-ID: <CANWiJYhQaRU9QqGhO+Z8rK6CYbhEtKDQ6eiLKbmixdPa+Z137w@mail.gmail.com>

HI Babar,
just use git clone. here is some example / tips for you
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_with_Asterisk/

hope that helps.

regards,
DUO

On Thu, May 24, 2018 at 10:26 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Babar,
>
> On Thu, May 24, 2018 at 03:14:32PM +0000, Babar Ali wrote:
> > Thanks your for your help & support, i just grabbed tar file direct
> using wget
> > wget https://github.com/osmocom/libosmocore/archive/0.11.0.tar.gz
>
> Where did you find instructions that this would work?
>
> --
> - 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)
>



-- 
Best Regards,
Sandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180525/ca1198ee/attachment.htm>

From laforge at gnumonks.org  Fri May 25 07:00:33 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 25 May 2018 09:00:33 +0200
Subject: OsmoCon 2018 CfP / submit your topic[s] *now* !
Message-ID: <20180525070033.GC667@nataraja>

Dear Osmocom community,

one of the main difficulty with OsmoCon 2017 last year was that nobody
submitted talks / discussions within the deadline, early enough to allow
for proper planning.

This lead to the situation where the sysmocom team had to come up with
a schedule/agenda on their own.  Later on *much after the CfP deadline*,
people then squeezed in talks, making the overall schedule too full.

It is up to you to avoid this situation again in 2018 by submitting your
talk *RIGHT NOW*.  We will be very strict regarding late submissions.  So
if you would like to shape the Agenda of OsmoCon 2018, this is your
chance.  Please use it.

We will have to create a schedule soon, as [almost] nobody will register
to a conference unless the schedule is known.  If there's not sufficient
contribution in terms of CfP response from the wider community, don't
complain later that 90% of the talks are from sysmocom team members and
only about the Cellular Network Infrastructure topics.

You have been warned.  Please make your CfP submission in time at
	https://pretalx.sysmocom.de/osmocon2018/cfp

before the CfP deadline on
	*2018-05-30 23:59 (Europe/Berlin)*

Thanks for your kind attention.  Looking forward to meet with the
community at OsmoCon 2018 in October.

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 nhofmeyr at sysmocom.de  Fri May 25 11:49:34 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 25 May 2018 13:49:34 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <2017265492.1085139.1527176389308@mail.yahoo.com>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
 <2017265492.1085139.1527176389308@mail.yahoo.com>
Message-ID: <20180525114934.GA16483@my.box>

Oh geez -- if one goes to github, clicks on "releases", one gets a link to a
tar that obviously is just the source tree without a .version file.

Maybe we should add an explicit check to our build that errors out if the
version is unknown?

Babar, the best course would be to install the latest packages from our feeds,
or to build from source using a git clone.

http://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
http://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source

~N
-------------- 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/20180525/f2961c8a/attachment.bin>

From nhofmeyr at sysmocom.de  Fri May 25 12:06:28 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 25 May 2018 14:06:28 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <2018140242.4999729.1527178217593@mail.yahoo.com>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
 <2018140242.4999729.1527178217593@mail.yahoo.com>
Message-ID: <20180525120628.GB16483@my.box>

On Thu, May 24, 2018 at 04:10:17PM +0000, Babar Ali wrote:
> hi harald?
> i am still unable complie & install osmotrx here attached complete compile log, would you please point out where is mistake.

I can't see any mistake there. 'make install' went through fine and succeeded.
If there are errors besides the compiler warnings, they are not in your mail.
Errors are usually given away by the word "error" :P

You should find stuff installed in /usr/local/bin/, might need to add that to
your PATH env.

Are you aware that you built as 'root'? You usually don't want to do that,
except maybe the 'make install' step.

Your system's name is "nanoBTS" -- you are aware that osmo-trx is used for SDR
hardware and is not applicable to a nanoBTS in the slightest?

~N

-------------- 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/20180525/5ce3cc19/attachment.bin>

From babarbuttgrt at yahoo.com  Fri May 25 17:53:26 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Fri, 25 May 2018 17:53:26 +0000 (UTC)
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180525114934.GA16483@my.box>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
 <2017265492.1085139.1527176389308@mail.yahoo.com>
 <20180525114934.GA16483@my.box>
Message-ID: <1741205042.5460557.1527270806429@mail.yahoo.com>

Thank You Neels
Now i?ll try to build the source using git clone
But git tag -l does not shows 0.11.0 version it only shows the version till 0.96.0


Sent from Yahoo Mail for iPhone


On Friday, May 25, 2018, 4:49 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

Oh geez -- if one goes to github, clicks on "releases", one gets a link to a
tar that obviously is just the source tree without a .version file.

Maybe we should add an explicit check to our build that errors out if the
version is unknown?

Babar, the best course would be to install the latest packages from our feeds,
or to build from source using a git clone.

http://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages
http://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source

~N



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180525/97fe891b/attachment.htm>

From babarbuttgrt at yahoo.com  Fri May 25 18:03:23 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Fri, 25 May 2018 18:03:23 +0000 (UTC)
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180525120628.GB16483@my.box>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
 <2018140242.4999729.1527178217593@mail.yahoo.com>
 <20180525120628.GB16483@my.box>
Message-ID: <1019202499.5438972.1527271403108@mail.yahoo.com>

I just make it using root user and then make install,
Did you noticed in complier log which shows ?Nothing to be done for install..... in most cases ! What does its mean??
I just changed my raspbian host name as nanoBTS, i already aware that osmos-trx works for SDR!
Presently i am compiling it to work with LimeSDR mini, would you please suggest which version will work perfectly with LimeSDR mini??
Thank You
Regards
Babar

On Friday, May 25, 2018, 5:06 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

On Thu, May 24, 2018 at 04:10:17PM +0000, Babar Ali wrote:
> hi harald?
> i am still unable complie & install osmotrx here attached complete compile log, would you please point out where is mistake.

I can't see any mistake there. 'make install' went through fine and succeeded.
If there are errors besides the compiler warnings, they are not in your mail.
Errors are usually given away by the word "error" :P

You should find stuff installed in /usr/local/bin/, might need to add that to
your PATH env.

Are you aware that you built as 'root'? You usually don't want to do that,
except maybe the 'make install' step.

Your system's name is "nanoBTS" -- you are aware that osmo-trx is used for SDR
hardware and is not applicable to a nanoBTS in the slightest?

~N



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180525/59c508d6/attachment.htm>

From djks74 at gmail.com  Sat May 26 02:35:29 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Sat, 26 May 2018 09:35:29 +0700
Subject: osmo-trx and osmo-bts-trx ip address with LimeSDR
Message-ID: <CANWiJYihZ9hM34a5g0=0CuNEvY5YdVW2-08gVT16_uOjhMLawg@mail.gmail.com>

Dear list,
I have question about osmo-trx config with osmo-bts-trx.

if in osmo-bts-trx
 osmotrx ip local 192.168.100.73
 osmotrx ip remote 192.168.100.100

then what ip address fill on osmo-trx for limesdr.cfg?

 bind-ip 192.168.100.73
 remote-ip 192.168.100.100

Please correct me, cause I confuse osmo-trx won't running if not using same
ip as 127.0.0.1

well,
Does 127.0.0.1 is fine for only sms/call network in new split?

please advise. Thanks.

-- 
Best Regards,
DUO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180526/1bad8e1c/attachment.htm>

From babarbuttgrt at yahoo.com  Sat May 26 16:54:50 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Sat, 26 May 2018 16:54:50 +0000 (UTC)
Subject: Compiler Error OsmocomTRX
In-Reply-To: <20180525120628.GB16483@my.box>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
 <2018140242.4999729.1527178217593@mail.yahoo.com>
 <20180525120628.GB16483@my.box>
Message-ID: <673776793.5676985.1527353690264@mail.yahoo.com>

Hi Neels?
I just made fresh insallation rasbian, again tried to build osmot-trx
I am able to make and install only following binaries.
1:- osmo-trx-uhd2:- osmo-trx-lms <? build with limesdr support
But make install did not build osmo-trx binary, nither i have found in /usr/local/bin?
Would you please help/guide me the right way.
Regards
Babar

On Friday, May 25, 2018, 5:06 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:

On Thu, May 24, 2018 at 04:10:17PM +0000, Babar Ali wrote:
> hi harald?
> i am still unable complie & install osmotrx here attached complete compile log, would you please point out where is mistake.

I can't see any mistake there. 'make install' went through fine and succeeded.
If there are errors besides the compiler warnings, they are not in your mail.
Errors are usually given away by the word "error" :P

You should find stuff installed in /usr/local/bin/, might need to add that to
your PATH env.

Are you aware that you built as 'root'? You usually don't want to do that,
except maybe the 'make install' step.

Your system's name is "nanoBTS" -- you are aware that osmo-trx is used for SDR
hardware and is not applicable to a nanoBTS in the slightest?

~N



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180526/8b52e049/attachment.htm>

From nhofmeyr at sysmocom.de  Sun May 27 23:27:20 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 28 May 2018 01:27:20 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <673776793.5676985.1527353690264@mail.yahoo.com>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
 <2018140242.4999729.1527178217593@mail.yahoo.com>
 <20180525120628.GB16483@my.box>
 <673776793.5676985.1527353690264@mail.yahoo.com>
Message-ID: <20180527232720.GA31340@my.box>

I already pointed you at the wiki page describing how to build from source, and
already commented that your build log looks perfectly fine.

"Nothing to be done for install" happens only in source directories where, hold
your breath, nothing needs to be installed. If you get no "error", then there
is no error, as I did actually mention before.

The problem you are having should be super trivial -- it doesn't seem to be
specific to Osmocom.

I will not try to solve it by email, which is very inefficient for this kind of
problem. I hope you can get someone to help you out with it, maybe taking a
peek over your shoulder. For all I can tell you're already done.

~N
-------------- 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/20180528/9bb07e97/attachment.bin>

From keith at rhizomatica.org  Mon May 28 07:36:59 2018
From: keith at rhizomatica.org (Keith Whyte)
Date: Mon, 28 May 2018 09:36:59 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <20180524134757.GA1529@my.box>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box> <20180523145549.GT3639@nataraja>
 <08e1ea59-18a8-9a65-32df-1e1a7483222c@rhizomatica.org>
 <20180524134757.GA1529@my.box>
Message-ID: <48a199ee-b1bc-71aa-ae6e-cdfd22c741bf@rhizomatica.org>



On 24/05/18 15:47, Neels Hofmeyr wrote:
> On Wed, May 23, 2018 at 10:27:38PM +0200, Keith Whyte wrote:
>> From quick observation on legacy openBSC, we just accept the PERIODIC
>> LUR for a "detached" MS and update the LAC in the HLR.
> Perodic LU applies to attached MS, not detached ones.
Yes.. but  "detached", according to who?
> Have you got the logic reversed, or is that a bug?
Here's what I did.
1) Power on MS, Let it IMSI Attach.
2) Mark the MS as detached in HLR (sqlite)
3) Wait for the PERIODIC LUR.

>
> And the legacy OpenBSC has no osmo-hlr, you're referring to the sqlite db?
Yes, of course.
>
> ~N



From keith at rhizomatica.org  Mon May 28 07:52:35 2018
From: keith at rhizomatica.org (Keith Whyte)
Date: Mon, 28 May 2018 09:52:35 +0200
Subject: Writing FPLMS to SIM
Message-ID: <7d4a853a-2d3e-b38b-1f0e-83807a29af1b@rhizomatica.org>

Hi all

Somebody mentioned recently (at osmodevcon was it?) about writing to the
FPLMNS list to avoid service loss due to
LUR reject cause 11 (I think?)

I notice we don't seem to have this an a option in pySim-prog.py, so I
am wondering what tool was used?

Thanks!


(I noted the commented FIXME section for HPLMN in pySim.read.py and from
there was able to modify read address and read and decipher the FPLMN
list, although i did not get a nice readable output format yet.)




From laforge at gnumonks.org  Mon May 28 08:05:25 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 28 May 2018 10:05:25 +0200
Subject: Writing FPLMS to SIM
In-Reply-To: <7d4a853a-2d3e-b38b-1f0e-83807a29af1b@rhizomatica.org>
References: <7d4a853a-2d3e-b38b-1f0e-83807a29af1b@rhizomatica.org>
Message-ID: <20180528080525.GF11424@nataraja>

Hi Keith,

On Mon, May 28, 2018 at 09:52:35AM +0200, Keith Whyte wrote:
> Somebody mentioned recently (at osmodevcon was it?) about writing to the
> FPLMNS list to avoid service loss due to LUR reject cause 11 (I think?)

Yes, this is what's done e.g. at CCC event networks.

> I notice we don't seem to have this an a option in pySim-prog.py, so I
> am wondering what tool was used?

AFAIR a not published (probably too hackish?) tool originally written by Kevin Redon.

I think it simply sends the raw hex encoded file as part of a WRITE BINARY APDU.
But Kevin (Cc) should know better...

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 pespin at sysmocom.de  Mon May 28 08:47:55 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Mon, 28 May 2018 10:47:55 +0200
Subject: Compiler Error OsmocomTRX
In-Reply-To: <673776793.5676985.1527353690264@mail.yahoo.com>
References: <mailman.0.1527113981.74974.openbsc@lists.osmocom.org>
 <919359332.4725750.1527114228097@mail.yahoo.com>
 <20180524064726.GY3639@nataraja> <20180524135440.GC1529@my.box>
 <20180524140706.GJ3639@nataraja>
 <769075290.4981204.1527174872822@mail.yahoo.com>
 <20180524152636.GM3639@nataraja>
 <2018140242.4999729.1527178217593@mail.yahoo.com>
 <20180525120628.GB16483@my.box>
 <673776793.5676985.1527353690264@mail.yahoo.com>
Message-ID: <409f6274-04f0-b2be-4538-f97318ed2174@sysmocom.de>


> I am able to make and install only following binaries.
> 
> 1:- osmo-trx-uhd
> 2:- osmo-trx-lms <? build with limesdr support
> 
> But make install did not build osmo-trx binary, nither i have found in 
> /usr/local/bin
> 

As of current master, osmo-trx no longer exists. It was replaced by 
osmo-trx-uhd, so you should use that one most probably.

-- 
- 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 kevredon at mail.tsaitgaist.info  Mon May 28 09:00:14 2018
From: kevredon at mail.tsaitgaist.info (Kevin Redon)
Date: Mon, 28 May 2018 11:00:14 +0200
Subject: Writing FPLMS to SIM
In-Reply-To: <20180528080525.GF11424@nataraja>
References: <7d4a853a-2d3e-b38b-1f0e-83807a29af1b@rhizomatica.org>
 <20180528080525.GF11424@nataraja>
Message-ID: <20180528090014.GA25843@coil>

On Mon, May 28, 2018 at 10:05:25AM +0200, Harald Welte wrote:
> AFAIR a not published (probably too hackish?) tool originally written by Kevin Redon.
> 
> I think it simply sends the raw hex encoded file as part of a WRITE BINARY APDU.
> But Kevin (Cc) should know better...

I used two programs to write the SIM file containing the list of forbidden PLMN (EF_FPLMN).
The first is in C and was used to provision SIM cards (e.g. writing a lot of other files).
The second is easier and more convenient to use. It's a scriptor script. Scriptor is a tool included in the pcsc-tool package (also providing pcsc_check) which allows to send raw APDU through PCSC card readers.

Here the script:
#!/usr/bin/env scriptor
reset
# select MF
a0 a4 00 00 02 3f 00
# select DF_GSM
a0 a4 00 00 02 7f 20
# verify ADM
#A0 20 00 05 08 xx xx xx xx xx xx xx xx
# select EF_FPLMN
a0 a4 00 00 02 6f 7b
# write binary EF_FPLMN (forbid 262 01, 262 02, 262 03, 262 07)
a0 d6 00 00 0c 62 f2 10 62 f2 20 62 f2 30 62 f2 70

put that in a file and run it using scriptor
this script has the advantage to work with SIMs and USIMs, and is easy to modify.
the FPLMN file can be updated by the user, but you need to verify CHV1/PIN1 (e.g. the PIN) if it is set.
to avoid asking the user his pin when updating the card I just used the ADM pin (# verify ADM line), which was static for the SIM cards provided up to 31c3.
the list of FPLMN is 262 01, 262 02, 262 03, 262 07. You can read it in the file content (swap nibble, f padded, e.g. 262 01 becomes 62 f2 10). When addind/removing data from this hex string, don't forget to update the length field (0c here).


From nhofmeyr at sysmocom.de  Mon May 28 10:41:01 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 28 May 2018 12:41:01 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <48a199ee-b1bc-71aa-ae6e-cdfd22c741bf@rhizomatica.org>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box> <20180523145549.GT3639@nataraja>
 <08e1ea59-18a8-9a65-32df-1e1a7483222c@rhizomatica.org>
 <20180524134757.GA1529@my.box>
 <48a199ee-b1bc-71aa-ae6e-cdfd22c741bf@rhizomatica.org>
Message-ID: <20180528104101.GA1498@my.box>

On Mon, May 28, 2018 at 09:36:59AM +0200, Keith Whyte wrote:
> 
> 
> On 24/05/18 15:47, Neels Hofmeyr wrote:
> > On Wed, May 23, 2018 at 10:27:38PM +0200, Keith Whyte wrote:
> >> From quick observation on legacy openBSC, we just accept the PERIODIC
> >> LUR for a "detached" MS and update the LAC in the HLR.
> > Perodic LU applies to attached MS, not detached ones.

Ah, I understand now. I got the wording the wrong way, thought you wrote "we
accept Periodic LU *only* for detached MS" while you meant to say "when a
Periodic LU comes in for a detached phone, we simply accept it".

Ok, yes, the idea remains: not trigger SMPP signals on the periodic-ness of the
LU, but rather wherever the MSC decides to change between "attached" and
"detached".

Whether a "periodic" lu is then also accepted as "imsi attach" or not is then
a mere implementation detail of the MSC.

~N
-------------- 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/20180528/a390d20e/attachment.bin>

From keith at rhizomatica.org  Mon May 28 11:09:34 2018
From: keith at rhizomatica.org (Keith Whyte)
Date: Mon, 28 May 2018 13:09:34 +0200
Subject: Writing FPLMS to SIM
In-Reply-To: <20180528090014.GA25843@coil>
References: <7d4a853a-2d3e-b38b-1f0e-83807a29af1b@rhizomatica.org>
 <20180528080525.GF11424@nataraja> <20180528090014.GA25843@coil>
Message-ID: <d43a9968-17e2-8783-da4c-b54137e7a3d8@rhizomatica.org>



On 28/05/18 11:00, Kevin Redon wrote:
>
> I used two programs to write the SIM file containing the list of forbidden PLMN (EF_FPLMN).
> The first is in C and was used to provision SIM cards (e.g. writing a lot of other files).
> The second is easier and more convenient to use. It's a scriptor script. 
Thanks Kevin!

I was looking at pySim - I've now got pySim-read.py to output the FPLMN
list formatted for human reading, although my code is probably not yet
best practice pythonic. :-)

I will try to see if I can reverse that logic and include FPLMN list
updating in pySim-prog.py




From keith at rhizomatica.org  Mon May 28 11:14:15 2018
From: keith at rhizomatica.org (Keith Whyte)
Date: Mon, 28 May 2018 13:14:15 +0200
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <20180528104101.GA1498@my.box>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box> <20180523145549.GT3639@nataraja>
 <08e1ea59-18a8-9a65-32df-1e1a7483222c@rhizomatica.org>
 <20180524134757.GA1529@my.box>
 <48a199ee-b1bc-71aa-ae6e-cdfd22c741bf@rhizomatica.org>
 <20180528104101.GA1498@my.box>
Message-ID: <f8211406-ac54-a426-59a6-0de2f783ed2f@rhizomatica.org>



On 28/05/18 12:41, Neels Hofmeyr wrote:
> Ah, I understand now. I got the wording the wrong way, thought you wrote "we
> accept Periodic LU *only* for detached MS" while you meant to say "when a
> Periodic LU comes in for a detached phone, we simply accept it".

Ah yes. Sorry. "just" can be ambiguous in English. I should endeavor to
not use it.


>
> Ok, yes, the idea remains: not trigger SMPP signals on the periodic-ness of the
> LU, but rather wherever the MSC decides to change between "attached" and
> "detached".

For the moment, what I've done is extend the SMPP availability statuses
and send a different status for IMSI_ATTACH to PERIODIC
The my SMPP listener is reacting differently depending on the status..
This works for the moment for the application in hand, but I assume it's
not something we want to be concerned about in master.

k




From domi at tomcsanyi.net  Tue May 29 15:42:32 2018
From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi=2C?= Domonkos)
Date: Tue, 29 May 2018 17:42:32 +0200 (CEST)
Subject: UICC with ISIM application
Message-ID: <1801956005.8566.1527608552840.JavaMail.zimbra@tomcsanyi.net>

Hello All, 

Sorry if this is an off-topic question, but I was wondering: does anyone know of any carrier that actually uses a UICC ('SIM card') with the ISIM application installed? So far all cards I saw have only USIM, maybe CSIM on them. I'd like to extend Benoit's card library with ISIM support, but there is no way to test my code right now, so I'm thinking about buying maybe a card. 

Thanks. 

Domi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/bc44daf9/attachment.htm>

From laforge at gnumonks.org  Tue May 29 15:59:21 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 29 May 2018 17:59:21 +0200
Subject: UICC with ISIM application
In-Reply-To: <1801956005.8566.1527608552840.JavaMail.zimbra@tomcsanyi.net>
References: <1801956005.8566.1527608552840.JavaMail.zimbra@tomcsanyi.net>
Message-ID: <20180529155921.GM5680@nataraja>

Hi Domi,

On Tue, May 29, 2018 at 05:42:32PM +0200, Tomcs?nyi, Domonkos wrote:
> Sorry if this is an off-topic question, 

no problem.

> I'd like to extend Benoit's card library with ISIM support, but there is no way to test my code right now, so I'm thinking about buying maybe a card. 

We will be sourcing samples of ISIM-enabled cards for our next generation sysmoUSIM
soon, but right now we don't have them yet.

In terms of public operators, I honestly don't know.  I haven't bought any subscriptions/SIM
cards recently.

I would expect that LTE/IMS enabled MVNOs are more likely to use the ISIM applications than the
classic MNOs.

-- 
- 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 pshinjo at sect.tu-berlin.de  Tue May 29 15:55:33 2018
From: pshinjo at sect.tu-berlin.de (Shinjo Park)
Date: Tue, 29 May 2018 17:55:33 +0200
Subject: UICC with ISIM application
In-Reply-To: <1801956005.8566.1527608552840.JavaMail.zimbra@tomcsanyi.net>
References: <1801956005.8566.1527608552840.JavaMail.zimbra@tomcsanyi.net>
Message-ID: <2198070.HudFgU0ziR@brandenburg>

Hi Domi,

According to osmo-sim-auth, 3 Austria, AT&T USA, T-Mobile USA has ISIM applet 
installed. 3 Austria card was purchased in late 2016, both USA cards in ~2012. 
No chance to test whether IMS services were accessible with that cards though.

Shinjo

2018? 5? 29? ??? ?? 5? 42? 32? CEST? Tomcs?nyi, Domonkos ?? ? ?:
> Hello All,
> 
> Sorry if this is an off-topic question, but I was wondering: does anyone
> know of any carrier that actually uses a UICC ('SIM card') with the ISIM
> application installed? So far all cards I saw have only USIM, maybe CSIM on
> them. I'd like to extend Benoit's card library with ISIM support, but there
> is no way to test my code right now, so I'm thinking about buying maybe a
> card.
> 
> Thanks.
> 
> Domi


-- 
Shinjo Park <pshinjo at sect.tu-berlin.de>
Security in Telecommunications <sect.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272




From domi at tomcsanyi.net  Tue May 29 17:04:19 2018
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Tue, 29 May 2018 19:04:19 +0200 (CEST)
Subject: UICC with ISIM application
In-Reply-To: <2198070.HudFgU0ziR@brandenburg>
References: <1801956005.8566.1527608552840.JavaMail.zimbra@tomcsanyi.net>
 <2198070.HudFgU0ziR@brandenburg>
Message-ID: <39F6C830-0062-49AC-8978-CBDFB35B49D8@tomcsanyi.net>

Hi Harald and Shinjo,

Thank you for your replies. I decided I?ll first get a Hungarian VoLTE SIM card, because that?s the easiest for me, sincs I live here. If T-Mobile HU doesn?t use ISIM I?ll source a card from Austria.

If I?m done with development I?ll send a pull request to Benoit.
Maybe the code will be useful for reading sysmocom cards as well in the future.

Regards,
Domi


2018. m?j. 29. d?tummal, 18:02 id?pontban Shinjo Park <pshinjo at sect.tu-berlin.de> ?rta:

> Hi Domi,
> 
> According to osmo-sim-auth, 3 Austria, AT&T USA, T-Mobile USA has ISIM applet 
> installed. 3 Austria card was purchased in late 2016, both USA cards in ~2012. 
> No chance to test whether IMS services were accessible with that cards though.
> 
> Shinjo
> 
> 2018? 5? 29? ??? ?? 5? 42? 32? CEST? Tomcs?nyi, Domonkos ?? ? ?:
>> Hello All,
>> 
>> Sorry if this is an off-topic question, but I was wondering: does anyone
>> know of any carrier that actually uses a UICC ('SIM card') with the ISIM
>> application installed? So far all cards I saw have only USIM, maybe CSIM on
>> them. I'd like to extend Benoit's card library with ISIM support, but there
>> is no way to test my code right now, so I'm thinking about buying maybe a
>> card.
>> 
>> Thanks.
>> 
>> Domi
> 
> 
> -- 
> Shinjo Park <pshinjo at sect.tu-berlin.de>
> Security in Telecommunications <sect.tu-berlin.de>
> TU Berlin / Telekom Innovation Laboratories
> Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
> Phone: +49 30 8353 58272
> 
> 

From holger at freyther.de  Thu May 31 01:52:08 2018
From: holger at freyther.de (Holger Freyther)
Date: Thu, 31 May 2018 09:52:08 +0800
Subject: React to IMSI Attach but not PERIODIC
In-Reply-To: <f8211406-ac54-a426-59a6-0de2f783ed2f@rhizomatica.org>
References: <49534bd8-cdd0-616e-ecfc-8842cf5127b6@rhizomatica.org>
 <20180523123407.GA17213@my.box> <20180523145549.GT3639@nataraja>
 <08e1ea59-18a8-9a65-32df-1e1a7483222c@rhizomatica.org>
 <20180524134757.GA1529@my.box>
 <48a199ee-b1bc-71aa-ae6e-cdfd22c741bf@rhizomatica.org>
 <20180528104101.GA1498@my.box>
 <f8211406-ac54-a426-59a6-0de2f783ed2f@rhizomatica.org>
Message-ID: <29303353-897D-4FD8-BCE0-5300F7A9629F@freyther.de>



> On 28. May 2018, at 19:14, Keith Whyte <keith at rhizomatica.org> wrote:
> 
> 
> 
> For the moment, what I've done is extend the SMPP availability statuses
> and send a different status for IMSI_ATTACH to PERIODIC
> The my SMPP listener is reacting differently depending on the status..
> This works for the moment for the application in hand, but I assume it's
> not something we want to be concerned about in master.

Out of my head I don't know which fields/IEs you would use to indicate it
but I think it makes sense to differentiate it. It is easier for an app to
discard information it doesn't want to have than making it up. ;)

holger


From jererom211 at gmail.com  Tue May 29 13:35:48 2018
From: jererom211 at gmail.com (=?UTF-8?B?0JPQtdC+0YDQs9C40Lkg0J/RgNCw0LnQt9C10L3QtNC+0YDRhA==?=)
Date: Tue, 29 May 2018 13:35:48 -0000
Subject: Osmo-bts "shutdown timer expired"
Message-ID: <CAEuZkWKTUgF+SitLrHAm57hhc3C21GVCE_A1S2BHAQpVG+BG7w@mail.gmail.com>

?Hi, sorry for my English.  I installed osmocombb on Kali rolling. When i'm
trying to start my own bts, it works for 4 seconds, then i can see message
"Shutdown timer expired". Bellow you can see my config files. 1 screenshot
- 2 trx firmware on motorola c115. 2 screenshot, left - follow the
commercial BTS timer, right - starting MSC, SMS, HLR. 3 screenshot -
starting osmo-bts. 4 screen - my problem. I can connect with telnet to BSC
and BTS, but BTS - only for this 4 seconds, when it's up. I didn't replaced
filters on motorola, is it my problem? Or i just need to install smth more?
Also, if i write to the wrong mail list, tell me please where should i
write with my problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/44f7691f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ?????? ?????? (173).png
Type: image/png
Size: 398359 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/44f7691f/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ?????? ?????? (171).png
Type: image/png
Size: 322268 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/44f7691f/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ?????? ?????? (172).png
Type: image/png
Size: 460493 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/44f7691f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ?????? ?????? (174).png
Type: image/png
Size: 453714 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/44f7691f/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: open-bsc.cfg
Type: application/octet-stream
Size: 4068 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/44f7691f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts.cfg
Type: application/octet-stream
Size: 2515 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180529/44f7691f/attachment-0001.obj>