July 2019 - nextepc - lists.osmocom.org

CS Fallback in NextEPC
by Sukchan Lee 05 Aug '19

05 Aug '19

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

5 13

Nextepc died in some MT-Fallback
by Romeu Medeiros 28 Jul '19

28 Jul '19

Hello, In some situations the Nextepc is crashing when try the MT-CSFB. Here is the log: 07/17 17:48:53.270: [mme] WARNING: EMM_CAUSE : IMSI Unknown in HSS (mme-sm.c:339) 07/17 17:48:54.480: [mme] WARNING: ERROR DIAMETER Result Code(5001) (mme-fd-path.c:298) 07/17 17:48:54.480: [mme] WARNING: EMM_CAUSE : IMSI Unknown in HSS (mme-sm.c:339) 07/17 17:48:55.611: [s1ap] ERROR: Failed to encode S1AP-PDU[-1] (s1ap-encoder.c:41) 07/17 17:48:55.611: [mme] ERROR: s1ap_encode_pdu() failed (s1ap-build.c:555) 07/17 17:48:55.611: [mme] FATAL: s1ap_send_initial_context_setup_request: Assertion `rv == OGS_OK && s1apbuf' failed. (s1ap-path.c:252) File Logging: '//var/log/nextepc/mme.log' Configuration: '//etc/nextepc/mme.conf' 07/17 17:48:58.215: [mme] INFO: MME initialize...done (mme.c:28) NextEPC daemon v0.5.0.26-b642c 07/17 17:48:58.215: [gtp] INFO: gtp_server() [10.3.15.38]:2123 (gtp-path.c:36) 07/17 17:48:58.215: [gtp] INFO: gtp_server() [2804:828:3:15:b010:37ff:fe46:4521]:2123 (gtp-path.c:36) 07/17 17:48:58.215: [gtp] INFO: gtp_server() [2804:828:3:208:48a0:1cff:fed9:b7c9]:2123 (gtp-path.c:36) 07/17 17:48:58.215: [gtp] INFO: gtp_connect() [127.0.0.2]:2123 (gtp-path.c:61) 07/17 17:48:58.216: [mme] INFO: sgsap client() [127.0.0.1]:29118 (sgsap-lkpath.c:47) 07/17 17:48:58.216: [mme] INFO: s1ap_server() [10.3.15.38]:36412 (s1ap-lkpath.c:44) 07/17 17:48:58.217: [fd] INFO: CONNECTED TO 'hss.localdomain' (TCP,soc#14): (fd-logger.c:113) 07/17 17:48:58.802: [mme] INFO: eNB-S1 accepted[10.12.0.3]:36412 in s1_path module (s1ap-lkpath.c:70) In the attached file is the pcap from this moment, I will try to find what is happened. Thanks Romeu Medeiros

3 7

SMS
by Romeu Medeiros 18 Jul '19

18 Jul '19

Hello guys and @Sukchan Lee <acetcom(a)gmail.com> I tested with sucess the send and receive SMS in new version of NextEPC running together with OSMO-MSC/HLR (SGS). Thanks Romeu Medeiros

3 10

SNOW-3G / ZUC implementation under FOSS license?
by Paul Sutton 16 Jul '19

16 Jul '19

Hi Harald, The srsLTE implementation is taken from the ETSI specs simulation program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf https://www.etsi.org/intellectual-property-rights#mytoc3 and https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the copyright licensing details for software incorporated in ETSI standards however I have not taken legal advice on compatibility of this license with AGPLv3. >From a quick review, it looks like the CryptoMobile and NextEPC versions have taken the same approach. It would be good as you say to have a "clean copyright" implementation - perhaps this is something we could help with. Best regards, Paul > Hi! > > I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for > NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. > > However, it seems there is no real FOSS implementation of the SNOW-3G algoritm > around? All I could find was: > > * https://github.com/mitshell/CryptoMobile with unclear source of the code, > without a copyright statement or license annotation > > * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main… > without a copyright statement or license annotation > > * https://github.com/Jadson27101/SNOW_3G in go, > without a copyright statement or license annotation > > * https://github.com/KsirbJ/SNOW-3G > without a copyright statement or license annotation > > * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c > without a copyright statement or license annotation. Looks rather similar > to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? > > * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc > also contains no coypright statement or license, but might be construed > to be AGPLv3 like all of srsLTE. However, it states it is "adapted" > from ETSI/SAGE specifications. Does that mean it is an independent > implementation of the algorithm by just reading the specs, or does it > contain actual ETSI-copyrighted code? > > It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) > don't contain any actual information but all just point to the ETSI SAGE specification > which can be found (at the very least) here: > https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf > and interestingly doesn't contain any copyright statement whatsoever. > > This discussion is not about any potentially 'essential patents' that may or may > not apply in some jurisdictions on the algorithm itself. I'm currently only interested > in a "clean copyright" implementation of any of the EIA/EEA implementations used > on the LTE NAS layer. > > I'd appreciate any useful comments. Thanks! > > -- > - Harald Welte <laforge at gnumonks.org <https://lists.osmocom.org/mailman/listinfo/openbsc>> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -- ________________________________________________________________ Paul Sutton Ph.D. Software Radio Systems (SRS) http://www.softwareradiosystems.com paul(a)softwareradiosystems.com PGP Key ID: 3B4A5292 Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292 ________________________________________________________________

2 1

osmocom CN domain and keyword
by Peter Liu 16 Jul '19

16 Jul '19

(It's very urgent, please transfer this email to your CEO. Thanks) We are a Network Service Company which is the domain name registration center in Shanghai, China. On July 16, 2019, we received an application from Kaiqian Ltd requested "osmocom" as their internet keyword and China (CN) domain names (osmocom.cn, osmocom.com.cn, osmocom.net.cn, osmocom.org.cn). But after checking it, we find this name conflict with your company name or trademark. In order to deal with this matter better, it's necessary to send email to you and confirm whether your company have connection with this Chinese company or not? Best Regards *************************************** Peter Liu | Service & Operations Manager China Registry (Head Office) | 6012, Xingdi Building, No. 1698 Yishan Road, Shanghai 201103, China Tel: +86-02164193517 | Fax: +86-02164198327 | Mob: +86-13816428671 Email: peter(a)chinaregistry.org Web: www.chinaregistry.org *************************************** This email contains privileged and confidential information intended for the addressee only. If you are not the intended recipient, please destroy this email and inform the sender immediately. We appreciate you respecting the confidentiality of this information by not disclosing or using the information in this email.

1 0

OCS interface/NB-IoT support
by Daniel Feferman 15 Jul '19

15 Jul '19

Hi, First of all congrats for the work, I've been testing over this week and it has been really nice to stress it. I have two questions: 1- It would be really nice to see an OCS integration, is it possible to connect the PCRF and PGW with it? I believe this would be done by a 127.0.0.X IP, right? Is this something simple to implement? It would be nice to check the support to OCS 2- I believe you are developing NB-IoT support as part of your roadmap, what are the main challenges you see in this task? Is it just programming the messages of NB-IoT? Or is it something else? I can try to help you with this task. Best regards, Daniel <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Livre de vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 2

Re: CS Fallback in NextEPC
by Romeu Medeiros 14 Jul '19

14 Jul '19

Hello Sukchan, I already go out from the lab today, but Monday I will made this test that you ask for. Have a great day there. Romeu Medeiros Em sáb, 13 de jul de 2019 às 21:01, Sukchan Lee <acetcom(a)gmail.com> escreveu: > Hi Romeu, > > I'm really appreciate testing CSFB even though I have never been testing > this feature in the lab. > > BTW, I have one question. If we want to remove Security-Related IE in UE > Context Modification Request, > I think NextEPC should not derive kENB in Extended Service Request handler. > > Nevertheless, I've merged your pull request since it is properly worked at > first. ^^; > > If your lab is available, could you test one more by removing the > following code? > > In src/mme/emm-handler.c > 586 if (SECURITY_CONTEXT_IS_VALID(mme_ue)) { > 587 mme_kdf_enb(mme_ue->kasme, mme_ue->ul_count.i32, mme_ue->kenb); > 588 mme_kdf_nh(mme_ue->kasme, mme_ue->kenb, mme_ue->nh); > 589 mme_ue->nhcc = 1; > 590 } > > Just test it. If my expectation is true, I will fix all other things. > > Thank you for your GREAT job! > > Best regards, > Sukchan > > > > > > On Sun, Jul 14, 2019 at 8:04 AM Romeu Medeiros <medeiros(a)medeiros.eng.br> > wrote: > >> Hello Sukchan, >> >> Now after remove this everything run correctly. >> >> [image: image.png] >> >> I will made the change more beatiful and pull the modification to the git >> to you aprove. >> >> Thanks >> >> Romeu Medeiros >> >> On Sat, Jul 13, 2019 at 6:50 PM Romeu Medeiros <medeiros(a)medeiros.eng.br> >> wrote: >> >>> I found this in the 3GPP documentations [1]: >>> >>> [image: image.png] >>> >>> I will change the code to send only the CSFallback indicator in this >>> case to see if can solve the problem. >>> >>> Thanks >>> >>> Romeu Medeiros >>> >>> 1. >>> https://www.etsi.org/deliver/etsi_ts/136400_136499/136413/09.10.00_60/ts_13… >>> >>> On Sat, Jul 13, 2019 at 6:35 PM Romeu Medeiros <medeiros(a)medeiros.eng.br> >>> 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: 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(a)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 >>>>> # 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 >>>>> >>>>>

2 10

Question on Uplink 'sequence count' handling in MME
by Harald Welte 13 Jul '19

13 Jul '19

Hi Sukchan and list, I'm currently reading the MME code and I'm having some trouble understanding the handling of the uplink counter for NAS security. I only see mme_ue->ul_count.i32 ever being set to '0' when a new security context is used. But I don't see it ever being incremented? I only see ul_count.sqn incremented, but then the nas_mac_calculate() always gets ul_count.i32 passed as input. So I'm somehow not understanding how the MAC can ever verify on any uplink message beyond/after the first one which establishes a new security context. What am I missing? Thanks for your insight! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

SNOW-3G / ZUC implementation under FOSS license?
by Harald Welte 12 Jul '19

12 Jul '19

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

2 1

Easy way to add subscribers to hss without node.js / web UI
by Harald Welte 12 Jul '19

12 Jul '19

Hi Sukchan and list, I was wondering if there was a way to create subscribers in the HSS from a script or from the command line and avoid/bypass all the node.js and npm "nightmare" (I know, it's a matter of taste, but to me it is). Particularly for automated tests, I wouldnt't want to write scripts against a web gui to create subscribers. Also, for most operators (small or big), I guess they want to import a bulk CSV (or other format) file with key data. If there was a way to add subscribers from a script / command line, I could e.g. writea script to import the CSV for the sysmoUSIM/SJS1 easily. Thanks for any assistance. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 2

2025

2024

2023

2022

2021

2020

2019

nextepc July 2019