From dlfeferman at gmail.com Thu Jul 4 12:55:46 2019 From: dlfeferman at gmail.com (Daniel Feferman) Date: Thu, 4 Jul 2019 09:55:46 -0300 Subject: OCS interface/NB-IoT support Message-ID: 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 Livre de v?rus. www.avast.com . <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From acetcom at gmail.com Thu Jul 4 13:16:25 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Thu, 4 Jul 2019 22:16:25 +0900 Subject: OCS interface/NB-IoT support In-Reply-To: References: Message-ID: Hi Daniel, First of all, thank you for testing NextEPC. OCS/OFCS should be developed, but its priority is lower. I have received some data from you about NB-IoT, but it is not enough to implement the simulator. In fact, having pcap file will be very helpful. I also do not have NB-IoT equipment either. So I don't know if I can get it right. If I have some free time, I will try to support NB-IoT as well. Thank you again for reminding me. Best Regards, Sukchan On Thu, Jul 4, 2019 at 9:57 PM Daniel Feferman wrote: > 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 > > > Livre > de v?rus. www.avast.com > . > <#m_-6040955901365899195_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jul 9 11:50:26 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 Jul 2019 19:50:26 +0800 Subject: License for our test suites Message-ID: <20190709115026.GA3429@nataraja> Dear Osmocom community, during recent years we have developed a quite extensive set of test suites for virtually all interfaces on all protocol levels of our 2G stack, and recently even extended at least with some 3G IuCS coverage. Those test suites are considerably valuable for testing any kind of implementation of 2G / 3G network elements, even beyond Osmocom. I'm a bit worried that they might be used to test proprietary implementations, which would bring no value to growing FOSS in mobile communications. Whether we license the test suites under GPL or AGPL doesn't actually change much here: Imagine "EvilCorp" developing a BSC, using our test suites against it. They neither distribute the test suite, nor do they provide "access over a network" to it, an hence they could keep any modifications/extensions/derivatives private without having to contribute those back. I think this is problematic. We develop those test suites because we care about having well-tested FOSS in cellular communications, whether Osmocom or other FOSS projects. I certainly don't want to spend my spare time, or invest sysmocom resources towards improving the test coverage of any non-FOSS implementations. If such users are out there, they should at the very least contribute to the development effort in one way (code) or another (funding). For 2G/3G, I think this discussion is quite theoretical, as there is unlikely anyone else implementing those old technologies in proprietary systems - Osmocom is probably typically the latest player in the market to do so. However, as I'm currently working on a first set of TTCN3 tests for testing a LTE MME (initially attacing to S1 and SGs), I'm wondering if we should continue to release related code under traditional copyleft licenses. One idea would be to have a license that permits the use of the test suites to test only FOSS software. In theory, that would mean that all projects we care about (such as currently srsLTE, nextepc, OAI EPC, ...) could use the test suites to test their software. On the other hand, if some vendor of proprietary MME/EPC software would want to [legally] use the tests, they would need to obtain a different (paid) license to the test suite. Of course they could simply ignore the license and we'd have little chance to learn about it - but I would argue most proper companies typically would obtain a license if they used some software they knew they had to license. This is a very double-edged sword. Drafting such a new license would cause license proliferation, which is always bad. It also raises quesetions of license compatibility with e.g. some of our common existing 'library' code that would need to be investigated. Finally, it also means that we'd no longer be writing "free software" nor "open source", as the respective relevant definitions always require "non discriminatory use for any purpose", which would no longer be the case here. This is currently an early stage brainstorming. Now is the right point in time to talk about this, before we release any LTE/EPC related tests. Let me know if you have any thoughts to share. While I'm cross-posting this to openbsc@ and nextepc@ lists, pleaes follow-up-to openbsc at lists.osmocom.org, as that's the main Osmocom mailing list and we don't have any specifically only for the test suites. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From silke.holtmanns at nokia-bell-labs.com Tue Jul 9 06:24:44 2019 From: silke.holtmanns at nokia-bell-labs.com (Holtmanns, Silke (Nokia - FI/Espoo)) Date: Tue, 9 Jul 2019 06:24:44 +0000 Subject: Somebody tried this (or parts of it) In-Reply-To: References: Message-ID: Maybe it goes through this time. Seems it did not make it the first time... From: Holtmanns, Silke (Nokia - FI/Espoo) Sent: Friday, July 5, 2019 12:55 PM To: nextepc at lists.osmocom.org Cc: Kalliola, Aapo (Nokia - FI/Espoo) Subject: Somebody tried this (or parts of it) Hi, are mainly interested in the core network part and not on the UE part. What we want to do is have a PGW which has some the EPC "machinery" behind to get a TEID and have MME, HSS, SGW initialized and some not real UEs i.e. the fake UEs would sit in or next to the eNB. We do not need real internet connection for the "fake UE" and user plane is also not that important for us. Any hints? Greetings silke -------------- next part -------------- An HTML attachment was scrubbed... URL: From silke.holtmanns at nokia-bell-labs.com Wed Jul 10 08:07:23 2019 From: silke.holtmanns at nokia-bell-labs.com (Holtmanns, Silke (Nokia - FI/Espoo)) Date: Wed, 10 Jul 2019 08:07:23 +0000 Subject: Security research Message-ID: Hi, I'm part of security research and we are mainly interested in the core network part and not on the UE part. What we want to do is have a PGW which has some the EPC "machinery" behind to get a TEID and have MME, HSS, SGW initialized and some not real UEs i.e. the fake UEs would sit in or next to the eNB. In the end we are interested in plugging this EPC next to a real one with a real S8 connection. We do not need real internet connection for the "fake UE" and user plane is also not that important for us. So how can we get a "fake UE" into the eNB, so that is makes all the protocol runs for data communication set-up. Any hints? Greetings silke -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Wed Jul 10 16:38:20 2019 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 10 Jul 2019 18:38:20 +0200 (CEST) Subject: Security research In-Reply-To: References: Message-ID: Hi Silke, Good to see you here on the list! :) I am also quite new here, because although I worked once on some core network stuff some years ago I just signed up for this list yesterday. I think, as far as I remember the only virtual UE implementation I saw came from EURECOM/openAirInterface. Maybe that is something worth checking out. Otherwise a fake UE can be implemented even in Python with the help of libmich/pycrate I think. I am still new in thr area of available open-source core networks. I know that a very lightweight and compact package is offeted by srsEPC - although it probably does not have the S8 interface you require. I need to have a closer look at nextEPC to see how exactly it looks like, so I won?t talk about that now. Wish you good luck! Cheers, Domi (the guy from P3 ;) ) 2019. j?l. 10. d?tummal, 10:21 id?pontban Holtmanns, Silke (Nokia - FI/Espoo) ?rta: > > Hi, > > I?m part of security research and we are mainly interested in the core network part and not on the UE part. > > What we want to do is have a PGW which has some the EPC ?machinery? behind to get a TEID and have MME, HSS, SGW initialized and some not real UEs i.e. the fake UEs would sit in or next to the eNB. > > In the end we are interested in plugging this EPC next to a real one with a real S8 connection. > > We do not need real internet connection for the ?fake UE? and user plane is also not that important for us. > So how can we get a ?fake UE? into the eNB, so that is makes all the protocol runs for data communication set-up. > > Any hints? > > Greetings silke > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jul 11 00:49:56 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Jul 2019 08:49:56 +0800 Subject: Security research In-Reply-To: References: Message-ID: <20190711004956.GK3429@nataraja> Hi Silke, I'm not entirely sure if I'm getting this right, so please clarify: You are looking for all of the below: 1) a simulated UE (possibly integrated with eNB) which can perform things like attach + PDN connection establishment over S1 to a MME, just like a real UE 2) an EPC (MME, S-GW, P-GW, HSS) exposing at least the S8 interface between S-GW and P-GW so that you can then also a) connect a real eNB to that same MME above b) operate a second, 3rd party P-GW next to the P-GW above, interfacing over S8 (GTP) to the S-GW above Does that correctly represent your requirement? I would assume that in general, nextepc would be able to work as your MME/S-GW/P-GW/HSS. I'm not sure which exact procedures you will need it to support (quite a number of them are not yet implemented, e.g. the S6 between MME and HSS is quite "rudimentary" AFAICT. The more interesting question is the "simulated eNB" part. I know that srsUE contains all the related NAS logic for the UE, but I'm not aware of a (public / open source) way to run it e.g. without real hardware against srsENB so that you have both UE and eNB covered, exposing an S1 interface. It would probably be best to inquire with SRS about this, maybe they can make that functoinality available either in their open source version or you could obtain it under their dual-licensing scheme. Unrelated to the above: I'm currently working on a TTCN-3 test suite for the MME, which basically includes the eNB-Side S1 interface, as well as the basic NAS procedures of a UE, so we can test the [nextepc] MME. But it's unfortunately at a development stage where it's not yet doing anything useful yet - and it's also just a hobby/pet project I'm doing in my spare time, without any clear timeline or any commercial backing :/ There are of course various proprietary options available on the market (like the NG4T testers), but I guess you're inquiring here as you're specifically looking for open source. -- - Harald Welte 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 Thu Jul 11 04:54:00 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Jul 2019 12:54:00 +0800 Subject: Wy does the MME need a mongodb database? Message-ID: <20190711045400.GS3429@nataraja> Hi Sukchan and othres, I'm wondering why the MME itself is currently requiring a mongodb database? What is it used for? I'm a bit confused, I thought mongodb was only used by the HSS for subscriber storage. However, it seems that (at least with current nextepc), the MME also needs mongodb. I cannot immediately find any code that uses it? Regards, Harald -- - Harald Welte 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 Thu Jul 11 05:28:36 2019 From: acetcom at gmail.com (=?utf-8?B?7J207ISd7LCs?=) Date: Thu, 11 Jul 2019 14:28:36 +0900 Subject: Wy does the MME need a mongodb database? In-Reply-To: <20190711045400.GS3429@nataraja> References: <20190711045400.GS3429@nataraja> Message-ID: Hi Harald and others, Basically, MME/SGW/PGW don?t have to connect to the MongoDB server. As such, there is no MongoDB uri in mme/sgw/pgw.conf. See https://github.com/open5gs/nextepc/blob/master/support/config/mme.conf.in Perhaps, nextepc.conf has the mongodb parameter for developers to use easily. But nextepc architecture don?t want to use DB in mme/sgw/pgw. Only hss/pcrf can connect to database. Thanks! Best Regards, Sukchan 2019. 7. 11. ?? 1:54, Harald Welte ??: > Hi Sukchan and othres, > > I'm wondering why the MME itself is currently requiring a mongodb database? > What is it used for? I'm a bit confused, I thought mongodb was only used > by the HSS for subscriber storage. However, it seems that (at least with current > nextepc), the MME also needs mongodb. I cannot immediately find any code > that uses it? > > Regards, > Harald > -- > - Harald Welte 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: From acetcom at gmail.com Thu Jul 11 15:14:51 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Fri, 12 Jul 2019 00:14:51 +0900 Subject: CS Fallback in NextEPC Message-ID: 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: # # # # o Single MSC/VLR # sgsap: # addr: 127.0.0.2 # plmn_id: # mcc: 001 # mnc: 01 # tac: 4130 # lac: 43690 # # o Multiple MSC/VLR # sgsap: # - addr: 127.0.0.2 # plmn_id: # mcc: 001 # mnc: 01 # tac: 4131 # lac: 43692 # - addr # - 127.0.0.3 # - fe80::2%lo0 # plmn_id: # mcc: 001 # mnc: 01 # tac: 4132 # lac: 43692 # - name: msc.open5gs.org # plmn_id: # mcc: 001 # mnc: 01 # tac: 4133 # lac: 43693 # FYI, I also attach the pcap that I run with nextepc simulator as below. $ ./tests/testcsfb mo-idle-test : SUCCESS mt-idle-test : SUCCESS mo-active-test : SUCCESS mt-active-test : SUCCESS All tests passed. Feel free to raise any questions about this things. Best Regards, Sukchan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nextepc_csfb.pcapng Type: application/octet-stream Size: 57524 bytes Desc: not available URL: From laforge at gnumonks.org Thu Jul 11 16:47:09 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Jul 2019 00:47:09 +0800 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: <20190711164709.GI3429@nataraja> Hi Sukchan, On Fri, Jul 12, 2019 at 12:14:51AM +0900, Sukchan Lee wrote: > Today I've added CS Fallback and released NextEPC v0.5.0 Thanks a lot! > So, I'd just like to test this part with Osmocom project, but it seems to > be a difficult task. The reason is why I have little knowledge about 2G/3G. > Nevertheless, I will try to do it I advise you to not spend too much time on it until we can provide you with a set of configuration and instructions on how to configure this, instead of spending a lot of time in trial and error. I think we can save you some time there. A good starting point would be to use the nightly builds for Ubuntu or Debian, (see https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds) and try to follow the general instructions of https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box. The goal would be to create a network with two phones/IMSIs where you can have a 2G-to-2G voice call first. Only once that works, the LTE neighbor cell information and SGs configuration can be added. You will need the following parts for a minimal 2G setup: * osmo-trx + osmo-bts-trx (if using SDR like B2x0) * osmo-bsc (RR) * osmo-msc (MM + CC) * osmo-hlr * osmo-stp (for SS7/SIGTRAN between BSC and MSC) * osmo-mgw (for RTP audio streams; one instance can be shared between BSC and MSC) All of the above can run on a single machine > BTW, I don't know if there is anyone who wants to integrate this big thing. For sure we want to, and we also know there are users out there who want to. > Even though I'm not sure if this will help, but let me introduce the > configuration of the NextEPC. Thanks, this is useful. We'll try to to set this up accordingly, but it may take some time. Philipp (Cc) has been developing most of the SGs interface on the Osmocom side, he can help you (here on this list and by direct e-mail) with any related issues. > FYI, I also attach the pcap that I run with nextepc simulator as below. Thanks, I'd like to ask Philipp to review this and report if it reflects his expectations about the SGs interface procedures. btw/unrelated: I've been hacking a lot on TTCN-3 tests for the MME, and I've managed to get the way into NAS (EMM/ESM) and am getting all the way up to a Attach Reject (see attached pcap). As I'm only simulating S1AP and SGsAP so far (and not diameter), it's expected that the attach will be rejected. I guess I'll start with using nextepc-hss first, and add diameter support to the tests only in a later step. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From rafael at rhizomatica.org Thu Jul 11 20:16:41 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Thu, 11 Jul 2019 17:16:41 -0300 Subject: CS Fallback in NextEPC In-Reply-To: <20190711164709.GI3429@nataraja> References: <20190711164709.GI3429@nataraja> Message-ID: <0ebcdcb0-29cc-6e15-9e67-dd4ef90e7827@rhizomatica.org> Rhizomatica is very much interested in testing such setup with CS voice fallback for LTE to GSM. Cheers! Rafael Diniz On 7/11/19 1:47 PM, Harald Welte wrote: > Hi Sukchan, > > On Fri, Jul 12, 2019 at 12:14:51AM +0900, Sukchan Lee wrote: >> Today I've added CS Fallback and released NextEPC v0.5.0 > > Thanks a lot! > >> So, I'd just like to test this part with Osmocom project, but it seems to >> be a difficult task. The reason is why I have little knowledge about 2G/3G. >> Nevertheless, I will try to do it > > I advise you to not spend too much time on it until we can provide you > with a set of configuration and instructions on how to configure this, > instead of spending a lot of time in trial and error. I think we can > save you some time there. > > A good starting point would be to use the nightly builds for Ubuntu or Debian, > (see https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds) > and try to follow the general instructions of https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box. The goal would be to create a network with two phones/IMSIs > where you can have a 2G-to-2G voice call first. Only once that works, the > LTE neighbor cell information and SGs configuration can be added. > > You will need the following parts for a minimal 2G setup: > > * osmo-trx + osmo-bts-trx (if using SDR like B2x0) > * osmo-bsc (RR) > * osmo-msc (MM + CC) > * osmo-hlr > * osmo-stp (for SS7/SIGTRAN between BSC and MSC) > * osmo-mgw (for RTP audio streams; one instance can be shared between BSC and MSC) > > All of the above can run on a single machine > >> BTW, I don't know if there is anyone who wants to integrate this big thing. > > For sure we want to, and we also know there are users out there who want to. > >> Even though I'm not sure if this will help, but let me introduce the >> configuration of the NextEPC. > > Thanks, this is useful. We'll try to to set this up accordingly, but it may > take some time. > > Philipp (Cc) has been developing most of the SGs interface on the Osmocom > side, he can help you (here on this list and by direct e-mail) with any related > issues. > >> FYI, I also attach the pcap that I run with nextepc simulator as below. > > Thanks, I'd like to ask Philipp to review this and report if it reflects his > expectations about the SGs interface procedures. > > btw/unrelated: I've been hacking a lot on TTCN-3 tests for the MME, and > I've managed to get the way into NAS (EMM/ESM) and am getting all the > way up to a Attach Reject (see attached pcap). As I'm only simulating > S1AP and SGsAP so far (and not diameter), it's expected that the attach > will be rejected. I guess I'll start with using nextepc-hss first, and > add diameter support to the tests only in a later step. > > Regards, > Harald > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From acetcom at gmail.com Thu Jul 11 22:19:35 2019 From: acetcom at gmail.com (=?utf-8?B?7J207ISd7LCs?=) Date: Fri, 12 Jul 2019 07:19:35 +0900 Subject: CS Fallback in NextEPC In-Reply-To: <20190711164709.GI3429@nataraja> References: <20190711164709.GI3429@nataraja> Message-ID: Hi Harald, There is no pcap file. Could you attach it? Thanks! Best Regards, Sukchan 2019. 7. 12. ?? 1:47, Harald Welte ??: > Hi Sukchan, > >> On Fri, Jul 12, 2019 at 12:14:51AM +0900, Sukchan Lee wrote: >> Today I've added CS Fallback and released NextEPC v0.5.0 > > Thanks a lot! > >> So, I'd just like to test this part with Osmocom project, but it seems to >> be a difficult task. The reason is why I have little knowledge about 2G/3G. >> Nevertheless, I will try to do it > > I advise you to not spend too much time on it until we can provide you > with a set of configuration and instructions on how to configure this, > instead of spending a lot of time in trial and error. I think we can > save you some time there. > > A good starting point would be to use the nightly builds for Ubuntu or Debian, > (see https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds) > and try to follow the general instructions of https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box. The goal would be to create a network with two phones/IMSIs > where you can have a 2G-to-2G voice call first. Only once that works, the > LTE neighbor cell information and SGs configuration can be added. > > You will need the following parts for a minimal 2G setup: > > * osmo-trx + osmo-bts-trx (if using SDR like B2x0) > * osmo-bsc (RR) > * osmo-msc (MM + CC) > * osmo-hlr > * osmo-stp (for SS7/SIGTRAN between BSC and MSC) > * osmo-mgw (for RTP audio streams; one instance can be shared between BSC and MSC) > > All of the above can run on a single machine > >> BTW, I don't know if there is anyone who wants to integrate this big thing. > > For sure we want to, and we also know there are users out there who want to. > >> Even though I'm not sure if this will help, but let me introduce the >> configuration of the NextEPC. > > Thanks, this is useful. We'll try to to set this up accordingly, but it may > take some time. > > Philipp (Cc) has been developing most of the SGs interface on the Osmocom > side, he can help you (here on this list and by direct e-mail) with any related > issues. > >> FYI, I also attach the pcap that I run with nextepc simulator as below. > > Thanks, I'd like to ask Philipp to review this and report if it reflects his > expectations about the SGs interface procedures. > > btw/unrelated: I've been hacking a lot on TTCN-3 tests for the MME, and > I've managed to get the way into NAS (EMM/ESM) and am getting all the > way up to a Attach Reject (see attached pcap). As I'm only simulating > S1AP and SGsAP so far (and not diameter), it's expected that the attach > will be rejected. I guess I'll start with using nextepc-hss first, and > add diameter support to the tests only in a later step. > > Regards, > Harald > > -- > - Harald Welte 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 Thu Jul 11 23:10:24 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Jul 2019 07:10:24 +0800 Subject: Easy way to add subscribers to hss without node.js / web UI Message-ID: <20190711231023.GL3429@nataraja> 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 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 Fri Jul 12 00:12:30 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Fri, 12 Jul 2019 09:12:30 +0900 Subject: Easy way to add subscribers to hss without node.js / web UI In-Reply-To: <20190711231023.GL3429@nataraja> References: <20190711231023.GL3429@nataraja> Message-ID: Hi Harald, It is a good idea to provide these script. Let me start to survey node.js or python library. Some time might be needed. I?ll support CSV. And also I?d like to support all possible subscriber info that nextepc test code used to. Thanks for raising this issues. Best Regards, Sukchan 2019. 7. 12. ?? 8:10, Harald Welte ??: > 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 http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jul 12 03:31:59 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Jul 2019 11:31:59 +0800 Subject: Easy way to add subscribers to hss without node.js / web UI In-Reply-To: <20190711231023.GL3429@nataraja> References: <20190711231023.GL3429@nataraja> Message-ID: <20190712033159.GM3429@nataraja> Hi! it seems I found a way to do it: Insert a json document looking like the attachment using mongoimport like this: mongoimport -d nextepc -c subscribers ./subscriber_imsi1.json It may not be elegant, but it works for now, I'm getting a NAS AuthReq in response to an AttachReq in my test case now, after the subscriber was created with above command. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: subscriber_imsi1.json Type: application/json Size: 1220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20190712-attach-auth_req.pcap Type: application/vnd.tcpdump.pcap Size: 544 bytes Desc: not available URL: From laforge at gnumonks.org Fri Jul 12 03:36:29 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Jul 2019 11:36:29 +0800 Subject: TTCN3 tests for MME (was Re: CS Fallback in NextEPC) In-Reply-To: References: <20190711164709.GI3429@nataraja> Message-ID: <20190712033629.GN3429@nataraja> Hi Sukchan, On Fri, Jul 12, 2019 at 07:19:35AM +0900, ??? wrote: > 2019. 7. 12. ?? 1:47, Harald Welte ??: > > > btw/unrelated: I've been hacking a lot on TTCN-3 tests for the MME, and > > I've managed to get the way into NAS (EMM/ESM) and am getting all the > > way up to a Attach Reject (see attached pcap). As I'm only simulating > > S1AP and SGsAP so far (and not diameter), it's expected that the attach > > will be rejected. I guess I'll start with using nextepc-hss first, and > > add diameter support to the tests only in a later step. > > There is no pcap file. Could you attach it? > Thanks! Sorry, please find it attached. It's not much, but it shows that the basic S1AP and NAS infrastructure for emulating eNB and UE works. I sill have to write quite a bit of code to actually perform the authentication successful, as well as to implement at least integrity protection on the NAS layer. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: 20190711-ttcn3_mme_test.pcap Type: application/vnd.tcpdump.pcap Size: 610 bytes Desc: not available URL: From laforge at gnumonks.org Fri Jul 12 09:32:27 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Jul 2019 17:32:27 +0800 Subject: SNOW-3G / ZUC implementation under FOSS license? Message-ID: <20190712093227.GU3429@nataraja> Hi! I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. However, it seems there is no real FOSS implementation of the SNOW-3G algoritm around? All I could find was: * https://github.com/mitshell/CryptoMobile with unclear source of the code, without a copyright statement or license annotation * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main.c without a copyright statement or license annotation * https://github.com/Jadson27101/SNOW_3G in go, without a copyright statement or license annotation * https://github.com/KsirbJ/SNOW-3G without a copyright statement or license annotation * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c without a copyright statement or license annotation. Looks rather similar to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc also contains no coypright statement or license, but might be construed to be AGPLv3 like all of srsLTE. However, it states it is "adapted" from ETSI/SAGE specifications. Does that mean it is an independent implementation of the algorithm by just reading the specs, or does it contain actual ETSI-copyrighted code? It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) don't contain any actual information but all just point to the ETSI SAGE specification which can be found (at the very least) here: https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf and interestingly doesn't contain any copyright statement whatsoever. This discussion is not about any potentially 'essential patents' that may or may not apply in some jurisdictions on the algorithm itself. I'm currently only interested in a "clean copyright" implementation of any of the EIA/EEA implementations used on the LTE NAS layer. I'd appreciate any useful comments. Thanks! -- - Harald Welte 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 Fri Jul 12 13:54:37 2019 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Fri, 12 Jul 2019 15:54:37 +0200 (CEST) Subject: SNOW-3G / ZUC implementation under FOSS license? In-Reply-To: <20190712093227.GU3429@nataraja> References: <20190712093227.GU3429@nataraja> Message-ID: <392D91FA-6C25-4E66-AD0A-2EBD94BA0C71@tomcsanyi.net> Hi Harald! CryptoMobile was created by Benoit Michau, so I added him in Cc, maybe he could clarify the license situation. Encryption support for srsLTE was, I think, mainly worked on by David Rupprecht, whom I also added in Cc. I hope these people are going to be able to help you. Kind regards, Domi 2019. j?l. 12. d?tummal, 11:32 id?pontban Harald Welte ?rta: > Hi! > > I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for > NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. > > However, it seems there is no real FOSS implementation of the SNOW-3G algoritm > around? All I could find was: > > * https://github.com/mitshell/CryptoMobile with unclear source of the code, > without a copyright statement or license annotation > > * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main.c > without a copyright statement or license annotation > > * https://github.com/Jadson27101/SNOW_3G in go, > without a copyright statement or license annotation > > * https://github.com/KsirbJ/SNOW-3G > without a copyright statement or license annotation > > * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c > without a copyright statement or license annotation. Looks rather similar > to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? > > * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc > also contains no coypright statement or license, but might be construed > to be AGPLv3 like all of srsLTE. However, it states it is "adapted" > from ETSI/SAGE specifications. Does that mean it is an independent > implementation of the algorithm by just reading the specs, or does it > contain actual ETSI-copyrighted code? > > It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) > don't contain any actual information but all just point to the ETSI SAGE specification > which can be found (at the very least) here: > https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf > and interestingly doesn't contain any copyright statement whatsoever. > > This discussion is not about any potentially 'essential patents' that may or may > not apply in some jurisdictions on the algorithm itself. I'm currently only interested > in a "clean copyright" implementation of any of the EIA/EEA implementations used > on the LTE NAS layer. > > I'd appreciate any useful comments. Thanks! > > -- > - Harald Welte 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 Sat Jul 13 13:18:47 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 13 Jul 2019 21:18:47 +0800 Subject: Question on Uplink 'sequence count' handling in MME Message-ID: <20190713131847.GA3429@nataraja> 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 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 Jul 13 15:13:32 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Sun, 14 Jul 2019 00:13:32 +0900 Subject: Question on Uplink 'sequence count' handling in MME In-Reply-To: <20190713131847.GA3429@nataraja> References: <20190713131847.GA3429@nataraja> Message-ID: Hi Harald, For the most part, you need to see the UNION definitions in src/mme/mme_context.h as below. 348 union { 349 struct { 350 ED3(uint8_t spare;, 351 uint16_t overflow;, 352 uint8_t sqn;) 353 } __attribute__ ((packed)); 354 uint32_t i32; 355 } ul_count; Therefore, increasing SQN will also increase ul_count.i32. Let me add the comments in src/mme/nas_security.c /* If SQN exeeds 1 bytes and turn in once again, Overflow is increased */ 197 if (mme_ue->ul_count.sqn > h->sequence_number) 198 mme_ue->ul_count.overflow++; /* Always set SQN from UE's SQN as below */ 199 mme_ue->ul_count.sqn = h->sequence_number; Let me know if I have misunderstood anything. Thanks a lot! Best Regards, Sukchan On Sat, Jul 13, 2019 at 10:19 PM Harald Welte wrote: > 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 > 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: From medeiros at medeiros.eng.br Sat Jul 13 21:35:23 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sat, 13 Jul 2019 18:35:23 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: 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 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: > > # > # > # > # o Single MSC/VLR > # sgsap: > # addr: 127.0.0.2 > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4130 > # lac: 43690 > # > # o Multiple MSC/VLR > # sgsap: > # - addr: 127.0.0.2 > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4131 > # lac: 43692 > # - addr > # - 127.0.0.3 > # - fe80::2%lo0 > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4132 > # lac: 43692 > # - name: msc.open5gs.org > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4133 > # lac: 43693 > # > > FYI, I also attach the pcap that I run with nextepc simulator as below. > > $ ./tests/testcsfb > mo-idle-test : SUCCESS > mt-idle-test : SUCCESS > mo-active-test : SUCCESS > mt-active-test : SUCCESS > All tests passed. > > Feel free to raise any questions about this things. > > Best Regards, > Sukchan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 217008 bytes Desc: not available URL: From medeiros at medeiros.eng.br Sat Jul 13 21:50:11 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sat, 13 Jul 2019 18:50:11 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: 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_136413v091000p.pdf On Sat, Jul 13, 2019 at 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: 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 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: >> >> # >> # >> # >> # o Single MSC/VLR >> # sgsap: >> # addr: 127.0.0.2 >> # plmn_id: >> # mcc: 001 >> # mnc: 01 >> # tac: 4130 >> # lac: 43690 >> # >> # o Multiple MSC/VLR >> # sgsap: >> # - addr: 127.0.0.2 >> # plmn_id: >> # mcc: 001 >> # mnc: 01 >> # tac: 4131 >> # lac: 43692 >> # - addr >> # - 127.0.0.3 >> # - fe80::2%lo0 >> # plmn_id: >> # mcc: 001 >> # mnc: 01 >> # tac: 4132 >> # lac: 43692 >> # - name: msc.open5gs.org >> # plmn_id: >> # mcc: 001 >> # mnc: 01 >> # tac: 4133 >> # lac: 43693 >> # >> >> FYI, I also attach the pcap that I run with nextepc simulator as below. >> >> $ ./tests/testcsfb >> mo-idle-test : SUCCESS >> mt-idle-test : SUCCESS >> mo-active-test : SUCCESS >> mt-active-test : SUCCESS >> All tests passed. >> >> Feel free to raise any questions about this things. >> >> Best Regards, >> Sukchan >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 217008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 60539 bytes Desc: not available URL: From medeiros at medeiros.eng.br Sat Jul 13 23:04:38 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sat, 13 Jul 2019 20:04:38 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: 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 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_136413v091000p.pdf > > On Sat, Jul 13, 2019 at 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: 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 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: >>> >>> # >>> # >>> # >>> # o Single MSC/VLR >>> # sgsap: >>> # addr: 127.0.0.2 >>> # plmn_id: >>> # mcc: 001 >>> # mnc: 01 >>> # tac: 4130 >>> # lac: 43690 >>> # >>> # o Multiple MSC/VLR >>> # sgsap: >>> # - addr: 127.0.0.2 >>> # plmn_id: >>> # mcc: 001 >>> # mnc: 01 >>> # tac: 4131 >>> # lac: 43692 >>> # - addr >>> # - 127.0.0.3 >>> # - fe80::2%lo0 >>> # plmn_id: >>> # mcc: 001 >>> # mnc: 01 >>> # tac: 4132 >>> # lac: 43692 >>> # - name: msc.open5gs.org >>> # plmn_id: >>> # mcc: 001 >>> # mnc: 01 >>> # tac: 4133 >>> # lac: 43693 >>> # >>> >>> FYI, I also attach the pcap that I run with nextepc simulator as below. >>> >>> $ ./tests/testcsfb >>> mo-idle-test : SUCCESS >>> mt-idle-test : SUCCESS >>> mo-active-test : SUCCESS >>> mt-active-test : SUCCESS >>> All tests passed. >>> >>> Feel free to raise any questions about this things. >>> >>> Best Regards, >>> Sukchan >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 217008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 60539 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 130318 bytes Desc: not available URL: From medeiros at medeiros.eng.br Sun Jul 14 00:03:26 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sat, 13 Jul 2019 21:03:26 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: 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 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 > 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 >> 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_136413v091000p.pdf >>> >>> On Sat, Jul 13, 2019 at 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: 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 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: >>>>> >>>>> # >>>>> # >>>>> # >>>>> # o Single MSC/VLR >>>>> # sgsap: >>>>> # addr: 127.0.0.2 >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4130 >>>>> # lac: 43690 >>>>> # >>>>> # o Multiple MSC/VLR >>>>> # sgsap: >>>>> # - addr: 127.0.0.2 >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4131 >>>>> # lac: 43692 >>>>> # - addr >>>>> # - 127.0.0.3 >>>>> # - fe80::2%lo0 >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4132 >>>>> # lac: 43692 >>>>> # - name: msc.open5gs.org >>>>> # plmn_id: >>>>> # mcc: 001 >>>>> # mnc: 01 >>>>> # tac: 4133 >>>>> # lac: 43693 >>>>> # >>>>> >>>>> FYI, I also attach the pcap that I run with nextepc simulator as below. >>>>> >>>>> $ ./tests/testcsfb >>>>> mo-idle-test : SUCCESS >>>>> mt-idle-test : SUCCESS >>>>> mo-active-test : SUCCESS >>>>> mt-active-test : SUCCESS >>>>> All tests passed. >>>>> >>>>> Feel free to raise any questions about this things. >>>>> >>>>> Best Regards, >>>>> Sukchan >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 130318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 217008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 60539 bytes Desc: not available URL: From medeiros at medeiros.eng.br Sun Jul 14 01:48:21 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sat, 13 Jul 2019 22:48:21 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Hello Sukchan, In some situations the CSFB will be realized in a partner network, (Another GSM/3G Network), with this the MNC and MCC will be different. I suggest this configuration format for this case: sgsap: addr: 127.0.0.2 port: 29119 plmn_id: mcc: 001 mnc: 01 dest_plmn_id: mcc: 002 mnc: 02 tac: 4130 lac: 43690 With this, the RegistredLAI will have this information MCC: 002, MNC: 02 and LAI: 43690. If you agree with this I can implement this. Thanks Romeu Medeiros On Sat, Jul 13, 2019 at 9:03 PM Romeu Medeiros wrote: > 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 > 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 >> 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 >>> 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_136413v091000p.pdf >>>> >>>> On Sat, Jul 13, 2019 at 6:35 PM Romeu Medeiros < >>>> medeiros at 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 >>>>> 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: >>>>>> >>>>>> # >>>>>> # >>>>>> # >>>>>> # o Single MSC/VLR >>>>>> # sgsap: >>>>>> # addr: 127.0.0.2 >>>>>> # plmn_id: >>>>>> # mcc: 001 >>>>>> # mnc: 01 >>>>>> # tac: 4130 >>>>>> # lac: 43690 >>>>>> # >>>>>> # o Multiple MSC/VLR >>>>>> # sgsap: >>>>>> # - addr: 127.0.0.2 >>>>>> # plmn_id: >>>>>> # mcc: 001 >>>>>> # mnc: 01 >>>>>> # tac: 4131 >>>>>> # lac: 43692 >>>>>> # - addr >>>>>> # - 127.0.0.3 >>>>>> # - fe80::2%lo0 >>>>>> # plmn_id: >>>>>> # mcc: 001 >>>>>> # mnc: 01 >>>>>> # tac: 4132 >>>>>> # lac: 43692 >>>>>> # - name: msc.open5gs.org >>>>>> # plmn_id: >>>>>> # mcc: 001 >>>>>> # mnc: 01 >>>>>> # tac: 4133 >>>>>> # lac: 43693 >>>>>> # >>>>>> >>>>>> FYI, I also attach the pcap that I run with nextepc simulator as >>>>>> below. >>>>>> >>>>>> $ ./tests/testcsfb >>>>>> mo-idle-test : SUCCESS >>>>>> mt-idle-test : SUCCESS >>>>>> mo-active-test : SUCCESS >>>>>> mt-active-test : SUCCESS >>>>>> All tests passed. >>>>>> >>>>>> Feel free to raise any questions about this things. >>>>>> >>>>>> Best Regards, >>>>>> Sukchan >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 130318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 217008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 60539 bytes Desc: not available URL: From acetcom at gmail.com Sun Jul 14 01:58:51 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Sun, 14 Jul 2019 10:58:51 +0900 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Hi Romeu, I actually have no experience to deploy LTE to the field at all. If so, please let me know anything. By the way, is it reasonable to change the configuration file like this? sgsap: addr: 127.0.0.2 port: 29119 tai: plmn_id: mcc: 001 mnc: 01 tac: 4130 lai: plmn_id: mcc: 002 mnc: 02 lac: 43690 And also, if you're comfortable working, I'll give you the commit permission. Of course, you can work pull request like now. Feel free to ask me anything! Thanks a lot! -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Sun Jul 14 02:00:44 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sat, 13 Jul 2019 23:00:44 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Hello Sukchan, It's perfect your idea. Tomorow i will do it and send to you a pull request! Thanks Romeu Medeiros On Sat, Jul 13, 2019 at 10:59 PM Sukchan Lee wrote: > Hi Romeu, > > I actually have no experience to deploy LTE to the field at all. If so, > please let me know anything. > > By the way, is it reasonable to change the configuration file like this? > > sgsap: > addr: 127.0.0.2 > port: 29119 > tai: > plmn_id: > mcc: 001 > mnc: 01 > tac: 4130 > lai: > plmn_id: > mcc: 002 > mnc: 02 > lac: 43690 > > And also, if you're comfortable working, I'll give you the commit > permission. > Of course, you can work pull request like now. > > Feel free to ask me anything! > > Thanks a lot! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Sun Jul 14 04:21:50 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sun, 14 Jul 2019 01:21:50 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Hello man, I finished and generate the pull request. Thanks On Sat, Jul 13, 2019 at 11:00 PM Romeu Medeiros wrote: > Hello Sukchan, > > It's perfect your idea. > > Tomorow i will do it and send to you a pull request! > > Thanks > > Romeu Medeiros > > On Sat, Jul 13, 2019 at 10:59 PM Sukchan Lee wrote: > >> Hi Romeu, >> >> I actually have no experience to deploy LTE to the field at all. If so, >> please let me know anything. >> >> By the way, is it reasonable to change the configuration file like this? >> >> sgsap: >> addr: 127.0.0.2 >> port: 29119 >> tai: >> plmn_id: >> mcc: 001 >> mnc: 01 >> tac: 4130 >> lai: >> plmn_id: >> mcc: 002 >> mnc: 02 >> lac: 43690 >> >> And also, if you're comfortable working, I'll give you the commit >> permission. >> Of course, you can work pull request like now. >> >> Feel free to ask me anything! >> >> Thanks a lot! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Sun Jul 14 04:51:24 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sun, 14 Jul 2019 01:51:24 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Sukchan, After the push the modification i try here and the sgs connection is not established anymore. I'm trying to find where I made some error. Thanks Romeu Medeiros On Sun, Jul 14, 2019 at 1:21 AM Romeu Medeiros wrote: > Hello man, > > I finished and generate the pull request. > > Thanks > > > On Sat, Jul 13, 2019 at 11:00 PM Romeu Medeiros > wrote: > >> Hello Sukchan, >> >> It's perfect your idea. >> >> Tomorow i will do it and send to you a pull request! >> >> Thanks >> >> Romeu Medeiros >> >> On Sat, Jul 13, 2019 at 10:59 PM Sukchan Lee wrote: >> >>> Hi Romeu, >>> >>> I actually have no experience to deploy LTE to the field at all. If so, >>> please let me know anything. >>> >>> By the way, is it reasonable to change the configuration file like this? >>> >>> sgsap: >>> addr: 127.0.0.2 >>> port: 29119 >>> tai: >>> plmn_id: >>> mcc: 001 >>> mnc: 01 >>> tac: 4130 >>> lai: >>> plmn_id: >>> mcc: 002 >>> mnc: 02 >>> lac: 43690 >>> >>> And also, if you're comfortable working, I'll give you the commit >>> permission. >>> Of course, you can work pull request like now. >>> >>> Feel free to ask me anything! >>> >>> Thanks a lot! >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Sun Jul 14 05:03:29 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sun, 14 Jul 2019 02:03:29 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Oh, It was just the identation from the config file. Thanks On Sun, Jul 14, 2019 at 1:51 AM Romeu Medeiros wrote: > Sukchan, > > After the push the modification i try here and the sgs connection is not > established anymore. > > I'm trying to find where I made some error. > > Thanks > > Romeu Medeiros > > On Sun, Jul 14, 2019 at 1:21 AM Romeu Medeiros > wrote: > >> Hello man, >> >> I finished and generate the pull request. >> >> Thanks >> >> >> On Sat, Jul 13, 2019 at 11:00 PM Romeu Medeiros >> wrote: >> >>> Hello Sukchan, >>> >>> It's perfect your idea. >>> >>> Tomorow i will do it and send to you a pull request! >>> >>> Thanks >>> >>> Romeu Medeiros >>> >>> On Sat, Jul 13, 2019 at 10:59 PM Sukchan Lee wrote: >>> >>>> Hi Romeu, >>>> >>>> I actually have no experience to deploy LTE to the field at all. If so, >>>> please let me know anything. >>>> >>>> By the way, is it reasonable to change the configuration file like this? >>>> >>>> sgsap: >>>> addr: 127.0.0.2 >>>> port: 29119 >>>> tai: >>>> plmn_id: >>>> mcc: 001 >>>> mnc: 01 >>>> tac: 4130 >>>> lai: >>>> plmn_id: >>>> mcc: 002 >>>> mnc: 02 >>>> lac: 43690 >>>> >>>> And also, if you're comfortable working, I'll give you the commit >>>> permission. >>>> Of course, you can work pull request like now. >>>> >>>> Feel free to ask me anything! >>>> >>>> Thanks a lot! >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From acetcom at gmail.com Sun Jul 14 05:08:19 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Sun, 14 Jul 2019 14:08:19 +0900 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Hi Romeu, FYI, your update uses the config as follows plmn_id: mcc: 001 mnc: 01 tac: 33 However it is not good since tac is not included in plmn_id. As such, I've fixed it as below plmn_id: mcc: 001 mnc: 01 tac: 33 In YAML world, indentation is very important. Please see the ./support/config/nextepc.conf.in and ./test/sample-csfb.in In current master branch, the above configuration is working fine. Thanks a lot! On Sun, Jul 14, 2019 at 2:03 PM Romeu Medeiros wrote: > Oh, > > It was just the identation from the config file. > > Thanks > > > > On Sun, Jul 14, 2019 at 1:51 AM Romeu Medeiros > wrote: > >> Sukchan, >> >> After the push the modification i try here and the sgs connection is not >> established anymore. >> >> I'm trying to find where I made some error. >> >> Thanks >> >> Romeu Medeiros >> >> On Sun, Jul 14, 2019 at 1:21 AM Romeu Medeiros >> wrote: >> >>> Hello man, >>> >>> I finished and generate the pull request. >>> >>> Thanks >>> >>> >>> On Sat, Jul 13, 2019 at 11:00 PM Romeu Medeiros < >>> medeiros at medeiros.eng.br> wrote: >>> >>>> Hello Sukchan, >>>> >>>> It's perfect your idea. >>>> >>>> Tomorow i will do it and send to you a pull request! >>>> >>>> Thanks >>>> >>>> Romeu Medeiros >>>> >>>> On Sat, Jul 13, 2019 at 10:59 PM Sukchan Lee wrote: >>>> >>>>> Hi Romeu, >>>>> >>>>> I actually have no experience to deploy LTE to the field at all. If >>>>> so, please let me know anything. >>>>> >>>>> By the way, is it reasonable to change the configuration file like >>>>> this? >>>>> >>>>> sgsap: >>>>> addr: 127.0.0.2 >>>>> port: 29119 >>>>> tai: >>>>> plmn_id: >>>>> mcc: 001 >>>>> mnc: 01 >>>>> tac: 4130 >>>>> lai: >>>>> plmn_id: >>>>> mcc: 002 >>>>> mnc: 02 >>>>> lac: 43690 >>>>> >>>>> And also, if you're comfortable working, I'll give you the commit >>>>> permission. >>>>> Of course, you can work pull request like now. >>>>> >>>>> Feel free to ask me anything! >>>>> >>>>> Thanks a lot! >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Sun Jul 14 05:14:22 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sun, 14 Jul 2019 02:14:22 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Sukchan, The currently identation of this configuration is : sgsap: addr: 127.0.0.1 port: 29118 tai: plmn_id: mcc: 001 mnc: 01 tac: 12345 lai: plmn_id: mcc: 002 mnc: 02 lac: 51212 sgw: gtpc: addr: 127.0.0.2 I think that is better be like this: sgsap: addr: 127.0.0.1 port: 29118 tai: plmn_id: mcc: 001 mnc: 01 tac: 12345 lai: plmn_id: mcc: 002 mnc: 02 lac: 51212 sgw: gtpc: addr: 127.0.0.2 What do you think? the sgsap tag will be in the root_key, like the sgw and pgw. Thanks Romeu Medeiros On Sun, Jul 14, 2019 at 2:08 AM Sukchan Lee wrote: > Hi Romeu, > > FYI, your update uses the config as follows > > plmn_id: > mcc: 001 > mnc: 01 > tac: 33 > > However it is not good since tac is not included in plmn_id. As such, I've > fixed it as below > plmn_id: > mcc: 001 > mnc: 01 > tac: 33 > > In YAML world, indentation is very important. > > Please see the ./support/config/nextepc.conf.in and ./test/sample-csfb.in > In current master branch, the above configuration is working fine. > > Thanks a lot! > > > > On Sun, Jul 14, 2019 at 2:03 PM Romeu Medeiros > wrote: > >> Oh, >> >> It was just the identation from the config file. >> >> Thanks >> >> >> >> On Sun, Jul 14, 2019 at 1:51 AM Romeu Medeiros >> wrote: >> >>> Sukchan, >>> >>> After the push the modification i try here and the sgs connection is not >>> established anymore. >>> >>> I'm trying to find where I made some error. >>> >>> Thanks >>> >>> Romeu Medeiros >>> >>> On Sun, Jul 14, 2019 at 1:21 AM Romeu Medeiros >>> wrote: >>> >>>> Hello man, >>>> >>>> I finished and generate the pull request. >>>> >>>> Thanks >>>> >>>> >>>> On Sat, Jul 13, 2019 at 11:00 PM Romeu Medeiros < >>>> medeiros at medeiros.eng.br> wrote: >>>> >>>>> Hello Sukchan, >>>>> >>>>> It's perfect your idea. >>>>> >>>>> Tomorow i will do it and send to you a pull request! >>>>> >>>>> Thanks >>>>> >>>>> Romeu Medeiros >>>>> >>>>> On Sat, Jul 13, 2019 at 10:59 PM Sukchan Lee >>>>> wrote: >>>>> >>>>>> Hi Romeu, >>>>>> >>>>>> I actually have no experience to deploy LTE to the field at all. If >>>>>> so, please let me know anything. >>>>>> >>>>>> By the way, is it reasonable to change the configuration file like >>>>>> this? >>>>>> >>>>>> sgsap: >>>>>> addr: 127.0.0.2 >>>>>> port: 29119 >>>>>> tai: >>>>>> plmn_id: >>>>>> mcc: 001 >>>>>> mnc: 01 >>>>>> tac: 4130 >>>>>> lai: >>>>>> plmn_id: >>>>>> mcc: 002 >>>>>> mnc: 02 >>>>>> lac: 43690 >>>>>> >>>>>> And also, if you're comfortable working, I'll give you the commit >>>>>> permission. >>>>>> Of course, you can work pull request like now. >>>>>> >>>>>> Feel free to ask me anything! >>>>>> >>>>>> Thanks a lot! >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From acetcom at gmail.com Sun Jul 14 05:22:39 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Sun, 14 Jul 2019 14:22:39 +0900 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Hi Romeu, With your configuration syntax, tai and lai become subgroups of port. If port is omitted, these will be subgroups of addr. And also, as I mentioned earlier, tac become subgroups of plmn_id. For reference, I will paste the example in support/config/nextepc.conf.in here again. sgsap: - addr: 127.0.0.2 tai: plmn_id: mcc: 001 mnc: 01 tac: 4131 lai: plmn_id: mcc: 001 mnc: 01 lac: 43691 - addr - 127.0.0.3 - fe80::2%lo0 tai: plmn_id: mcc: 001 mnc: 01 tac: 4132 lai: plmn_id: mcc: 002 mnc: 02 lac: 43692 - name: msc.open5gs.org tai: plmn_id: mcc: 001 mnc: 01 tac: 4133 lai: plmn_id: mcc: 002 mnc: 02 lac: 43693 Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Sun Jul 14 05:25:02 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sun, 14 Jul 2019 02:25:02 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: Thanks a lot! Have a good day there! Everything is running, Monday I will test the code that you asked before! Good weekend there. On Sun, Jul 14, 2019 at 2:22 AM Sukchan Lee wrote: > Hi Romeu, > > With your configuration syntax, tai and lai become subgroups of port. If > port is omitted, these will be subgroups of addr. And also, as I mentioned > earlier, tac become subgroups of plmn_id. > > For reference, I will paste the example in support/config/nextepc.conf.in > here again. > > sgsap: > - addr: 127.0.0.2 > tai: > plmn_id: > mcc: 001 > mnc: 01 > tac: 4131 > lai: > plmn_id: > mcc: 001 > mnc: 01 > lac: 43691 > - addr > - 127.0.0.3 > - fe80::2%lo0 > tai: > plmn_id: > mcc: 001 > mnc: 01 > tac: 4132 > lai: > plmn_id: > mcc: 002 > mnc: 02 > lac: 43692 > - name: msc.open5gs.org > tai: > plmn_id: > mcc: 001 > mnc: 01 > tac: 4133 > lai: > plmn_id: > mcc: 002 > mnc: 02 > lac: 43693 > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at softwareradiosystems.com Mon Jul 15 11:58:08 2019 From: paul at softwareradiosystems.com (Paul Sutton) Date: Mon, 15 Jul 2019 12:58:08 +0100 Subject: SNOW-3G / ZUC implementation under FOSS license? Message-ID: <796d2296-36e9-daa1-ddc4-f10f35f778e5@softwareradiosystems.com> Hi Harald, The srsLTE implementation is taken from the ETSI specs simulation program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf https://www.etsi.org/intellectual-property-rights#mytoc3 and https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the copyright licensing details for software incorporated in ETSI standards however I have not taken legal advice on compatibility of this license with AGPLv3. >From a quick review, it looks like the CryptoMobile and NextEPC versions have taken the same approach. It would be good as you say to have a "clean copyright" implementation - perhaps this is something we could help with. Best regards, Paul > Hi! > > I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for > NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. > > However, it seems there is no real FOSS implementation of the SNOW-3G algoritm > around? All I could find was: > > * https://github.com/mitshell/CryptoMobile with unclear source of the code, > without a copyright statement or license annotation > > * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main.c > without a copyright statement or license annotation > > * https://github.com/Jadson27101/SNOW_3G in go, > without a copyright statement or license annotation > > * https://github.com/KsirbJ/SNOW-3G > without a copyright statement or license annotation > > * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c > without a copyright statement or license annotation. Looks rather similar > to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? > > * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc > also contains no coypright statement or license, but might be construed > to be AGPLv3 like all of srsLTE. However, it states it is "adapted" > from ETSI/SAGE specifications. Does that mean it is an independent > implementation of the algorithm by just reading the specs, or does it > contain actual ETSI-copyrighted code? > > It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) > don't contain any actual information but all just point to the ETSI SAGE specification > which can be found (at the very least) here: > https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf > and interestingly doesn't contain any copyright statement whatsoever. > > This discussion is not about any potentially 'essential patents' that may or may > not apply in some jurisdictions on the algorithm itself. I'm currently only interested > in a "clean copyright" implementation of any of the EIA/EEA implementations used > on the LTE NAS layer. > > I'd appreciate any useful comments. Thanks! > > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -- ________________________________________________________________ Paul Sutton Ph.D. Software Radio Systems (SRS) http://www.softwareradiosystems.com paul at softwareradiosystems.com PGP Key ID: 3B4A5292 Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292 ________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlfeferman at gmail.com Mon Jul 15 17:43:53 2019 From: dlfeferman at gmail.com (Daniel Feferman) Date: Mon, 15 Jul 2019 14:43:53 -0300 Subject: OCS interface/NB-IoT support In-Reply-To: References: Message-ID: Hi Sukchan, Sorry for the late reply, I?ve been trying to get the pcap but I believe I can only provide you the pcap on the SGW and PGW, I do not believe I will be able to get a pcap file for the MME, just a .txt/.csv for the MME. Best regards, Daniel On Thu, Jul 4, 2019 at 10:16 AM Sukchan Lee wrote: > Hi Daniel, > > First of all, thank you for testing NextEPC. > > OCS/OFCS should be developed, but its priority is lower. > > I have received some data from you about NB-IoT, but it is not enough to > implement the simulator. > In fact, having pcap file will be very helpful. > > I also do not have NB-IoT equipment either. So I don't know if I can get > it right. > If I have some free time, I will try to support NB-IoT as well. > > Thank you again for reminding me. > > Best Regards, > Sukchan > > > On Thu, Jul 4, 2019 at 9:57 PM Daniel Feferman > wrote: > >> 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 >> >> >> Livre >> de v?rus. www.avast.com >> . >> >> <#m_-219267673172915276_m_-6040955901365899195_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Tue Jul 16 16:33:28 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Tue, 16 Jul 2019 13:33:28 -0300 Subject: SMS Message-ID: Hello guys and @Sukchan Lee I tested with sucess the send and receive SMS in new version of NextEPC running together with OSMO-MSC/HLR (SGS). Thanks Romeu Medeiros -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jul 16 11:05:53 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 16 Jul 2019 20:05:53 +0900 Subject: SNOW-3G / ZUC implementation under FOSS license? In-Reply-To: <796d2296-36e9-daa1-ddc4-f10f35f778e5@softwareradiosystems.com> References: <796d2296-36e9-daa1-ddc4-f10f35f778e5@softwareradiosystems.com> Message-ID: <20190716110553.GE3325@nataraja> Hi Paul, On Mon, Jul 15, 2019 at 12:58:08PM +0100, Paul Sutton wrote: > The srsLTE implementation is taken from the ETSI specs simulation > program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf > and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf thanks for your feedback. > https://www.etsi.org/intellectual-property-rights#mytoc3 and > https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the > copyright licensing details for software incorporated in ETSI > standards however I have not taken legal advice on compatibility of > this license with AGPLv3. I personally find all I found so far on the the ETSI "IP policy" quite shady, to be honest. It's weird how the "restricted usage undertaking" and related documents appear to be devoid of any information about what kind of rights or license they are talking about. "intellectual property" is a marketing term. It could refer to anything from trademarks, patents to copyright. It's a bit of a surprise that the industry doesn't appear to have developed more legal clarity around this. This is not only true for those crypto systems, but equally true e.g. of the reference voice codec implementations. The specs requires a bit-exact match to what is released as their source code - yet that source code comes without copyright statement or any indication of license terms. The big question is how realistically one could write an independent implementation which renders the bit-exact results without writing code that looks identical. Also, there's typically always some collections of constants / tables, which you have to copy 1:1. Sure, there's some flexibility in the details of an implementation, but to me it's somewhat questionable how that would look from a copyright point of view. Guess I'll have to have that discussion within the FOSS legal circles I happen to have found my way into. It would be great to have a discussion around all of this with ETSI, but I somehow fear they will not really have anyone on the table with a deep understanding how FOSS works both legally and technically. > It would be good as you say to have a "clean copyright" implementation > - perhaps this is something we could help with. I'd very much like that idea. If you have capacity to work on that: great! Maybe it's also something where one could convince some FOSS-friendly academics that it would be worth having e.g. some students work on it. I don't really have much day-to-day contacts to academic cryptographers, but I know quite a few and can try to ask around. Regards, Harald -- - Harald Welte 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 Jul 16 22:35:12 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Wed, 17 Jul 2019 07:35:12 +0900 Subject: SMS In-Reply-To: References: Message-ID: Hi Romeu, Wow! It?s amazing. I can?t thank you enough for your effort. Best Regards, Sukchan 2019? 7? 17? (?) ?? 1:33, Romeu Medeiros ?? ??: > Hello guys and @Sukchan Lee > > I tested with sucess the send and receive SMS in new version of NextEPC running together with OSMO-MSC/HLR (SGS). > > Thanks > > Romeu Medeiros -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeiros at medeiros.eng.br Tue Jul 16 22:45:02 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Tue, 16 Jul 2019 19:45:02 -0300 Subject: SMS In-Reply-To: References: Message-ID: Sukchan, We can't thank you enough for the nextepc. I think that in some situations the msc is losing the sgs registrations and can't forward the sms. But I will more tests before to disturb you there. Thanks and success! Romeu Medeiros Em ter, 16 de jul de 2019 ?s 19:35, Sukchan Lee escreveu: > Hi Romeu, > > Wow! It?s amazing. > I can?t thank you enough for your effort. > > Best Regards, > Sukchan > > > > 2019? 7? 17? (?) ?? 1:33, Romeu Medeiros ?? ??: > >> Hello guys and @Sukchan Lee >> >> I tested with sucess the send and receive SMS in new version of NextEPC >> running together with OSMO-MSC/HLR (SGS). >> >> Thanks >> >> Romeu Medeiros >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jul 17 09:38:37 2019 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 17 Jul 2019 18:38:37 +0900 Subject: SMS In-Reply-To: References: Message-ID: <20190717093837.GJ3325@nataraja> Hi Romeu, On Tue, Jul 16, 2019 at 07:45:02PM -0300, Romeu Medeiros wrote: > I think that in some situations the msc is losing the sgs registrations and > can't forward the sms. But I will more tests before to disturb you there. feel free to share some pcap files, we're also happy to review them from the osmocom point of view. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From medeiros at medeiros.eng.br Wed Jul 17 19:40:38 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Wed, 17 Jul 2019 16:40:38 -0300 Subject: SMS In-Reply-To: <20190717093837.GJ3325@nataraja> References: <20190717093837.GJ3325@nataraja> Message-ID: Hello Harald, I will make more tests in the Labs tomorrow and I'll let you know if I found something. Thanks for the help! Romeu Medeiros On Wed, Jul 17, 2019 at 6:40 AM Harald Welte wrote: > Hi Romeu, > > On Tue, Jul 16, 2019 at 07:45:02PM -0300, Romeu Medeiros wrote: > > > I think that in some situations the msc is losing the sgs registrations > and > > can't forward the sms. But I will more tests before to disturb you there. > > feel free to share some pcap files, we're also happy to review them from > the osmocom > point of view. > > -- > - Harald Welte > 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: From medeiros at medeiros.eng.br Wed Jul 17 19:47:19 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Wed, 17 Jul 2019 16:47:19 -0300 Subject: SMS In-Reply-To: References: Message-ID: Hello Sukchan, I found something stranger, When the VLR try to Pagging the UE, the NextEPC-MME make the pagging correctly. But when this UE is not reachable the NextEPC it not sending to VLR the SGsAP-UE-UNREACHABLE, like is necessary in the documentation: [image: image.png] I will try to fix it. In attached I'm sending a pcap from this case. The IMSI unreachable in this case is 724210000000002. Thanks Romeu Medeiros On Tue, Jul 16, 2019 at 7:45 PM Romeu Medeiros wrote: > Sukchan, > > We can't thank you enough for the nextepc. > > I think that in some situations the msc is losing the sgs registrations > and can't forward the sms. But I will more tests before to disturb you > there. > > Thanks and success! > > Romeu Medeiros > > Em ter, 16 de jul de 2019 ?s 19:35, Sukchan Lee > escreveu: > >> Hi Romeu, >> >> Wow! It?s amazing. >> I can?t thank you enough for your effort. >> >> Best Regards, >> Sukchan >> >> >> >> 2019? 7? 17? (?) ?? 1:33, Romeu Medeiros ?? ??: >> >>> Hello guys and @Sukchan Lee >>> >>> I tested with sucess the send and receive SMS in new version of NextEPC >>> running together with OSMO-MSC/HLR (SGS). >>> >>> Thanks >>> >>> Romeu Medeiros >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: saida94sgs.pcap Type: application/octet-stream Size: 13568 bytes Desc: not available URL: From medeiros at medeiros.eng.br Wed Jul 17 20:55:08 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Wed, 17 Jul 2019 17:55:08 -0300 Subject: Nextepc died in some MT-Fallback Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: saida97csfb.pcap Type: application/octet-stream Size: 390334 bytes Desc: not available URL: From acetcom at gmail.com Wed Jul 17 21:14:54 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Thu, 18 Jul 2019 06:14:54 +0900 Subject: SMS In-Reply-To: References: Message-ID: Hi Romeu, I?ve missed to implement ue-unreachable. Soon, I will add this feature. Thank you for your effort. Best Regards, Sukchan 2019? 7? 18? (?) ?? 4:47, Romeu Medeiros ?? ??: > Hello Sukchan, > > I found something stranger, > > When the VLR try to Pagging the UE, the NextEPC-MME make the pagging > correctly. > > But when this UE is not reachable the NextEPC it not sending to VLR the > SGsAP-UE-UNREACHABLE, like is necessary in the documentation: > > [image: image.png] > > I will try to fix it. > > In attached I'm sending a pcap from this case. > > The IMSI unreachable in this case is 724210000000002. > > Thanks > > Romeu Medeiros > > > On Tue, Jul 16, 2019 at 7:45 PM Romeu Medeiros > wrote: > >> Sukchan, >> >> We can't thank you enough for the nextepc. >> >> I think that in some situations the msc is losing the sgs registrations >> and can't forward the sms. But I will more tests before to disturb you >> there. >> >> Thanks and success! >> >> Romeu Medeiros >> >> Em ter, 16 de jul de 2019 ?s 19:35, Sukchan Lee >> escreveu: >> >>> Hi Romeu, >>> >>> Wow! It?s amazing. >>> I can?t thank you enough for your effort. >>> >>> Best Regards, >>> Sukchan >>> >>> >>> >>> 2019? 7? 17? (?) ?? 1:33, Romeu Medeiros ?? >>> ??: >>> >>>> Hello guys and @Sukchan Lee >>>> >>>> I tested with sucess the send and receive SMS in new version of NextEPC >>>> running together with OSMO-MSC/HLR (SGS). >>>> >>>> Thanks >>>> >>>> Romeu Medeiros >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165608 bytes Desc: not available URL: From medeiros at medeiros.eng.br Wed Jul 17 21:17:31 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Wed, 17 Jul 2019 18:17:31 -0300 Subject: SMS In-Reply-To: <20190717093837.GJ3325@nataraja> References: <20190717093837.GJ3325@nataraja> Message-ID: Harald, I some situations, when the MME lost connection with the OSMO-MSC and return this connection if I try send a MT-CSFB the OSMO-MSC is crashing. I get this error in the log: <0006> sgs_iface.c:470 XXXXXXXXXX state == 1 conf_by_radio_contact_ind == 1 <0011> sgs_iface.c:251 (sub IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269) Tx PAGING-REQUEST suitable MME found, but no SGS connection present! <0005> sgs_iface.c:480 SGs-UE(imsi:724210000000003)[0x563949b08fc0]{SGs-ASSOCIATED}: Will not Page (no MME) <0005> paging.c:101 Paging: IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 for MNCC: establish call: Starting paging failed (rc=-22) <0001> gsm_04_08_cc.c:1922 trans(CC IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 callref-0x1396 tid-255) Failed to allocate paging token. Segmentation fault (core dumped) I'll try why this happened, but I'm not getting used to it in the OSMO source code. Can you tell me (if you have time) how identify where this crash is occouring? In the attach have the PCAP of the SGS between the OSMO and NextEPC-MME. Thanks Romeu Medeiros On Wed, Jul 17, 2019 at 6:40 AM Harald Welte wrote: > Hi Romeu, > > On Tue, Jul 16, 2019 at 07:45:02PM -0300, Romeu Medeiros wrote: > > > I think that in some situations the msc is losing the sgs registrations > and > > can't forward the sms. But I will more tests before to disturb you there. > > feel free to share some pcap files, we're also happy to review them from > the osmocom > point of view. > > -- > - Harald Welte > 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: From medeiros at medeiros.eng.br Wed Jul 17 21:18:14 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Wed, 17 Jul 2019 18:18:14 -0300 Subject: SMS In-Reply-To: References: <20190717093837.GJ3325@nataraja> Message-ID: Harald, Sorry, I forgot to attach the pcap file. Thanks On Wed, Jul 17, 2019 at 6:17 PM Romeu Medeiros wrote: > Harald, > > I some situations, when the MME lost connection with the OSMO-MSC and > return this connection if I try send a MT-CSFB the OSMO-MSC is crashing. > > I get this error in the log: > > <0006> sgs_iface.c:470 XXXXXXXXXX state == 1 conf_by_radio_contact_ind == > 1 > <0011> sgs_iface.c:251 (sub > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269) Tx > PAGING-REQUEST suitable MME found, but no SGS connection present! > <0005> sgs_iface.c:480 > SGs-UE(imsi:724210000000003)[0x563949b08fc0]{SGs-ASSOCIATED}: Will not Page > (no MME) > <0005> paging.c:101 Paging: > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 for MNCC: > establish call: Starting paging failed (rc=-22) > <0001> gsm_04_08_cc.c:1922 trans(CC > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 callref-0x1396 > tid-255) Failed to allocate paging token. > Segmentation fault (core dumped) > > I'll try why this happened, but I'm not getting used to it in the OSMO > source code. Can you tell me (if you have time) how identify where this > crash is occouring? > > > In the attach have the PCAP of the SGS between the OSMO and NextEPC-MME. > > Thanks > > Romeu Medeiros > > On Wed, Jul 17, 2019 at 6:40 AM Harald Welte wrote: > >> Hi Romeu, >> >> On Tue, Jul 16, 2019 at 07:45:02PM -0300, Romeu Medeiros wrote: >> >> > I think that in some situations the msc is losing the sgs registrations >> and >> > can't forward the sms. But I will more tests before to disturb you >> there. >> >> feel free to share some pcap files, we're also happy to review them from >> the osmocom >> point of view. >> >> -- >> - Harald Welte >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: saida98csfb.pcap Type: application/octet-stream Size: 17440 bytes Desc: not available URL: From customerservice at chinanethost.com Tue Jul 16 08:29:10 2019 From: customerservice at chinanethost.com (Peter Liu) Date: Tue, 16 Jul 2019 16:29:10 +0800 Subject: osmocom CN domain and keyword Message-ID: <20190716162920833545@chinanethost.com> (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 at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Jul 17 23:28:22 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Jul 2019 01:28:22 +0200 Subject: SMS In-Reply-To: References: <20190717093837.GJ3325@nataraja> Message-ID: <20190717232822.GY3325@nataraja> Hi Romeu, On Wed, Jul 17, 2019 at 06:17:31PM -0300, Romeu Medeiros wrote: > I some situations, when the MME lost connection with the OSMO-MSC and > return this connection if I try send a MT-CSFB the OSMO-MSC is crashing. that obviously shouldn't happen. > I get this error in the log: > > <0006> sgs_iface.c:470 XXXXXXXXXX state == 1 conf_by_radio_contact_ind == 1 > <0011> sgs_iface.c:251 (sub > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269) Tx > PAGING-REQUEST suitable MME found, but no SGS connection present! > <0005> sgs_iface.c:480 > SGs-UE(imsi:724210000000003)[0x563949b08fc0]{SGs-ASSOCIATED}: Will not Page > (no MME) > <0005> paging.c:101 Paging: > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 for MNCC: > establish call: Starting paging failed (rc=-22) > <0001> gsm_04_08_cc.c:1922 trans(CC > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 callref-0x1396 > tid-255) Failed to allocate paging token. > Segmentation fault (core dumped) Thanks. I created a bug at https://osmocom.org/issues/4117 > I'll try why this happened, but I'm not getting used to it in the OSMO > source code. Can you tell me (if you have time) how identify where this > crash is occouring? It's the same as any other C program: * compile with "-g" * run it in gdb * provoke the setfault * take a "backtrace full" after the crash It would be great if you could amend the bugtracker with that information, but I would guess the information you provided is already sufficient for Philipp, the implementor of the SGs support in OsmoMSC. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From medeiros at medeiros.eng.br Thu Jul 18 01:07:55 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Wed, 17 Jul 2019 22:07:55 -0300 Subject: SMS In-Reply-To: <20190717232822.GY3325@nataraja> References: <20190717093837.GJ3325@nataraja> <20190717232822.GY3325@nataraja> Message-ID: Hello Harald, I sent the backtrace full in the bugtracker. Thanks Romeu Medeiros On Wed, Jul 17, 2019 at 8:30 PM Harald Welte wrote: > Hi Romeu, > > On Wed, Jul 17, 2019 at 06:17:31PM -0300, Romeu Medeiros wrote: > > I some situations, when the MME lost connection with the OSMO-MSC and > > return this connection if I try send a MT-CSFB the OSMO-MSC is crashing. > > that obviously shouldn't happen. > > > I get this error in the log: > > > > <0006> sgs_iface.c:470 XXXXXXXXXX state == 1 conf_by_radio_contact_ind > == 1 > > <0011> sgs_iface.c:251 (sub > > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269) Tx > > PAGING-REQUEST suitable MME found, but no SGS connection present! > > <0005> sgs_iface.c:480 > > SGs-UE(imsi:724210000000003)[0x563949b08fc0]{SGs-ASSOCIATED}: Will not > Page > > (no MME) > > <0005> paging.c:101 Paging: > > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 for MNCC: > > establish call: Starting paging failed (rc=-22) > > <0001> gsm_04_08_cc.c:1922 trans(CC > > IMSI-724210000000003:MSISDN-5544912340003:TMSI-0x8E44F269 callref-0x1396 > > tid-255) Failed to allocate paging token. > > Segmentation fault (core dumped) > > Thanks. I created a bug at https://osmocom.org/issues/4117 > > > I'll try why this happened, but I'm not getting used to it in the OSMO > > source code. Can you tell me (if you have time) how identify where this > > crash is occouring? > > It's the same as any other C program: > * compile with "-g" > * run it in gdb > * provoke the setfault > * take a "backtrace full" after the crash > > It would be great if you could amend the bugtracker with that information, > but I would guess the information you provided is already sufficient for > Philipp, > the implementor of the SGs support in OsmoMSC. > > -- > - Harald Welte > 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: From rafael at rhizomatica.org Fri Jul 19 16:29:59 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Fri, 19 Jul 2019 13:29:59 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: Message-ID: <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org> Hi all, I'd also like to test SMS and CSFB in LTE. I have some experience with the Osmocom GSM stack, but not much with the NextEPC LTE. Could you point me which fields should I set in the configuration files? Thanks, Rafael Diniz On 7/13/19 6:35 PM, Romeu Medeiros wrote: > Hello?Sukchan and friends. > > I'm trying to use the CSFB in test lab, and every time that nextepc send > the UEContextModificationRequest, the UE respond with an > UEContextModificationFaliure [ Protocol-cause=semantic-error ]. > > image.png > > I'm looking why I'm getting this. Someone have any idea? > > Thanks > > Romeu Medeiros > > On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee > 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: > > # > # ? > # > # ?o Single MSC/VLR > # ? ?sgsap: > # ? ? ?addr: 127.0.0.2 > # ? ? ?plmn_id: > # ? ? ? ?mcc: 001 > # ? ? ? ?mnc: 01 > # ? ? ?tac: 4130 > # ? ? ?lac: 43690 > # > # ?o Multiple MSC/VLR > # ? ?sgsap: > # ? ? ?- addr: 127.0.0.2 > # ? ? ? ?plmn_id: > # ? ? ? ? ?mcc: 001 > # ? ? ? ? ?mnc: 01 > # ? ? ? ?tac: 4131 > # ? ? ? ?lac: 43692 > # ? ? ?- addr > # ? ? ? ? - 127.0.0.3 > # ? ? ? ? - fe80::2%lo0 > # ? ? ? ?plmn_id: > # ? ? ? ? ?mcc: 001 > # ? ? ? ? ?mnc: 01 > # ? ? ? ?tac: 4132 > # ? ? ? ?lac: 43692 > # ? ? ?- name: msc.open5gs.org > # ? ? ? ?plmn_id: > # ? ? ? ? ?mcc: 001 > # ? ? ? ? ?mnc: 01 > # ? ? ? ?tac: 4133 > # ? ? ? ?lac: 43693 > # > > FYI, I also attach the pcap that I run with nextepc simulator as below. > > $ ./tests/testcsfb > mo-idle-test ? ? ? ?: SUCCESS > mt-idle-test ? ? ? ?: SUCCESS > mo-active-test ? ? ?: SUCCESS > mt-active-test ? ? ?: SUCCESS > All tests passed. > > Feel free to raise any questions about this things. > > Best Regards, > ? ? Sukchan > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From medeiros at medeiros.eng.br Fri Jul 19 19:58:00 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Fri, 19 Jul 2019 16:58:00 -0300 Subject: CS Fallback in NextEPC In-Reply-To: <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org> References: <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org> Message-ID: 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 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 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 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 > > 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: > > > > # > > # > > # > > # o Single MSC/VLR > > # sgsap: > > # addr: 127.0.0.2 > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4130 > > # lac: 43690 > > # > > # o Multiple MSC/VLR > > # sgsap: > > # - addr: 127.0.0.2 > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4131 > > # lac: 43692 > > # - addr > > # - 127.0.0.3 > > # - fe80::2%lo0 > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4132 > > # lac: 43692 > > # - name: msc.open5gs.org > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4133 > > # lac: 43693 > > # > > > > FYI, I also attach the pcap that I run with nextepc simulator as > below. > > > > $ ./tests/testcsfb > > mo-idle-test : SUCCESS > > mt-idle-test : SUCCESS > > mo-active-test : SUCCESS > > mt-active-test : SUCCESS > > All tests passed. > > > > Feel free to raise any questions about this things. > > > > Best Regards, > > Sukchan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael at rhizomatica.org Fri Jul 19 20:51:23 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Fri, 19 Jul 2019 17:51:23 -0300 Subject: CS Fallback in NextEPC In-Reply-To: References: <097e83a1-6592-2d2a-58bb-22242401b05b@rhizomatica.org> Message-ID: 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 > ? ? ? ? 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 > > 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 > 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 > > >> 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: > > > >? ? ?# > >? ? ?# ? > >? ? ?# > >? ? ?# ?o Single MSC/VLR > >? ? ?# ? ?sgsap: > >? ? ?# ? ? ?addr: 127.0.0.2 > >? ? ?# ? ? ?plmn_id: > >? ? ?# ? ? ? ?mcc: 001 > >? ? ?# ? ? ? ?mnc: 01 > >? ? ?# ? ? ?tac: 4130 > >? ? ?# ? ? ?lac: 43690 > >? ? ?# > >? ? ?# ?o Multiple MSC/VLR > >? ? ?# ? ?sgsap: > >? ? ?# ? ? ?- addr: 127.0.0.2 > >? ? ?# ? ? ? ?plmn_id: > >? ? ?# ? ? ? ? ?mcc: 001 > >? ? ?# ? ? ? ? ?mnc: 01 > >? ? ?# ? ? ? ?tac: 4131 > >? ? ?# ? ? ? ?lac: 43692 > >? ? ?# ? ? ?- addr > >? ? ?# ? ? ? ? - 127.0.0.3 > >? ? ?# ? ? ? ? - fe80::2%lo0 > >? ? ?# ? ? ? ?plmn_id: > >? ? ?# ? ? ? ? ?mcc: 001 > >? ? ?# ? ? ? ? ?mnc: 01 > >? ? ?# ? ? ? ?tac: 4132 > >? ? ?# ? ? ? ?lac: 43692 > >? ? ?# ? ? ?- name: msc.open5gs.org > > >? ? ?# ? ? ? ?plmn_id: > >? ? ?# ? ? ? ? ?mcc: 001 > >? ? ?# ? ? ? ? ?mnc: 01 > >? ? ?# ? ? ? ?tac: 4133 > >? ? ?# ? ? ? ?lac: 43693 > >? ? ?# > > > >? ? ?FYI, I also attach the pcap that I run with nextepc simulator > as below. > > > >? ? ?$ ./tests/testcsfb > >? ? ?mo-idle-test ? ? ? ?: SUCCESS > >? ? ?mt-idle-test ? ? ? ?: SUCCESS > >? ? ?mo-active-test ? ? ?: SUCCESS > >? ? ?mt-active-test ? ? ?: SUCCESS > >? ? ?All tests passed. > > > >? ? ?Feel free to raise any questions about this things. > > > >? ? ?Best Regards, > >? ? ?? ? Sukchan > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From acetcom at gmail.com Sun Jul 21 13:59:44 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Sun, 21 Jul 2019 22:59:44 +0900 Subject: Nextepc died in some MT-Fallback In-Reply-To: References: Message-ID: Today I've analyzed this problem. Luckily it was reproduced in simulator. The bad news seems to be a problem with the asn1c library. More than 9 protocol IE cannot be built from InitialContextSetupRequest. So, I've added some workaround as below. if CS Fallback then Add CS Fallback ProtofcolIE Add RegisteredLAI ELSE if RadioCababiltiy Add RadioCapbability endif ELSE prevents InitialContextSetupRequest from creating more than 9 protocol IEs. See more information the following link: https://github.com/open5gs/nextepc/commit/f19009c736875847f30d7ea010d1064c5810d644 Thanks a lot! Best Regards, Sukchan On Thu, Jul 18, 2019 at 5:55 AM Romeu Medeiros wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jul 21 14:41:06 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 21 Jul 2019 16:41:06 +0200 Subject: Nextepc died in some MT-Fallback In-Reply-To: References: Message-ID: <20190721144106.GP21123@nataraja> Hi Sukchan, On Sun, Jul 21, 2019 at 10:59:44PM +0900, Sukchan Lee wrote: > The bad news seems to be a problem with the asn1c library. > More than 9 protocol IE cannot be built from InitialContextSetupRequest. I suggest to report this upstream to the asn1c hackers and ask for theri help. It may also work using one of the other versions/branches of asn1c for comparison. -- - Harald Welte 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 Sun Jul 21 15:02:20 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Mon, 22 Jul 2019 00:02:20 +0900 Subject: Nextepc died in some MT-Fallback In-Reply-To: <20190721144106.GP21123@nataraja> References: <20190721144106.GP21123@nataraja> Message-ID: Hi Harald, Of course, I will. But before that I should check the other asn1c upstream version. And I need to reproduce test code for asn1c hacker to analyze this problem easily. And then, I will post this issue. Thanks a lot! Best Regards Sukchan 2019. 7. 21. ?? 11:41, Harald Welte ??: > Hi Sukchan, > >> On Sun, Jul 21, 2019 at 10:59:44PM +0900, Sukchan Lee wrote: >> The bad news seems to be a problem with the asn1c library. >> More than 9 protocol IE cannot be built from InitialContextSetupRequest. > > I suggest to report this upstream to the asn1c hackers and ask for theri help. > > It may also work using one of the other versions/branches of asn1c for comparison. > -- > - Harald Welte 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 Wed Jul 24 13:18:38 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Wed, 24 Jul 2019 22:18:38 +0900 Subject: Nextepc died in some MT-Fallback In-Reply-To: References: <20190721144106.GP21123@nataraja> Message-ID: It seems that this is not a problem with the asn1c library. There is a bug in ogs_calloc()/ogs_free(). I've changed memory alloc()/free() as below. https://github.com/open5gs/nextepc/commit/dba1fcac5c29509a9e662a9fedc37a674a416df3 And then, the source code is modified like the following. diff --git a/lib/asn1c/common/asn_internal.h b/lib/asn1c/common/asn_internal.h index 77e005f7..d561043b 100644 --- a/lib/asn1c/common/asn_internal.h +++ b/lib/asn1c/common/asn_internal.h @@ -23,7 +23,7 @@ extern "C" { #define ASN1C_ENVIRONMENT_VERSION 923 /* Compile-time version */ int get_asn1c_environment_version(void); /* Run-time version */ -#if 0 /* modified by acetcom */ +#if 1 /* modified by acetcom */ #define CALLOC(nmemb, size) calloc(nmemb, size) #define MALLOC(size) malloc(size) #define REALLOC(oldptr, size) realloc(oldptr, size) So, s1ap encoder/decoder is executed with system's calloc()/free(). And then, run the following command. $ ./test/testcsfb crash-test The above test is not crashed. Of course, if ogs_calloc()/ogs_free() is used, the above test command is crashed. So, I need to analyze what the bug of ogs-memory.c raise this crash. Thanks! On Mon, Jul 22, 2019 at 12:02 AM Sukchan Lee wrote: > Hi Harald, > > Of course, I will. But before that I should check the other asn1c upstream > version. And I need to reproduce test code for asn1c hacker to analyze this > problem easily. > > And then, I will post this issue. > > Thanks a lot! > > Best Regards > Sukchan > > 2019. 7. 21. ?? 11:41, Harald Welte ??: > > > Hi Sukchan, > > > >> On Sun, Jul 21, 2019 at 10:59:44PM +0900, Sukchan Lee wrote: > >> The bad news seems to be a problem with the asn1c library. > >> More than 9 protocol IE cannot be built from InitialContextSetupRequest. > > > > I suggest to report this upstream to the asn1c hackers and ask for theri > help. > > > > It may also work using one of the other versions/branches of asn1c for > comparison. > > -- > > - Harald Welte > 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: From acetcom at gmail.com Wed Jul 24 13:20:54 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Wed, 24 Jul 2019 22:20:54 +0900 Subject: Nextepc died in some MT-Fallback In-Reply-To: References: <20190721144106.GP21123@nataraja> Message-ID: Ah, one more modification is needed as below. diff --git a/src/mme/s1ap-build.c b/src/mme/s1ap-build.c index a49d117e..cfbedc87 100644 --- a/src/mme/s1ap-build.c +++ b/src/mme/s1ap-build.c @@ -531,7 +531,8 @@ int s1ap_build_initial_context_setup_request( ogs_assert(mme_ue->p_tmsi); s1ap_uint16_to_OCTET_STRING(mme_ue->csmap->lai.lac, &LAI->lAC); - } else if (mme_ue->ueRadioCapability.buf && + } + if (mme_ue->ueRadioCapability.buf && mme_ue->ueRadioCapability.size) { /* Set UeRadioCapability if exists */ S1AP_UERadioCapability_t *UERadioCapability = NULL; The above change is also needed to encode more than 9 procotol IE. Thanks! On Wed, Jul 24, 2019 at 10:18 PM Sukchan Lee wrote: > It seems that this is not a problem with the asn1c library. There is a bug > in ogs_calloc()/ogs_free(). > > I've changed memory alloc()/free() as below. > > https://github.com/open5gs/nextepc/commit/dba1fcac5c29509a9e662a9fedc37a674a416df3 > > And then, the source code is modified like the following. > diff --git a/lib/asn1c/common/asn_internal.h > b/lib/asn1c/common/asn_internal.h > index 77e005f7..d561043b 100644 > --- a/lib/asn1c/common/asn_internal.h > +++ b/lib/asn1c/common/asn_internal.h > @@ -23,7 +23,7 @@ extern "C" { > #define ASN1C_ENVIRONMENT_VERSION 923 /* Compile-time > version */ > int get_asn1c_environment_version(void); /* Run-time version */ > > -#if 0 /* modified by acetcom */ > +#if 1 /* modified by acetcom */ > #define CALLOC(nmemb, size) calloc(nmemb, size) > #define MALLOC(size) malloc(size) > #define REALLOC(oldptr, size) realloc(oldptr, size) > > So, s1ap encoder/decoder is executed with system's calloc()/free(). > > And then, run the following command. > $ ./test/testcsfb crash-test > > The above test is not crashed. > Of course, if ogs_calloc()/ogs_free() is used, the above test command is > crashed. > > So, I need to analyze what the bug of ogs-memory.c raise this crash. > > Thanks! > > > > > On Mon, Jul 22, 2019 at 12:02 AM Sukchan Lee wrote: > >> Hi Harald, >> >> Of course, I will. But before that I should check the other asn1c >> upstream version. And I need to reproduce test code for asn1c hacker to >> analyze this problem easily. >> >> And then, I will post this issue. >> >> Thanks a lot! >> >> Best Regards >> Sukchan >> >> 2019. 7. 21. ?? 11:41, Harald Welte ??: >> >> > Hi Sukchan, >> > >> >> On Sun, Jul 21, 2019 at 10:59:44PM +0900, Sukchan Lee wrote: >> >> The bad news seems to be a problem with the asn1c library. >> >> More than 9 protocol IE cannot be built from >> InitialContextSetupRequest. >> > >> > I suggest to report this upstream to the asn1c hackers and ask for >> theri help. >> > >> > It may also work using one of the other versions/branches of asn1c for >> comparison. >> > -- >> > - Harald Welte >> 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: From acetcom at gmail.com Sun Jul 28 15:18:59 2019 From: acetcom at gmail.com (Sukchan Lee) Date: Mon, 29 Jul 2019 00:18:59 +0900 Subject: Nextepc died in some MT-Fallback In-Reply-To: References: <20190721144106.GP21123@nataraja> Message-ID: Hi Romeu, I've fixed this issue. There is a big bug in ogs_realloc(); The issue link as below, OGSLib : https://github.com/open5gs/ogslib/issues/4 NextEPC: https://github.com/open5gs/nextepc/issues/231 The code is fixed like the following. https://github.com/open5gs/ogslib/commit/4a6c2e2a4afcc3337b2748d0df645b4b57c0750d Many thanks! Best Regards, Sukchan On Wed, Jul 24, 2019 at 10:20 PM Sukchan Lee wrote: > Ah, one more modification is needed as below. > > diff --git a/src/mme/s1ap-build.c b/src/mme/s1ap-build.c > index a49d117e..cfbedc87 100644 > --- a/src/mme/s1ap-build.c > +++ b/src/mme/s1ap-build.c > @@ -531,7 +531,8 @@ int s1ap_build_initial_context_setup_request( > ogs_assert(mme_ue->p_tmsi); > s1ap_uint16_to_OCTET_STRING(mme_ue->csmap->lai.lac, &LAI->lAC); > > - } else if (mme_ue->ueRadioCapability.buf && > + } > + if (mme_ue->ueRadioCapability.buf && > mme_ue->ueRadioCapability.size) { > /* Set UeRadioCapability if exists */ > S1AP_UERadioCapability_t *UERadioCapability = NULL; > > The above change is also needed to encode more than 9 procotol IE. > > Thanks! > > > > On Wed, Jul 24, 2019 at 10:18 PM Sukchan Lee wrote: > >> It seems that this is not a problem with the asn1c library. There is a >> bug in ogs_calloc()/ogs_free(). >> >> I've changed memory alloc()/free() as below. >> >> https://github.com/open5gs/nextepc/commit/dba1fcac5c29509a9e662a9fedc37a674a416df3 >> >> And then, the source code is modified like the following. >> diff --git a/lib/asn1c/common/asn_internal.h >> b/lib/asn1c/common/asn_internal.h >> index 77e005f7..d561043b 100644 >> --- a/lib/asn1c/common/asn_internal.h >> +++ b/lib/asn1c/common/asn_internal.h >> @@ -23,7 +23,7 @@ extern "C" { >> #define ASN1C_ENVIRONMENT_VERSION 923 /* Compile-time >> version */ >> int get_asn1c_environment_version(void); /* Run-time version */ >> >> -#if 0 /* modified by acetcom */ >> +#if 1 /* modified by acetcom */ >> #define CALLOC(nmemb, size) calloc(nmemb, size) >> #define MALLOC(size) malloc(size) >> #define REALLOC(oldptr, size) realloc(oldptr, size) >> >> So, s1ap encoder/decoder is executed with system's calloc()/free(). >> >> And then, run the following command. >> $ ./test/testcsfb crash-test >> >> The above test is not crashed. >> Of course, if ogs_calloc()/ogs_free() is used, the above test command is >> crashed. >> >> So, I need to analyze what the bug of ogs-memory.c raise this crash. >> >> Thanks! >> >> >> >> >> On Mon, Jul 22, 2019 at 12:02 AM Sukchan Lee wrote: >> >>> Hi Harald, >>> >>> Of course, I will. But before that I should check the other asn1c >>> upstream version. And I need to reproduce test code for asn1c hacker to >>> analyze this problem easily. >>> >>> And then, I will post this issue. >>> >>> Thanks a lot! >>> >>> Best Regards >>> Sukchan >>> >>> 2019. 7. 21. ?? 11:41, Harald Welte ??: >>> >>> > Hi Sukchan, >>> > >>> >> On Sun, Jul 21, 2019 at 10:59:44PM +0900, Sukchan Lee wrote: >>> >> The bad news seems to be a problem with the asn1c library. >>> >> More than 9 protocol IE cannot be built from >>> InitialContextSetupRequest. >>> > >>> > I suggest to report this upstream to the asn1c hackers and ask for >>> theri help. >>> > >>> > It may also work using one of the other versions/branches of asn1c for >>> comparison. >>> > -- >>> > - Harald Welte >>> 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: From medeiros at medeiros.eng.br Sun Jul 28 15:21:42 2019 From: medeiros at medeiros.eng.br (Romeu Medeiros) Date: Sun, 28 Jul 2019 12:21:42 -0300 Subject: Nextepc died in some MT-Fallback In-Reply-To: References: <20190721144106.GP21123@nataraja> Message-ID: Hello Sukchan, Thanks for this! I will try tomorrow. Thanks Romeu Medeiros Em dom, 28 de jul de 2019 ?s 12:19, Sukchan Lee escreveu: > Hi Romeu, > > I've fixed this issue. There is a big bug in ogs_realloc(); > > The issue link as below, > OGSLib : https://github.com/open5gs/ogslib/issues/4 > NextEPC: https://github.com/open5gs/nextepc/issues/231 > > The code is fixed like the following. > > https://github.com/open5gs/ogslib/commit/4a6c2e2a4afcc3337b2748d0df645b4b57c0750d > > Many thanks! > > Best Regards, > Sukchan > > > On Wed, Jul 24, 2019 at 10:20 PM Sukchan Lee wrote: > >> Ah, one more modification is needed as below. >> >> diff --git a/src/mme/s1ap-build.c b/src/mme/s1ap-build.c >> index a49d117e..cfbedc87 100644 >> --- a/src/mme/s1ap-build.c >> +++ b/src/mme/s1ap-build.c >> @@ -531,7 +531,8 @@ int s1ap_build_initial_context_setup_request( >> ogs_assert(mme_ue->p_tmsi); >> s1ap_uint16_to_OCTET_STRING(mme_ue->csmap->lai.lac, &LAI->lAC); >> >> - } else if (mme_ue->ueRadioCapability.buf && >> + } >> + if (mme_ue->ueRadioCapability.buf && >> mme_ue->ueRadioCapability.size) { >> /* Set UeRadioCapability if exists */ >> S1AP_UERadioCapability_t *UERadioCapability = NULL; >> >> The above change is also needed to encode more than 9 procotol IE. >> >> Thanks! >> >> >> >> On Wed, Jul 24, 2019 at 10:18 PM Sukchan Lee wrote: >> >>> It seems that this is not a problem with the asn1c library. There is a >>> bug in ogs_calloc()/ogs_free(). >>> >>> I've changed memory alloc()/free() as below. >>> >>> https://github.com/open5gs/nextepc/commit/dba1fcac5c29509a9e662a9fedc37a674a416df3 >>> >>> And then, the source code is modified like the following. >>> diff --git a/lib/asn1c/common/asn_internal.h >>> b/lib/asn1c/common/asn_internal.h >>> index 77e005f7..d561043b 100644 >>> --- a/lib/asn1c/common/asn_internal.h >>> +++ b/lib/asn1c/common/asn_internal.h >>> @@ -23,7 +23,7 @@ extern "C" { >>> #define ASN1C_ENVIRONMENT_VERSION 923 /* Compile-time >>> version */ >>> int get_asn1c_environment_version(void); /* Run-time version */ >>> >>> -#if 0 /* modified by acetcom */ >>> +#if 1 /* modified by acetcom */ >>> #define CALLOC(nmemb, size) calloc(nmemb, size) >>> #define MALLOC(size) malloc(size) >>> #define REALLOC(oldptr, size) realloc(oldptr, size) >>> >>> So, s1ap encoder/decoder is executed with system's calloc()/free(). >>> >>> And then, run the following command. >>> $ ./test/testcsfb crash-test >>> >>> The above test is not crashed. >>> Of course, if ogs_calloc()/ogs_free() is used, the above test command is >>> crashed. >>> >>> So, I need to analyze what the bug of ogs-memory.c raise this crash. >>> >>> Thanks! >>> >>> >>> >>> >>> On Mon, Jul 22, 2019 at 12:02 AM Sukchan Lee wrote: >>> >>>> Hi Harald, >>>> >>>> Of course, I will. But before that I should check the other asn1c >>>> upstream version. And I need to reproduce test code for asn1c hacker to >>>> analyze this problem easily. >>>> >>>> And then, I will post this issue. >>>> >>>> Thanks a lot! >>>> >>>> Best Regards >>>> Sukchan >>>> >>>> 2019. 7. 21. ?? 11:41, Harald Welte ??: >>>> >>>> > Hi Sukchan, >>>> > >>>> >> On Sun, Jul 21, 2019 at 10:59:44PM +0900, Sukchan Lee wrote: >>>> >> The bad news seems to be a problem with the asn1c library. >>>> >> More than 9 protocol IE cannot be built from >>>> InitialContextSetupRequest. >>>> > >>>> > I suggest to report this upstream to the asn1c hackers and ask for >>>> theri help. >>>> > >>>> > It may also work using one of the other versions/branches of asn1c >>>> for comparison. >>>> > -- >>>> > - Harald Welte >>>> 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: