From rafael at rhizomatica.org  Fri Aug  2 21:45:01 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Fri, 2 Aug 2019 18:45:01 -0300
Subject: CS Fallback in NextEPC
In-Reply-To: <dd8d7a36-f6fa-eeca-fbf8-b97e02c097d0@rhizomatica.org>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <CAL=AzhqPxsFUD5To4bvha0ro-7t=qLXA0zKL-3Qs4Ci2y+Vdtg@mail.gmail.com>
 <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org>
 <CAL=Azhr7_f1vV1g5vALj3dxJLBNHoFhZcv3bfmco8Xqic=ScPg@mail.gmail.com>
 <dd8d7a36-f6fa-eeca-fbf8-b97e02c097d0@rhizomatica.org>
Message-ID: <2ca712a4-427f-166b-eadc-832b9772ca85@rhizomatica.org>

Hi all,

Just a small question - what is the meaning of the "name" field in the
sgsap configuration?

Thanks,
Rafael Diniz

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

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

From acetcom at gmail.com  Fri Aug  2 22:05:32 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Sat, 3 Aug 2019 07:05:32 +0900
Subject: CS Fallback in NextEPC
In-Reply-To: <2ca712a4-427f-166b-eadc-832b9772ca85@rhizomatica.org>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <CAL=AzhqPxsFUD5To4bvha0ro-7t=qLXA0zKL-3Qs4Ci2y+Vdtg@mail.gmail.com>
 <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org>
 <CAL=Azhr7_f1vV1g5vALj3dxJLBNHoFhZcv3bfmco8Xqic=ScPg@mail.gmail.com>
 <dd8d7a36-f6fa-eeca-fbf8-b97e02c097d0@rhizomatica.org>
 <2ca712a4-427f-166b-eadc-832b9772ca85@rhizomatica.org>
Message-ID: <CAKoHG8BGDL3qKwQsAm-Ryhf_tDyN-FF=-s2+BwcsfwPXt=1UZA@mail.gmail.com>

Hi Rafael,

In the NextEPC, there are two ways to specify peers. 'addr' sets the IP
address, and 'name' sets the hostname.
So, if your network is configured to look up the VLR as a hostname, you can
use 'name'.

'port' was just made for testing. If you want to use a different port
without using standard 29118, you can put  'port' number.

By the way, I've changed how to configure CS Fallback & SMS as below.

#  o Single MSC/VLR(127.0.0.2)
    sgsap:
      addr: 127.0.0.2
      map:
        tai:
          plmn_id:
            mcc: 001
            mnc: 01
          tac: 4130
        lai:
          plmn_id:
            mcc: 001
            mnc: 01
          lac: 43690
      map:
        tai:
          plmn_id:
            mcc: 002
            mnc: 02
          tac: 4132
        lai:
          plmn_id:
            mcc: 002
            mnc: 02
          lac: 43692

#  o Multiple MSC/VLR
    sgsap:
      - addr: 127.0.0.2
        port: 29119
        map:
          tai:
            plmn_id:
              mcc: 001
              mnc: 01
            tac: 4131
          lai:
            plmn_id:
              mcc: 001
              mnc: 01
            lac: 43691
        map:
          tai:
            plmn_id:
              mcc: 002
              mnc: 02
            tac: 4132
          lai:
            plmn_id:
              mcc: 002
              mnc: 02
            lac: 43692
      - addr
         - 127.0.0.3
         - fe80::2%lo
        map:
          tai:
            plmn_id:
              mcc: 001
              mnc: 01
            tac: 4132
          lai:
            plmn_id:
              mcc: 002
              mnc: 02
            lac: 43692
      - name: msc.open5gs.org
        map:
          tai:
            plmn_id:
              mcc: 001
              mnc: 01
            tac: 4133
          lai:
            plmn_id:
              mcc: 002
              mnc: 02
            lac: 43693

Thanks a lot!

Best Regards,
    Sukchan




On Sat, Aug 3, 2019 at 6:45 AM Rafael Diniz <rafael at rhizomatica.org> wrote:

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

From rafael at rhizomatica.org  Mon Aug  5 19:42:28 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Mon, 5 Aug 2019 16:42:28 -0300
Subject: CS Fallback in NextEPC
In-Reply-To: <CAKoHG8BGDL3qKwQsAm-Ryhf_tDyN-FF=-s2+BwcsfwPXt=1UZA@mail.gmail.com>
References: <CAKoHG8C9=a8pH6fidZPg2LCdF6GOq7pu32j7bZocsYR=0950Hw@mail.gmail.com>
 <CAL=AzhqPxsFUD5To4bvha0ro-7t=qLXA0zKL-3Qs4Ci2y+Vdtg@mail.gmail.com>
 <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org>
 <CAL=Azhr7_f1vV1g5vALj3dxJLBNHoFhZcv3bfmco8Xqic=ScPg@mail.gmail.com>
 <dd8d7a36-f6fa-eeca-fbf8-b97e02c097d0@rhizomatica.org>
 <2ca712a4-427f-166b-eadc-832b9772ca85@rhizomatica.org>
 <CAKoHG8BGDL3qKwQsAm-Ryhf_tDyN-FF=-s2+BwcsfwPXt=1UZA@mail.gmail.com>
Message-ID: <b2ca5353-0b28-20a2-a85d-42766358f6aa@rhizomatica.org>

Thanks a lot Sukchan,

I'll test this week!

Rafael Diniz

On 8/2/19 7:05 PM, Sukchan Lee wrote:
> Hi Rafael,
>
> In the NextEPC, there are two ways to specify peers. 'addr' sets the
> IP address, and 'name' sets the hostname.
> So, if your network is configured to look up the VLR as a hostname,
> you can use 'name'.
>
> 'port' was just made for testing. If you want to use a different port
> without using standard 29118, you can put? 'port' number.
>
> By the way, I've changed how to configure CS Fallback & SMS as below.
>
> # ?o Single MSC/VLR(127.0.0.2)
> ? ? sgsap:
> ? ? ? addr: 127.0.0.2
> ? ? ? map:
> ? ? ? ? tai:
> ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? mcc: 001
> ? ? ? ? ? ? mnc: 01
> ? ? ? ? ? tac: 4130
> ? ? ? ? lai:
> ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? mcc: 001
> ? ? ? ? ? ? mnc: 01
> ? ? ? ? ? lac: 43690
> ? ? ? map:
> ? ? ? ? tai:
> ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? mcc: 002
> ? ? ? ? ? ? mnc: 02
> ? ? ? ? ? tac: 4132
> ? ? ? ? lai:
> ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? mcc: 002
> ? ? ? ? ? ? mnc: 02
> ? ? ? ? ? lac: 43692
>
> # ?o Multiple MSC/VLR
> ? ? sgsap:
> ? ? ? - addr: 127.0.0.2
> ? ? ? ? port: 29119
> ? ? ? ? map:
> ? ? ? ? ? tai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 001
> ? ? ? ? ? ? ? mnc: 01
> ? ? ? ? ? ? tac: 4131
> ? ? ? ? ? lai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 001
> ? ? ? ? ? ? ? mnc: 01
> ? ? ? ? ? ? lac: 43691
> ? ? ? ? map:
> ? ? ? ? ? tai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 002
> ? ? ? ? ? ? ? mnc: 02
> ? ? ? ? ? ? tac: 4132
> ? ? ? ? ? lai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 002
> ? ? ? ? ? ? ? mnc: 02
> ? ? ? ? ? ? lac: 43692
> ? ? ? - addr
> ? ? ? ? ?- 127.0.0.3
> ? ? ? ? ?- fe80::2%lo
> ? ? ? ? map:
> ? ? ? ? ? tai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 001
> ? ? ? ? ? ? ? mnc: 01
> ? ? ? ? ? ? tac: 4132
> ? ? ? ? ? lai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 002
> ? ? ? ? ? ? ? mnc: 02
> ? ? ? ? ? ? lac: 43692
> ? ? ? - name: msc.open5gs.org <http://msc.open5gs.org>
> ? ? ? ? map:
> ? ? ? ? ? tai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 001
> ? ? ? ? ? ? ? mnc: 01
> ? ? ? ? ? ? tac: 4133
> ? ? ? ? ? lai:
> ? ? ? ? ? ? plmn_id:
> ? ? ? ? ? ? ? mcc: 002
> ? ? ? ? ? ? ? mnc: 02
> ? ? ? ? ? ? lac: 43693
>
> Thanks a lot!
>
> Best Regards,
> ? ? Sukchan
>
>
>
>
> On Sat, Aug 3, 2019 at 6:45 AM Rafael Diniz <rafael at rhizomatica.org
> <mailto:rafael at rhizomatica.org>> wrote:
>
>     Hi all,
>
>     Just a small question - what is the meaning of the "name" field in the
>     sgsap configuration?
>
>     Thanks,
>     Rafael Diniz
>
>     On 7/19/19 5:51 PM, Rafael Diniz wrote:
>     > Obrigado Romeu!
>     >
>     > On 7/19/19 4:58 PM, Romeu Medeiros wrote:
>     >> Hello Rafael
>     >>
>     >> I just configure the NextEPC to connect via SGS to OSMO-MSC,
>     like this:
>     >>
>     >> ? ? sgsap:
>     >> ? ? ? ? addr: 127.0.0.1
>     >> ? ? ? ? port: 29118
>     >> ? ? ? ? name: vlr.example.net <http://vlr.example.net>
>     <http://vlr.example.net>
>     >> ? ? ? ? tai:
>     >> ? ? ? ? ? ?plmn_id:
>     >> ? ? ? ? ? ? ?mcc: 724
>     >> ? ? ? ? ? ? ?mnc: 21
>     >> ? ? ? ? ? ?tac: 12345
>     >> ? ? ? ? lai:
>     >> ? ? ? ? ? ?plmn_id:
>     >> ? ? ? ? ? ? ?mcc: 724
>     >> ? ? ? ? ? ? ?mnc: 4
>     >> ? ? ? ? ? ?lac: 51544
>     >>
>     >> And the configuration in the MSC:
>     >>
>     >> sgs
>     >> ?local-port 29118
>     >> ?local-ip 0.0.0.0
>     >> ?vlr-name vlr.example.net <http://vlr.example.net>
>     <http://vlr.example.net>
>     >>
>     >> And configure the IMSI in the Osmo-HLR and NextEPC-HSS
>     >>
>     >> If you need more help tell me.
>     >>
>     >>
>     >> Thanks
>     >>
>     >> Romeu Medeiros
>     >>
>     >>
>     >> And?
>     >>
>     >> On Fri, Jul 19, 2019 at 1:31 PM Rafael Diniz
>     <rafael at rhizomatica.org <mailto:rafael at rhizomatica.org>
>     >> <mailto:rafael at rhizomatica.org
>     <mailto:rafael at rhizomatica.org>>> wrote:
>     >>
>     >>? ? ?Hi all,
>     >>
>     >>? ? ?I'd also like to test SMS and CSFB in LTE. I have some
>     experience with
>     >>? ? ?the Osmocom GSM stack, but not much with the NextEPC LTE.
>     Could you
>     >>? ? ?point me which fields should I set in the configuration files?
>     >>
>     >>? ? ?Thanks,
>     >>? ? ?Rafael Diniz
>     >>
>     >>? ? ?On 7/13/19 6:35 PM, Romeu Medeiros wrote:
>     >>? ? ?> Hello?Sukchan and friends.
>     >>? ? ?>
>     >>? ? ?> I'm trying to use the CSFB in test lab, and every time that
>     >>? ? ?nextepc send
>     >>? ? ?> the UEContextModificationRequest, the UE respond with an
>     >>? ? ?> UEContextModificationFaliure [
>     Protocol-cause=semantic-error ].
>     >>? ? ?>
>     >>? ? ?> image.png
>     >>? ? ?>
>     >>? ? ?> I'm looking why I'm getting this. Someone have any idea?
>     >>? ? ?>
>     >>? ? ?> Thanks
>     >>? ? ?>
>     >>? ? ?> Romeu Medeiros
>     >>? ? ?>
>     >>? ? ?> On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee
>     <acetcom at gmail.com <mailto:acetcom at gmail.com>
>     >>? ? ?<mailto:acetcom at gmail.com <mailto:acetcom at gmail.com>>
>     >>? ? ?> <mailto:acetcom at gmail.com <mailto:acetcom at gmail.com>
>     <mailto:acetcom at gmail.com <mailto:acetcom at gmail.com>>>> wrote:
>     >>? ? ?>
>     >>? ? ?>? ? ?Dear Osmocom & NextEPC Community,
>     >>? ? ?>
>     >>? ? ?>? ? ?Today I've added CS Fallback and released NextEPC v0.5.0
>     >>? ? ?>
>     >>? ? ?>? ? ?So, I'd just like to test this part with Osmocom
>     project, but it
>     >>? ? ?>? ? ?seems to be a difficult task. The reason is why I
>     have little
>     >>? ? ?>? ? ?knowledge about 2G/3G. Nevertheless, I will try to do it
>     >>? ? ?>
>     >>? ? ?>? ? ?BTW, I don't know if there is anyone who wants to
>     integrate
>     >>? ? ?this big
>     >>? ? ?>? ? ?thing.
>     >>? ? ?>? ? ?Even though I'm not sure if this will help, but let me
>     >>? ? ?introduce the
>     >>? ? ?>? ? ?configuration of the NextEPC.
>     >>? ? ?>
>     >>? ? ?>? ? ?To use SGsAP, change the mme.conf as follows:
>     >>? ? ?>
>     >>? ? ?>? ? ?#
>     >>? ? ?>? ? ?# ?<sgsap>
>     >>? ? ?>? ? ?#
>     >>? ? ?>? ? ?# ?o Single MSC/VLR
>     >>? ? ?>? ? ?# ? ?sgsap:
>     >>? ? ?>? ? ?# ? ? ?addr: 127.0.0.2
>     >>? ? ?>? ? ?# ? ? ?plmn_id:
>     >>? ? ?>? ? ?# ? ? ? ?mcc: 001
>     >>? ? ?>? ? ?# ? ? ? ?mnc: 01
>     >>? ? ?>? ? ?# ? ? ?tac: 4130
>     >>? ? ?>? ? ?# ? ? ?lac: 43690
>     >>? ? ?>? ? ?#
>     >>? ? ?>? ? ?# ?o Multiple MSC/VLR
>     >>? ? ?>? ? ?# ? ?sgsap:
>     >>? ? ?>? ? ?# ? ? ?- addr: 127.0.0.2
>     >>? ? ?>? ? ?# ? ? ? ?plmn_id:
>     >>? ? ?>? ? ?# ? ? ? ? ?mcc: 001
>     >>? ? ?>? ? ?# ? ? ? ? ?mnc: 01
>     >>? ? ?>? ? ?# ? ? ? ?tac: 4131
>     >>? ? ?>? ? ?# ? ? ? ?lac: 43692
>     >>? ? ?>? ? ?# ? ? ?- addr
>     >>? ? ?>? ? ?# ? ? ? ? - 127.0.0.3
>     >>? ? ?>? ? ?# ? ? ? ? - fe80::2%lo0
>     >>? ? ?>? ? ?# ? ? ? ?plmn_id:
>     >>? ? ?>? ? ?# ? ? ? ? ?mcc: 001
>     >>? ? ?>? ? ?# ? ? ? ? ?mnc: 01
>     >>? ? ?>? ? ?# ? ? ? ?tac: 4132
>     >>? ? ?>? ? ?# ? ? ? ?lac: 43692
>     >>? ? ?>? ? ?# ? ? ?- name: msc.open5gs.org
>     <http://msc.open5gs.org> <http://msc.open5gs.org>
>     >>? ? ?<http://msc.open5gs.org>
>     >>? ? ?>? ? ?# ? ? ? ?plmn_id:
>     >>? ? ?>? ? ?# ? ? ? ? ?mcc: 001
>     >>? ? ?>? ? ?# ? ? ? ? ?mnc: 01
>     >>? ? ?>? ? ?# ? ? ? ?tac: 4133
>     >>? ? ?>? ? ?# ? ? ? ?lac: 43693
>     >>? ? ?>? ? ?#
>     >>? ? ?>
>     >>? ? ?>? ? ?FYI, I also attach the pcap that I run with nextepc
>     simulator
>     >>? ? ?as below.
>     >>? ? ?>
>     >>? ? ?>? ? ?$ ./tests/testcsfb
>     >>? ? ?>? ? ?mo-idle-test ? ? ? ?: SUCCESS
>     >>? ? ?>? ? ?mt-idle-test ? ? ? ?: SUCCESS
>     >>? ? ?>? ? ?mo-active-test ? ? ?: SUCCESS
>     >>? ? ?>? ? ?mt-active-test ? ? ?: SUCCESS
>     >>? ? ?>? ? ?All tests passed.
>     >>? ? ?>
>     >>? ? ?>? ? ?Feel free to raise any questions about this things.
>     >>? ? ?>
>     >>? ? ?>? ? ?Best Regards,
>     >>? ? ?>? ? ?? ? Sukchan
>     >>? ? ?>
>     >>
>     >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190805/7c796882/attachment.bin>

From mathieu at xilan.net  Tue Aug 13 09:28:49 2019
From: mathieu at xilan.net (Mathieu)
Date: Tue, 13 Aug 2019 11:28:49 +0200
Subject: ignore initial APN
Message-ID: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>

Hi,


I'm trying to setup nextepc to provide service for multiple ISPs with 
the same core network.

Is there a way to ignore the APN configured in the UE, and rather use 
the one configured with the webui ?

On the same topic, is it possible to restrict a UE to the apn configured 
with the webui ?


Thanks,


Best regards,



From domi at tomcsanyi.net  Tue Aug 13 14:56:32 2019
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Tue, 13 Aug 2019 16:56:32 +0200 (CEST)
Subject: ignore initial APN
In-Reply-To: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
References: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
Message-ID: <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>

Hi Matthieu,

I might be wrong here, but I don?t think there is a way allowed in the standards to ignore the UE?s APN. That?s why you can end up even in commercial networks without mobile data access - not knowing the correct APN will make it impossible for the network to route your traffic. Most networks when you connect using an incorrect APN tend to send a text message containing the correct one to fix the issue in the UE.

Naturally I?d assume there is a way to hack into nextEPC to ignore the UEs APN but I?d consider this a hack, not a real solution. I think it is better to make sure UEs are provisioned correctly.

Just my 2cents worth of opinion :)

Cheers,
Domi

2019. aug. 13. d?tummal, 11:35 id?pontban Mathieu <mathieu at xilan.net> ?rta:

> Hi,
> 
> 
> I'm trying to setup nextepc to provide service for multiple ISPs with the same core network.
> 
> Is there a way to ignore the APN configured in the UE, and rather use the one configured with the webui ?
> 
> On the same topic, is it possible to restrict a UE to the apn configured with the webui ?
> 
> 
> Thanks,
> 
> 
> Best regards,
> 

From laforge at gnumonks.org  Wed Aug 14 07:07:15 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Aug 2019 09:07:15 +0200
Subject: ignore initial APN
In-Reply-To: <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
References: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
 <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
Message-ID: <20190814070715.GN9715@nataraja>

On Tue, Aug 13, 2019 at 04:56:32PM +0200, Tomcs?nyi, Domonkos wrote:
> I might be wrong here, but I don?t think there is a way allowed in the standards to ignore the UE?s APN.

In legacy 2G/3G networks, this is possible by use of CAMEL.  The gsmSCF
next to the HLR can add ralated CSI (Camel Subscription Information)
when doing the InsertSubscriberData to the gprsSSF inside the SGSN.

So I would actually be surprised if they removed that kind of capability
from the EPC architecture.  I don't know *how* it would be implemented
on LTE/EPC, though.

Regards,
	Harald
> Naturally I?d assume there is a way to hack into nextEPC to ignore the UEs APN but I?d consider this a hack, not a real solution. I think it is better to make sure UEs are provisioned correctly.

This is said easier than it's done in practise.  Particularly if you run
a small network/operator with a small number of subscribers, you will
not have the market strength to have phone manufacturers or OS vendors
include your APN configuration in their software/updates.  I have heard
that e.g. in the case of Apple, an operator (evne MVNO) must have at
least 100k [apple-using?] subscribers in order to get there.

A work-around can be the use of APN ACLs on the USIM, but then you must
get that right in the very beginning, and never change your APN
confuguration unless you have the entire OTA update infrastructure in
plase and tested/verified so you can roll out changes to the USIM via
RFM (Remote File Managament).

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 domi at tomcsanyi.net  Wed Aug 14 08:05:50 2019
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Wed, 14 Aug 2019 10:05:50 +0200 (CEST)
Subject: ignore initial APN
In-Reply-To: <20190814070715.GN9715@nataraja>
References: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
 <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
 <20190814070715.GN9715@nataraja>
Message-ID: <E455E0C0-9DE3-40C4-B174-955DA026AF35@tomcsanyi.net>

Hello Harald,

>> On Tue, Aug 13, 2019 at 04:56:32PM +0200, Tomcs?nyi, Domonkos wrote:
>> I might be wrong here, but I don?t think there is a way allowed in the standards to ignore the UE?s APN.
> 
> In legacy 2G/3G networks, this is possible by use of CAMEL.  The gsmSCF
> next to the HLR can add ralated CSI (Camel Subscription Information)
> when doing the InsertSubscriberData to the gprsSSF inside the SGSN.
> 
> So I would actually be surprised if they removed that kind of capability
> from the EPC architecture.  I don't know *how* it would be implemented
> on LTE/EPC, though.
> 

You are fully right, I keep forgetting about CAMEL :). I am pretty sure too that it is somehow inplemented in LTE/EPC as well, but I also have not looked into the standards for that yet.

>> Naturally I?d assume there is a way to hack into nextEPC to ignore the UEs APN but I?d consider this a hack, not a real solution. I think it is better to make sure UEs are provisioned correctly.
> 
> This is said easier than it's done in practise.  Particularly if you run
> a small network/operator with a small number of subscribers, you will
> not have the market strength to have phone manufacturers or OS vendors
> include your APN configuration in their software/updates.  I have heard
> that e.g. in the case of Apple, an operator (evne MVNO) must have at
> least 100k [apple-using?] subscribers in order to get there.
> 

I have chosen my wording poorly when I said ?provisioned?. I was trying to say that in such scenarios imho setting up the APN manually in the Settings app of the UE (=asking the user to do so and maybe provide some instructions?) or by sending a configuration SMS is a feasible way of dealing with this. I am pretty certain at least one of these methods should work, even in case of Apple devices.

Cheers,
Domi

From mathieu at xilan.net  Wed Aug 14 07:56:59 2019
From: mathieu at xilan.net (Mathieu)
Date: Wed, 14 Aug 2019 09:56:59 +0200
Subject: ignore initial APN
In-Reply-To: <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
References: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
 <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
Message-ID: <efd996fa-41ba-f3c6-6d83-a99bfbf02bc9@xilan.net>

Hi Domi,

Thanks for your answer.
I have a commercial epc that is able to do it: I can "ignore the initial 
APN", then set a default APN. This way, whatever the APN is configured 
in the UE, I can decide what APN is used. I was wondering if nextepc can 
do the same.
It's convenient in my case, because the end users must be able to change 
their ISP without reconfiguring their UE (in some case, they even don't 
have access to the UE configuration), and I dedicated one APN per ISP.



Regards,

Mathieu


Le 13/08/2019 ? 16:56, Tomcs?nyi, Domonkos a ?crit?:
> Hi Matthieu,
>
> I might be wrong here, but I don?t think there is a way allowed in the standards to ignore the UE?s APN. That?s why you can end up even in commercial networks without mobile data access - not knowing the correct APN will make it impossible for the network to route your traffic. Most networks when you connect using an incorrect APN tend to send a text message containing the correct one to fix the issue in the UE.
>
> Naturally I?d assume there is a way to hack into nextEPC to ignore the UEs APN but I?d consider this a hack, not a real solution. I think it is better to make sure UEs are provisioned correctly.
>
> Just my 2cents worth of opinion :)
>
> Cheers,
> Domi
>
> 2019. aug. 13. d?tummal, 11:35 id?pontban Mathieu <mathieu at xilan.net> ?rta:
>
>> Hi,
>>
>>
>> I'm trying to setup nextepc to provide service for multiple ISPs with the same core network.
>>
>> Is there a way to ignore the APN configured in the UE, and rather use the one configured with the webui ?
>>
>> On the same topic, is it possible to restrict a UE to the apn configured with the webui ?
>>
>>
>> Thanks,
>>
>>
>> Best regards,
>>



From acetcom at gmail.com  Wed Aug 14 10:21:16 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Wed, 14 Aug 2019 19:21:16 +0900
Subject: ignore initial APN
In-Reply-To: <efd996fa-41ba-f3c6-6d83-a99bfbf02bc9@xilan.net>
References: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
 <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
 <efd996fa-41ba-f3c6-6d83-a99bfbf02bc9@xilan.net>
Message-ID: <A49ED626-F184-4F32-82FD-149DAEE40F54@gmail.com>

Hi Mathieu,

It?s an interesting for ?ignoring an initial APN?. Regarding this, I have a question. 

There are two options to add this feature. One is per-UE, the other is HSS globally.

What is better? And also, let me know how the commercial EPC configures this things.

Thank you for raising this feature!

2019. 8. 14. ?? 4:56, Mathieu <mathieu at xilan.net> ??:

> Hi Domi,
> 
> Thanks for your answer.
> I have a commercial epc that is able to do it: I can "ignore the initial APN", then set a default APN. This way, whatever the APN is configured in the UE, I can decide what APN is used. I was wondering if nextepc can do the same.
> It's convenient in my case, because the end users must be able to change their ISP without reconfiguring their UE (in some case, they even don't have access to the UE configuration), and I dedicated one APN per ISP.
> 
> 
> 
> Regards,
> 
> Mathieu
> 
> 
>> Le 13/08/2019 ? 16:56, Tomcs?nyi, Domonkos a ?crit :
>> Hi Matthieu,
>> 
>> I might be wrong here, but I don?t think there is a way allowed in the standards to ignore the UE?s APN. That?s why you can end up even in commercial networks without mobile data access - not knowing the correct APN will make it impossible for the network to route your traffic. Most networks when you connect using an incorrect APN tend to send a text message containing the correct one to fix the issue in the UE.
>> 
>> Naturally I?d assume there is a way to hack into nextEPC to ignore the UEs APN but I?d consider this a hack, not a real solution. I think it is better to make sure UEs are provisioned correctly.
>> 
>> Just my 2cents worth of opinion :)
>> 
>> Cheers,
>> Domi
>> 
>> 2019. aug. 13. d?tummal, 11:35 id?pontban Mathieu <mathieu at xilan.net> ?rta:
>> 
>>> Hi,
>>> 
>>> 
>>> I'm trying to setup nextepc to provide service for multiple ISPs with the same core network.
>>> 
>>> Is there a way to ignore the APN configured in the UE, and rather use the one configured with the webui ?
>>> 
>>> On the same topic, is it possible to restrict a UE to the apn configured with the webui ?
>>> 
>>> 
>>> Thanks,
>>> 
>>> 
>>> Best regards,
> 


From mathieu at xilan.net  Wed Aug 14 12:39:16 2019
From: mathieu at xilan.net (Mathieu)
Date: Wed, 14 Aug 2019 14:39:16 +0200
Subject: ignore initial APN
In-Reply-To: <A49ED626-F184-4F32-82FD-149DAEE40F54@gmail.com>
References: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
 <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
 <efd996fa-41ba-f3c6-6d83-a99bfbf02bc9@xilan.net>
 <A49ED626-F184-4F32-82FD-149DAEE40F54@gmail.com>
Message-ID: <f9b31eb6-2455-c77f-7e9f-00fa88ec1458@xilan.net>

Hi Sukchan,

In the commercial EPC, the "ignore APN" option is global, then I can set 
a default APN per UE. I have another option to restrict each UE to a 
certain list of APNs. This way, I can have multiple APNs configured, but 
set each UE to its right APN, whatever is configured in the UE.
In my case, the "ignore APN" can be global, but maybe others can be 
interested to do it on a per-UE basis.

Thanks,

Mathieu

Le 14/08/2019 ? 12:21, Sukchan Lee a ?crit?:
> Hi Mathieu,
>
> It?s an interesting for ?ignoring an initial APN?. Regarding this, I have a question.
>
> There are two options to add this feature. One is per-UE, the other is HSS globally.
>
> What is better? And also, let me know how the commercial EPC configures this things.
>
> Thank you for raising this feature!
>
> 2019. 8. 14. ?? 4:56, Mathieu <mathieu at xilan.net> ??:
>
>> Hi Domi,
>>
>> Thanks for your answer.
>> I have a commercial epc that is able to do it: I can "ignore the initial APN", then set a default APN. This way, whatever the APN is configured in the UE, I can decide what APN is used. I was wondering if nextepc can do the same.
>> It's convenient in my case, because the end users must be able to change their ISP without reconfiguring their UE (in some case, they even don't have access to the UE configuration), and I dedicated one APN per ISP.
>>
>>
>>
>> Regards,
>>
>> Mathieu
>>
>>
>>> Le 13/08/2019 ? 16:56, Tomcs?nyi, Domonkos a ?crit :
>>> Hi Matthieu,
>>>
>>> I might be wrong here, but I don?t think there is a way allowed in the standards to ignore the UE?s APN. That?s why you can end up even in commercial networks without mobile data access - not knowing the correct APN will make it impossible for the network to route your traffic. Most networks when you connect using an incorrect APN tend to send a text message containing the correct one to fix the issue in the UE.
>>>
>>> Naturally I?d assume there is a way to hack into nextEPC to ignore the UEs APN but I?d consider this a hack, not a real solution. I think it is better to make sure UEs are provisioned correctly.
>>>
>>> Just my 2cents worth of opinion :)
>>>
>>> Cheers,
>>> Domi
>>>
>>> 2019. aug. 13. d?tummal, 11:35 id?pontban Mathieu <mathieu at xilan.net> ?rta:
>>>
>>>> Hi,
>>>>
>>>>
>>>> I'm trying to setup nextepc to provide service for multiple ISPs with the same core network.
>>>>
>>>> Is there a way to ignore the APN configured in the UE, and rather use the one configured with the webui ?
>>>>
>>>> On the same topic, is it possible to restrict a UE to the apn configured with the webui ?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Best regards,




From rafael at rhizomatica.org  Wed Aug 14 16:54:45 2019
From: rafael at rhizomatica.org (Rafael Diniz)
Date: Wed, 14 Aug 2019 13:54:45 -0300
Subject: ignore initial APN
In-Reply-To: <f9b31eb6-2455-c77f-7e9f-00fa88ec1458@xilan.net>
References: <5db995fd-79ad-e1fc-0e4c-8825d347160c@xilan.net>
 <8BA4EF19-7784-4722-AD9F-28C68BE2AAA7@tomcsanyi.net>
 <efd996fa-41ba-f3c6-6d83-a99bfbf02bc9@xilan.net>
 <A49ED626-F184-4F32-82FD-149DAEE40F54@gmail.com>
 <f9b31eb6-2455-c77f-7e9f-00fa88ec1458@xilan.net>
Message-ID: <7a9e29eb-06c0-4b9e-0700-74540a336a9f@rhizomatica.org>

We also have interest in the ignore APN (globally) feature also.

Thanks,
Rafael Diniz
Rhizomatica

On 8/14/19 9:39 AM, Mathieu wrote:
> Hi Sukchan,
>
> In the commercial EPC, the "ignore APN" option is global, then I can
> set a default APN per UE. I have another option to restrict each UE to
> a certain list of APNs. This way, I can have multiple APNs configured,
> but set each UE to its right APN, whatever is configured in the UE.
> In my case, the "ignore APN" can be global, but maybe others can be
> interested to do it on a per-UE basis.
>
> Thanks,
>
> Mathieu
>
> Le 14/08/2019 ? 12:21, Sukchan Lee a ?crit?:
>> Hi Mathieu,
>>
>> It?s an interesting for ?ignoring an initial APN?. Regarding this, I
>> have a question.
>>
>> There are two options to add this feature. One is per-UE, the other
>> is HSS globally.
>>
>> What is better? And also, let me know how the commercial EPC
>> configures this things.
>>
>> Thank you for raising this feature!
>>
>> 2019. 8. 14. ?? 4:56, Mathieu <mathieu at xilan.net> ??:
>>
>>> Hi Domi,
>>>
>>> Thanks for your answer.
>>> I have a commercial epc that is able to do it: I can "ignore the
>>> initial APN", then set a default APN. This way, whatever the APN is
>>> configured in the UE, I can decide what APN is used. I was wondering
>>> if nextepc can do the same.
>>> It's convenient in my case, because the end users must be able to
>>> change their ISP without reconfiguring their UE (in some case, they
>>> even don't have access to the UE configuration), and I dedicated one
>>> APN per ISP.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Mathieu
>>>
>>>
>>>> Le 13/08/2019 ? 16:56, Tomcs?nyi, Domonkos a ?crit :
>>>> Hi Matthieu,
>>>>
>>>> I might be wrong here, but I don?t think there is a way allowed in
>>>> the standards to ignore the UE?s APN. That?s why you can end up
>>>> even in commercial networks without mobile data access - not
>>>> knowing the correct APN will make it impossible for the network to
>>>> route your traffic. Most networks when you connect using an
>>>> incorrect APN tend to send a text message containing the correct
>>>> one to fix the issue in the UE.
>>>>
>>>> Naturally I?d assume there is a way to hack into nextEPC to ignore
>>>> the UEs APN but I?d consider this a hack, not a real solution. I
>>>> think it is better to make sure UEs are provisioned correctly.
>>>>
>>>> Just my 2cents worth of opinion :)
>>>>
>>>> Cheers,
>>>> Domi
>>>>
>>>> 2019. aug. 13. d?tummal, 11:35 id?pontban Mathieu
>>>> <mathieu at xilan.net> ?rta:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> I'm trying to setup nextepc to provide service for multiple ISPs
>>>>> with the same core network.
>>>>>
>>>>> Is there a way to ignore the APN configured in the UE, and rather
>>>>> use the one configured with the webui ?
>>>>>
>>>>> On the same topic, is it possible to restrict a UE to the apn
>>>>> configured with the webui ?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> Best regards,
>
>

-------------- 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/nextepc/attachments/20190814/89b0e558/attachment.bin>

From laforge at gnumonks.org  Sat Aug 17 13:18:10 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 17 Aug 2019 15:18:10 +0200
Subject: PGW without root or changing /dev/net/tun permissions
Message-ID: <20190817131810.GP2319@nataraja>

Hi Sukchan and friends,

the installation instructions recommend changing the permissions of /dev/net/tun,
which can be dangerous as it gives permissions to potentially many other processes.

There are several better alternatives to this:

1) give CAP_NET_ADMIN permission to the pgw binary:
   Simply execute "setcap cap_net_admin=ep /usr/local/bin/nextepc-pgwd"
   and then you can run the process as 'nextepc' user, like the other processes.

   The sad part about this is that nextepc-pgwd has now the power to reconfigure
   anything about linux netwowrking.  The best approach would be to drop those
   capabiligies after creating/configuring the tun devices using
   prctl(PR_CAPBSET_DROP, CAP_NET_ADMIN) - this way it is ensured that
   after start-up, no capabilities survive, and even if somebody manages
   to get code execution in the PGW, it is not a privilege escalation.

2) create the tun devices *before* starting the P-GW, and then start the
   PGW as non-root.  We offer this method in OsmoGGSN, see Section 8.3
   of http://ftp.osmocom.org/docs/latest/osmoggsn-usermanual.pdf
   This can even be done with systemd now.

I suggest to first change the documentation to recomend the setcap
approach, and then later to adopt privilege dropping or another
approach.

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 acetcom at gmail.com  Sat Aug 17 15:57:58 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Sun, 18 Aug 2019 00:57:58 +0900
Subject: PGW without root or changing /dev/net/tun permissions
In-Reply-To: <20190817131810.GP2319@nataraja>
References: <20190817131810.GP2319@nataraja>
Message-ID: <CAKoHG8A4rpoy4acnMqLdQebfFC1FP+V8ozPiC1o9gGZj=YKCXw@mail.gmail.com>

Hi Harald,

Generally, NextEPC recommend to start P-GW as non-root. So, before the
starting P-GW, TUN device should be setting up properly.

Perhaps I need to adjust the TUN device permission section of the NextEPC
documentation. In fact, in general, most people don't need this doc part.
The reason I wrote was because of the docker environment. TUN didn't work
properly in docker, so if I installed udev or modified the permission it
worked.

As you suggested, I'll have to revisit this section and revise the document.

Thank you for raising this issue.

Best Regards,
    Sukchan


On Sat, Aug 17, 2019 at 10:18 PM Harald Welte <laforge at gnumonks.org> wrote:

> Hi Sukchan and friends,
>
> the installation instructions recommend changing the permissions of
> /dev/net/tun,
> which can be dangerous as it gives permissions to potentially many other
> processes.
>
> There are several better alternatives to this:
>
> 1) give CAP_NET_ADMIN permission to the pgw binary:
>    Simply execute "setcap cap_net_admin=ep /usr/local/bin/nextepc-pgwd"
>    and then you can run the process as 'nextepc' user, like the other
> processes.
>
>    The sad part about this is that nextepc-pgwd has now the power to
> reconfigure
>    anything about linux netwowrking.  The best approach would be to drop
> those
>    capabiligies after creating/configuring the tun devices using
>    prctl(PR_CAPBSET_DROP, CAP_NET_ADMIN) - this way it is ensured that
>    after start-up, no capabilities survive, and even if somebody manages
>    to get code execution in the PGW, it is not a privilege escalation.
>
> 2) create the tun devices *before* starting the P-GW, and then start the
>    PGW as non-root.  We offer this method in OsmoGGSN, see Section 8.3
>    of http://ftp.osmocom.org/docs/latest/osmoggsn-usermanual.pdf
>    This can even be done with systemd now.
>
> I suggest to first change the documentation to recomend the setcap
> approach, and then later to adopt privilege dropping or another
> approach.
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190818/b6a80e70/attachment.htm>

From mathieu at xilan.net  Fri Aug 23 08:08:46 2019
From: mathieu at xilan.net (Mathieu)
Date: Fri, 23 Aug 2019 10:08:46 +0200
Subject: nextepc vs nextepc
Message-ID: <f6cb4391-c7ad-6909-2c6b-81fa66f9f7d1@xilan.net>

Hi everyone,


Does someone know the difference between these two projects:


https://github.com/open5gs/nextepc

https://github.com/nextepc/nextepc


They seem to share some code, but the second one seems to be owned by a 
US company, and the code as not been updated for months. (only 14 
commits in the repo)


There are nextepc packages in the universe ubuntu repo too now, but I 
don't know which version it is. Any idea ?

Which project should be used ?


Thanks,


Mathieu



From acetcom at gmail.com  Fri Aug 23 09:57:22 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Fri, 23 Aug 2019 18:57:22 +0900
Subject: nextepc vs nextepc
In-Reply-To: <f6cb4391-c7ad-6909-2c6b-81fa66f9f7d1@xilan.net>
References: <f6cb4391-c7ad-6909-2c6b-81fa66f9f7d1@xilan.net>
Message-ID: <CAKoHG8C1tRaJu2=k8P9NV0k8h8xY07uO0sGvhHQgJhor5LOkmw@mail.gmail.com>

Hi Mathieu,

FYI, see the link below.
https://github.com/open5gs/nextepc/issues/181

Perhaps many people are confused the NextEPC name.
I'm still less prepared, but let me send my next plan in a separate email.

Thanks a lot!

Best Regards,
    Sukchan


On Fri, Aug 23, 2019 at 5:44 PM Mathieu <mathieu at xilan.net> wrote:

> Hi everyone,
>
>
> Does someone know the difference between these two projects:
>
>
> https://github.com/open5gs/nextepc
>
> https://github.com/nextepc/nextepc
>
>
> They seem to share some code, but the second one seems to be owned by a
> US company, and the code as not been updated for months. (only 14
> commits in the repo)
>
>
> There are nextepc packages in the universe ubuntu repo too now, but I
> don't know which version it is. Any idea ?
>
> Which project should be used ?
>
>
> Thanks,
>
>
> Mathieu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190823/c69a2699/attachment.htm>

From mathieu at xilan.net  Fri Aug 23 10:24:41 2019
From: mathieu at xilan.net (Mathieu)
Date: Fri, 23 Aug 2019 12:24:41 +0200
Subject: nextepc vs nextepc
In-Reply-To: <CAKoHG8C1tRaJu2=k8P9NV0k8h8xY07uO0sGvhHQgJhor5LOkmw@mail.gmail.com>
References: <f6cb4391-c7ad-6909-2c6b-81fa66f9f7d1@xilan.net>
 <CAKoHG8C1tRaJu2=k8P9NV0k8h8xY07uO0sGvhHQgJhor5LOkmw@mail.gmail.com>
Message-ID: <324ad92e-64db-6637-e0ea-93ab482bd2a0@xilan.net>

Hi Sukchan,

Thanks for this clarification. I'll continue to use your version then :)

Looking forward seeing your next plan.

Best regards

Mathieu

Le 23/08/2019 ? 11:57, Sukchan Lee a ?crit?:
> Hi Mathieu,
>
> FYI, see the link below.
> https://github.com/open5gs/nextepc/issues/181
>
> Perhaps many people are confused the NextEPC name.
> I'm still less prepared, but let me send my next plan in a separate email.
>
> Thanks a lot!
>
> Best Regards,
> ? ? Sukchan
>
>
> On Fri, Aug 23, 2019 at 5:44 PM Mathieu <mathieu at xilan.net 
> <mailto:mathieu at xilan.net>> wrote:
>
>     Hi everyone,
>
>
>     Does someone know the difference between these two projects:
>
>
>     https://github.com/open5gs/nextepc
>
>     https://github.com/nextepc/nextepc
>
>
>     They seem to share some code, but the second one seems to be owned
>     by a
>     US company, and the code as not been updated for months. (only 14
>     commits in the repo)
>
>
>     There are nextepc packages in the universe ubuntu repo too now, but I
>     don't know which version it is. Any idea ?
>
>     Which project should be used ?
>
>
>     Thanks,
>
>
>     Mathieu
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190823/9bbfd210/attachment.htm>

From acetcom at gmail.com  Fri Aug 23 12:00:34 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Fri, 23 Aug 2019 21:00:34 +0900
Subject: What's next plan?
Message-ID: <CAKoHG8C3aRETs5=acXaKy_Pa3XUhM9P+d5AYaq_HbkK4kvrC9A@mail.gmail.com>

Dear Community People.

Some people are asking about next plan. I didn't answer correctly because I
don't know how much time I have or how much my abilities are possible. But
now I think I need to start sharing what I want to do.

I don't know if it's possible to this, but I'd just like to prepare to move
5G Core. But there are a lots of things before that and I don't know
exactly when this project is going on.

Anyway, in order to share the code used by 4G/5G, I will separate the
repository as follows:

Repo1 : libogscore - apt install libogscore-dev

Repo2 : libogs-asn1c
   - common : apt install libogs-asn1c-common-dev
   - s1ap : apt install libogs-asn1c-s1ap-dev

Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev
   - libfdcore
   - libfdproto

Repo4 : libogslib - apt install libogslib-dev
   - s1ap : apt install libogs-s1ap-dev
      DEPEND libogs-asn1c-common-dev libogs-asn1c-s1ap
   - nas : apt install libogs-nas-dev
   - gtp : apt install libogs-gtp-dev
   - diameter : apt install libogs-diameter-dev
      DEPEND libogs-freeDiameter-dev
   - app : apt install libogs-app-dev

Repo5 : ogs-mme - apt install ogs-mme
  ; DEPEND libogs-app-dev libogs-s1ap-dev libogs-nas-dev libogs-gtp-dev
libogs-diameter-dev
Repo6 : ogs-hss - apt install ogs-hss
  ; DEPEND libogs-app-dev libogs-diameter-dev
Repo7 : ogs-pcrf - apt install ogs-pcrf
  ; DEPEND libogs-app-dev libogs-diameter-dev
Repo8 : ogs-sgw - apt install ogs-sgw
  ; DEPEND libogs-app-dev libogs-gtp-dev
Repo9 : ogs-pgw - apt install ogs-pgw
  ; DEPEND libogs-app-dev libogs-gtp-dev libogs-diameter-dev

Repo10 : ogs-epc
  ; if all stuff are available, current nextepc repo is changed to ogs-dev
for managing issues list

This approach is similar to the osmocom project. In fact, I'm not sure
whether this is good or not. However, osmocom manages 2G/3G like this and I
believe that experience.

So I'll do it from now.

P.S.
Please, feel free to give any idea the above plan. Expecially, 'NAMING'. ^^;

Thanks a lot!

Best Regards,
     Sukchan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190823/ff81cfda/attachment.htm>

From laforge at gnumonks.org  Mon Aug 26 20:01:33 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 26 Aug 2019 22:01:33 +0200
Subject: What's next plan?
In-Reply-To: <CAKoHG8C3aRETs5=acXaKy_Pa3XUhM9P+d5AYaq_HbkK4kvrC9A@mail.gmail.com>
References: <CAKoHG8C3aRETs5=acXaKy_Pa3XUhM9P+d5AYaq_HbkK4kvrC9A@mail.gmail.com>
Message-ID: <20190826200130.GH5940@nataraja>

Hi Sukchan,

thanks for sharing your thoughts.

On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote:
> Anyway, in order to share the code used by 4G/5G, I will separate the
> repository as follows:
> [...]

In general, I think it may make sense to split things up, but only to the extent
that the related [library] code is really going to be used by multiple applications
which logically don't belong together.

I currently don't know sufficiently about 5G to know how much of the
existing code would be needed in a 5G core.  For example, I don't think
DIAMETER is used in a true/native 5G core.

> This approach is similar to the osmocom project. In fact, I'm not sure
> whether this is good or not. However, osmocom manages 2G/3G like this and I
> believe that experience.

Beware there are consequences.  For example, if you have libraries in a
separate repository, you must be very careful about maintaining ABI and
API compatibility, as well as managing LIBVERSION properly.  This means
in general it's best to never modify any existing symbol (function) but
to only introduce new ones.  Otherwise a library upgrade without
application upgrade would break.

Also, you typically want to ensure backwards API compatibility, so that
any old application can be build with any new library version.  In order
to ensure this, it is best to have automatic testing that e.g. builds
all old/existing tags of applications against the 'master of the day'
of libraries.

So given the limited resources (time/developers), it requires careful
thinking whether all the related overhead makes sense.  Some things can
be automatized, but it also requires quite a bit of discipline from the
developer[s]. So be warned :P

> Please, feel free to give any idea the above plan. Expecially, 'NAMING'. ^^;

I think it's a good idea to avoid nextepc naming confusion related to
the U.S. entity nextepc inc. using an older codebase and your new
project.

I agree it is a good idea to separate any shared libraries into separate
repositories, but only *if* they are used by multiple other
repositories, and if you are committed to providing a rather stable API
and ABI.

I am not sure if moving towards the full set of repositories as
described is the best choice at this point.  It might be an idea to only
separate those which you will need from your new 5G core elements?

by the way: When creating the new repositories, make sure the git
history remains.  You can create the new repositories using 'git
filter-branch' of the current nextepc.git repository, keeping the
history of all the relevant commits.  Finally, you can then rename/move
files in one new commit.

The git commit history is just as important or sometimes even more
important for any future developers than the actual code.

Of course the above is just my opinion.  It's your project, you get to
decide :)

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 acetcom at gmail.com  Tue Aug 27 08:59:37 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Tue, 27 Aug 2019 17:59:37 +0900
Subject: What's next plan?
In-Reply-To: <20190826200130.GH5940@nataraja>
References: <CAKoHG8C3aRETs5=acXaKy_Pa3XUhM9P+d5AYaq_HbkK4kvrC9A@mail.gmail.com>
 <20190826200130.GH5940@nataraja>
Message-ID: <CAKoHG8D_2OofM6kdcmhG8HcCXt1-ewhroFKf43r3tt28=rZz1Q@mail.gmail.com>

See inline below.

On Tue, Aug 27, 2019 at 5:10 AM Harald Welte <laforge at gnumonks.org> wrote:

> Hi Sukchan,
>
> thanks for sharing your thoughts.
>
> On Fri, Aug 23, 2019 at 09:00:34PM +0900, Sukchan Lee wrote:
> > Anyway, in order to share the code used by 4G/5G, I will separate the
> > repository as follows:
> > [...]
>
> In general, I think it may make sense to split things up, but only to the
> extent
> that the related [library] code is really going to be used by multiple
> applications
> which logically don't belong together.
>
> I currently don't know sufficiently about 5G to know how much of the
> existing code would be needed in a 5G core.  For example, I don't think
> DIAMETER is used in a true/native 5G core.
>

Also I don't enough knowledge of 5G Core either. I really want to remove
the freeDiameter library in 5G. But DIAMETER still needs to connect the IMS
core on 5G. If true, I need to separate freeDiameter and NextEPC.


> > This approach is similar to the osmocom project. In fact, I'm not sure
> > whether this is good or not. However, osmocom manages 2G/3G like this
> and I
> > believe that experience.
>
> Beware there are consequences.  For example, if you have libraries in a
> separate repository, you must be very careful about maintaining ABI and
> API compatibility, as well as managing LIBVERSION properly.  This means
> in general it's best to never modify any existing symbol (function) but
> to only introduce new ones.  Otherwise a library upgrade without
> application upgrade would break.
>
> Also, you typically want to ensure backwards API compatibility, so that
> any old application can be build with any new library version.  In order
> to ensure this, it is best to have automatic testing that e.g. builds
> all old/existing tags of applications against the 'master of the day'
> of libraries.
>
> So given the limited resources (time/developers), it requires careful
> thinking whether all the related overhead makes sense.  Some things can
> be automatized, but it also requires quite a bit of discipline from the
> developer[s]. So be warned :P
>

I missed the library compatibility part. In split repository, I agreed that
it would be really hard to manage this. Hmm..IMHO, I need to reduce the
number of library since my time and ability is limited.


> > Please, feel free to give any idea the above plan. Expecially, 'NAMING'.
> ^^;
>
> I think it's a good idea to avoid nextepc naming confusion related to
> the U.S. entity nextepc inc. using an older codebase and your new
> project.
>
> I agree it is a good idea to separate any shared libraries into separate
> repositories, but only *if* they are used by multiple other
> repositories, and if you are committed to providing a rather stable API
> and ABI.
>
> I am not sure if moving towards the full set of repositories as
> described is the best choice at this point.  It might be an idea to only
> separate those which you will need from your new 5G core elements?
>
> by the way: When creating the new repositories, make sure the git
> history remains.  You can create the new repositories using 'git
> filter-branch' of the current nextepc.git repository, keeping the
> history of all the relevant commits.  Finally, you can then rename/move
> files in one new commit.
>
The git commit history is just as important or sometimes even more
> important for any future developers than the actual code.


I will do it definitely!


>
>
Of course the above is just my opinion.  It's your project, you get to
> decide :)
>

I'm really appreciated for your comments. From your advice, I'll revise the
REPO like the followings.

Repo1 : libogscore - apt install libogscore-dev

Repo2 : libogs-asn1c
   - common : apt install libogs-asn1c-common-dev
   - s1ap : apt install libogs-asn1c-s1ap-dev

Repo3 : libogs-freeDiameter - apt install libogs-freeDiameter-dev
   - libfdcore
   - libfdproto

Repo4 : Changes nextepc to ogs-epc.

Best Regards,
      Sukchan



>
> Regards,?


>         Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190827/650d2f29/attachment.htm>

From laforge at gnumonks.org  Tue Aug 27 10:59:52 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 27 Aug 2019 12:59:52 +0200
Subject: nextepc based LTE network @ CCCamp2019
Message-ID: <20190827105952.GJ5940@nataraja>

Hi all,

During the Chaos Communication Camp 2019 (an international hacker camp
with about 5500 participants) last week, there is a tradition to operate
Osmocom based 2G and more recently also 3G networks.

This time I operated a nextepc based 4G/LTE network next to the camp 2G/3G
networks.  In order to share one subscriber database, I have implemented
osmo_dia2gsup, which can translate  the S6a/S6d diameter into Osmocom GSUP
protocol, so nextepc can be used without nextepc-hssd but with osmo-hlr instead.

The network was operating six Ericsson RBS6402 in Band 7 (2600 MHz).

Some more details can be found at


Regarding the nextepc side:

* 2439 uniqua IMSIs were seen
** 147 unique IMSIs of CCC SIM cards (26242)
** 2292 non-CCC IMSIs
** 75 unique MCC-MNC tuples
** 34 unique MCCs
** The usual suspects (Europe + North America), but also...
*** Malaysia, Indonesia, Australia, New Zealand, South Africa
* 560 Attach accept (CCC SIM cards)
* 46590 Attach reject (commercial operator SIM cards)
* 629 PDN context (APN) activations
* 235 handovers between cells (X2)
* 64 crashes + restarts of nextepc-mme
* 9 crashes + restarts of nextepc-pgw
* 0 crashes + restarts of nextepc-sgw
* 10 crashes + restarts of nextepc-pcrf

In general, it worked quite nicely, and I have to congratulate Sukchan on
his work at nextepc.

I investigated some of the crashes, reported them to the issue tracker and
attempted to fix some of them on-site.  The actual codebase that was running
can be found at https://github.com/laf0rge/nextepc/commits/laforge/cccamp19

>From my experience with operating such a "large" nextepc network for the first
time, I have the following overall feedback, which basically boils down
to three major areas:

== the use of assert() ==

ASSERT should never be triggered by anything that is received from another
network entity.  So if a eNB sends an unknown S1AP-ID, or if a SGW sends
an unknown TEID, or if the NAS MAC validation fails, or a EMM message
cannot be decoded - all of those must be handled gracefully without
terminating the program.  This 'fail fast' way of programming can be
done when writing code in C++ (exceptions that are caught) or in erlang
(one process per message, crashing that one doesn't bring the entire MME
down).

I've tried my best to review all ogs_assert() in the MME and came up
with the following patch:
https://github.com/laf0rge/nextepc/commit/3b528af8fd51c85769123338eb57a4635c9d699e
which requires
https://github.com/laf0rge/ogslib/commit/dc36ccbb080038306666931bdc97f6204fd5c011
which introduces ogs_expect() and ogs_expect_or_return() macros that can
be used in many places instead of ogs_assert().

It would also be possible to use this kind of 'fail fast' approach in C
programs, but then one would have to use longjmp() from the 'assert',
and you would have to use some kind of hierarchical memory allocator so
that in the 'exception handler' you can release any dynamic allocations
that were made before.


== the lack of introspection ==

When you operate a network, it is vital to have some visibility.  For the
MME you want to inspect how many subscribers are currently attached, where
they are attached (TAC), whether they currently have an UE Context (and at
which eNB), which TMSI/GUTI was allocated, etc.

Likewise, for both SGW and PGW you want to see which PDN contexts exist, from
which peer IP adresses, which APN was used, what IP addresses have been allocated, etc.

In the Osmocom world, we implement this introspection in two ways:
* by means of the VTY interface (for the human user)
* by means of the CTRL interface (for other programs)

If I hadn't been busy with debugging various other issues, I would have actually
attempted to add a basic VTY interface to nextepc-mmed.

For sure there may be better ways to expose this state (ideally with the same
piece of code providing access to both human users as well as external programs),
but I'm not aware of any nice C language implementation in FOSS that one could
use right away.


== logging without context ==

When looking at log file output, it is very important that this log file output
always carry sufficient context.  IF there are many subscribers acting in parallel,
you need to know which subscriber / pdn context / ... a given log message relates
to, otherwise the log message is rather useless.

For example, if you get
	[mme] DEBUG: [MME] Authentication-Information-Answer (mme-fd-path.c:211)
then even at DEBUG level you have no indication what so ever for which
particular subscriber this AIA was received.  I would normally expect
that the UE is resolved from the DIAMETER session-id, and then the UEs
identity (IMSI) can be printed.

I also find it suboptimal that log lines often span multiple lines, which means
you cannot simply 'grep' for something, as you always need to check some lines
before and/or after.  But I guess conrary to the lack of context, this
is a matter of teste and one can have different opinions about it.


I'll try to contribute as much as I can regarding bug fixes and
enhancements.  Thanks again for all the great work so far!

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  Tue Aug 27 14:12:23 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 27 Aug 2019 16:12:23 +0200
Subject: nextepc based LTE network @ CCCamp2019
In-Reply-To: <20190827105952.GJ5940@nataraja>
References: <20190827105952.GJ5940@nataraja>
Message-ID: <20190827141223.GF4423@nataraja>

Hi all,

On Tue, Aug 27, 2019 at 12:59:52PM +0200, Harald Welte wrote:
> Some more details can be found at

I forgot to insert the link here:
http://people.osmocom.org/laforge/slides/cccamp2019-how_the_camp_lte_works.pdf

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 acetcom at gmail.com  Tue Aug 27 14:20:37 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Tue, 27 Aug 2019 23:20:37 +0900
Subject: nextepc based LTE network @ CCCamp2019
In-Reply-To: <20190827105952.GJ5940@nataraja>
References: <20190827105952.GJ5940@nataraja>
Message-ID: <CAKoHG8B3c+cgAT7X+4RqQYfb+vjUkECzNh1Q8P7UHpfRJdrAug@mail.gmail.com>

Hi Harald,

I'm really surprising that nextepc can support such a large people.
I'd like to share my though about three good point.

1. ogs_expect()
I think that ogs_expect() is really good starting point to remove
unnecessary ogs_assert().
So, I added my version in ogslib() repository as below.

#define ogs_expect(expr, fallback) \
    do { \
        if (ogs_likely(expr)) ; \
        else { \
            ogs_error("%s: Expectation `%s' failed.", OGS_FUNC, #expr); \
            fallback; \
        } \
    } while (0)

Let me know if the above interface has a problem.

2. VTY/CTRL
I'm happy if nextepc can have such a good VTY/CTL. Indeed, this is actually
needed if someone would like to test nextepc on a large scale.

3. Logging
I agree that IMSI, APN context is needed when logging. So, I think
mme_log()/sgw_log()/... needs to be introduced. And also, I saw a fix of
the freeDiameter logging. How about merging it  to master branch. Please
github pull request if you agree.

Much appreciated about your super work!

Best Regards,
    Sukchan



On Tue, Aug 27, 2019 at 8:00 PM Harald Welte <laforge at gnumonks.org> wrote:

> Hi all,
>
> During the Chaos Communication Camp 2019 (an international hacker camp
> with about 5500 participants) last week, there is a tradition to operate
> Osmocom based 2G and more recently also 3G networks.
>
> This time I operated a nextepc based 4G/LTE network next to the camp 2G/3G
> networks.  In order to share one subscriber database, I have implemented
> osmo_dia2gsup, which can translate  the S6a/S6d diameter into Osmocom GSUP
> protocol, so nextepc can be used without nextepc-hssd but with osmo-hlr
> instead.
>
> The network was operating six Ericsson RBS6402 in Band 7 (2600 MHz).
>
> Some more details can be found at
>
>
> Regarding the nextepc side:
>
> * 2439 uniqua IMSIs were seen
> ** 147 unique IMSIs of CCC SIM cards (26242)
> ** 2292 non-CCC IMSIs
> ** 75 unique MCC-MNC tuples
> ** 34 unique MCCs
> ** The usual suspects (Europe + North America), but also...
> *** Malaysia, Indonesia, Australia, New Zealand, South Africa
> * 560 Attach accept (CCC SIM cards)
> * 46590 Attach reject (commercial operator SIM cards)
> * 629 PDN context (APN) activations
> * 235 handovers between cells (X2)
> * 64 crashes + restarts of nextepc-mme
> * 9 crashes + restarts of nextepc-pgw
> * 0 crashes + restarts of nextepc-sgw
> * 10 crashes + restarts of nextepc-pcrf
>
> In general, it worked quite nicely, and I have to congratulate Sukchan on
> his work at nextepc.
>
> I investigated some of the crashes, reported them to the issue tracker and
> attempted to fix some of them on-site.  The actual codebase that was
> running
> can be found at
> https://github.com/laf0rge/nextepc/commits/laforge/cccamp19
>
> From my experience with operating such a "large" nextepc network for the
> first
> time, I have the following overall feedback, which basically boils down
> to three major areas:
>
> == the use of assert() ==
>
> ASSERT should never be triggered by anything that is received from another
> network entity.  So if a eNB sends an unknown S1AP-ID, or if a SGW sends
> an unknown TEID, or if the NAS MAC validation fails, or a EMM message
> cannot be decoded - all of those must be handled gracefully without
> terminating the program.  This 'fail fast' way of programming can be
> done when writing code in C++ (exceptions that are caught) or in erlang
> (one process per message, crashing that one doesn't bring the entire MME
> down).
>
> I've tried my best to review all ogs_assert() in the MME and came up
> with the following patch:
>
> https://github.com/laf0rge/nextepc/commit/3b528af8fd51c85769123338eb57a4635c9d699e
> which requires
>
> https://github.com/laf0rge/ogslib/commit/dc36ccbb080038306666931bdc97f6204fd5c011
> which introduces ogs_expect() and ogs_expect_or_return() macros that can
> be used in many places instead of ogs_assert().
>
> It would also be possible to use this kind of 'fail fast' approach in C
> programs, but then one would have to use longjmp() from the 'assert',
> and you would have to use some kind of hierarchical memory allocator so
> that in the 'exception handler' you can release any dynamic allocations
> that were made before.
>
>
> == the lack of introspection ==
>
> When you operate a network, it is vital to have some visibility.  For the
> MME you want to inspect how many subscribers are currently attached, where
> they are attached (TAC), whether they currently have an UE Context (and at
> which eNB), which TMSI/GUTI was allocated, etc.
>
> Likewise, for both SGW and PGW you want to see which PDN contexts exist,
> from
> which peer IP adresses, which APN was used, what IP addresses have been
> allocated, etc.
>
> In the Osmocom world, we implement this introspection in two ways:
> * by means of the VTY interface (for the human user)
> * by means of the CTRL interface (for other programs)
>
> If I hadn't been busy with debugging various other issues, I would have
> actually
> attempted to add a basic VTY interface to nextepc-mmed.
>
> For sure there may be better ways to expose this state (ideally with the
> same
> piece of code providing access to both human users as well as external
> programs),
> but I'm not aware of any nice C language implementation in FOSS that one
> could
> use right away.
>
>
> == logging without context ==
>
> When looking at log file output, it is very important that this log file
> output
> always carry sufficient context.  IF there are many subscribers acting in
> parallel,
> you need to know which subscriber / pdn context / ... a given log message
> relates
> to, otherwise the log message is rather useless.
>
> For example, if you get
>         [mme] DEBUG: [MME] Authentication-Information-Answer
> (mme-fd-path.c:211)
> then even at DEBUG level you have no indication what so ever for which
> particular subscriber this AIA was received.  I would normally expect
> that the UE is resolved from the DIAMETER session-id, and then the UEs
> identity (IMSI) can be printed.
>
> I also find it suboptimal that log lines often span multiple lines, which
> means
> you cannot simply 'grep' for something, as you always need to check some
> lines
> before and/or after.  But I guess conrary to the lack of context, this
> is a matter of teste and one can have different opinions about it.
>
>
> I'll try to contribute as much as I can regarding bug fixes and
> enhancements.  Thanks again for all the great work so far!
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190827/684aba88/attachment.htm>

From laforge at gnumonks.org  Tue Aug 27 14:31:41 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 27 Aug 2019 16:31:41 +0200
Subject: nextepc based LTE network @ CCCamp2019
In-Reply-To: <CAKoHG8B3c+cgAT7X+4RqQYfb+vjUkECzNh1Q8P7UHpfRJdrAug@mail.gmail.com>
References: <20190827105952.GJ5940@nataraja>
 <CAKoHG8B3c+cgAT7X+4RqQYfb+vjUkECzNh1Q8P7UHpfRJdrAug@mail.gmail.com>
Message-ID: <20190827143140.GI4423@nataraja>

Hi Sukchan,

On Tue, Aug 27, 2019 at 11:20:37PM +0900, Sukchan Lee wrote:

> I'm really surprising that nextepc can support such a large people.

What I'm personally quite happy is that I couldn't see any clear memory
leaks.  Knowing from experience, this is one of the hardest tasks in
development of complex C-language software.

> 1. ogs_expect()
> I think that ogs_expect() is really good starting point to remove
> unnecessary ogs_assert().
> So, I added my version in ogslib() repository as below.
> 
> #define ogs_expect(expr, fallback) \
>     do { \
>         if (ogs_likely(expr)) ; \
>         else { \
>             ogs_error("%s: Expectation `%s' failed.", OGS_FUNC, #expr); \
>             fallback; \
>         } \
>     } while (0)
> 
> Let me know if the above interface has a problem.

I don't see a problem, other than the code looking - from my point of view
"ugly".  having return statements inside a macro argument is highly unusual,
AFAICT.

Also, in your version, how would a "print a message but do nothing else" look like?
I think it would be "ogs_expect(ret == OGS_OK, );" where the empty second argument
looks completely unlike C code at all...

I understand your motivation and I was also thinking about something like this
originally, but I decided against it.  At least at the moment most of your
related functions return 'void' anyway, so my ogs_expect_or_return() worked fine.

I think as soon as you want to do something else but either nothing or return,
then you need to introduce a proper if-clause with error handling.  That's why
I introduced only those two versions and not a flexible variant.

> 2. VTY/CTRL
> I'm happy if nextepc can have such a good VTY/CTL. Indeed, this is actually
> needed if someone would like to test nextepc on a large scale.

As indicated, the question is whether I should simply start adding Osmocom VTY
using libosmocore, or if we should spend some more time looking for alternatives
or even designing + writing some new, better system and then introduce this to
nextepc.  I'm a bit undecided here at this point.  Take the quick route or the long
path...

> 3. Logging
> I agree that IMSI, APN context is needed when logging. So, I think
> mme_log()/sgw_log()/... needs to be introduced. And also, I saw a fix of
> the freeDiameter logging. How about merging it  to master branch. Please
> github pull request if you agree.

It's probably even more like a mme_ue_log() or something like that, because you
may have different objects/structs which provide loggign context.

In Osmocom we have introduced log macros like LOG_MSC_A(), LOG_MNCC_CALL(), lOG_MSUB()
where the first argument is typically the 'object' providing context.  Those macros then
expand to a call to the generic logging macro/function.

-- 
- 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 acetcom at gmail.com  Tue Aug 27 15:14:08 2019
From: acetcom at gmail.com (Sukchan Lee)
Date: Wed, 28 Aug 2019 00:14:08 +0900
Subject: nextepc based LTE network @ CCCamp2019
In-Reply-To: <20190827143140.GI4423@nataraja>
References: <20190827105952.GJ5940@nataraja>
 <CAKoHG8B3c+cgAT7X+4RqQYfb+vjUkECzNh1Q8P7UHpfRJdrAug@mail.gmail.com>
 <20190827143140.GI4423@nataraja>
Message-ID: <CAKoHG8C2acwWn0tDq7q3s3-EBydyK_0HPULQAbXX8vyt4TPMng@mail.gmail.com>

See inline!

On Tue, Aug 27, 2019 at 11:40 PM Harald Welte <laforge at gnumonks.org> wrote:

> Hi Sukchan,
>
> On Tue, Aug 27, 2019 at 11:20:37PM +0900, Sukchan Lee wrote:
>
> > I'm really surprising that nextepc can support such a large people.
>
> What I'm personally quite happy is that I couldn't see any clear memory
> leaks.  Knowing from experience, this is one of the hardest tasks in
> development of complex C-language software.
>
> > 1. ogs_expect()
> > I think that ogs_expect() is really good starting point to remove
> > unnecessary ogs_assert().
> > So, I added my version in ogslib() repository as below.
> >
> > #define ogs_expect(expr, fallback) \
> >     do { \
> >         if (ogs_likely(expr)) ; \
> >         else { \
> >             ogs_error("%s: Expectation `%s' failed.", OGS_FUNC, #expr); \
> >             fallback; \
> >         } \
> >     } while (0)
> >
> > Let me know if the above interface has a problem.
>
> I don't see a problem, other than the code looking - from my point of view
> "ugly".  having return statements inside a macro argument is highly
> unusual,
> AFAICT.
>
> Also, in your version, how would a "print a message but do nothing else"
> look like?
> I think it would be "ogs_expect(ret == OGS_OK, );" where the empty second
> argument
> looks completely unlike C code at all...
>
> I understand your motivation and I was also thinking about something like
> this
> originally, but I decided against it.  At least at the moment most of your
> related functions return 'void' anyway, so my ogs_expect_or_return()
> worked fine.
>
> I think as soon as you want to do something else but either nothing or
> return,
> then you need to introduce a proper if-clause with error handling.  That's
> why
> I introduced only those two versions and not a flexible variant.
>

Ah! Now, I understand your intention. So I did rollback
ogs_expect_or_return().
Thank you for introducing a good interface.



> > 2. VTY/CTRL
> > I'm happy if nextepc can have such a good VTY/CTL. Indeed, this is
> actually
> > needed if someone would like to test nextepc on a large scale.
>
> As indicated, the question is whether I should simply start adding Osmocom
> VTY
> using libosmocore, or if we should spend some more time looking for
> alternatives
> or even designing + writing some new, better system and then introduce
> this to
> nextepc.  I'm a bit undecided here at this point.  Take the quick route or
> the long
> path...
>

Basically, I planned to implement HTTP/JSON for this part(e.g. GET /ue,
POST /logging). And also, I'd like to monitor the status in the WebUI.
However, to do so, we need to create one process to handle it. IMHO, it
will take a long to implement it. I also don't know which one is better for
us.


> > 3. Logging
> > I agree that IMSI, APN context is needed when logging. So, I think
> > mme_log()/sgw_log()/... needs to be introduced. And also, I saw a fix of
> > the freeDiameter logging. How about merging it  to master branch. Please
> > github pull request if you agree.
>
> It's probably even more like a mme_ue_log() or something like that,
> because you
> may have different objects/structs which provide loggign context.
>
> In Osmocom we have introduced log macros like LOG_MSC_A(),
> LOG_MNCC_CALL(), lOG_MSUB()
> where the first argument is typically the 'object' providing context.
> Those macros then
> expand to a call to the generic logging macro/function.
>

I saw your work! LOG macro with context adds the prefix logging. I will
refer your work when I improve a logging.

-- 
> - 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/nextepc/attachments/20190828/c4ba2889/attachment.htm>

From matt9j at cs.washington.edu  Tue Aug 27 17:46:14 2019
From: matt9j at cs.washington.edu (Matt Johnson)
Date: Tue, 27 Aug 2019 12:46:14 -0500
Subject: nextepc based LTE network @ CCCamp2019
In-Reply-To: <CAKoHG8C2acwWn0tDq7q3s3-EBydyK_0HPULQAbXX8vyt4TPMng@mail.gmail.com>
References: <20190827105952.GJ5940@nataraja>
 <CAKoHG8B3c+cgAT7X+4RqQYfb+vjUkECzNh1Q8P7UHpfRJdrAug@mail.gmail.com>
 <20190827143140.GI4423@nataraja>
 <CAKoHG8C2acwWn0tDq7q3s3-EBydyK_0HPULQAbXX8vyt4TPMng@mail.gmail.com>
Message-ID: <5582bc12-fcac-4eb9-8bce-41d64b5a15c7@cs.washington.edu>

Thanks Harald for the detailed writeup and the work to get a large 
NextEPC network up and running.

Regarding point 2, I think it might be good to consider starting with 
only a programmatic interface (CTRL or some kind of RPC framework 
possibly?) integrated directly into the EPC code, and then providing the 
end UI to users as a client of the programmatic interface. This would 
allow separating out the client UI code from the core EPC components 
more easily, and make it more scalable to add additional interfaces as 
needed (I.E. a web gui and a telnet cli existing in parallel, with 
access to the same underlying functionality).

-Matt J.

On 8/27/19 10:14 AM, Sukchan Lee wrote:
> See inline!
>
> On Tue, Aug 27, 2019 at 11:40 PM Harald Welte <laforge at gnumonks.org 
> <mailto:laforge at gnumonks.org>> wrote:
>
>     Hi Sukchan,
>
>     On Tue, Aug 27, 2019 at 11:20:37PM +0900, Sukchan Lee wrote:
>
>     > I'm really surprising that nextepc can support such a large people.
>
>     What I'm personally quite happy is that I couldn't see any clear
>     memory
>     leaks.? Knowing from experience, this is one of the hardest tasks in
>     development of complex C-language software.
>
>     > 1. ogs_expect()
>     > I think that ogs_expect() is really good starting point to remove
>     > unnecessary ogs_assert().
>     > So, I added my version in ogslib() repository as below.
>     >
>     > #define ogs_expect(expr, fallback) \
>     >? ? ?do { \
>     >? ? ? ? ?if (ogs_likely(expr)) ; \
>     >? ? ? ? ?else { \
>     >? ? ? ? ? ? ?ogs_error("%s: Expectation `%s' failed.", OGS_FUNC,
>     #expr); \
>     >? ? ? ? ? ? ?fallback; \
>     >? ? ? ? ?} \
>     >? ? ?} while (0)
>     >
>     > Let me know if the above interface has a problem.
>
>     I don't see a problem, other than the code looking - from my point
>     of view
>     "ugly".? having return statements inside a macro argument is
>     highly unusual,
>     AFAICT.
>
>     Also, in your version, how would a "print a message but do nothing
>     else" look like?
>     I think it would be "ogs_expect(ret == OGS_OK, );" where the empty
>     second argument
>     looks completely unlike C code at all...
>
>     I understand your motivation and I was also thinking about
>     something like this
>     originally, but I decided against it.? At least at the moment most
>     of your
>     related functions return 'void' anyway, so my
>     ogs_expect_or_return() worked fine.
>
>     I think as soon as you want to do something else but either
>     nothing or return,
>     then you need to introduce a proper if-clause with error
>     handling.? That's why
>     I introduced only those two versions and not a flexible variant.
>
>
> Ah! Now, I understand your intention. So I did rollback 
> ogs_expect_or_return().
> Thank you for introducing a good interface.
>
>     > 2. VTY/CTRL
>     > I'm happy if nextepc can have such a good VTY/CTL. Indeed, this
>     is actually
>     > needed if someone would like to test nextepc on a large scale.
>
>     As indicated, the question is whether I should simply start adding
>     Osmocom VTY
>     using libosmocore, or if we should spend some more time looking
>     for alternatives
>     or even designing + writing some new, better system and then
>     introduce this to
>     nextepc.? I'm a bit undecided here at this point.? Take the quick
>     route or the long
>     path...
>
>
> Basically, I planned to implement HTTP/JSON for this part(e.g. GET 
> /ue, POST /logging). And also, I'd like to monitor the status in the 
> WebUI. However, to do so, we need to create one process to handle it. 
> IMHO, it will take a long to implement it. I also don't know which one 
> is better for us.
>
>     > 3. Logging
>     > I agree that IMSI, APN context is needed when logging. So, I think
>     > mme_log()/sgw_log()/... needs to be introduced. And also, I saw
>     a fix of
>     > the freeDiameter logging. How about merging it? to master
>     branch. Please
>     > github pull request if you agree.
>
>     It's probably even more like a mme_ue_log() or something like
>     that, because you
>     may have different objects/structs which provide loggign context.
>
>     In Osmocom we have introduced log macros like LOG_MSC_A(),
>     LOG_MNCC_CALL(), lOG_MSUB()
>     where the first argument is typically the 'object' providing
>     context.? Those macros then
>     expand to a call to the generic logging macro/function.
>
>
> I saw your work! LOG macro with context adds the prefix logging. I 
> will refer your work when I improve a logging.
>
>     -- 
>     - Harald Welte <laforge at gnumonks.org
>     <mailto:laforge at gnumonks.org>> http://laforge.gnumonks.org/
>     ============================================================================
>     "Privacy in residential applications is a desirable marketing option."
>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300
>     175-7 Ch. A6)
>