From axilirator at gmail.com Thu Jun 1 07:07:53 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 1 Jun 2017 14:07:53 +0700 Subject: vty talloc report In-Reply-To: <20170531213456.GA22914@my.box> References: <20170531213456.GA22914@my.box> Message-ID: Hi Neels, > If you submitted a patch for it I would probably +vote it. Not yet. > I guess it would actually be a whole bunch of patches, > a common part in libosmocore and using it in each osmo* program? Probably, it would be a whole bunch of patches for osmo* programs only. I was wondering about modifying libosmovty to enable a new VTY command in all projects, like Harald did in osmo-fsm implementation. But in case of FSM, all state machines are being registered before use, so libosmovty "knows" about them. What is impossible in case of talloc contexts right now. Of course, we can write a new function and register every root talloc context using it. What about that? Regarding to the commands to add, I think show ctx all - Show list of all registered talloc contexts. show ctx NAME - Find specified context and call talloc_report_full. With best regards, Vadim Yanitskiy. 2017-06-01 4:34 GMT+07:00 Neels Hofmeyr : > re "what do you guys think about having a special VTY command to get a > talloc report?" > > If you submitted a patch for it I would probably +vote it. I guess it would > actually be a whole bunch of patches, a common part in libosmocore and > using it > in each osmo* program? > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Thu Jun 1 07:48:17 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 1 Jun 2017 14:48:17 +0700 Subject: vty talloc report In-Reply-To: References: <20170531213456.GA22914@my.box> Message-ID: Great news, > Of course, we can write a new function and register every > root talloc context using it. What about that? I just found, that talloc context may be specified in vty_app_info structure: /*! Information an application registers with the VTY */ struct vty_app_info { /*! \brief name of the application */ const char *name; /*! \brief version string of the application */ const char *version; /*! \brief copyright string of the application */ const char *copyright; /*! \brief \ref talloc context */ void *tall_ctx; // ... } But almost all osmo* applications don't set this pointer. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Thu Jun 1 17:02:55 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 1 Jun 2017 19:02:55 +0200 Subject: Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB In-Reply-To: References: <20170529075143.4nsf3hmq6dilsbzv@nataraja> Message-ID: <20170601170255.GE28885@my.box> On Tue, May 30, 2017 at 08:53:56PM -0700, Gerard Lawrence Pinto wrote: > > I'm happy to review it once there is a repo based on the original one > > with change sets to review. We can also move osmo-sim-auth to gerrit so > > you can submit your patches there. osmo-sim-auth is on gerrit already, seems to have been there for a while already. For the record, how to use gerrit: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit osmo-sim-auth patches: https://gerrit.osmocom.org/#/q/project:osmo-sim-auth ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From emily.mcmilin at gmail.com Thu Jun 1 21:32:51 2017 From: emily.mcmilin at gmail.com (emily mcmilin) Date: Thu, 1 Jun 2017 14:32:51 -0700 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: <20170527184325.GD1882@my.box> References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> <20170527184325.GD1882@my.box> Message-ID: Hi Max, Neels, > In case of NITB I > suggest to use net.0.bsc.N.notification-rejection-v1 where N is the number you've > used in your NITB config for bts entry (use 0 if unsure). Is it possible include a programmatic way to test TRAP functionality for osmo-nitb? As I am not clear on what triggers a "notification-rejection-v1", I am unable to verify the TRAP functionality, however I have tried to following: while 1) running bsc_control.py with TRAP option in terminal 1: `vagrant at endaga-client-osmocom:~$ python ~/openbsc/openbsc/contrib/bsc_control.py -m -d localhost -p 4249` 2) blocking a physical phone that was previously connected: a) attaching a phone with the auth policy set as: `auth policy accept-all` b) changing the auth policy to `auth policy closed` and instigating failed attempts to attach the same phone and 3) modifying and then deleting an arbitrary subscriber, which did not appear to be a meaningful test of the issuance of a "notification-rejection-v1" TRAP message, given failure setup noted below: ``` vagrant at endaga-client-osmocom:~$ python ~/openbsc/openbsc/contrib/bsc_control.py -s subscriber-modify-v1 2620345,445566 -d localhost -p 4249 Got message: SET_REPLY 2448569608243303391 subscriber-modify-v1 OK vagrant at endaga-client-osmocom:~$ python ~/openbsc/openbsc/contrib/bsc_control.py -s subscriber-delete-v1 2620345,445566 -d localhost -p 4249 Got message: ERROR 719581889546954682 Failed to find subscriber vagrant at endaga-client-osmocom:~$ ``` Nonetheless, neither produced any TRAP message in terminal 1. Please let me know your thoughts on a including a programmatic way to test TRAP functionality for osmo-nitb. Thanks, Emily From mychaela.falconia at gmail.com Fri Jun 2 06:01:34 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Thu, 1 Jun 2017 22:01:34 -0800 Subject: Creating GSM Users Association (GSMUA) In-Reply-To: <20170529081407.deqbb2gdycpcf7uf@nataraja> References: <20170529081407.deqbb2gdycpcf7uf@nataraja> Message-ID: Hi Harald, Thank you for taking the time to respond to my GSMUA idea. I agree with you that representing the interests of users at GSMA/ETSI/3GPP would a task beyond our means, but I still see social value in creating our own totally informal group purely for mutual support and camaraderie. Throughout human history members of various oppressed minorities have banded together for mutual support, even if that support is purely emotional and nothing more, and I am currently experiencing an unmet need for such a group with regard to GSM/2G. > Regarding your proposal: It seems like a contradiction in terms to me if > you establish something called an 'user association' while your interest > is (at least partially) to represent "boutique manufacturers" regarding > IMEI allocations. My idea of a recycled IMEI registry was just one potential application for GSMUA, and the overall idea of GSMUA still appeals to me even if we don't pursue the recycled IMEI registry idea. As for representing boutique manufacturers of end user devices in a user association alongside with actual end users, I don't see much of a contradiction, as the interests of the two are expected to coincide. Boutique manufacturers are fundamentally different from mainstream ones: while mainstream manufs act as users' enemies for all practical purposes (they prefer to serve the interests of carriers and/or governments instead, and their entire "security" model sees the user as the enemy), boutique manufs exist for no purpose except to serve the interests of underrepresented end users, and given that FLOSS development typically proceeds by scratching one's own itch, a real-life boutique manuf of GSM devices will almost certainly make those devices for his or her own personal use first and foremost, and then offer them for sale in extremely small volume to others of a like mind. In my original proposal I outlined the following list of parties whom I see as the target audience for my proposed GSMUA: * Empowered end users; * Small boutique manufacturers for devices for said empowered end users; * Small community and other non-mainstream network operators, i.e., those who operate networks for the empowered end users and their FLOSS devices to connect to. A key goal of GSMUA is to be a truly neutral meeting ground where all of the above can come together, with everyone being equally welcome regardless of specific project affiliation, if any. The closest thing that exists so far where all kinds of different people with an interest in cellular telephony can come together are your OsmoCon and OsmoDevCon get-togethers, but those are limited to projects that fall under the Osmocom umbrella, and do not include non-Osmocom projects in the same general space. My vision for GSMUA is to be more inclusive and more neutral, a place where people from Osmocom, FreeCalypso, OpenBTS, YateBTS and others (as well as just persons who are simply interested in the general subject matter, but not affiliated or involved with any specific project) can come together (at least online if not physically) without any of them being in a dominant position. The very fact that this discussion we are having right now has to be cross-posted to 3 different mailing lists is an indication of the problem which my GSMUA proposal is meant to solve: there presently exists no truly neutral, truly general community mailing list where *everyone* with an interest in non-big-bucks GSM and other cellular networks can interact with others in the same field, regardless of whether their specific interest is in running their own network, making their own end user phones, or just using one or both of those as a highly intelligent, highly empowered end user, and without being specific to any one particular project. One specific reason why I feel there is a need for people on the empowered-end-user mobile device side to meet with people on the network infrastructure and network operations side is the imminent threat of GSM/2G shutdown by the uncaring major network operators. There exist people in the world, myself included, for whom life without GSM/2G would be absolutely intolerable, as GSM/2G is the only cellular technology for which there exist practically usable FLOSS implementations on the MS/UE side. In both USA and Canada there is only one GSM/2G operator left, and if T-Mobile USA and Rogers completely shut down their GSM/2G networks in another year or two, and reallocate every last 200 kHz channel in both 1900 and 850 MHz bands to their stinking 3G/4G/whatever services so no one else can set up replacement community networks, users of Calypso phones will be completely screwed. This is where people in the OpenBTS/OpenBSC/etc projects can come to the rescue. As I understand it, there are both commercial and community operators who run their own GSM/2G networks using BTS hardware and software built and maintained by the Osmocom/OpenBTS/etc community, and because of the imminent shutdown of GSM/2G services in "first world" regions, I feel that a bridge needs to be built ASAP between users of 2G-only Calypso phones on one end and those non-mainstream community network operators on the other end. To put it simply, if the evil first world governments take away the last remaining bit of spectrum from GSM/2G users, we (the latter users) need to know which remote third world village we should flee to where we can set up our own OpenBTS/OpenBSC/OsmoNITB/etc GSM/2G network without having radio regulators show up with tanks the next morning to shut it down, or where such a community network already exists. To put the matter in perspective, I will be giving a presentation about FreeCalypso at REcon in Montreal just two weeks from now, and the subject of imminent GSM/2G shutdown will be unavoidable. Unless there exists another person in the world who is as crazy as me and who would be willing and able to carry out a project similar to FreeCalypso, but using leaked Qualcomm or MTK sources for some 3G-capable or even LTE-capable chip instead of TI's 2G-only ones (seems rather unlikely to me that anyone else can be insane enough to do such a thing), creating a GSM village in some remote 3rd world location that would welcome refugees from the "first world" fleeing from 3G/4G tyranny seems like the most proper solution which I should advocate for. M~ From apaijmans at gmail.com Fri Jun 2 06:28:36 2017 From: apaijmans at gmail.com (Albert Paijmans) Date: Fri, 2 Jun 2017 08:28:36 +0200 Subject: ipaccess 1800/1900 model Message-ID: Hello, In the Netherlands the free gsm channel for private gsm networks is; 1875 - 1879,9 MHz 200 mW e.r.p. 200 kHz 875 - 1879,8 MHz 50 mW/MHz e.r.p. ?4,5 MHz But I am a little bit confused as to how to set up an ipacces nanobts with those frequencies In OsmoBTS configuration file find bts 0 and set band to GSM1800 Also set frequencies to right value arfcn The example says ( https://osmocom.org/projects/openbsc/wiki/Multi-BTS_with_handover) trx 0 rf_locked 0 arfcn 74 ... trx 1 rf_locked 0 arfcn 84 --------------- I am not sure what to put at arfcn as the correct frequency with the mentioned frequency.. A second question, the nanoBTS comes in 1800 for GSM1800, and GSM1900 variant thereof (almost identical hardware) Well I can get 2 of the 1900 version very cheap from the USA but setting the configuration file bts 0 band GSM1800 won?t change the frequeny of the 1900 model to 1800MHz? Or can I only use the 1900 version in the free 1900MHz DECT frequency range? I have attached the official document of the Dutch regulatory body with the allowed frequencies, see page 28 for DECT frequencies in 1900 band and page 29 for picocell frequencies in the 1800 band. To me it seems both bands 1800 and 1900 are allowed, 1800Mhz is the official private gsm but for testing purposes using a 1900 model on the DECT band should be ok to. If the nanobts 1900 US model could also operate on the 1800 band that would be even better. Thanks, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: brochure-vergunningsvrije-radiotoepassingen.pdf Type: application/pdf Size: 230435 bytes Desc: not available URL: From laforge at gnumonks.org Fri Jun 2 08:09:12 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 02 Jun 2017 10:09:12 +0200 Subject: ARFCN calculation (was Re: ipaccess 1800/1900 model) In-Reply-To: References: Message-ID: <774B5837-A69A-43C1-BEF6-62D253E45D28@gnumonks.org> ARFCN is the way how frequencies are expressed in gsm, unrelated to osmocom. You should find an arfcn calculators online. Also, libosmocore includes the osmo-arfcn tool. Regards, Harald -- Sent from a mobile device. Please excuse my brevity. From holger at freyther.de Fri Jun 2 16:17:08 2017 From: holger at freyther.de (Holger Freyther) Date: Sat, 3 Jun 2017 00:17:08 +0800 Subject: libosmo-sccp: Build breakage on --disable-static Message-ID: <48BBCE2F-C3DD-4692-BC1F-0D997AC0DF52@freyther.de> Hi, I just looked into a build breakage when --disable-static is passed. The first failure is because of: libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \ -no-undefined \ -export-symbols-regex '^osmo_' The testcases use xua_* sua_ symbols but they are not exported. Shall we export them or shall we forbid --disable-static on libosmo-sccp? The second part is that I had preferred the sccp library to be static only to avoid having to do proper ABI checking/versioning. If we fix the above, maybe we have to fix this part too? holger From laforge at gnumonks.org Sat Jun 3 08:40:22 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 3 Jun 2017 10:40:22 +0200 Subject: libosmo-sccp: Build breakage on --disable-static In-Reply-To: <48BBCE2F-C3DD-4692-BC1F-0D997AC0DF52@freyther.de> References: <48BBCE2F-C3DD-4692-BC1F-0D997AC0DF52@freyther.de> Message-ID: <20170603084022.s5a7w5glws3w7wjj@nataraja> Hi Holger, On Sat, Jun 03, 2017 at 12:17:08AM +0800, Holger Freyther wrote: > The first failure is because of: > > libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \ > -no-undefined \ > -export-symbols-regex '^osmo_' > > The testcases use xua_* sua_ symbols but they are not exported. Shall > we export them or shall we forbid --disable-static on libosmo-sccp? I actually really liked the idea as an elegant way to have test cases access more "private" / "low-end" functions inside the implementation, while ensuring only proper APIs are exposed to actual applications (which use dynamic libs). I would actually like to use that in all the other libraries / code we have. So yes, the idea can still be bad, but what other option do we have in terms of having more symbols available to test caeses than those used in production? Manually linking the individual .o files is ugly, as the list keeps growing for each and every unit test as the library code evolves. What about having a separate static library only used for the unit tests, and building that even while --disable-static is used? In that case one could even play games like #define STATIC static in production builds, and define it to nothing in the build for unit tests, if needed. > The second part is that I had preferred the sccp library to be static > only to avoid having to do proper ABI checking/versioning. If we fix > the above, maybe we have to fix this part too? I'm not sure why it should be different from all the other libosmo* libraries in that regard? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sat Jun 3 10:22:35 2017 From: holger at freyther.de (Holger Freyther) Date: Sat, 3 Jun 2017 18:22:35 +0800 Subject: libosmo-sccp: Build breakage on --disable-static In-Reply-To: <20170603084022.s5a7w5glws3w7wjj@nataraja> References: <48BBCE2F-C3DD-4692-BC1F-0D997AC0DF52@freyther.de> <20170603084022.s5a7w5glws3w7wjj@nataraja> Message-ID: <7BBC4936-87B0-41F3-931F-A72703788C26@freyther.de> > On 3. Jun 2017, at 16:40, Harald Welte wrote: > > Hi Holger, Hi, > I actually really liked the idea as an elegant way to have test cases > access more "private" / "low-end" functions inside the implementation, > while ensuring only proper APIs are exposed to actual applications > (which use dynamic libs). I would actually like to use that in all the > other libraries / code we have. As time permits I will see if we can get the libtool m4 not generate the --disable-static option or at least error on it. > #define STATIC static > in production builds, and define it to nothing in the build for unit > tests, if needed. yes, something like this is done in Qt when building for testing but I think the setup is complicated for us. >> The second part is that I had preferred the sccp library to be static >> only to avoid having to do proper ABI checking/versioning. If we fix >> the above, maybe we have to fix this part too? > > I'm not sure why it should be different from all the other libosmo* > libraries in that regard? Historically as being one of the first libraries? I had no goal of a clean namespace, API, etc. holger From nhofmeyr at sysmocom.de Sat Jun 3 13:59:27 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 3 Jun 2017 15:59:27 +0200 Subject: osmo-gsm-manuals DRAFT In-Reply-To: <20170514180511.GB24995@my.box> References: <20170514130411.GA24995@my.box> <20170514135302.sli3bovlczr4k4pq@nataraja> <20170514180511.GB24995@my.box> Message-ID: <20170603135927.GB1605@my.box> I was recently annoyed by the DRAFT watermark again when re-configuring a sysmoBTS for the osmo-gsm-tester and trying to paste from the manual. On Sun, May 14, 2017 at 08:05:11PM +0200, Neels Hofmeyr wrote: > Playing around for some minutes, I found these snippets: > > Show "DRAFT" in the document header and drop the watermark: [...] > > I also found a bit of code to put a "DRAFT" on only the first page, but I find > it impossibly hard to figure out how to switch this snippet on and off [...] No ideas anyone to switch on/off a bit of dblatex.sty? We can show "DRAFT" on the first page always, needing manual .sty editing to disable the DRAFT. No-one ever seems to render without the DRAFT watermark anyway. I submitted both as separate patches, https://gerrit.osmocom.org/2838 https://gerrit.osmocom.org/2839 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sat Jun 3 16:55:43 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 3 Jun 2017 18:55:43 +0200 Subject: ipaccess 1800/1900 model In-Reply-To: References: Message-ID: <20170603165543.GD1605@my.box> On Fri, Jun 02, 2017 at 08:28:36AM +0200, Albert Paijmans wrote: > Well I can get 2 of the 1900 version very cheap from the USA but setting > the configuration file bts 0 band GSM1800 won?t change the frequeny of the > 1900 model to 1800MHz? If your hardware is built for the 1900 band, then editing configuration files to mismatching values won't change your hardware. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon Jun 5 17:43:31 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Jun 2017 19:43:31 +0200 Subject: images Message-ID: <20170605174331.GA18635@my.box> People keep posting images to this list. I saw that mailman allows to remove image attachments by file suffix and/or by mime type. I suggest we put jpg, png, bmp on the list of attachments to remove. AFAICT there was zero need for a legitimate image post, and if we'd want to we can always create a wiki page or redmine ticket and attach the image there. It would be nicer to bounce messages with such attachments completely, but dropping the attachments is the next best thing. Opinions? I don't have access to the list admin, so (if we agree) someone else would need to effect this / give me the pw: mailman admin / "MIME-/HTML-Filter" / tick 'yes' on top and add image suffixes to the reject list ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From huanglin.bupt at gmail.com Tue Jun 6 10:09:16 2017 From: huanglin.bupt at gmail.com (Lin HUANG) Date: Tue, 6 Jun 2017 18:09:16 +0800 Subject: Accelerate3g5 Problem in cellphone attach procedure Message-ID: Hello, We met a problem during the cellphone trying to attach to the network. The modules we ran are: Nano femtocell <- LAN -> osmo-hnbgw <--> osmo-msc <--> osmo-hlr. The cellphone with sysmcom USIM searched the network 90170 and then tried to register in it. The authentication was passed but the connection was released. The cellphone automatically repeated the attach again and again, but always failed. In the output of HLR, it seems the authentication is OK: ---------------------- 20170606183004032 DAUC <0003> db_auc.c:222 901700000014922: Generated 5 vectors 20170606183004032 DAUC <0003> db_auc.c:227 901700000014922: Updating SQN=1728 in DB ... 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU RECEIVED 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED -> ISD SENT ---------------------- But in the output of MSC: ---------------------- 20170606183005665 DMM <0002> gsm_04_08.c:3798 <- SECURITY MODE COMPLETE IMSI:901700000014922 ... 20170606183005666 DMM <0002> gsm_04_08.c:201 -> MSISDN:333 LOCATION UPDATE ACCEPT ... 20170606183005666 DMSC <000a> msc_ifaces.c:44 msc_tx 17 bytes to MSISDN:333 via RAN_UTRAN_IU 20170606183005666 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP DT (SUA link 0xcacde0 conn_id 0) 20170606183005666 DSUA <001b> sua.c:506 Received SCCP User Primitive (N-DATArequest) 20170606183005666 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 14 00 1e 00 00 02 00 10 40 12 11 05 02 09 f1 89 28 b6 17 08 99 10 07 00 00 10 94 22 00 3b 40 01 00 00 00 ) 20170606183005666 DVLR <001d> vlr_lu_fsm.c:321 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE 20170606183005666 DVLR <001d> vlr_lu_fsm.c:355 vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT) 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(901700000014922)[0xcd5250] 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Freeing instance 20170606183005666 DVLR <001d> fsm.c:275 lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Deallocated 20170606183005666 DVLR <001d> vlr_lu_fsm.c:700 vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE 20170606183005666 DMM <0002> vlr_lu_fsm.c:692 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: Received Event SUBSCR_CONN_E_ACCEPTED 20170606183005666 DMM <0002> subscr_conn.c:77 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: SUBSCR_CONN_FROM_LU 20170606183005666 DMM <0002> subscr_conn.c:84 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: state_chg to SUBSCR_CONN_S_ACCEPTED 20170606183005668 DMM <0002> subscr_conn.c:132 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: Received Event SUBSCR_CONN_E_BUMP 20170606183005668 DMM <0002> subscr_conn.c:168 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: bump: releasing conn 20170606183005668 DMM <0002> subscr_conn.c:169 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: state_chg to SUBSCR_CONN_S_RELEASED 20170606183005668 DMM <0002> subscr_conn.c:255 Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR) ---------------------- Why is there a 'Received Event SUBSCR_CONN_E_BUMP'? Regards Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Jun 6 11:25:20 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 6 Jun 2017 13:25:20 +0200 Subject: Accelerate3g5 Problem in cellphone attach procedure In-Reply-To: References: Message-ID: <20170606112520.GA14537@my.box> Hi Lin, On Tue, Jun 06, 2017 at 06:09:16PM +0800, Lin HUANG wrote: > In the output of HLR, it seems the authentication is OK: > ---------------------- > 20170606183004032 DAUC <0003> db_auc.c:222 901700000014922: Generated 5 > vectors > 20170606183004032 DAUC <0003> db_auc.c:227 901700000014922: Updating > SQN=1728 in DB > ... > 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU > RECEIVED > 20170606183005665 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED > -> ISD SENT > ---------------------- looks good > But in the output of MSC: > ---------------------- > 20170606183005665 DMM <0002> gsm_04_08.c:3798 <- SECURITY MODE COMPLETE > IMSI:901700000014922 > ... > 20170606183005666 DMM <0002> gsm_04_08.c:201 -> MSISDN:333 LOCATION UPDATE > ACCEPT > ... > 20170606183005666 DMSC <000a> msc_ifaces.c:44 msc_tx 17 bytes to MSISDN:333 > via RAN_UTRAN_IU > 20170606183005666 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP > DT (SUA link 0xcacde0 conn_id 0) > 20170606183005666 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170606183005666 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 14 00 1e > 00 00 02 00 10 40 12 11 05 02 09 f1 89 28 b6 17 08 99 10 07 00 00 10 94 22 > 00 3b 40 01 00 00 00 ) > 20170606183005666 DVLR <001d> vlr_lu_fsm.c:321 > lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: > state_chg to LU_COMPL_VLR_S_DONE > 20170606183005666 DVLR <001d> vlr_lu_fsm.c:355 > vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: Received > Event VLR_ULA_E_LU_COMPL_SUCCESS ^ Location updating is successful at this point. The Finite State Machine for LU is hence torn down: > 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_PARENT) > 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Removing > from parent vlr_lu_fsm(901700000014922)[0xcd5250] > 20170606183005666 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: Freeing > instance > 20170606183005666 DVLR <001d> fsm.c:275 > lu_compl_vlr_fsm(901700000014922)[0xcab580]{LU_COMPL_VLR_S_DONE}: > Deallocated > 20170606183005666 DVLR <001d> vlr_lu_fsm.c:700 > vlr_lu_fsm(901700000014922)[0xcd5250]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg > to VLR_ULA_S_DONE > 20170606183005666 DMM <0002> vlr_lu_fsm.c:692 > Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: Received Event > SUBSCR_CONN_E_ACCEPTED > 20170606183005666 DMM <0002> subscr_conn.c:77 > Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: > SUBSCR_CONN_FROM_LU > 20170606183005666 DMM <0002> subscr_conn.c:84 > Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_NEW}: state_chg to > SUBSCR_CONN_S_ACCEPTED The connection to the phone is now classified as valid and usable. > 20170606183005668 DMM <0002> subscr_conn.co:132 > Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: Received > Event SUBSCR_CONN_E_BUMP > Why is there a 'Received Event SUBSCR_CONN_E_BUMP'? A "bump" event triggers a query whether any jobs are still pending for a connection, like delivering an SMS or somesuch. Typically after a LU there is nothing left to do. The phone is attached but idle: > 20170606183005668 DMM <0002> subscr_conn.c:168 > Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: bump: > releasing conn > 20170606183005668 DMM <0002> subscr_conn.c:169 > Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_ACCEPTED}: state_chg > to SUBSCR_CONN_S_RELEASED > 20170606183005668 DMM <0002> subscr_conn.c:255 > Subscr_Conn(901700000014922)[0xcd22f0]{SUBSCR_CONN_S_RELEASED}: Terminating > (cause = OSMO_FSM_TERM_REGULAR) Indeed nothing left to do, connection is discarded, phone is subscribed and waiting for any events that would create a new connection. So everything looks good from these logs. Cannot tell why this procedure would repeat over and over? Does it? ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Tue Jun 6 13:49:06 2017 From: holger at freyther.de (Holger Freyther) Date: Tue, 6 Jun 2017 21:49:06 +0800 Subject: Accelerate3g5 Problem in cellphone attach procedure In-Reply-To: <20170606112520.GA14537@my.box> References: <20170606112520.GA14537@my.box> Message-ID: <158104AB-03FA-4294-8A59-9C155EE3E77B@freyther.de> > On 6. Jun 2017, at 19:25, Neels Hofmeyr wrote: > > So everything looks good from these logs. Cannot tell why this procedure would > repeat over and over? Does it? Is a TMSI assigned? What is the TMSI? @Lin: Please make a trace of two/three loops and attach it to the mail. holger From renxianyuanqi at gmail.com Wed Jun 7 02:48:16 2017 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Wed, 7 Jun 2017 10:48:16 +0800 Subject: Accelerate3g5 Problem in cellphone attach procedure In-Reply-To: <158104AB-03FA-4294-8A59-9C155EE3E77B@freyther.de> References: <20170606112520.GA14537@my.box> <158104AB-03FA-4294-8A59-9C155EE3E77B@freyther.de> Message-ID: Thanks for the quick reply. >Is a TMSI assigned? What is the TMSI? just fond TMSI at osmo-hnbw's terminal:(0x0 not looks good ) <0001> hnbgw_hnbap.c:386 HNB-REGISTER-REQ from > 000295-0000120574 at ap.ipaccess.com > <0000> context_map.c:139 Running context mapper garbage collection > <0000> context_map.c:139 Running context mapper garbage collection > <0000> context_map.c:139 Running context mapper garbage collection > <0001> hnbap_decoder.c:759 Decoding message UERegisterRequestIEs > (hnbap_decoder.c:759) > <0001> hnbgw_hnbap.c:436 UE-REGISTER-REQ ID_type=1 imsi=901700000014922 > cause=1 > > *<0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014922, > tmsi 0x0*<0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs > (rua_decoder.c:21) > <0003> hnbgw_rua.c:310 RUA Connect.req(ctx=0x17, normal) > <0000> context_map.c:83 Creating new Mapping RUA CTX 0xa67da0/23 <-> SCU > Conn ID 0xa669e0/1000 > <0002> sua.c:506 Received SCCP User Primitive (N-CONNECTrequest) > <0002> sua.c:254 (1000) state chg IDLE->CONN_PEND_OUT > <0002> sua.c:160 sua_link_send(01 00 08 01 00 00 00 84 00 06 00 08 00 00 > 00 00 01 15 00 08 00 00 00 02 01 04 00 08 00 00 03 e8 01 03 00 08 00 02 00 > 07 01 16 00 08 00 00 00 00 01 0b 00 52 00 13 40 4a 00 00 06 00 03 40 01 00 > 00 0f 40 06 00 09 f1 07 28 b6 00 3a 40 08 00 09 f1 07 ff ff ff ff 00 10 40 > 18 17 05 08 70 09 f1 89 ff fe 57 08 99 10 07 00 00 10 94 22 33 03 57 58 a6 > 00 4f 40 03 00 00 17 00 56 40 05 09 f1 07 00 17 00 00 ) more infomation of osmo-hnbg's terminal: <0005> telnet_interface.c:95 telnet at 127.0.0.1 2323 > <0003> hnbgw_cn.c:384 New hnbgw_cnlink 0x1f9a9e0 (gw 0x1f4a1c0): 127.0.0.1 > 14001 CS > <0003> hnbgw_cn.c:384 New hnbgw_cnlink 0x1f9b8a0 (gw 0x1f4a1c0): 127.0.0.1 > 14001 PS > <0000> hnbgw.c:524 Listening for Iuh at 192.168.31.147 29169 > <0000> context_map.c:139 Running context mapper garbage collection > <0001> hnbap_decoder.c:305 Decoding message HNBRegisterRequestIEs > (hnbap_decoder.c:305) > <0001> hnbgw_hnbap.c:386 HNB-REGISTER-REQ from > 000295-0000120574 at ap.ipaccess.com > <0000> context_map.c:139 Running context mapper garbage collection > <0000> context_map.c:139 Running context mapper garbage collection > <0000> context_map.c:139 Running context mapper garbage collection > <0000> context_map.c:139 Running context mapper garbage collection > <0001> hnbap_decoder.c:759 Decoding message UERegisterRequestIEs > (hnbap_decoder.c:759) > <0001> hnbgw_hnbap.c:436 UE-REGISTER-REQ ID_type=1 imsi=901700000014922 > cause=1 > <0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014922, tmsi > 0x0 > <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21) > <0003> hnbgw_rua.c:310 RUA Connect.req(ctx=0x17, normal) > <0000> context_map.c:83 Creating new Mapping RUA CTX 0x1f9bda0/23 <-> SCU > Conn ID 0x1f9a9e0/1000 > <0002> sua.c:506 Received SCCP User Primitive (N-CONNECTrequest) > <0002> sua.c:254 (1000) state chg IDLE->CONN_PEND_OUT > <0002> sua.c:160 sua_link_send(01 00 08 01 00 00 00 84 00 06 00 08 00 00 > 00 00 01 15 00 08 00 00 00 02 01 04 00 08 00 00 03 e8 01 03 00 08 00 02 00 > 07 01 16 00 08 00 00 00 00 01 0b 00 52 00 13 40 4a 00 00 06 00 03 40 01 00 > 00 0f 40 06 00 09 f1 07 28 b6 00 3a 40 08 00 09 f1 07 ff ff ff ff 00 10 40 > 18 17 05 08 70 09 f1 89 ff fe 57 08 99 10 07 00 00 10 94 22 33 03 57 58 a6 > 00 4f 40 03 00 00 17 00 56 40 05 09 f1 07 00 17 00 00 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:2) > <0002> sua.c:254 (1000) state chg CONN_PEND_OUT->ACTIVE > <0000> hnbgw_cn.c:337 sccp_sap_up(N-CONNECTconfirm) > <0000> hnbgw_cn.c:269 handle_cn_conn_conf() conn_id=1000 > <0000> hnbgw_cn.c:271 handle_cn_conn_conf() called_addr=0.0.0.0 > <0000> hnbgw_cn.c:273 handle_cn_conn_conf() calling_addr=0.0.0.0 > <0000> hnbgw_cn.c:275 handle_cn_conn_conf() responding_addr=0.0.0.0 > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 78 bytes > <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21) > <0003> hnbgw_rua.c:310 RUA Connect.req(ctx=0x17, normal) > <0000> context_map.c:83 Creating new Mapping RUA CTX 0x1f9bda0/23 <-> SCU > Conn ID 0x1f9b8a0/1000 > <0002> sua.c:506 Received SCCP User Primitive (N-CONNECTrequest) > <0002> sua.c:254 (1000) state chg IDLE->CONN_PEND_OUT > <0002> sua.c:160 sua_link_send(01 00 08 01 00 00 00 b0 00 06 00 08 00 00 > 00 00 01 15 00 08 00 00 00 02 01 04 00 08 00 00 03 e8 01 03 00 08 00 02 00 > 07 01 16 00 08 00 00 00 00 01 0b 00 7e 00 13 40 76 00 00 07 00 03 40 01 80 > 00 0f 40 06 00 09 f1 07 28 b6 00 37 40 01 63 00 3a 40 08 00 09 f1 07 ff ff > ff ff 00 10 40 3f 3e 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 > ff ff 00 ff fe ff 1a 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 > e8 c4 b1 98 87 91 00 26 17 05 58 04 e0 60 c0 40 5d 01 00 00 4f 40 03 00 00 > 17 00 56 40 05 09 f1 07 00 17 00 00 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:2) > <0002> sua.c:254 (1000) state chg CONN_PEND_OUT->ACTIVE > <0000> hnbgw_cn.c:337 sccp_sap_up(N-CONNECTconfirm) > <0000> hnbgw_cn.c:269 handle_cn_conn_conf() conn_id=1000 > <0000> hnbgw_cn.c:271 handle_cn_conn_conf() called_addr=0.0.0.0 > <0000> hnbgw_cn.c:273 handle_cn_conn_conf() calling_addr=0.0.0.0 > <0000> hnbgw_cn.c:275 handle_cn_conn_conf() responding_addr=0.0.0.0 > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 34 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 00 01 0b 00 1c 00 14 40 14 00 00 01 00 10 40 0d > 0c 05 54 eb f4 45 4c 21 04 a9 b6 87 20 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 58 bytes > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 28 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 00 01 0b 00 10 20 06 00 08 00 00 01 00 06 00 01 > 00 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 44 bytes > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 58 bytes > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 37 bytes > <0000> rua_decoder.c:121 Decoding message RUA_DisconnectIEs > (rua_decoder.c:121) > <0003> hnbgw_rua.c:340 RUA Disconnect.req(ctx=0x17,cause=radio(normal)) > <0002> sua.c:506 Received SCCP User Primitive (N-DISCONNECTrequest) > <0002> sua.c:254 (1000) state chg ACTIVE->DISCONN_PEND > <0002> sua.c:470 About to send the SUA RELRE > <0002> sua.c:160 sua_link_send(01 00 08 04 00 00 00 34 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 00 01 04 00 08 00 00 03 e8 01 06 00 08 00 00 00 > 00 01 0b 00 0b 20 01 00 03 00 00 00 00 ) > <0000> context_map.c:139 Running context mapper garbage collection > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 84 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 00 01 0b 00 69 00 14 40 61 00 00 04 00 10 40 3f > 3e 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 ff ff 00 ff fe ff > 1a 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 e8 c4 b1 98 87 91 > 00 26 17 05 58 04 e0 60 c0 40 5d 01 00 00 0f 40 06 00 09 f1 07 28 b6 00 37 > 40 01 63 00 3a 40 08 00 09 f1 07 ff ff ff ff 00 00 00 ) > <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21) > <0003> hnbgw_rua.c:310 RUA Connect.req(ctx=0x17, normal) > <0002> sua.c:506 Received SCCP User Primitive (N-CONNECTrequest) > <0002> sua.c:254 (1000) state chg IDLE->CONN_PEND_OUT > <0002> sua.c:160 sua_link_send(01 00 08 01 00 00 00 84 00 06 00 08 00 00 > 00 00 01 15 00 08 00 00 00 02 01 04 00 08 00 00 03 e8 01 03 00 08 00 02 00 > 07 01 16 00 08 00 00 00 00 01 0b 00 52 00 13 40 4a 00 00 06 00 03 40 01 00 > 00 0f 40 06 00 09 f1 07 28 b6 00 3a 40 08 00 09 f1 07 ff ff ff ff 00 10 40 > 18 17 05 08 70 09 f1 89 ff fe 57 08 99 10 07 00 00 10 94 22 33 03 57 58 a6 > 00 4f 40 03 00 00 17 00 56 40 05 09 f1 07 00 17 00 00 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:2) > <0002> sua.c:254 (1000) state chg CONN_PEND_OUT->ACTIVE > <0000> hnbgw_cn.c:337 sccp_sap_up(N-CONNECTconfirm) > <0000> hnbgw_cn.c:269 handle_cn_conn_conf() conn_id=1000 > <0000> hnbgw_cn.c:271 handle_cn_conn_conf() called_addr=0.0.0.0 > <0000> hnbgw_cn.c:273 handle_cn_conn_conf() calling_addr=0.0.0.0 > <0000> hnbgw_cn.c:275 handle_cn_conn_conf() responding_addr=0.0.0.0 > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 78 bytes > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 34 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 01 01 0b 00 1c 00 14 40 14 00 00 01 00 10 40 0d > 0c 05 54 9e 44 9d 77 21 04 8a 42 ee ac ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 58 bytes > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 28 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 01 01 0b 00 10 20 06 00 08 00 00 01 00 06 00 01 > 00 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 44 bytes > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 58 bytes > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 37 bytes > <0000> rua_decoder.c:121 Decoding message RUA_DisconnectIEs > (rua_decoder.c:121) > <0003> hnbgw_rua.c:340 RUA Disconnect.req(ctx=0x17,cause=radio(normal)) > <0002> sua.c:506 Received SCCP User Primitive (N-DISCONNECTrequest) > <0002> sua.c:254 (1000) state chg ACTIVE->DISCONN_PEND > <0002> sua.c:470 About to send the SUA RELRE > <0002> sua.c:160 sua_link_send(01 00 08 04 00 00 00 34 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 01 01 04 00 08 00 00 03 e8 01 06 00 08 00 00 00 > 00 01 0b 00 0b 20 01 00 03 00 00 00 00 ) > <0000> context_map.c:139 Running context mapper garbage collection > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 84 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 00 01 0b 00 69 00 14 40 61 00 00 04 00 10 40 3f > 3e 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 ff ff 00 ff fe ff > 1a 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 e8 c4 b1 98 87 91 > 00 26 17 05 58 04 e0 60 c0 40 5d 01 00 00 0f 40 06 00 09 f1 07 28 b6 00 37 > 40 01 63 00 3a 40 08 00 09 f1 07 ff ff ff ff 00 00 00 ) > <0000> rua_decoder.c:21 Decoding message RUA_ConnectIEs (rua_decoder.c:21) > <0003> hnbgw_rua.c:310 RUA Connect.req(ctx=0x17, normal) > <0002> sua.c:506 Received SCCP User Primitive (N-CONNECTrequest) > <0002> sua.c:254 (1000) state chg IDLE->CONN_PEND_OUT > <0002> sua.c:160 sua_link_send(01 00 08 01 00 00 00 84 00 06 00 08 00 00 > 00 00 01 15 00 08 00 00 00 02 01 04 00 08 00 00 03 e8 01 03 00 08 00 02 00 > 07 01 16 00 08 00 00 00 00 01 0b 00 52 00 13 40 4a 00 00 06 00 03 40 01 00 > 00 0f 40 06 00 09 f1 07 28 b6 00 3a 40 08 00 09 f1 07 ff ff ff ff 00 10 40 > 18 17 05 08 70 09 f1 89 ff fe 57 08 99 10 07 00 00 10 94 22 33 03 57 58 a6 > 00 4f 40 03 00 00 17 00 56 40 05 09 f1 07 00 17 00 00 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:2) > <0002> sua.c:254 (1000) state chg CONN_PEND_OUT->ACTIVE > <0000> hnbgw_cn.c:337 sccp_sap_up(N-CONNECTconfirm) > <0000> hnbgw_cn.c:269 handle_cn_conn_conf() conn_id=1000 > <0000> hnbgw_cn.c:271 handle_cn_conn_conf() called_addr=0.0.0.0 > <0000> hnbgw_cn.c:273 handle_cn_conn_conf() calling_addr=0.0.0.0 > <0000> hnbgw_cn.c:275 handle_cn_conn_conf() responding_addr=0.0.0.0 > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 78 bytes > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 34 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 02 01 0b 00 1c 00 14 40 14 00 00 01 00 10 40 0d > 0c 05 54 e5 d3 56 43 21 04 98 c6 f8 13 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 58 bytes > <0000> rua_decoder.c:307 Decoding message RUA_DirectTransferIEs > (rua_decoder.c:307) > <0003> hnbgw_rua.c:386 RUA Data.req(ctx=0x17) > <0002> sua.c:506 Received SCCP User Primitive (N-DATArequest) > <0002> sua.c:160 sua_link_send(01 00 08 08 00 00 00 28 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 02 01 0b 00 10 20 06 00 08 00 00 01 00 06 00 01 > 00 ) > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 44 bytes > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 58 bytes > <0002> sua.c:1410 sua_cli_read_cb() rx > <0002> sua.c:1146 Received SUA Message (8:8) > <0000> hnbgw_cn.c:337 sccp_sap_up(N-DATAindication) > <0003> hnbgw_rua.c:113 transmitting RUA (cn=cs) payload of 37 bytes > <0000> rua_decoder.c:121 Decoding message RUA_DisconnectIEs > (rua_decoder.c:121) > <0003> hnbgw_rua.c:340 RUA Disconnect.req(ctx=0x17,cause=radio(normal)) > <0002> sua.c:506 Received SCCP User Primitive (N-DISCONNECTrequest) > <0002> sua.c:254 (1000) state chg ACTIVE->DISCONN_PEND > <0002> sua.c:470 About to send the SUA RELRE > <0002> sua.c:160 sua_link_send(01 00 08 04 00 00 00 34 00 06 00 08 00 00 > 00 00 01 05 00 08 00 00 00 02 01 04 00 08 00 00 03 e8 01 06 00 08 00 00 00 > 00 01 0b 00 0b 20 01 00 03 00 00 00 00 ) Information of osmo-hlr's terminal: 20170607111159419 DDB <0001> db.c:121 SQlite3 compiled with 'SYSTEM_MALLOC' > 20170607111159419 DDB <0001> db.c:121 SQlite3 compiled with 'TEMP_STORE=1' > 20170607111159419 DDB <0001> db.c:121 SQlite3 compiled with 'THREADSAFE=1' > 20170607111159419 DDB <0001> db.c:130 Unable to set SQlite3 SQL statement > log callback > 20170607111159422 DLCTRL <000b> control_if.c:789 CTRL at 127.0.0.1 4259 > 20170607111212128 DLINP <0006> input/ipa.c:263 accept()ed new link from > 127.0.0.1 to port 2222 > 20170607111212128 DLGSUP <000e> gsup_server.c:273 New GSUP client > 127.0.0.1:37150 (IND=0) > 20170607111212174 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111212174 DLINP <0006> input/ipa.c:338 message received > 20170607111212174 DLGSUP <000e> gsup_server.c:180 CCM Callback > 20170607111212174 DLGSUP <000e> gsup_server.c:136 0: MSC-00-00-00-00-00-00 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 0: 4d 53 43 2d 30 30 2d > 30 30 2d 30 30 2d 30 30 2d 30 30 2d 30 30 00 00 > 20170607111212174 DLGSUP <000e> gsup_server.c:136 1: MSC-00-00-00-00-00-00 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 1: 4d 53 43 2d 30 30 2d > 30 30 2d 30 30 2d 30 30 2d 30 30 2d 30 30 00 00 > 20170607111212174 DLGSUP <000e> gsup_server.c:136 2: 00:00:00:00:00:00 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 2: 30 30 3a 30 30 3a 30 > 30 3a 30 30 3a 30 30 3a 30 30 00 00 > 20170607111212174 DLGSUP <000e> gsup_server.c:136 3: 00:00:00:00:00:00 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 3: 30 30 3a 30 30 3a 30 > 30 3a 30 30 3a 30 30 3a 30 30 00 00 > 20170607111212174 DLGSUP <000e> gsup_server.c:136 4: 00:00:00:00:00:00 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 4: 30 30 3a 30 30 3a 30 > 30 3a 30 30 3a 30 30 3a 30 30 00 00 > 20170607111212174 DLGSUP <000e> gsup_server.c:136 5: 00:00:00:00:00:00 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 5: 30 30 3a 30 30 3a 30 > 30 3a 30 30 3a 30 30 3a 30 30 00 00 > 20170607111212174 DLGSUP <000e> gsup_server.c:136 7: 00:00:00:00:00:00 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 7: 30 30 3a 30 30 3a 30 > 30 3a 30 30 3a 30 30 3a 30 30 00 00 > 20170607111212174 DLGSUP <000e> gsup_server.c:136 8: 0/0/0 > 20170607111212174 DLGSUP <000e> gsup_server.c:139 8: 30 2f 30 2f 30 00 00 > 20170607111212174 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111212174 DLINP <0006> input/ipa.c:338 message received > 20170607111212174 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111212174 DLINP <0006> input/ipa.c:338 message received > 20170607111232178 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111232178 DLINP <0006> input/ipa.c:338 message received > 20170607111252181 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111252181 DLINP <0006> input/ipa.c:338 message received > 20170607111312182 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111312182 DLINP <0006> input/ipa.c:338 message received > 20170607111332185 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111332185 DLINP <0006> input/ipa.c:338 message received > 20170607111352190 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111352190 DLINP <0006> input/ipa.c:338 message received > 20170607111412191 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111412191 DLINP <0006> input/ipa.c:338 message received > 20170607111412656 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111412656 DLINP <0006> input/ipa.c:338 message received > 20170607111412656 DAUC <0003> db_auc.c:132 901700000014922: No 2G Auth Data > 20170607111412656 DAUC <0003> db_auc.c:213 901700000014922: Calling to > generate 5 vectors > 20170607111412657 DAUC <0003> auc.c:94 Computing 5 auth vectors: 3G only > (2G derived from 3G keys) > 20170607111412657 DAUC <0003> auc.c:96 3G: k = > 391b2415c07960489e95b8252d6891f2 > 20170607111412657 DAUC <0003> auc.c:99 3G: opc = > a5eebf53f188b2ecec18b859f9cf5580 > 20170607111412658 DAUC <0003> auc.c:101 3G: for sqn ind 0, previous sqn > was 1120 > 20170607111412658 DAUC <0003> auc.c:113 vector [0]: rand = > 290b278eb6e75a9b24fb3b7429e95cb7 > 20170607111412658 DAUC <0003> auc.c:137 vector [0]: sqn = 1152 > 20170607111412658 DAUC <0003> auc.c:139 vector [0]: autn = > 7c95667233b700001b73c31408df68fb > 20170607111412658 DAUC <0003> auc.c:140 vector [0]: ck = > 47bb3655ac0629fec010770793df18d4 > 20170607111412658 DAUC <0003> auc.c:141 vector [0]: ik = > 4d399f123a1b076ef101e7917eed0583 > 20170607111412659 DAUC <0003> auc.c:142 vector [0]: res = > 182cf6be6f989d490000000000000000 > 20170607111412659 DAUC <0003> auc.c:143 vector [0]: res_len = 8 > 20170607111412659 DAUC <0003> auc.c:147 vector [0]: kc = 3b9339d17b2f33c7 > 20170607111412659 DAUC <0003> auc.c:148 vector [0]: sres = 77b46bf7 > 20170607111412659 DAUC <0003> auc.c:149 vector [0]: auth_types = 0x3 > 20170607111412659 DAUC <0003> auc.c:113 vector [1]: rand = > 186da8712a3f88c5aff10237fe90ea4c > 20170607111412659 DAUC <0003> auc.c:137 vector [1]: sqn = 1184 > 20170607111412659 DAUC <0003> auc.c:139 vector [1]: autn = > c2710a1dbca200008976bba9ce298421 > 20170607111412659 DAUC <0003> auc.c:140 vector [1]: ck = > 563e4709816f7ef2ca4710545618dad2 > 20170607111412659 DAUC <0003> auc.c:141 vector [1]: ik = > e06a9d0be16b41f46e391a22abaae180 > 20170607111412659 DAUC <0003> auc.c:142 vector [1]: res = > 075ae0614ba2aba00000000000000000 > 20170607111412659 DAUC <0003> auc.c:143 vector [1]: res_len = 8 > 20170607111412659 DAUC <0003> auc.c:147 vector [1]: kc = 122ad0749db60454 > 20170607111412659 DAUC <0003> auc.c:148 vector [1]: sres = 4cf84bc1 > 20170607111412659 DAUC <0003> auc.c:149 vector [1]: auth_types = 0x3 > 20170607111412660 DAUC <0003> auc.c:113 vector [2]: rand = > 51771b9b3e5abd58695212ba5f6ca671 > 20170607111412661 DAUC <0003> auc.c:137 vector [2]: sqn = 1216 > 20170607111412661 DAUC <0003> auc.c:139 vector [2]: autn = > c63f8b297caa00006196230e87e206d2 > 20170607111412661 DAUC <0003> auc.c:140 vector [2]: ck = > b23561961fb11061f81eb77663a298e7 > 20170607111412661 DAUC <0003> auc.c:141 vector [2]: ik = > a08659c7f95ebbabe146b4f07e5d58ea > 20170607111412661 DAUC <0003> auc.c:142 vector [2]: res = > bd280358a90242960000000000000000 > 20170607111412661 DAUC <0003> auc.c:143 vector [2]: res_len = 8 > 20170607111412661 DAUC <0003> auc.c:147 vector [2]: kc = 0beb3bd7fb106bc7 > 20170607111412661 DAUC <0003> auc.c:148 vector [2]: sres = 142a41ce > 20170607111412661 DAUC <0003> auc.c:149 vector [2]: auth_types = 0x3 > 20170607111412661 DAUC <0003> auc.c:113 vector [3]: rand = > 16dd6cc60a08c61911cd883acc3a1798 > 20170607111412661 DAUC <0003> auc.c:137 vector [3]: sqn = 1248 > 20170607111412661 DAUC <0003> auc.c:139 vector [3]: autn = > c8e9d51a3afe0000841b2b7099686e74 > 20170607111412661 DAUC <0003> auc.c:140 vector [3]: ck = > 1545e8a0784bf1d758481b6458184ae2 > 20170607111412662 DAUC <0003> auc.c:141 vector [3]: ik = > ab1b0f90e950c8c6a0a69833073abe29 > 20170607111412662 DAUC <0003> auc.c:142 vector [3]: res = > 3ac465b434a83d920000000000000000 > 20170607111412662 DAUC <0003> auc.c:143 vector [3]: res_len = 8 > 20170607111412662 DAUC <0003> auc.c:147 vector [3]: kc = 46b06467ce39cdda > 20170607111412662 DAUC <0003> auc.c:148 vector [3]: sres = 0e6c5826 > 20170607111412662 DAUC <0003> auc.c:149 vector [3]: auth_types = 0x3 > 20170607111412662 DAUC <0003> auc.c:113 vector [4]: rand = > 35efb31811ae05eaad714917cf47e36b > 20170607111412662 DAUC <0003> auc.c:137 vector [4]: sqn = 1280 > 20170607111412662 DAUC <0003> auc.c:139 vector [4]: autn = > fca3d2b6002d000007849341c354ad86 > 20170607111412662 DAUC <0003> auc.c:140 vector [4]: ck = > f6e8d9fbef692fd189d1be5b0a0b9a4e > 20170607111412663 DAUC <0003> auc.c:141 vector [4]: ik = > 431b11384acf193873f2295eabe06c65 > 20170607111412663 DAUC <0003> auc.c:142 vector [4]: res = > 895122651358edcf0000000000000000 > 20170607111412663 DAUC <0003> auc.c:143 vector [4]: res_len = 8 > 20170607111412663 DAUC <0003> auc.c:147 vector [4]: kc = 4fd05fc6044dc0c2 > 20170607111412663 DAUC <0003> auc.c:148 vector [4]: sres = 9a09cfaa > 20170607111412663 DAUC <0003> auc.c:149 vector [4]: auth_types = 0x3 > 20170607111412663 DAUC <0003> db_auc.c:222 901700000014922: Generated 5 > vectors > 20170607111412663 DAUC <0003> db_auc.c:227 901700000014922: Updating > SQN=1280 in DB > 20170607111412666 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111412666 DLINP <0006> input/ipa.c:366 sending data > 20170607111412667 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111412667 DLINP <0006> input/ipa.c:366 sending data > 20170607111413200 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111413200 DLINP <0006> input/ipa.c:338 message received > 20170607111413200 DAUC <0003> db_auc.c:132 901700000014922: No 2G Auth Data > 20170607111413200 DAUC <0003> db_auc.c:213 901700000014922: Calling to > generate 5 vectors > 20170607111413200 DAUC <0003> auc.c:94 Computing 5 auth vectors: 3G only > (2G derived from 3G keys), with AUTS resync > 20170607111413200 DAUC <0003> auc.c:96 3G: k = > 391b2415c07960489e95b8252d6891f2 > 20170607111413200 DAUC <0003> auc.c:99 3G: opc = > a5eebf53f188b2ecec18b859f9cf5580 > 20170607111413200 DAUC <0003> auc.c:101 3G: for sqn ind 0, previous sqn > was 1280 > 20170607111413200 DAUC <0003> auc.c:113 vector [0]: rand = > cf9812f4bbc3c790bf44fd9113a7ba43 > 20170607111413200 DAUC <0003> auc.c:122 vector [0]: resync: auts = > 97be1c1a6065138ef453cf3339d4 > 20170607111413200 DAUC <0003> auc.c:124 vector [0]: resync: rand_auts = > 290b278eb6e75a9b24fb3b7429e95cb7 > 20170607111413201 DAUC <0003> auc.c:137 vector [0]: sqn = 1632 > 20170607111413201 DAUC <0003> auc.c:139 vector [0]: autn = > 29a7a580b3750000e3b863d44b4d284c > 20170607111413201 DAUC <0003> auc.c:140 vector [0]: ck = > 0f1845cdc17567ec2f9a3d9f9fddf557 > 20170607111413201 DAUC <0003> auc.c:141 vector [0]: ik = > 0535fb7ba013c2695d5d2dc8149ddb2f > 20170607111413201 DAUC <0003> auc.c:142 vector [0]: res = > 5eecdce81488a78a0000000000000000 > 20170607111413201 DAUC <0003> auc.c:143 vector [0]: res_len = 8 > 20170607111413201 DAUC <0003> auc.c:147 vector [0]: kc = 78eaaee1ea268bfd > 20170607111413201 DAUC <0003> auc.c:148 vector [0]: sres = 4a647b62 > 20170607111413201 DAUC <0003> auc.c:149 vector [0]: auth_types = 0x3 > 20170607111413201 DAUC <0003> auc.c:113 vector [1]: rand = > 8106dd5bcd141db96401d17e5aa960ed > 20170607111413201 DAUC <0003> auc.c:137 vector [1]: sqn = 1664 > 20170607111413201 DAUC <0003> auc.c:139 vector [1]: autn = > 411360a06a71000004f4b5034857c3f5 > 20170607111413201 DAUC <0003> auc.c:140 vector [1]: ck = > 734241fc87a2f22ef176b48ad660f729 > 20170607111413201 DAUC <0003> auc.c:141 vector [1]: ik = > 786836d05d74c64d4c1f41b69bf704d2 > 20170607111413201 DAUC <0003> auc.c:142 vector [1]: res = > c6fa36f4d713eb8d0000000000000000 > 20170607111413201 DAUC <0003> auc.c:143 vector [1]: res_len = 8 > 20170607111413201 DAUC <0003> auc.c:147 vector [1]: kc = b64382109741c798 > 20170607111413201 DAUC <0003> auc.c:148 vector [1]: sres = 11e9dd79 > 20170607111413201 DAUC <0003> auc.c:149 vector [1]: auth_types = 0x3 > 20170607111413201 DAUC <0003> auc.c:113 vector [2]: rand = > 5fde1572c3b22f2c706469c42c4ecd4d > 20170607111413201 DAUC <0003> auc.c:137 vector [2]: sqn = 1696 > 20170607111413201 DAUC <0003> auc.c:139 vector [2]: autn = > f978984c431500001cf507b50c5c75cd > 20170607111413201 DAUC <0003> auc.c:140 vector [2]: ck = > 95feed87ffd50147a2a659eb46da6505 > 20170607111413201 DAUC <0003> auc.c:141 vector [2]: ik = > 4cb0b22594be10a2d6a6c41fdcbe1f04 > 20170607111413201 DAUC <0003> auc.c:142 vector [2]: res = > 55fbe73d8d5848cd0000000000000000 > 20170607111413201 DAUC <0003> auc.c:143 vector [2]: res_len = 8 > 20170607111413201 DAUC <0003> auc.c:147 vector [2]: kc = ad4ec256f10f6be4 > 20170607111413201 DAUC <0003> auc.c:148 vector [2]: sres = d8a3aff0 > 20170607111413201 DAUC <0003> auc.c:149 vector [2]: auth_types = 0x3 > 20170607111413201 DAUC <0003> auc.c:113 vector [3]: rand = > 76f2ed2dec6cd2d278cdce8baff6830f > 20170607111413201 DAUC <0003> auc.c:137 vector [3]: sqn = 1728 > 20170607111413201 DAUC <0003> auc.c:139 vector [3]: autn = > c941e4394e8100004895877c9ce5690e > 20170607111413201 DAUC <0003> auc.c:140 vector [3]: ck = > 24f560a505e6a9f604f50d435d2185f7 > 20170607111413201 DAUC <0003> auc.c:141 vector [3]: ik = > e1fd4fc66b6666dc48762d54d0353103 > 20170607111413201 DAUC <0003> auc.c:142 vector [3]: res = > b813fb6b2f3c35170000000000000000 > 20170607111413201 DAUC <0003> auc.c:143 vector [3]: res_len = 8 > 20170607111413201 DAUC <0003> auc.c:147 vector [3]: kc = 898b0f74e3947bde > 20170607111413201 DAUC <0003> auc.c:148 vector [3]: sres = 972fce7c > 20170607111413201 DAUC <0003> auc.c:149 vector [3]: auth_types = 0x3 > 20170607111413201 DAUC <0003> auc.c:113 vector [4]: rand = > c06a0678c8c1dc7f8022aa2114e0ebd8 > 20170607111413201 DAUC <0003> auc.c:137 vector [4]: sqn = 1760 > 20170607111413201 DAUC <0003> auc.c:139 vector [4]: autn = > d8040bdc675e000058d87e4b146cc15d > 20170607111413201 DAUC <0003> auc.c:140 vector [4]: ck = > 40e4c154fad0783526f5ffd843cf696c > 20170607111413201 DAUC <0003> auc.c:141 vector [4]: ik = > bc13071980796eb3be6a1e9f8061f648 > 20170607111413201 DAUC <0003> auc.c:142 vector [4]: res = > a740f8619e68f2ac0000000000000000 > 20170607111413201 DAUC <0003> auc.c:143 vector [4]: res_len = 8 > 20170607111413201 DAUC <0003> auc.c:147 vector [4]: kc = 6468270ab90789a2 > 20170607111413201 DAUC <0003> auc.c:148 vector [4]: sres = 39280acd > 20170607111413201 DAUC <0003> auc.c:149 vector [4]: auth_types = 0x3 > 20170607111413201 DAUC <0003> db_auc.c:222 901700000014922: Generated 5 > vectors > 20170607111413202 DAUC <0003> db_auc.c:227 901700000014922: Updating > SQN=1760 in DB > 20170607111413204 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111413204 DLINP <0006> input/ipa.c:366 sending data > 20170607111413204 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111413204 DLINP <0006> input/ipa.c:366 sending data > 20170607111414858 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111414858 DLINP <0006> input/ipa.c:338 message received > 20170607111414858 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU > RECEIVED > 20170607111414858 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED > -> ISD SENT > 20170607111414858 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111414858 DLINP <0006> input/ipa.c:366 sending data > 20170607111414858 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111414858 DLINP <0006> input/ipa.c:366 sending data > 20170607111414860 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111414860 DLINP <0006> input/ipa.c:338 message received > 20170607111414860 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111414860 DLINP <0006> input/ipa.c:366 sending data > 20170607111414860 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111414860 DLINP <0006> input/ipa.c:366 sending data > 20170607111431715 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111431715 DLINP <0006> input/ipa.c:338 message received > 20170607111431715 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU > RECEIVED > 20170607111431715 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED > -> ISD SENT > 20170607111431715 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111431715 DLINP <0006> input/ipa.c:366 sending data > 20170607111431715 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111431715 DLINP <0006> input/ipa.c:366 sending data > 20170607111431715 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111431715 DLINP <0006> input/ipa.c:338 message received > 20170607111431716 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111431716 DLINP <0006> input/ipa.c:366 sending data > 20170607111431716 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111431716 DLINP <0006> input/ipa.c:366 sending data > 20170607111432192 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111432192 DLINP <0006> input/ipa.c:338 message received > 20170607111448222 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111448222 DLINP <0006> input/ipa.c:338 message received > 20170607111448222 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU > RECEIVED > 20170607111448222 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED > -> ISD SENT > 20170607111448222 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111448222 DLINP <0006> input/ipa.c:366 sending data > 20170607111448222 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111448222 DLINP <0006> input/ipa.c:366 sending data > 20170607111448223 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111448223 DLINP <0006> input/ipa.c:338 message received > 20170607111448223 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111448223 DLINP <0006> input/ipa.c:366 sending data > 20170607111448224 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111448224 DLINP <0006> input/ipa.c:366 sending data > 20170607111452193 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111452193 DLINP <0006> input/ipa.c:338 message received > 20170607111504691 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111504691 DLINP <0006> input/ipa.c:338 message received > 20170607111504691 DMAIN <0000> luop.c:148 LU OP state change: NULL -> LU > RECEIVED > 20170607111504691 DMAIN <0000> luop.c:148 LU OP state change: LU RECEIVED > -> ISD SENT > 20170607111504691 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111504691 DLINP <0006> input/ipa.c:366 sending data > 20170607111504691 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111504691 DLINP <0006> input/ipa.c:366 sending data > 20170607111504694 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111504694 DLINP <0006> input/ipa.c:338 message received > 20170607111504694 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111504694 DLINP <0006> input/ipa.c:366 sending data > 20170607111504694 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111504694 DLINP <0006> input/ipa.c:366 sending data > 20170607111512194 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111512195 DLINP <0006> input/ipa.c:338 message received > 20170607111532197 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111532197 DLINP <0006> input/ipa.c:338 message received > 20170607111552203 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111552203 DLINP <0006> input/ipa.c:338 message received > 20170607111612204 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111612205 DLINP <0006> input/ipa.c:338 message received > 20170607111632207 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111632207 DLINP <0006> input/ipa.c:338 message received > 20170607111652212 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111652212 DLINP <0006> input/ipa.c:338 message received > 20170607111712213 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111712213 DLINP <0006> input/ipa.c:338 message received > 20170607111732214 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111732214 DLINP <0006> input/ipa.c:338 message received > 20170607111752219 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111752219 DLINP <0006> input/ipa.c:338 message received > 20170607111812220 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111812220 DLINP <0006> input/ipa.c:338 message received > 20170607111832225 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111832226 DLINP <0006> input/ipa.c:338 message received > 20170607111852231 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111852231 DLINP <0006> input/ipa.c:338 message received > 20170607111912231 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111912231 DLINP <0006> input/ipa.c:338 message received > 20170607111932232 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111932232 DLINP <0006> input/ipa.c:338 message received > 20170607111952237 DLINP <0006> input/ipa.c:387 connected read/write > 20170607111952238 DLINP <0006> input/ipa.c:338 message received > 20170607112012237 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112012237 DLINP <0006> input/ipa.c:338 message received > 20170607112032242 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112032242 DLINP <0006> input/ipa.c:338 message received > 20170607112052244 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112052244 DLINP <0006> input/ipa.c:338 message received > 20170607112112244 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112112245 DLINP <0006> input/ipa.c:338 message received > 20170607112132250 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112132250 DLINP <0006> input/ipa.c:338 message received > 20170607112152252 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112152253 DLINP <0006> input/ipa.c:338 message received > 20170607112212253 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112212253 DLINP <0006> input/ipa.c:338 message received > 20170607112232258 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112232258 DLINP <0006> input/ipa.c:338 message received > 20170607112252263 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112252263 DLINP <0006> input/ipa.c:338 message received > 20170607112312265 DLINP <0006> input/ipa.c:387 connected read/write > 20170607112312265 DLINP <0006> input/ipa.c:338 message received Information of osmo-msc's terminal: 20170607113302784 DMNCC <0006> msc_main.c:397 Using internal MNCC handler. > 20170607113302784 DLGLOBAL <001f> telnet_interface.c:95 telnet at > 127.0.0.1 4254 > 20170607113302784 DSMPP <0017> smpp_smsc.c:978 SMPP at 0.0.0.0 2775 > 20170607113302785 DLGSUP <0029> gsup_client.c:76 GSUP connecting to > 127.0.0.1:2222 > 20170607113302788 DLSMS <0025> sms_queue.c:252 Attempting to send 20 SMS > 20170607113302789 DLSMS <0025> sms_queue.c:236 SMS queue: no SMS to be sent > 20170607113302789 DLSMS <0025> sms_queue.c:263 Sending SMS done (0 > attempted) > 20170607113302789 DLSMS <0025> sms_queue.c:319 SMSqueue added 0 messages > in 0 rounds > 20170607113302789 DMGCP <000b> mgcpgw_client.c:369 MGCP GW connection: > 0.0.0.0:0 -> 192.168.31.147:2427 > 20170607113302789 DLINP <0021> input/ipa.c:129 connection done. > 20170607113302789 DLGSUP <0029> gsup_client.c:134 GSUP link to > 127.0.0.1:2222 UP > 20170607113302789 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113302789 DLINP <0021> input/ipa.c:136 connected read > 20170607113302789 DLINP <0021> input/ipa.c:54 message received > 20170607113302789 DLINP <0021> input/ipaccess.c:706 received ID get > 20170607113302789 DLINP <0021> input/ipaccess.c:641 tag 8: 0/0/0 > 20170607113302789 DLINP <0021> input/ipaccess.c:641 tag 7: > 00:00:00:00:00:00 > 20170607113302789 DLINP <0021> input/ipaccess.c:641 tag 2: > 00:00:00:00:00:00 > 20170607113302789 DLINP <0021> input/ipaccess.c:641 tag 3: > 00:00:00:00:00:00 > 20170607113302790 DLINP <0021> input/ipaccess.c:641 tag 4: > 00:00:00:00:00:00 > 20170607113302790 DLINP <0021> input/ipaccess.c:641 tag 5: > 00:00:00:00:00:00 > 20170607113302790 DLINP <0021> input/ipaccess.c:641 tag 1: > MSC-00-00-00-00-00-00 > 20170607113302790 DLINP <0021> input/ipaccess.c:641 tag 0: > MSC-00-00-00-00-00-00 > 20170607113302790 DLINP <0021> input/ipa.c:140 connected write > 20170607113302790 DLINP <0021> input/ipa.c:90 sending data > 20170607113302790 DLINP <0021> input/ipa.c:140 connected write > 20170607113302790 DLINP <0021> input/ipa.c:90 sending data > 20170607113302790 DLINP <0021> input/ipa.c:136 connected read > 20170607113302790 DLINP <0021> input/ipa.c:54 message received > 20170607113302829 DLINP <0021> input/ipa.c:136 connected read > 20170607113302829 DLINP <0021> input/ipa.c:54 message received > 20170607113302829 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113312917 DLINP <0021> stream.c:553 accept()ed new link from > 127.0.0.1 to port 14001 > 20170607113312917 DSUA <001b> sua.c:1351 New SCTP connection accepted > 20170607113312917 DLINP <0021> stream.c:553 accept()ed new link from > 127.0.0.1 to port 14001 > 20170607113312917 DSUA <001b> sua.c:1351 New SCTP connection accepted > 20170607113316249 DLINP <0021> stream.c:802 connected read/write > 20170607113316249 DLINP <0021> stream.c:750 message received > 20170607113316249 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 148 > 20170607113316249 DSUA <001b> sua.c:1236 (127.0.0.1:49836<-> > 127.0.0.1:14001) SUA SRV SCTP NOTIFICATION 32770 flags=0x0 > 20170607113316249 DSUA <001b> sua.c:1249 (127.0.0.1:49836<-> > 127.0.0.1:14001) SUA SRV PEER_ADDR_CHANGE > 20170607113316761 DLINP <0021> stream.c:802 connected read/write > 20170607113316761 DLINP <0021> stream.c:750 message received > 20170607113316761 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 148 > 20170607113316761 DSUA <001b> sua.c:1236 (127.0.0.1:38893<-> > 127.0.0.1:14001) SUA SRV SCTP NOTIFICATION 32770 flags=0x0 > 20170607113316761 DSUA <001b> sua.c:1249 (127.0.0.1:38893<-> > 127.0.0.1:14001) SUA SRV PEER_ADDR_CHANGE > 20170607113322794 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113322794 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113322794 DLINP <0021> input/ipa.c:140 connected write > 20170607113322794 DLINP <0021> input/ipa.c:90 sending data > 20170607113322794 DLINP <0021> input/ipa.c:140 connected write > 20170607113322794 DLINP <0021> input/ipa.c:90 sending data > 20170607113322794 DLINP <0021> input/ipa.c:136 connected read > 20170607113322794 DLINP <0021> input/ipa.c:54 message received > 20170607113322794 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113342797 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113342797 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113342797 DLINP <0021> input/ipa.c:140 connected write > 20170607113342797 DLINP <0021> input/ipa.c:90 sending data > 20170607113342797 DLINP <0021> input/ipa.c:140 connected write > 20170607113342797 DLINP <0021> input/ipa.c:90 sending data > 20170607113342798 DLINP <0021> input/ipa.c:136 connected read > 20170607113342798 DLINP <0021> input/ipa.c:54 message received > 20170607113342798 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113402797 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113402797 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113402798 DLINP <0021> input/ipa.c:140 connected write > 20170607113402798 DLINP <0021> input/ipa.c:90 sending data > 20170607113402798 DLINP <0021> input/ipa.c:140 connected write > 20170607113402798 DLINP <0021> input/ipa.c:90 sending data > 20170607113402798 DLINP <0021> input/ipa.c:136 connected read > 20170607113402798 DLINP <0021> input/ipa.c:54 message received > 20170607113402798 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113422801 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113422801 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113422801 DLINP <0021> input/ipa.c:140 connected write > 20170607113422801 DLINP <0021> input/ipa.c:90 sending data > 20170607113422801 DLINP <0021> input/ipa.c:140 connected write > 20170607113422801 DLINP <0021> input/ipa.c:90 sending data > 20170607113422801 DLINP <0021> input/ipa.c:136 connected read > 20170607113422801 DLINP <0021> input/ipa.c:54 message received > 20170607113422801 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113442807 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113442807 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113442807 DLINP <0021> input/ipa.c:140 connected write > 20170607113442807 DLINP <0021> input/ipa.c:90 sending data > 20170607113442807 DLINP <0021> input/ipa.c:140 connected write > 20170607113442807 DLINP <0021> input/ipa.c:90 sending data > 20170607113442808 DLINP <0021> input/ipa.c:136 connected read > 20170607113442808 DLINP <0021> input/ipa.c:54 message received > 20170607113442808 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113502807 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113502807 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113502808 DLINP <0021> input/ipa.c:140 connected write > 20170607113502808 DLINP <0021> input/ipa.c:90 sending data > 20170607113502808 DLINP <0021> input/ipa.c:140 connected write > 20170607113502808 DLINP <0021> input/ipa.c:90 sending data > 20170607113502808 DLINP <0021> input/ipa.c:136 connected read > 20170607113502808 DLINP <0021> input/ipa.c:54 message received > 20170607113502808 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113522814 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113522814 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113522814 DLINP <0021> input/ipa.c:140 connected write > 20170607113522814 DLINP <0021> input/ipa.c:90 sending data > 20170607113522814 DLINP <0021> input/ipa.c:140 connected write > 20170607113522814 DLINP <0021> input/ipa.c:90 sending data > 20170607113522814 DLINP <0021> input/ipa.c:136 connected read > 20170607113522814 DLINP <0021> input/ipa.c:54 message received > 20170607113522815 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113524298 DLINP <0021> stream.c:802 connected read/write > 20170607113524298 DLINP <0021> stream.c:750 message received > 20170607113524299 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 132 > 20170607113524299 DSUA <001b> sua.c:1146 Received SUA Message (8:1) > 20170607113524299 DSUA <001b> sua.c:659 sua_parse_addr(IEI=259) (4) 00 02 > 00 07 > 20170607113524299 DSUA <001b> sua.c:254 (0) state chg IDLE->CONN_PEND_IN > 20170607113524299 DRANAP <001a> iu.c:721 sccp_sap_up(N-CONNECTindication) > 20170607113524299 DRANAP <001a> iu.c:730 N-CONNECT.ind(X->0) > 20170607113524299 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-CONNECTresponse) > 20170607113524299 DSUA <001b> sua.c:254 (0) state chg CONN_PEND_IN->ACTIVE > 20170607113524299 DSUA <001b> sua.c:160 sua_link_send(01 00 08 02 00 00 00 > 30 00 06 00 08 00 00 00 00 01 15 00 08 00 00 00 02 01 05 00 08 00 00 03 e8 > 01 04 00 08 00 00 00 00 01 16 00 08 00 00 00 00 ) > 20170607113524299 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Initial UE > Message) > 20170607113524299 DRLL <0000> ranap_decoder.c:2641 Decoding message > RANAP_InitialUE_MessageIEs (ranap_decoder.c:2641) > 20170607113524299 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=19) > 20170607113524299 DRANAP <001a> iu.c:143 New RNC 23 (LAC=10422 RAC=0) > 20170607113524299 DIUCS <001e> msc_main.c:321 got IuCS message 23 bytes: > 05 08 70 09 f1 89 ff fe 57 08 99 10 07 00 00 10 94 22 33 03 57 58 a6 > 20170607113524299 DIUCS <001e> msc_main.c:325 got IuCS message on MNC 70 > MCC 901 LAC 10422 RAC 0 > 20170607113524299 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 0 > 20170607113524299 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113524299 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7fde0, conn_id 0 > 20170607113524299 DIUCS <001e> iucs.c:44 Allocating IuCS subscriber conn: > lac 10422, link_id 0x1c7fde0, conn_id 0 > 20170607113524299 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8) > 20170607113524299 DMM <0002> fsm.c:231 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_INIT}: Allocated > 20170607113524299 DMM <0002> subscr_conn.c:344 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_INIT}: Received Event > SUBSCR_CONN_E_START > 20170607113524299 DMM <0002> subscr_conn.c:66 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_INIT}: state_chg to > SUBSCR_CONN_S_NEW > 20170607113524299 DMM <0002> gsm_04_08.c:300 LOCATION UPDATING REQUEST: > MI(IMSI)=901700000014922 type=NORMAL > 20170607113524299 DMM <0002> gsm_04_08.c:345 LU/new-LAC: 65534/10422 > 20170607113524299 DVLR <001d> fsm.c:231 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_IDLE}: Allocated > 20170607113524299 DVLR <001d> fsm.c:261 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_IDLE}: is child of > Subscr_Conn(901700000014922)[0x1ca52f0] > 20170607113524299 DVLR <001d> vlr_lu_fsm.c:1409 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_IDLE}: rev=R99 net=UTRAN > Auth+Ciph > 20170607113524299 DVLR <001d> vlr_lu_fsm.c:1415 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_IDLE}: Received Event > VLR_ULA_E_UPDATE_LA > 20170607113524299 DVLR <001d> vlr.c:375 set IMSI on subscriber; > IMSI=901700000014922 id=901700000014922 > 20170607113524299 DVLR <001d> vlr.c:334 New subscr, IMSI: 901700000014922 > 20170607113524299 DVLR <001d> vlr_lu_fsm.c:838 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1() > 20170607113524299 DVLR <001d> vlr_lu_fsm.c:845 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_IDLE}: state_chg to > VLR_ULA_S_WAIT_AUTH > 20170607113524299 DVLR <001d> fsm.c:231 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_NEEDS_AUTH}: > Allocated > 20170607113524299 DVLR <001d> fsm.c:261 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_NEEDS_AUTH}: is > child of vlr_lu_fsm(901700000014922)[0x1ca8250] > 20170607113524299 DVLR <001d> vlr_auth_fsm.c:602 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_NEEDS_AUTH}: > Received Event VLR_AUTH_E_START > 20170607113524299 DVLR <001d> vlr.c:145 GSUP tx: 08010809710000004129f2 > 20170607113524299 DVLR <001d> vlr_auth_fsm.c:296 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_NEEDS_AUTH}: > state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI > 20170607113524299 DMM <0002> osmo_msc.c:54 IMSI:901700000014922: bump: > conn still being established (SUBSCR_CONN_S_NEW) > 20170607113524299 DLINP <0021> input/ipa.c:140 connected write > 20170607113524299 DLINP <0021> input/ipa.c:90 sending data > 20170607113524299 DLINP <0021> stream.c:802 connected read/write > 20170607113524299 DLINP <0021> stream.c:767 sending data > 20170607113524299 DLINP <0021> input/ipa.c:140 connected write > 20170607113524299 DLINP <0021> input/ipa.c:90 sending data > 20170607113524299 DLINP <0021> stream.c:802 connected read/write > 20170607113524299 DLINP <0021> stream.c:767 sending data > 20170607113524303 DLINP <0021> input/ipa.c:136 connected read > 20170607113524303 DLINP <0021> input/ipa.c:54 message received > 20170607113524303 DVLR <001d> vlr.c:790 GSUP rx 511: > 0a010809710000004129f20362201097c08af4e489069463f235833423f4c421044242c26c2208a3f15f998fdd0c2e23103b5c23f342ebdf6baa28f57ca6c7f6dc24100c3fdfbb39bd6a703eba56ad524c4fe925100fa4f283610800008a131af6576e60862708ebf4454ca9b68720036220101595ffdaf06a27d0cafe39ec7ee356de2104140673db2208deb018c1ac2bd0c2231054f32afbf3bcadd134fd7a9e3533e7342410cd70db2bbefe823473ce938fd45a18132510667c8dd1067d0000e24b9b22574e0eb427089e449d778a42eeac036220101cbff4654712b2bffdaeea373dfd28d421047d15ae5022084b5a6368a43e0a732310567c6861094a593cc77ffb3ac8d3131c241035c0f4cda8548274ef9904fecdf3c22725100075752ddbce0000d91fcdc34c0acc542708e5d3564398c6f8130362201047c9683572d789e926efa28e6289382c2104dc4330502208e05c6d596967b2a5231047070ff418f32b475866ada3bbf1e8da2410af999826ec713e2250a4572826144f1a2510eceea9c9d287000084db5b0aba42d2f02708379065e7ebd355b703622010763a869e57e93d7a3f44276d1bd3e92a2104efd82f9722086323a24b7b8af130231054ce33598044bf0ae77a0b6dd230744d241055b9bae4eb996bed852e209bc267519a2510286790e0320d0000ef1a670fad7ab4b327081f3e0555f0e62ac2 > 20170607113524303 DVLR <001d> vlr.c:608 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: > Received Event VLR_AUTH_E_HLR_SAI_ACK > 20170607113524303 DVLR <001d> vlr.c:588 SUBSCR(IMSI:901700000014922) > Received 5 auth tuples > 20170607113524303 DVLR <001d> vlr_auth_fsm.c:352 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: > state_chg to VLR_SUB_AS_WAIT_RESP > 20170607113524303 DVLR <001d> vlr_auth_fsm.c:263 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_WAIT_RESP}: got > auth tuple: use_count=1 key_seq=0 > 20170607113524303 DMM <0002> gsm_04_08.c:552 -> AUTH REQ (rand = > 97c08af4e489069463f235833423f4c4) > 20170607113524303 DMM <0002> gsm_04_08.c:554 AUTH REQ (autn = > 0fa4f283610800008a131af6576e6086) > 20170607113524303 DMSC <000a> msc_ifaces.c:44 msc_tx 37 bytes to > IMSI:901700000014922 via RAN_UTRAN_IU > 20170607113524303 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP > DT (SUA link 0x1c7fde0 conn_id 0) > 20170607113524303 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113524303 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 54 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 3a 00 14 00 32 > 00 00 02 00 10 40 26 25 05 12 00 97 c0 8a f4 e4 89 06 94 63 f2 35 83 34 23 > f4 c4 20 10 0f a4 f2 83 61 08 00 00 8a 13 1a f6 57 6e 60 86 00 3b 40 01 00 > 00 00 ) > 20170607113524303 DLINP <0021> stream.c:802 connected read/write > 20170607113524303 DLINP <0021> stream.c:767 sending data > 20170607113524303 DLINP <0021> stream.c:802 connected read/write > 20170607113524303 DLINP <0021> stream.c:767 sending data > 20170607113524483 DLINP <0021> stream.c:802 connected read/write > 20170607113524483 DLINP <0021> stream.c:750 message received > 20170607113524483 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 176 > 20170607113524483 DSUA <001b> sua.c:1146 Received SUA Message (8:1) > 20170607113524483 DSUA <001b> sua.c:659 sua_parse_addr(IEI=259) (4) 00 02 > 00 07 > 20170607113524483 DSUA <001b> sua.c:254 (0) state chg IDLE->CONN_PEND_IN > 20170607113524483 DRANAP <001a> iu.c:721 sccp_sap_up(N-CONNECTindication) > 20170607113524483 DRANAP <001a> iu.c:730 N-CONNECT.ind(X->0) > 20170607113524483 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-CONNECTresponse) > 20170607113524483 DSUA <001b> sua.c:254 (0) state chg CONN_PEND_IN->ACTIVE > 20170607113524483 DSUA <001b> sua.c:160 sua_link_send(01 00 08 02 00 00 00 > 30 00 06 00 08 00 00 00 00 01 15 00 08 00 00 00 02 01 05 00 08 00 00 03 e8 > 01 04 00 08 00 00 00 00 01 16 00 08 00 00 00 00 ) > 20170607113524483 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Initial UE > Message) > 20170607113524483 DRLL <0000> ranap_decoder.c:2641 Decoding message > RANAP_InitialUE_MessageIEs (ranap_decoder.c:2641) > 20170607113524483 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=19) > 20170607113524483 DRANAP <001a> iu.c:164 RNC 23 changes its details: > LAC=10422 RAC=0 --> LAC=10422 RAC=99 > 20170607113524483 DRANAP <001a> iu.c:171 RNC 23 on new link (LAC=10422 > RAC=99) > 20170607113524483 DIUCS <001e> msc_main.c:321 got IuCS message 62 bytes: > 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 ff ff 00 ff fe ff 1a > 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 e8 c4 b1 98 87 91 00 > 26 17 05 58 04 e0 60 c0 40 5d 01 00 > 20170607113524483 DIUCS <001e> msc_main.c:325 got IuCS message on MNC 70 > MCC 901 LAC 10422 RAC 99 > 20170607113524483 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7e310, conn_id 0 > 20170607113524483 DIUCS <001e> iucs.c:76 0: IMSI:901700000014922 Iu link > 0x1c7fde0, conn_id 0 > 20170607113524483 DIUCS <001e> iucs.c:101 subscribers registered: 1 > 20170607113524483 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7e310, conn_id 0 > 20170607113524483 DIUCS <001e> iucs.c:44 Allocating IuCS subscriber conn: > lac 10422, link_id 0x1c7e310, conn_id 0 > 20170607113524483 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_PDISC_MM_GPRS:0x01 (0x8:0x1) > 20170607113524483 DRLL <0000> gsm_04_08.c:3602 subscr unknown: Message not > permitted for initial conn: GSM48_PDISC_MM_GPRS:0x01 > 20170607113524483 DRLL <0000> osmo_msc.c:217 Freeing subscriber connection > with NULL subscriber > 20170607113524483 DLINP <0021> stream.c:802 connected read/write > 20170607113524483 DLINP <0021> stream.c:767 sending data > 20170607113524483 DLINP <0021> stream.c:802 connected read/write > 20170607113524484 DLINP <0021> stream.c:767 sending data > 20170607113524721 DLINP <0021> stream.c:802 connected read/write > 20170607113524721 DLINP <0021> stream.c:750 message received > 20170607113524721 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 52 > 20170607113524721 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113524721 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113524721 DRANAP <001a> iu.c:754 N-DATA.ind(0, 00 14 40 14 00 00 > 01 00 10 40 0d 0c 05 54 eb f4 45 4c 21 04 a9 b6 87 20 ) > 20170607113524721 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Direct > Transfer) > 20170607113524722 DRLL <0000> ranap_decoder.c:3197 Decoding message > RANAP_DirectTransferIEs (ranap_decoder.c:3197) > 20170607113524722 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=20) > 20170607113524722 DIUCS <001e> msc_main.c:321 got IuCS message 12 bytes: > 05 54 eb f4 45 4c 21 04 a9 b6 87 20 > 20170607113524722 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 0 > 20170607113524722 DIUCS <001e> iucs.c:76 0: IMSI:901700000014922 Iu link > 0x1c7fde0, conn_id 0 > 20170607113524722 DIUCS <001e> iucs.c:101 subscribers registered: 1 > 20170607113524722 DIUCS <001e> iucs.c:122 Found IuCS subscriber for > link_id 0x1c7fde0, conn_id 0 > 20170607113524722 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_MT_MM_AUTH_RESP (0x5:0x14) > 20170607113524722 DMM <0002> gsm_04_08.c:908 IMSI:901700000014922: MM R99 > AUTHENTICATION RESPONSE (res = ebf4454ca9b68720) > 20170607113524722 DVLR <001d> vlr.c:1043 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_WAIT_RESP}: > Received Event VLR_AUTH_E_MS_AUTH_RESP > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:142 > SUBSCR(IMSI:901700000014922) received res: eb f4 45 4c a9 b6 87 20 > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:179 > SUBSCR(IMSI:901700000014922) AUTH established UMTS security context > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:231 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_WAIT_RESP}: > Authentication terminating with result VLR_AUTH_RES_PASSED > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:235 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_WAIT_RESP}: > state_chg to VLR_SUB_AS_AUTHENTICATED > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_AUTHENTICATED}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_AUTHENTICATED}: > Removing from parent vlr_lu_fsm(901700000014922)[0x1ca8250] > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_AUTHENTICATED}: > Freeing instance > 20170607113524722 DVLR <001d> fsm.c:275 > VLR_Authenticate(901700000014922)[0x1ca8940]{VLR_SUB_AS_AUTHENTICATED}: > Deallocated > 20170607113524722 DVLR <001d> vlr_auth_fsm.c:240 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_AUTH}: Received Event > VLR_ULA_E_AUTH_RES > 20170607113524722 DVLR <001d> vlr_lu_fsm.c:812 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_AUTH}: > vlr_loc_upd_post_auth() > 20170607113524722 DMM <0002> gsm_04_08.c:3775 -> SECURITY MODE CONTROL > IMSI:901700000014922 > 20170607113524722 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113524722 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 06 00 1e > 00 00 02 00 0c 00 12 08 08 3b 5c 23 f3 42 eb df 6b aa 28 f5 7c a6 c7 f6 dc > 00 4b 00 01 40 00 00 ) > 20170607113524722 DVLR <001d> vlr_lu_fsm.c:830 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_AUTH}: state_chg to > VLR_ULA_S_WAIT_CIPH > 20170607113524722 DMM <0002> osmo_msc.c:54 IMSI:901700000014922: bump: > conn still being established (SUBSCR_CONN_S_NEW) > 20170607113524722 DLINP <0021> stream.c:802 connected read/write > 20170607113524722 DLINP <0021> stream.c:767 sending data > 20170607113524722 DLINP <0021> stream.c:802 connected read/write > 20170607113524722 DLINP <0021> stream.c:767 sending data > 20170607113524949 DLINP <0021> stream.c:802 connected read/write > 20170607113524950 DLINP <0021> stream.c:750 message received > 20170607113524950 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 40 > 20170607113524950 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113524950 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113524950 DRANAP <001a> iu.c:754 N-DATA.ind(0, 20 06 00 08 00 00 > 01 00 06 00 01 00 ) > 20170607113524950 DRSL <0004> ranap_common_cn.c:137 Rx CO SO (Security > Mode Control) > 20170607113524950 DRLL <0000> ranap_decoder.c:4315 Decoding message > RANAP_SecurityModeCompleteIEs (ranap_decoder.c:4315) > 20170607113524950 DRANAP <001a> iu.c:468 handle_co(dir=2, proc=6) > 20170607113524950 DIUCS <001e> msc_main.c:335 got IuCS event 1: > IU_EVENT_SECURITY_MODE_COMPLETE > 20170607113524950 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 0 > 20170607113524950 DIUCS <001e> iucs.c:76 0: IMSI:901700000014922 Iu link > 0x1c7fde0, conn_id 0 > 20170607113524950 DIUCS <001e> iucs.c:101 subscribers registered: 1 > 20170607113524950 DIUCS <001e> iucs.c:122 Found IuCS subscriber for > link_id 0x1c7fde0, conn_id 0 > 20170607113524950 DIUCS <001e> iucs_ranap.c:95 IuCS security mode complete > for IMSI:901700000014922 > 20170607113524950 DMM <0002> gsm_04_08.c:3798 <- SECURITY MODE COMPLETE > IMSI:901700000014922 > 20170607113524950 DVLR <001d> vlr.c:1052 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_CIPH}: Received Event > VLR_ULA_E_CIPH_RES > 20170607113524950 DVLR <001d> vlr_lu_fsm.c:780 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_CIPH}: > vlr_loc_upd_post_ciph() > 20170607113524950 DIUCS <001e> msc_ifaces.c:116 IMSI:901700000014922: tx > CommonID 901700000014922 > 20170607113524950 DRANAP <001a> iu.c:258 Transmitting RANAP CommonID (SUA > link 0x1c7fde0 conn_id 0) > 20170607113524951 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113524951 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 30 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 18 00 0f 40 10 > 00 00 01 00 17 40 09 50 09 71 00 00 00 41 29 f2 ) > 20170607113524951 DVLR <001d> vlr_lu_fsm.c:743 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_CIPH}: > vlr_loc_upd_node_4() > 20170607113524951 DVLR <001d> vlr_lu_fsm.c:752 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_CIPH}: state_chg to > VLR_ULA_S_WAIT_HLR_UPD > 20170607113524951 DVLR <001d> fsm.c:231 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_INIT}: Allocated > 20170607113524951 DVLR <001d> fsm.c:261 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_INIT}: is child > of vlr_lu_fsm(901700000014922)[0x1ca8250] > 20170607113524951 DVLR <001d> vlr_lu_fsm.c:164 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_INIT}: Received > Event UPD_HLR_VLR_E_START > 20170607113524951 DVLR <001d> vlr.c:145 GSUP tx: 04010809710000004129f2 > 20170607113524951 DVLR <001d> vlr_lu_fsm.c:81 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_INIT}: state_chg > to UPD_HLR_VLR_S_WAIT_FOR_DATA > 20170607113524951 DLINP <0021> input/ipa.c:140 connected write > 20170607113524951 DLINP <0021> input/ipa.c:90 sending data > 20170607113524951 DLINP <0021> stream.c:802 connected read/write > 20170607113524951 DLINP <0021> stream.c:767 sending data > 20170607113524951 DLINP <0021> input/ipa.c:140 connected write > 20170607113524951 DLINP <0021> input/ipa.c:90 sending data > 20170607113524951 DLINP <0021> stream.c:802 connected read/write > 20170607113524951 DLINP <0021> stream.c:767 sending data > 20170607113524952 DLINP <0021> input/ipa.c:136 connected read > 20170607113524952 DLINP <0021> input/ipa.c:54 message received > 20170607113524952 DVLR <001d> vlr.c:790 GSUP rx 16: > 10010809710000004129f208030233f3 > 20170607113524952 DVLR <001d> vlr.c:646 IMSI:901700000014922 has MSISDN:333 > 20170607113524952 DVLR <001d> vlr.c:145 GSUP tx: 12010809710000004129f2 > 20170607113524952 DLINP <0021> input/ipa.c:140 connected write > 20170607113524952 DLINP <0021> input/ipa.c:90 sending data > 20170607113524952 DLINP <0021> input/ipa.c:140 connected write > 20170607113524952 DLINP <0021> input/ipa.c:90 sending data > 20170607113524952 DLINP <0021> input/ipa.c:136 connected read > 20170607113524953 DLINP <0021> input/ipa.c:54 message received > 20170607113524953 DVLR <001d> vlr.c:790 GSUP rx 11: 06010809710000004129f2 > 20170607113524953 DVLR <001d> vlr.c:736 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_HLR_UPD}: Received > Event VLR_ULA_E_HLR_LU_RES > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:1145 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_WAIT_FOR_DATA}: > Received Event UPD_HLR_VLR_E_UPD_LOC_ACK > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:103 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_WAIT_FOR_DATA}: > state_chg to UPD_HLR_VLR_S_DONE > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_DONE}: Removing > from parent vlr_lu_fsm(901700000014922)[0x1ca8250] > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_DONE}: Freeing > instance > 20170607113524953 DVLR <001d> fsm.c:275 > upd_hlr_vlr_fsm(901700000014922)[0x1c7e580]{UPD_HLR_VLR_S_DONE}: Deallocated > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:104 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_HLR_UPD}: Received > Event VLR_ULA_E_UPD_HLR_COMPL > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:1153 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_HLR_UPD}: state_chg > to VLR_ULA_S_WAIT_LU_COMPL > 20170607113524953 DVLR <001d> fsm.c:231 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_INIT}: Allocated > 20170607113524953 DVLR <001d> fsm.c:261 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_INIT}: is child > of vlr_lu_fsm(901700000014922)[0x1ca8250] > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:725 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_INIT}: Received > Event LU_COMPL_VLR_E_START > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:385 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_INIT}: > state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES > 20170607113524953 DVLR <001d> fsm.c:231 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_INIT}: Allocated > 20170607113524953 DVLR <001d> fsm.c:261 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_INIT}: is child > of lu_compl_vlr_fsm(901700000014922)[0x1c7e580] > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:267 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_INIT}: Received > Event SUB_PRES_VLR_E_START > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:200 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_INIT}: > state_chg to SUB_PRES_VLR_S_DONE > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_DONE}: Removing > from parent lu_compl_vlr_fsm(901700000014922)[0x1c7e580] > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_DONE}: Freeing > instance > 20170607113524953 DVLR <001d> fsm.c:275 > sub_pres_vlr_fsm(901700000014922)[0x1c81590]{SUB_PRES_VLR_S_DONE}: > Deallocated > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:201 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: > Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL > 20170607113524953 DMM <0002> gsm_04_08.c:201 -> MSISDN:333 LOCATION UPDATE > ACCEPT > 20170607113524953 DMSC <000a> msc_ifaces.c:44 msc_tx 17 bytes to > MSISDN:333 via RAN_UTRAN_IU > 20170607113524953 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP > DT (SUA link 0x1c7fde0 conn_id 0) > 20170607113524953 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113524953 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 14 00 1e > 00 00 02 00 10 40 12 11 05 02 09 f1 89 28 b6 17 08 99 10 07 00 00 10 94 22 > 00 3b 40 01 00 00 00 ) > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:321 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: > state_chg to LU_COMPL_VLR_S_DONE > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:355 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_LU_COMPL}: Received > Event VLR_ULA_E_LU_COMPL_SUCCESS > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_PARENT) > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_DONE}: Removing > from parent vlr_lu_fsm(901700000014922)[0x1ca8250] > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_DONE}: Freeing > instance > 20170607113524953 DVLR <001d> fsm.c:275 > lu_compl_vlr_fsm(901700000014922)[0x1c7e580]{LU_COMPL_VLR_S_DONE}: > Deallocated > 20170607113524953 DVLR <001d> vlr_lu_fsm.c:700 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg > to VLR_ULA_S_DONE > 20170607113524953 DMM <0002> vlr_lu_fsm.c:692 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_NEW}: Received Event > SUBSCR_CONN_E_ACCEPTED > 20170607113524953 DMM <0002> subscr_conn.c:77 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_NEW}: > SUBSCR_CONN_FROM_LU > 20170607113524953 DMM <0002> subscr_conn.c:84 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_NEW}: state_chg to > SUBSCR_CONN_S_ACCEPTED > 20170607113524956 DMM <0002> subscr_conn.c:132 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_ACCEPTED}: Received > Event SUBSCR_CONN_E_BUMP > 20170607113524956 DMM <0002> subscr_conn.c:168 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_ACCEPTED}: bump: > releasing conn > 20170607113524956 DMM <0002> subscr_conn.c:169 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_ACCEPTED}: state_chg > to SUBSCR_CONN_S_RELEASED > 20170607113524956 DMM <0002> subscr_conn.c:255 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_RELEASED}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113524956 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_DONE}: Terminating (cause > = OSMO_FSM_TERM_PARENT) > 20170607113524956 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_DONE}: Removing from > parent Subscr_Conn(901700000014922)[0x1ca52f0] > 20170607113524956 DVLR <001d> vlr_lu_fsm.c:1342 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_DONE}: fsm_lu_cleanup > called with cause OSMO_FSM_TERM_PARENT > 20170607113524956 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_DONE}: Freeing instance > 20170607113524956 DVLR <001d> fsm.c:275 > vlr_lu_fsm(901700000014922)[0x1ca8250]{VLR_ULA_S_DONE}: Deallocated > 20170607113524956 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113524956 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 2c 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 11 00 01 00 09 > 00 00 01 00 04 40 02 07 80 00 00 00 ) > 20170607113524956 DRLL <0000> osmo_msc.c:211 subscr MSISDN:333: Freeing > subscriber connection > 20170607113524956 DMM <0002> subscr_conn.c:255 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_RELEASED}: Freeing > instance > 20170607113524956 DMM <0002> fsm.c:275 > Subscr_Conn(901700000014922)[0x1ca52f0]{SUBSCR_CONN_S_RELEASED}: Deallocated > 20170607113524956 DLINP <0021> stream.c:802 connected read/write > 20170607113524956 DLINP <0021> stream.c:767 sending data > 20170607113524956 DLINP <0021> stream.c:802 connected read/write > 20170607113524956 DLINP <0021> stream.c:767 sending data > 20170607113524956 DLINP <0021> stream.c:802 connected read/write > 20170607113524956 DLINP <0021> stream.c:767 sending data > 20170607113525164 DLINP <0021> stream.c:802 connected read/write > 20170607113525164 DLINP <0021> stream.c:750 message received > 20170607113525164 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 52 > 20170607113525164 DSUA <001b> sua.c:1146 Received SUA Message (8:4) > 20170607113525164 DRANAP <001a> iu.c:721 > sccp_sap_up(N-DISCONNECTindication) > 20170607113525164 DRANAP <001a> iu.c:747 N-DISCONNECT.ind(0) > 20170607113525164 DRSL <0004> ranap_common_cn.c:137 Rx CO SO (Iu Release) > 20170607113525164 DRLL <0000> ranap_decoder.c:4055 Decoding message > RANAP_Iu_ReleaseCompleteIEs (ranap_decoder.c:4055) > 20170607113525164 DRANAP <001a> iu.c:468 handle_co(dir=2, proc=1) > 20170607113525164 DIUCS <001e> msc_main.c:335 got IuCS event 2: > IU_EVENT_IU_RELEASE > 20170607113525165 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 0 > 20170607113525165 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113525165 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7fde0, conn_id 0 > 20170607113525165 DRANAP <001a> iucs_ranap.c:81 Cannot find subscriber for > IU event 2 > 20170607113525165 DRANAP <001a> iu.c:504 Iu Release event: Iu Event > callback returned -1 > 20170607113525165 DRANAP <001a> iu.c:537 Error in cn_ranap_handle_co (-1) > 20170607113525165 DSUA <001b> sua.c:254 (0) state chg ACTIVE->IDLE > 20170607113539843 DLINP <0021> stream.c:802 connected read/write > 20170607113539844 DLINP <0021> stream.c:750 message received > 20170607113539844 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 132 > 20170607113539844 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113539844 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113539844 DRANAP <001a> iu.c:754 N-DATA.ind(0, 00 14 40 61 00 00 > 04 00 10 40 3f 3e 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 ff > ff 00 ff fe ff 1a 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 e8 > c4 b1 98 87 91 00 26 17 05 58 04 e0 60 c0 40 5d 01 00 00 0f 40 06 00 09 f1 > 07 28 b6 00 37 40 01 63 00 3a 40 08 00 09 f1 07 ff ff ff ff ) > 20170607113539844 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Direct > Transfer) > 20170607113539844 DRLL <0000> ranap_decoder.c:3197 Decoding message > RANAP_DirectTransferIEs (ranap_decoder.c:3197) > 20170607113539844 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=20) > 20170607113539844 DIUCS <001e> msc_main.c:321 got IuCS message 62 bytes: > 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 ff ff 00 ff fe ff 1a > 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 e8 c4 b1 98 87 91 00 > 26 17 05 58 04 e0 60 c0 40 5d 01 00 > 20170607113539844 DIUCS <001e> msc_main.c:325 got IuCS message on MNC 70 > MCC 901 LAC 10422 RAC 99 > 20170607113539844 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7e310, conn_id 0 > 20170607113539844 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113539844 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7e310, conn_id 0 > 20170607113539844 DIUCS <001e> iucs.c:44 Allocating IuCS subscriber conn: > lac 10422, link_id 0x1c7e310, conn_id 0 > 20170607113539844 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_PDISC_MM_GPRS:0x01 (0x8:0x1) > 20170607113539844 DRLL <0000> gsm_04_08.c:3602 subscr unknown: Message not > permitted for initial conn: GSM48_PDISC_MM_GPRS:0x01 > 20170607113539844 DRLL <0000> osmo_msc.c:217 Freeing subscriber connection > with NULL subscriber > 20170607113540615 DLINP <0021> stream.c:802 connected read/write > 20170607113540616 DLINP <0021> stream.c:750 message received > 20170607113540616 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 132 > 20170607113540616 DSUA <001b> sua.c:1146 Received SUA Message (8:1) > 20170607113540616 DSUA <001b> sua.c:659 sua_parse_addr(IEI=259) (4) 00 02 > 00 07 > 20170607113540616 DSUA <001b> sua.c:254 (1) state chg IDLE->CONN_PEND_IN > 20170607113540616 DRANAP <001a> iu.c:721 sccp_sap_up(N-CONNECTindication) > 20170607113540616 DRANAP <001a> iu.c:730 N-CONNECT.ind(X->1) > 20170607113540616 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-CONNECTresponse) > 20170607113540616 DSUA <001b> sua.c:254 (1) state chg CONN_PEND_IN->ACTIVE > 20170607113540616 DSUA <001b> sua.c:160 sua_link_send(01 00 08 02 00 00 00 > 30 00 06 00 08 00 00 00 00 01 15 00 08 00 00 00 02 01 05 00 08 00 00 03 e8 > 01 04 00 08 00 00 00 01 01 16 00 08 00 00 00 00 ) > 20170607113540616 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Initial UE > Message) > 20170607113540616 DRLL <0000> ranap_decoder.c:2641 Decoding message > RANAP_InitialUE_MessageIEs (ranap_decoder.c:2641) > 20170607113540616 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=19) > 20170607113540616 DRANAP <001a> iu.c:164 RNC 23 changes its details: > LAC=10422 RAC=99 --> LAC=10422 RAC=0 > 20170607113540616 DRANAP <001a> iu.c:171 RNC 23 on new link (LAC=10422 > RAC=0) > 20170607113540616 DIUCS <001e> msc_main.c:321 got IuCS message 23 bytes: > 05 08 70 09 f1 89 ff fe 57 08 99 10 07 00 00 10 94 22 33 03 57 58 a6 > 20170607113540616 DIUCS <001e> msc_main.c:325 got IuCS message on MNC 70 > MCC 901 LAC 10422 RAC 0 > 20170607113540616 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 1 > 20170607113540616 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113540616 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7fde0, conn_id 1 > 20170607113540616 DIUCS <001e> iucs.c:44 Allocating IuCS subscriber conn: > lac 10422, link_id 0x1c7fde0, conn_id 1 > 20170607113540616 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8) > 20170607113540616 DMM <0002> fsm.c:231 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_INIT}: Allocated > 20170607113540616 DMM <0002> subscr_conn.c:344 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_INIT}: Received Event > SUBSCR_CONN_E_START > 20170607113540616 DMM <0002> subscr_conn.c:66 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_INIT}: state_chg to > SUBSCR_CONN_S_NEW > 20170607113540616 DMM <0002> gsm_04_08.c:300 LOCATION UPDATING REQUEST: > MI(IMSI)=901700000014922 type=NORMAL > 20170607113540616 DMM <0002> gsm_04_08.c:345 LU/new-LAC: 65534/10422 > 20170607113540616 DVLR <001d> fsm.c:231 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_IDLE}: Allocated > 20170607113540616 DVLR <001d> fsm.c:261 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_IDLE}: is child of > Subscr_Conn(901700000014922)[0x1ca5290] > 20170607113540616 DVLR <001d> vlr_lu_fsm.c:1409 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_IDLE}: rev=R99 net=UTRAN > Auth+Ciph > 20170607113540616 DVLR <001d> vlr_lu_fsm.c:1415 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_IDLE}: Received Event > VLR_ULA_E_UPDATE_LA > 20170607113540616 DVLR <001d> vlr_lu_fsm.c:838 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1() > 20170607113540616 DVLR <001d> vlr_lu_fsm.c:845 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_IDLE}: state_chg to > VLR_ULA_S_WAIT_AUTH > 20170607113540616 DVLR <001d> fsm.c:231 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_NEEDS_AUTH}: > Allocated > 20170607113540617 DVLR <001d> fsm.c:261 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_NEEDS_AUTH}: is > child of vlr_lu_fsm(901700000014922)[0x1ca9930] > 20170607113540617 DVLR <001d> vlr_auth_fsm.c:602 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_NEEDS_AUTH}: > Received Event VLR_AUTH_E_START > 20170607113540617 DVLR <001d> vlr_auth_fsm.c:300 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_NEEDS_AUTH}: > state_chg to VLR_SUB_AS_WAIT_RESP > 20170607113540617 DVLR <001d> vlr_auth_fsm.c:263 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_WAIT_RESP}: got > auth tuple: use_count=1 key_seq=1 > 20170607113540617 DMM <0002> gsm_04_08.c:552 -> AUTH REQ (rand = > 1595ffdaf06a27d0cafe39ec7ee356de) > 20170607113540617 DMM <0002> gsm_04_08.c:554 AUTH REQ (autn = > 667c8dd1067d0000e24b9b22574e0eb4) > 20170607113540617 DMSC <000a> msc_ifaces.c:44 msc_tx 37 bytes to > MSISDN:333 via RAN_UTRAN_IU > 20170607113540617 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP > DT (SUA link 0x1c7fde0 conn_id 1) > 20170607113540617 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113540617 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 54 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 3a 00 14 00 32 > 00 00 02 00 10 40 26 25 05 12 01 15 95 ff da f0 6a 27 d0 ca fe 39 ec 7e e3 > 56 de 20 10 66 7c 8d d1 06 7d 00 00 e2 4b 9b 22 57 4e 0e b4 00 3b 40 01 00 > 00 00 ) > 20170607113540617 DMM <0002> osmo_msc.c:54 MSISDN:333: bump: conn still > being established (SUBSCR_CONN_S_NEW) > 20170607113540617 DLINP <0021> stream.c:802 connected read/write > 20170607113540617 DLINP <0021> stream.c:767 sending data > 20170607113540617 DLINP <0021> stream.c:802 connected read/write > 20170607113540617 DLINP <0021> stream.c:767 sending data > 20170607113540617 DLINP <0021> stream.c:802 connected read/write > 20170607113540617 DLINP <0021> stream.c:767 sending data > 20170607113541234 DLINP <0021> stream.c:802 connected read/write > 20170607113541234 DLINP <0021> stream.c:750 message received > 20170607113541234 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 52 > 20170607113541234 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113541234 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113541234 DRANAP <001a> iu.c:754 N-DATA.ind(1, 00 14 40 14 00 00 > 01 00 10 40 0d 0c 05 54 9e 44 9d 77 21 04 8a 42 ee ac ) > 20170607113541234 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Direct > Transfer) > 20170607113541234 DRLL <0000> ranap_decoder.c:3197 Decoding message > RANAP_DirectTransferIEs (ranap_decoder.c:3197) > 20170607113541234 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=20) > 20170607113541234 DIUCS <001e> msc_main.c:321 got IuCS message 12 bytes: > 05 54 9e 44 9d 77 21 04 8a 42 ee ac > 20170607113541234 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 1 > 20170607113541234 DIUCS <001e> iucs.c:76 0: MSISDN:333 Iu link > 0x1c7fde0, conn_id 1 > 20170607113541234 DIUCS <001e> iucs.c:101 subscribers registered: 1 > 20170607113541234 DIUCS <001e> iucs.c:122 Found IuCS subscriber for > link_id 0x1c7fde0, conn_id 1 > 20170607113541234 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_MT_MM_AUTH_RESP (0x5:0x14) > 20170607113541234 DMM <0002> gsm_04_08.c:908 MSISDN:333: MM R99 > AUTHENTICATION RESPONSE (res = 9e449d778a42eeac) > 20170607113541234 DVLR <001d> vlr.c:1043 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_WAIT_RESP}: > Received Event VLR_AUTH_E_MS_AUTH_RESP > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:142 SUBSCR(MSISDN:333) > received res: 9e 44 9d 77 8a 42 ee ac > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:179 SUBSCR(MSISDN:333) AUTH > established UMTS security context > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:231 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_WAIT_RESP}: > Authentication terminating with result VLR_AUTH_RES_PASSED > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:235 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_WAIT_RESP}: > state_chg to VLR_SUB_AS_AUTHENTICATED > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_AUTHENTICATED}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_AUTHENTICATED}: > Removing from parent vlr_lu_fsm(901700000014922)[0x1ca9930] > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_AUTHENTICATED}: > Freeing instance > 20170607113541234 DVLR <001d> fsm.c:275 > VLR_Authenticate(901700000014922)[0x1ca9e90]{VLR_SUB_AS_AUTHENTICATED}: > Deallocated > 20170607113541234 DVLR <001d> vlr_auth_fsm.c:240 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_AUTH}: Received Event > VLR_ULA_E_AUTH_RES > 20170607113541235 DVLR <001d> vlr_lu_fsm.c:812 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_AUTH}: > vlr_loc_upd_post_auth() > 20170607113541235 DMM <0002> gsm_04_08.c:3775 -> SECURITY MODE CONTROL > MSISDN:333 > 20170607113541235 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113541235 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 06 00 1e > 00 00 02 00 0c 00 12 08 08 54 f3 2a fb f3 bc ad d1 34 fd 7a 9e 35 33 e7 34 > 00 4b 00 01 40 00 00 ) > 20170607113541235 DVLR <001d> vlr_lu_fsm.c:830 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_AUTH}: state_chg to > VLR_ULA_S_WAIT_CIPH > 20170607113541235 DMM <0002> osmo_msc.c:54 MSISDN:333: bump: conn still > being established (SUBSCR_CONN_S_NEW) > 20170607113541235 DLINP <0021> stream.c:802 connected read/write > 20170607113541235 DLINP <0021> stream.c:767 sending data > 20170607113541235 DLINP <0021> stream.c:802 connected read/write > 20170607113541235 DLINP <0021> stream.c:767 sending data > 20170607113541471 DLINP <0021> stream.c:802 connected read/write > 20170607113541471 DLINP <0021> stream.c:750 message received > 20170607113541471 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 40 > 20170607113541471 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113541471 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113541471 DRANAP <001a> iu.c:754 N-DATA.ind(1, 20 06 00 08 00 00 > 01 00 06 00 01 00 ) > 20170607113541471 DRSL <0004> ranap_common_cn.c:137 Rx CO SO (Security > Mode Control) > 20170607113541471 DRLL <0000> ranap_decoder.c:4315 Decoding message > RANAP_SecurityModeCompleteIEs (ranap_decoder.c:4315) > 20170607113541471 DRANAP <001a> iu.c:468 handle_co(dir=2, proc=6) > 20170607113541471 DIUCS <001e> msc_main.c:335 got IuCS event 1: > IU_EVENT_SECURITY_MODE_COMPLETE > 20170607113541471 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 1 > 20170607113541471 DIUCS <001e> iucs.c:76 0: MSISDN:333 Iu link > 0x1c7fde0, conn_id 1 > 20170607113541471 DIUCS <001e> iucs.c:101 subscribers registered: 1 > 20170607113541471 DIUCS <001e> iucs.c:122 Found IuCS subscriber for > link_id 0x1c7fde0, conn_id 1 > 20170607113541471 DIUCS <001e> iucs_ranap.c:95 IuCS security mode complete > for MSISDN:333 > 20170607113541471 DMM <0002> gsm_04_08.c:3798 <- SECURITY MODE COMPLETE > MSISDN:333 > 20170607113541471 DVLR <001d> vlr.c:1052 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_CIPH}: Received Event > VLR_ULA_E_CIPH_RES > 20170607113541471 DVLR <001d> vlr_lu_fsm.c:780 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_CIPH}: > vlr_loc_upd_post_ciph() > 20170607113541471 DIUCS <001e> msc_ifaces.c:116 MSISDN:333: tx CommonID > 901700000014922 > 20170607113541471 DRANAP <001a> iu.c:258 Transmitting RANAP CommonID (SUA > link 0x1c7fde0 conn_id 1) > 20170607113541471 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113541471 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 30 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 18 00 0f 40 10 > 00 00 01 00 17 40 09 50 09 71 00 00 00 41 29 f2 ) > 20170607113541471 DVLR <001d> vlr_lu_fsm.c:743 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_CIPH}: > vlr_loc_upd_node_4() > 20170607113541471 DVLR <001d> vlr_lu_fsm.c:752 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_CIPH}: state_chg to > VLR_ULA_S_WAIT_HLR_UPD > 20170607113541471 DVLR <001d> fsm.c:231 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_INIT}: Allocated > 20170607113541471 DVLR <001d> fsm.c:261 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_INIT}: is child > of vlr_lu_fsm(901700000014922)[0x1ca9930] > 20170607113541471 DVLR <001d> vlr_lu_fsm.c:164 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_INIT}: Received > Event UPD_HLR_VLR_E_START > 20170607113541471 DVLR <001d> vlr.c:145 GSUP tx: 04010809710000004129f2 > 20170607113541471 DVLR <001d> vlr_lu_fsm.c:81 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_INIT}: state_chg > to UPD_HLR_VLR_S_WAIT_FOR_DATA > 20170607113541471 DLINP <0021> input/ipa.c:140 connected write > 20170607113541471 DLINP <0021> input/ipa.c:90 sending data > 20170607113541471 DLINP <0021> stream.c:802 connected read/write > 20170607113541471 DLINP <0021> stream.c:767 sending data > 20170607113541471 DLINP <0021> input/ipa.c:140 connected write > 20170607113541471 DLINP <0021> input/ipa.c:90 sending data > 20170607113541471 DLINP <0021> stream.c:802 connected read/write > 20170607113541471 DLINP <0021> stream.c:767 sending data > 20170607113541472 DLINP <0021> input/ipa.c:136 connected read > 20170607113541472 DLINP <0021> input/ipa.c:54 message received > 20170607113541472 DVLR <001d> vlr.c:790 GSUP rx 16: > 10010809710000004129f208030233f3 > 20170607113541473 DVLR <001d> vlr.c:646 IMSI:901700000014922 has MSISDN:333 > 20170607113541473 DVLR <001d> vlr.c:145 GSUP tx: 12010809710000004129f2 > 20170607113541473 DLINP <0021> input/ipa.c:140 connected write > 20170607113541473 DLINP <0021> input/ipa.c:90 sending data > 20170607113541473 DLINP <0021> input/ipa.c:140 connected write > 20170607113541473 DLINP <0021> input/ipa.c:90 sending data > 20170607113541473 DLINP <0021> input/ipa.c:136 connected read > 20170607113541473 DLINP <0021> input/ipa.c:54 message received > 20170607113541473 DVLR <001d> vlr.c:790 GSUP rx 11: 06010809710000004129f2 > 20170607113541473 DVLR <001d> vlr.c:736 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_HLR_UPD}: Received > Event VLR_ULA_E_HLR_LU_RES > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:1145 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_WAIT_FOR_DATA}: > Received Event UPD_HLR_VLR_E_UPD_LOC_ACK > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:103 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_WAIT_FOR_DATA}: > state_chg to UPD_HLR_VLR_S_DONE > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_DONE}: Removing > from parent vlr_lu_fsm(901700000014922)[0x1ca9930] > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_DONE}: Freeing > instance > 20170607113541473 DVLR <001d> fsm.c:275 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8b20]{UPD_HLR_VLR_S_DONE}: Deallocated > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:104 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_HLR_UPD}: Received > Event VLR_ULA_E_UPD_HLR_COMPL > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:1153 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_HLR_UPD}: state_chg > to VLR_ULA_S_WAIT_LU_COMPL > 20170607113541473 DVLR <001d> fsm.c:231 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_INIT}: Allocated > 20170607113541473 DVLR <001d> fsm.c:261 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_INIT}: is child > of vlr_lu_fsm(901700000014922)[0x1ca9930] > 20170607113541473 DVLR <001d> vlr_lu_fsm.c:725 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_INIT}: Received > Event LU_COMPL_VLR_E_START > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:385 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_INIT}: > state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES > 20170607113541474 DVLR <001d> fsm.c:231 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_INIT}: Allocated > 20170607113541474 DVLR <001d> fsm.c:261 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_INIT}: is child > of lu_compl_vlr_fsm(901700000014922)[0x1c81380] > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:267 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_INIT}: Received > Event SUB_PRES_VLR_E_START > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:200 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_INIT}: > state_chg to SUB_PRES_VLR_S_DONE > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_DONE}: Removing > from parent lu_compl_vlr_fsm(901700000014922)[0x1c81380] > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_DONE}: Freeing > instance > 20170607113541474 DVLR <001d> fsm.c:275 > sub_pres_vlr_fsm(901700000014922)[0x1ca89c0]{SUB_PRES_VLR_S_DONE}: > Deallocated > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:201 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: > Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL > 20170607113541474 DMM <0002> gsm_04_08.c:201 -> MSISDN:333 LOCATION UPDATE > ACCEPT > 20170607113541474 DMSC <000a> msc_ifaces.c:44 msc_tx 17 bytes to > MSISDN:333 via RAN_UTRAN_IU > 20170607113541474 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP > DT (SUA link 0x1c7fde0 conn_id 1) > 20170607113541474 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113541474 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 14 00 1e > 00 00 02 00 10 40 12 11 05 02 09 f1 89 28 b6 17 08 99 10 07 00 00 10 94 22 > 00 3b 40 01 00 00 00 ) > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:321 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: > state_chg to LU_COMPL_VLR_S_DONE > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:355 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_LU_COMPL}: Received > Event VLR_ULA_E_LU_COMPL_SUCCESS > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_PARENT) > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_DONE}: Removing > from parent vlr_lu_fsm(901700000014922)[0x1ca9930] > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_DONE}: Freeing > instance > 20170607113541474 DVLR <001d> fsm.c:275 > lu_compl_vlr_fsm(901700000014922)[0x1c81380]{LU_COMPL_VLR_S_DONE}: > Deallocated > 20170607113541474 DVLR <001d> vlr_lu_fsm.c:700 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg > to VLR_ULA_S_DONE > 20170607113541474 DMM <0002> vlr_lu_fsm.c:692 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_NEW}: Received Event > SUBSCR_CONN_E_ACCEPTED > 20170607113541474 DMM <0002> subscr_conn.c:77 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_NEW}: > SUBSCR_CONN_FROM_LU > 20170607113541474 DMM <0002> subscr_conn.c:84 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_NEW}: state_chg to > SUBSCR_CONN_S_ACCEPTED > 20170607113541476 DMM <0002> subscr_conn.c:132 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_ACCEPTED}: Received > Event SUBSCR_CONN_E_BUMP > 20170607113541476 DMM <0002> subscr_conn.c:168 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_ACCEPTED}: bump: > releasing conn > 20170607113541476 DMM <0002> subscr_conn.c:169 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_ACCEPTED}: state_chg > to SUBSCR_CONN_S_RELEASED > 20170607113541476 DMM <0002> subscr_conn.c:255 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_RELEASED}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113541476 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_DONE}: Terminating (cause > = OSMO_FSM_TERM_PARENT) > 20170607113541476 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_DONE}: Removing from > parent Subscr_Conn(901700000014922)[0x1ca5290] > 20170607113541477 DVLR <001d> vlr_lu_fsm.c:1342 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_DONE}: fsm_lu_cleanup > called with cause OSMO_FSM_TERM_PARENT > 20170607113541477 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_DONE}: Freeing instance > 20170607113541477 DVLR <001d> fsm.c:275 > vlr_lu_fsm(901700000014922)[0x1ca9930]{VLR_ULA_S_DONE}: Deallocated > 20170607113541477 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113541477 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 2c 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 11 00 01 00 09 > 00 00 01 00 04 40 02 07 80 00 00 00 ) > 20170607113541477 DRLL <0000> osmo_msc.c:211 subscr MSISDN:333: Freeing > subscriber connection > 20170607113541477 DMM <0002> subscr_conn.c:255 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_RELEASED}: Freeing > instance > 20170607113541477 DMM <0002> fsm.c:275 > Subscr_Conn(901700000014922)[0x1ca5290]{SUBSCR_CONN_S_RELEASED}: Deallocated > 20170607113541477 DLINP <0021> stream.c:802 connected read/write > 20170607113541477 DLINP <0021> stream.c:767 sending data > 20170607113541477 DLINP <0021> stream.c:802 connected read/write > 20170607113541477 DLINP <0021> stream.c:767 sending data > 20170607113541477 DLINP <0021> stream.c:802 connected read/write > 20170607113541477 DLINP <0021> stream.c:767 sending data > 20170607113541687 DLINP <0021> stream.c:802 connected read/write > 20170607113541687 DLINP <0021> stream.c:750 message received > 20170607113541687 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 52 > 20170607113541687 DSUA <001b> sua.c:1146 Received SUA Message (8:4) > 20170607113541687 DRANAP <001a> iu.c:721 > sccp_sap_up(N-DISCONNECTindication) > 20170607113541687 DRANAP <001a> iu.c:747 N-DISCONNECT.ind(1) > 20170607113541687 DRSL <0004> ranap_common_cn.c:137 Rx CO SO (Iu Release) > 20170607113541687 DRLL <0000> ranap_decoder.c:4055 Decoding message > RANAP_Iu_ReleaseCompleteIEs (ranap_decoder.c:4055) > 20170607113541687 DRANAP <001a> iu.c:468 handle_co(dir=2, proc=1) > 20170607113541687 DIUCS <001e> msc_main.c:335 got IuCS event 2: > IU_EVENT_IU_RELEASE > 20170607113541687 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 1 > 20170607113541687 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113541687 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7fde0, conn_id 1 > 20170607113541687 DRANAP <001a> iucs_ranap.c:81 Cannot find subscriber for > IU event 2 > 20170607113541687 DRANAP <001a> iu.c:504 Iu Release event: Iu Event > callback returned -1 > 20170607113541687 DRANAP <001a> iu.c:537 Error in cn_ranap_handle_co (-1) > 20170607113541687 DSUA <001b> sua.c:254 (1) state chg ACTIVE->IDLE > 20170607113542816 DLGSUP <0029> gsup_client.c:244 GSUP ping callback > (connected, got PONG) > 20170607113542816 DLGSUP <0029> gsup_client.c:265 GSUP sending PING > 20170607113542816 DLINP <0021> input/ipa.c:140 connected write > 20170607113542817 DLINP <0021> input/ipa.c:90 sending data > 20170607113542817 DLINP <0021> input/ipa.c:140 connected write > 20170607113542817 DLINP <0021> input/ipa.c:90 sending data > 20170607113542817 DLINP <0021> input/ipa.c:136 connected read > 20170607113542817 DLINP <0021> input/ipa.c:54 message received > 20170607113542817 DLGSUP <0029> gsup_client.c:201 GSUP receiving PONG > 20170607113555085 DLINP <0021> stream.c:802 connected read/write > 20170607113555085 DLINP <0021> stream.c:750 message received > 20170607113555085 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 132 > 20170607113555085 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113555085 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113555085 DRANAP <001a> iu.c:754 N-DATA.ind(0, 00 14 40 61 00 00 > 04 00 10 40 3f 3e 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 ff > ff 00 ff fe ff 1a 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 e8 > c4 b1 98 87 91 00 26 17 05 58 04 e0 60 c0 40 5d 01 00 00 0f 40 06 00 09 f1 > 07 28 b6 00 37 40 01 63 00 3a 40 08 00 09 f1 07 ff ff ff ff ) > 20170607113555085 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Direct > Transfer) > 20170607113555085 DRLL <0000> ranap_decoder.c:3197 Decoding message > RANAP_DirectTransferIEs (ranap_decoder.c:3197) > 20170607113555085 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=20) > 20170607113555085 DIUCS <001e> msc_main.c:321 got IuCS message 62 bytes: > 08 01 03 e5 e0 34 71 0a 00 08 99 10 07 00 00 10 94 22 ff ff 00 ff fe ff 1a > 19 53 43 2b 25 96 62 1e 44 00 9d d8 c6 33 10 f2 20 04 e8 c4 b1 98 87 91 00 > 26 17 05 58 04 e0 60 c0 40 5d 01 00 > 20170607113555085 DIUCS <001e> msc_main.c:325 got IuCS message on MNC 70 > MCC 901 LAC 10422 RAC 99 > 20170607113555085 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7e310, conn_id 0 > 20170607113555085 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113555086 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7e310, conn_id 0 > 20170607113555086 DIUCS <001e> iucs.c:44 Allocating IuCS subscriber conn: > lac 10422, link_id 0x1c7e310, conn_id 0 > 20170607113555086 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_PDISC_MM_GPRS:0x01 (0x8:0x1) > 20170607113555086 DRLL <0000> gsm_04_08.c:3602 subscr unknown: Message not > permitted for initial conn: GSM48_PDISC_MM_GPRS:0x01 > 20170607113555086 DRLL <0000> osmo_msc.c:217 Freeing subscriber connection > with NULL subscriber > 20170607113557339 DLINP <0021> stream.c:802 connected read/write > 20170607113557339 DLINP <0021> stream.c:750 message received > 20170607113557339 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 132 > 20170607113557339 DSUA <001b> sua.c:1146 Received SUA Message (8:1) > 20170607113557339 DSUA <001b> sua.c:659 sua_parse_addr(IEI=259) (4) 00 02 > 00 07 > 20170607113557339 DSUA <001b> sua.c:254 (2) state chg IDLE->CONN_PEND_IN > 20170607113557339 DRANAP <001a> iu.c:721 sccp_sap_up(N-CONNECTindication) > 20170607113557339 DRANAP <001a> iu.c:730 N-CONNECT.ind(X->2) > 20170607113557339 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-CONNECTresponse) > 20170607113557339 DSUA <001b> sua.c:254 (2) state chg CONN_PEND_IN->ACTIVE > 20170607113557339 DSUA <001b> sua.c:160 sua_link_send(01 00 08 02 00 00 00 > 30 00 06 00 08 00 00 00 00 01 15 00 08 00 00 00 02 01 05 00 08 00 00 03 e8 > 01 04 00 08 00 00 00 02 01 16 00 08 00 00 00 00 ) > 20170607113557339 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Initial UE > Message) > 20170607113557339 DRLL <0000> ranap_decoder.c:2641 Decoding message > RANAP_InitialUE_MessageIEs (ranap_decoder.c:2641) > 20170607113557339 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=19) > 20170607113557339 DIUCS <001e> msc_main.c:321 got IuCS message 23 bytes: > 05 08 70 09 f1 89 ff fe 57 08 99 10 07 00 00 10 94 22 33 03 57 58 a6 > 20170607113557339 DIUCS <001e> msc_main.c:325 got IuCS message on MNC 70 > MCC 901 LAC 10422 RAC 0 > 20170607113557339 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 2 > 20170607113557340 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113557340 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7fde0, conn_id 2 > 20170607113557340 DIUCS <001e> iucs.c:44 Allocating IuCS subscriber conn: > lac 10422, link_id 0x1c7fde0, conn_id 2 > 20170607113557340 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8) > 20170607113557340 DMM <0002> fsm.c:231 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_INIT}: Allocated > 20170607113557340 DMM <0002> subscr_conn.c:344 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_INIT}: Received Event > SUBSCR_CONN_E_START > 20170607113557340 DMM <0002> subscr_conn.c:66 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_INIT}: state_chg to > SUBSCR_CONN_S_NEW > 20170607113557340 DMM <0002> gsm_04_08.c:300 LOCATION UPDATING REQUEST: > MI(IMSI)=901700000014922 type=NORMAL > 20170607113557340 DMM <0002> gsm_04_08.c:345 LU/new-LAC: 65534/10422 > 20170607113557340 DVLR <001d> fsm.c:231 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_IDLE}: Allocated > 20170607113557340 DVLR <001d> fsm.c:261 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_IDLE}: is child of > Subscr_Conn(901700000014922)[0x1c815d0] > 20170607113557340 DVLR <001d> vlr_lu_fsm.c:1409 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_IDLE}: rev=R99 net=UTRAN > Auth+Ciph > 20170607113557340 DVLR <001d> vlr_lu_fsm.c:1415 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_IDLE}: Received Event > VLR_ULA_E_UPDATE_LA > 20170607113557340 DVLR <001d> vlr_lu_fsm.c:838 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1() > 20170607113557340 DVLR <001d> vlr_lu_fsm.c:845 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_IDLE}: state_chg to > VLR_ULA_S_WAIT_AUTH > 20170607113557340 DVLR <001d> fsm.c:231 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_NEEDS_AUTH}: > Allocated > 20170607113557340 DVLR <001d> fsm.c:261 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_NEEDS_AUTH}: is > child of vlr_lu_fsm(901700000014922)[0x1c81700] > 20170607113557340 DVLR <001d> vlr_auth_fsm.c:602 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_NEEDS_AUTH}: > Received Event VLR_AUTH_E_START > 20170607113557340 DVLR <001d> vlr_auth_fsm.c:300 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_NEEDS_AUTH}: > state_chg to VLR_SUB_AS_WAIT_RESP > 20170607113557340 DVLR <001d> vlr_auth_fsm.c:263 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_WAIT_RESP}: got > auth tuple: use_count=1 key_seq=2 > 20170607113557340 DMM <0002> gsm_04_08.c:552 -> AUTH REQ (rand = > 1cbff4654712b2bffdaeea373dfd28d4) > 20170607113557340 DMM <0002> gsm_04_08.c:554 AUTH REQ (autn = > 0075752ddbce0000d91fcdc34c0acc54) > 20170607113557340 DMSC <000a> msc_ifaces.c:44 msc_tx 37 bytes to > MSISDN:333 via RAN_UTRAN_IU > 20170607113557340 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP > DT (SUA link 0x1c7fde0 conn_id 2) > 20170607113557340 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113557340 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 54 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 3a 00 14 00 32 > 00 00 02 00 10 40 26 25 05 12 02 1c bf f4 65 47 12 b2 bf fd ae ea 37 3d fd > 28 d4 20 10 00 75 75 2d db ce 00 00 d9 1f cd c3 4c 0a cc 54 00 3b 40 01 00 > 00 00 ) > 20170607113557340 DMM <0002> osmo_msc.c:54 MSISDN:333: bump: conn still > being established (SUBSCR_CONN_S_NEW) > 20170607113557340 DLINP <0021> stream.c:802 connected read/write > 20170607113557341 DLINP <0021> stream.c:767 sending data > 20170607113557341 DLINP <0021> stream.c:802 connected read/write > 20170607113557341 DLINP <0021> stream.c:767 sending data > 20170607113557341 DLINP <0021> stream.c:802 connected read/write > 20170607113557341 DLINP <0021> stream.c:767 sending data > 20170607113558464 DLINP <0021> stream.c:802 connected read/write > 20170607113558464 DLINP <0021> stream.c:750 message received > 20170607113558465 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 52 > 20170607113558465 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113558465 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113558465 DRANAP <001a> iu.c:754 N-DATA.ind(2, 00 14 40 14 00 00 > 01 00 10 40 0d 0c 05 54 e5 d3 56 43 21 04 98 c6 f8 13 ) > 20170607113558465 DRSL <0004> ranap_common_cn.c:43 Rx CO IM (Direct > Transfer) > 20170607113558465 DRLL <0000> ranap_decoder.c:3197 Decoding message > RANAP_DirectTransferIEs (ranap_decoder.c:3197) > 20170607113558465 DRANAP <001a> iu.c:468 handle_co(dir=1, proc=20) > 20170607113558465 DIUCS <001e> msc_main.c:321 got IuCS message 12 bytes: > 05 54 e5 d3 56 43 21 04 98 c6 f8 13 > 20170607113558465 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 2 > 20170607113558465 DIUCS <001e> iucs.c:76 0: MSISDN:333 Iu link > 0x1c7fde0, conn_id 2 > 20170607113558465 DIUCS <001e> iucs.c:101 subscribers registered: 1 > 20170607113558465 DIUCS <001e> iucs.c:122 Found IuCS subscriber for > link_id 0x1c7fde0, conn_id 2 > 20170607113558465 DRLL <0000> gsm_04_08.c:3595 Dispatching 04.08 message > GSM48_MT_MM_AUTH_RESP (0x5:0x14) > 20170607113558465 DMM <0002> gsm_04_08.c:908 MSISDN:333: MM R99 > AUTHENTICATION RESPONSE (res = e5d3564398c6f813) > 20170607113558465 DVLR <001d> vlr.c:1043 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_WAIT_RESP}: > Received Event VLR_AUTH_E_MS_AUTH_RESP > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:142 SUBSCR(MSISDN:333) > received res: e5 d3 56 43 98 c6 f8 13 > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:179 SUBSCR(MSISDN:333) AUTH > established UMTS security context > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:231 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_WAIT_RESP}: > Authentication terminating with result VLR_AUTH_RES_PASSED > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:235 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_WAIT_RESP}: > state_chg to VLR_SUB_AS_AUTHENTICATED > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_AUTHENTICATED}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_AUTHENTICATED}: > Removing from parent vlr_lu_fsm(901700000014922)[0x1c81700] > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:240 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_AUTHENTICATED}: > Freeing instance > 20170607113558465 DVLR <001d> fsm.c:275 > VLR_Authenticate(901700000014922)[0x1caaaa0]{VLR_SUB_AS_AUTHENTICATED}: > Deallocated > 20170607113558465 DVLR <001d> vlr_auth_fsm.c:240 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_AUTH}: Received Event > VLR_ULA_E_AUTH_RES > 20170607113558465 DVLR <001d> vlr_lu_fsm.c:812 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_AUTH}: > vlr_loc_upd_post_auth() > 20170607113558465 DMM <0002> gsm_04_08.c:3775 -> SECURITY MODE CONTROL > MSISDN:333 > 20170607113558465 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113558465 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 06 00 1e > 00 00 02 00 0c 00 12 08 08 56 7c 68 61 09 4a 59 3c c7 7f fb 3a c8 d3 13 1c > 00 4b 00 01 40 00 00 ) > 20170607113558466 DVLR <001d> vlr_lu_fsm.c:830 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_AUTH}: state_chg to > VLR_ULA_S_WAIT_CIPH > 20170607113558466 DMM <0002> osmo_msc.c:54 MSISDN:333: bump: conn still > being established (SUBSCR_CONN_S_NEW) > 20170607113558466 DLINP <0021> stream.c:802 connected read/write > 20170607113558466 DLINP <0021> stream.c:767 sending data > 20170607113558466 DLINP <0021> stream.c:802 connected read/write > 20170607113558466 DLINP <0021> stream.c:767 sending data > 20170607113559029 DLINP <0021> stream.c:802 connected read/write > 20170607113559029 DLINP <0021> stream.c:750 message received > 20170607113559030 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 40 > 20170607113559030 DSUA <001b> sua.c:1146 Received SUA Message (8:8) > 20170607113559030 DRANAP <001a> iu.c:721 sccp_sap_up(N-DATAindication) > 20170607113559030 DRANAP <001a> iu.c:754 N-DATA.ind(2, 20 06 00 08 00 00 > 01 00 06 00 01 00 ) > 20170607113559030 DRSL <0004> ranap_common_cn.c:137 Rx CO SO (Security > Mode Control) > 20170607113559030 DRLL <0000> ranap_decoder.c:4315 Decoding message > RANAP_SecurityModeCompleteIEs (ranap_decoder.c:4315) > 20170607113559031 DRANAP <001a> iu.c:468 handle_co(dir=2, proc=6) > 20170607113559031 DIUCS <001e> msc_main.c:335 got IuCS event 1: > IU_EVENT_SECURITY_MODE_COMPLETE > 20170607113559031 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 2 > 20170607113559031 DIUCS <001e> iucs.c:76 0: MSISDN:333 Iu link > 0x1c7fde0, conn_id 2 > 20170607113559031 DIUCS <001e> iucs.c:101 subscribers registered: 1 > 20170607113559031 DIUCS <001e> iucs.c:122 Found IuCS subscriber for > link_id 0x1c7fde0, conn_id 2 > 20170607113559031 DIUCS <001e> iucs_ranap.c:95 IuCS security mode complete > for MSISDN:333 > 20170607113559031 DMM <0002> gsm_04_08.c:3798 <- SECURITY MODE COMPLETE > MSISDN:333 > 20170607113559031 DVLR <001d> vlr.c:1052 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_CIPH}: Received Event > VLR_ULA_E_CIPH_RES > 20170607113559031 DVLR <001d> vlr_lu_fsm.c:780 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_CIPH}: > vlr_loc_upd_post_ciph() > 20170607113559031 DIUCS <001e> msc_ifaces.c:116 MSISDN:333: tx CommonID > 901700000014922 > 20170607113559031 DRANAP <001a> iu.c:258 Transmitting RANAP CommonID (SUA > link 0x1c7fde0 conn_id 2) > 20170607113559031 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113559031 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 30 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 18 00 0f 40 10 > 00 00 01 00 17 40 09 50 09 71 00 00 00 41 29 f2 ) > 20170607113559031 DVLR <001d> vlr_lu_fsm.c:743 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_CIPH}: > vlr_loc_upd_node_4() > 20170607113559031 DVLR <001d> vlr_lu_fsm.c:752 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_CIPH}: state_chg to > VLR_ULA_S_WAIT_HLR_UPD > 20170607113559031 DVLR <001d> fsm.c:231 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_INIT}: Allocated > 20170607113559031 DVLR <001d> fsm.c:261 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_INIT}: is child > of vlr_lu_fsm(901700000014922)[0x1c81700] > 20170607113559031 DVLR <001d> vlr_lu_fsm.c:164 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_INIT}: Received > Event UPD_HLR_VLR_E_START > 20170607113559031 DVLR <001d> vlr.c:145 GSUP tx: 04010809710000004129f2 > 20170607113559031 DVLR <001d> vlr_lu_fsm.c:81 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_INIT}: state_chg > to UPD_HLR_VLR_S_WAIT_FOR_DATA > 20170607113559031 DLINP <0021> input/ipa.c:140 connected write > 20170607113559031 DLINP <0021> input/ipa.c:90 sending data > 20170607113559031 DLINP <0021> stream.c:802 connected read/write > 20170607113559031 DLINP <0021> stream.c:767 sending data > 20170607113559031 DLINP <0021> input/ipa.c:140 connected write > 20170607113559032 DLINP <0021> input/ipa.c:90 sending data > 20170607113559032 DLINP <0021> stream.c:802 connected read/write > 20170607113559032 DLINP <0021> stream.c:767 sending data > 20170607113559032 DLINP <0021> input/ipa.c:136 connected read > 20170607113559032 DLINP <0021> input/ipa.c:54 message received > 20170607113559032 DVLR <001d> vlr.c:790 GSUP rx 16: > 10010809710000004129f208030233f3 > 20170607113559032 DVLR <001d> vlr.c:646 IMSI:901700000014922 has MSISDN:333 > 20170607113559032 DVLR <001d> vlr.c:145 GSUP tx: 12010809710000004129f2 > 20170607113559032 DLINP <0021> input/ipa.c:140 connected write > 20170607113559032 DLINP <0021> input/ipa.c:90 sending data > 20170607113559032 DLINP <0021> input/ipa.c:140 connected write > 20170607113559032 DLINP <0021> input/ipa.c:90 sending data > 20170607113559032 DLINP <0021> input/ipa.c:136 connected read > 20170607113559032 DLINP <0021> input/ipa.c:54 message received > 20170607113559032 DVLR <001d> vlr.c:790 GSUP rx 11: 06010809710000004129f2 > 20170607113559032 DVLR <001d> vlr.c:736 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_HLR_UPD}: Received > Event VLR_ULA_E_HLR_LU_RES > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:1145 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_WAIT_FOR_DATA}: > Received Event UPD_HLR_VLR_E_UPD_LOC_ACK > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:103 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_WAIT_FOR_DATA}: > state_chg to UPD_HLR_VLR_S_DONE > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_DONE}: Removing > from parent vlr_lu_fsm(901700000014922)[0x1c81700] > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:104 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_DONE}: Freeing > instance > 20170607113559033 DVLR <001d> fsm.c:275 > upd_hlr_vlr_fsm(901700000014922)[0x1ca8940]{UPD_HLR_VLR_S_DONE}: Deallocated > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:104 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_HLR_UPD}: Received > Event VLR_ULA_E_UPD_HLR_COMPL > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:1153 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_HLR_UPD}: state_chg > to VLR_ULA_S_WAIT_LU_COMPL > 20170607113559033 DVLR <001d> fsm.c:231 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_INIT}: Allocated > 20170607113559033 DVLR <001d> fsm.c:261 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_INIT}: is child > of vlr_lu_fsm(901700000014922)[0x1c81700] > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:725 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_INIT}: Received > Event LU_COMPL_VLR_E_START > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:385 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_INIT}: > state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES > 20170607113559033 DVLR <001d> fsm.c:231 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_INIT}: Allocated > 20170607113559033 DVLR <001d> fsm.c:261 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_INIT}: is child > of lu_compl_vlr_fsm(901700000014922)[0x1ca9840] > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:267 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_INIT}: Received > Event SUB_PRES_VLR_E_START > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:200 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_INIT}: > state_chg to SUB_PRES_VLR_S_DONE > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_DONE}: Removing > from parent lu_compl_vlr_fsm(901700000014922)[0x1ca9840] > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:201 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_DONE}: Freeing > instance > 20170607113559033 DVLR <001d> fsm.c:275 > sub_pres_vlr_fsm(901700000014922)[0x1caa850]{SUB_PRES_VLR_S_DONE}: > Deallocated > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:201 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: > Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL > 20170607113559033 DMM <0002> gsm_04_08.c:201 -> MSISDN:333 LOCATION UPDATE > ACCEPT > 20170607113559033 DMSC <000a> msc_ifaces.c:44 msc_tx 17 bytes to > MSISDN:333 via RAN_UTRAN_IU > 20170607113559033 DRANAP <001a> iu.c:391 Transmitting L3 Message as RANAP > DT (SUA link 0x1c7fde0 conn_id 2) > 20170607113559033 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113559033 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 40 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 26 00 14 00 1e > 00 00 02 00 10 40 12 11 05 02 09 f1 89 28 b6 17 08 99 10 07 00 00 10 94 22 > 00 3b 40 01 00 00 00 ) > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:321 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_WAIT_SUB_PRES}: > state_chg to LU_COMPL_VLR_S_DONE > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:355 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_LU_COMPL}: Received > Event VLR_ULA_E_LU_COMPL_SUCCESS > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_DONE}: > Terminating (cause = OSMO_FSM_TERM_PARENT) > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_DONE}: Removing > from parent vlr_lu_fsm(901700000014922)[0x1c81700] > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:733 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_DONE}: Freeing > instance > 20170607113559033 DVLR <001d> fsm.c:275 > lu_compl_vlr_fsm(901700000014922)[0x1ca9840]{LU_COMPL_VLR_S_DONE}: > Deallocated > 20170607113559033 DVLR <001d> vlr_lu_fsm.c:700 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_WAIT_LU_COMPL}: state_chg > to VLR_ULA_S_DONE > 20170607113559033 DMM <0002> vlr_lu_fsm.c:692 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_NEW}: Received Event > SUBSCR_CONN_E_ACCEPTED > 20170607113559033 DMM <0002> subscr_conn.c:77 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_NEW}: > SUBSCR_CONN_FROM_LU > 20170607113559033 DMM <0002> subscr_conn.c:84 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_NEW}: state_chg to > SUBSCR_CONN_S_ACCEPTED > 20170607113559035 DMM <0002> subscr_conn.c:132 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_ACCEPTED}: Received > Event SUBSCR_CONN_E_BUMP > 20170607113559035 DMM <0002> subscr_conn.c:168 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_ACCEPTED}: bump: > releasing conn > 20170607113559035 DMM <0002> subscr_conn.c:169 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_ACCEPTED}: state_chg > to SUBSCR_CONN_S_RELEASED > 20170607113559035 DMM <0002> subscr_conn.c:255 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_RELEASED}: > Terminating (cause = OSMO_FSM_TERM_REGULAR) > 20170607113559035 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_DONE}: Terminating (cause > = OSMO_FSM_TERM_PARENT) > 20170607113559035 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_DONE}: Removing from > parent Subscr_Conn(901700000014922)[0x1c815d0] > 20170607113559035 DVLR <001d> vlr_lu_fsm.c:1342 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_DONE}: fsm_lu_cleanup > called with cause OSMO_FSM_TERM_PARENT > 20170607113559035 DVLR <001d> subscr_conn.c:255 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_DONE}: Freeing instance > 20170607113559035 DVLR <001d> fsm.c:275 > vlr_lu_fsm(901700000014922)[0x1c81700]{VLR_ULA_S_DONE}: Deallocated > 20170607113559035 DSUA <001b> sua.c:506 Received SCCP User Primitive > (N-DATArequest) > 20170607113559035 DSUA <001b> sua.c:160 sua_link_send(01 00 08 08 00 00 00 > 2c 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 11 00 01 00 09 > 00 00 01 00 04 40 02 07 80 00 00 00 ) > 20170607113559035 DRLL <0000> osmo_msc.c:211 subscr MSISDN:333: Freeing > subscriber connection > 20170607113559035 DMM <0002> subscr_conn.c:255 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_RELEASED}: Freeing > instance > 20170607113559035 DMM <0002> fsm.c:275 > Subscr_Conn(901700000014922)[0x1c815d0]{SUBSCR_CONN_S_RELEASED}: Deallocated > 20170607113559035 DLINP <0021> stream.c:802 connected read/write > 20170607113559035 DLINP <0021> stream.c:767 sending data > 20170607113559035 DLINP <0021> stream.c:802 connected read/write > 20170607113559035 DLINP <0021> stream.c:767 sending data > 20170607113559035 DLINP <0021> stream.c:802 connected read/write > 20170607113559035 DLINP <0021> stream.c:767 sending data > 20170607113559644 DLINP <0021> stream.c:802 connected read/write > 20170607113559645 DLINP <0021> stream.c:750 message received > 20170607113559645 DSUA <001b> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() > returned 52 > 20170607113559645 DSUA <001b> sua.c:1146 Received SUA Message (8:4) > 20170607113559645 DRANAP <001a> iu.c:721 > sccp_sap_up(N-DISCONNECTindication) > 20170607113559645 DRANAP <001a> iu.c:747 N-DISCONNECT.ind(2) > 20170607113559645 DRSL <0004> ranap_common_cn.c:137 Rx CO SO (Iu Release) > 20170607113559645 DRLL <0000> ranap_decoder.c:4055 Decoding message > RANAP_Iu_ReleaseCompleteIEs (ranap_decoder.c:4055) > 20170607113559645 DRANAP <001a> iu.c:468 handle_co(dir=2, proc=1) > 20170607113559645 DIUCS <001e> msc_main.c:335 got IuCS event 2: > IU_EVENT_IU_RELEASE > 20170607113559645 DIUCS <001e> iucs.c:113 Looking for IuCS subscriber: > link_id 0x1c7fde0, conn_id 2 > 20170607113559645 DIUCS <001e> iucs.c:101 subscribers registered: 0 > 20170607113559645 DIUCS <001e> iucs.c:126 No IuCS subscriber found for > link_id 0x1c7fde0, conn_id 2 > 20170607113559645 DRANAP <001a> iucs_ranap.c:81 Cannot find subscriber for > IU event 2 > 20170607113559645 DRANAP <001a> iu.c:504 Iu Release event: Iu Event > callback returned -1 > 20170607113559645 DRANAP <001a> iu.c:537 Error in cn_ranap_handle_co (-1) > 20170607113559645 DSUA <001b> sua.c:254 (2) state chg ACTIVE->IDLE what should i do to fix it? 2017-06-06 21:49 GMT+08:00 Holger Freyther : > > > On 6. Jun 2017, at 19:25, Neels Hofmeyr wrote: > > > > So everything looks good from these logs. Cannot tell why this procedure > would > > repeat over and over? Does it? > > Is a TMSI assigned? What is the TMSI? > > @Lin: Please make a trace of two/three loops and attach it to the mail. > > holger > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Jun 7 02:54:50 2017 From: holger at freyther.de (Holger Freyther) Date: Wed, 7 Jun 2017 10:54:50 +0800 Subject: Accelerate3g5 Problem in cellphone attach procedure In-Reply-To: References: <20170606112520.GA14537@my.box> <158104AB-03FA-4294-8A59-9C155EE3E77B@freyther.de> Message-ID: <51AB5F0D-2CEB-41C2-948C-BA93C6A5805D@freyther.de> > On 7. Jun 2017, at 10:48, ?? 0xroot wrote: > > Thanks for the quick reply. I wondered if I need to clarify but then assumed it would be obvious enough. With trace I meant packet trace to capture what is being sent between the different components. > > >Is a TMSI assigned? What is the TMSI? > > just fond TMSI at osmo-hnbw's terminal:(0x0 not looks good ) > > <0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014922, tmsi 0x0 the phone ME might not have a TMSI initially. Not bad. From huanglin.bupt at gmail.com Wed Jun 7 03:54:44 2017 From: huanglin.bupt at gmail.com (Lin HUANG) Date: Wed, 7 Jun 2017 11:54:44 +0800 Subject: Accelerate3g5 Problem in cellphone attach procedure In-Reply-To: <51AB5F0D-2CEB-41C2-948C-BA93C6A5805D@freyther.de> References: <20170606112520.GA14537@my.box> <158104AB-03FA-4294-8A59-9C155EE3E77B@freyther.de> <51AB5F0D-2CEB-41C2-948C-BA93C6A5805D@freyther.de> Message-ID: Thank you Holger and Neels. The problem is solved now. We re-checked out the latest version and right branch of OpenBSC. The previous branch may be wrong. Now the cellphone was successfully attached. Lin 2017-06-07 10:54 GMT+08:00 Holger Freyther : > > > On 7. Jun 2017, at 10:48, ?? 0xroot wrote: > > > > Thanks for the quick reply. > > > I wondered if I need to clarify but then assumed it would be obvious > enough. With trace I meant packet trace to capture what is being sent > between the different components. > > > > > > > >Is a TMSI assigned? What is the TMSI? > > > > just fond TMSI at osmo-hnbw's terminal:(0x0 not looks good ) > > > > <0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014922, > tmsi 0x0 > > the phone ME might not have a TMSI initially. Not bad. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Wed Jun 7 17:51:20 2017 From: tom at tsou.cc (Tom Tsou) Date: Wed, 7 Jun 2017 10:51:20 -0700 Subject: osmo-trx: Generating frame sync output on GPIO? In-Reply-To: <20170526205941.3oaulnmva73toz3v@nataraja> References: <20170526205941.3oaulnmva73toz3v@nataraja> Message-ID: Hi Harald, On Fri, May 26, 2017 at 1:59 PM, Harald Welte wrote: > I was wondering if it is possible to generate a TDMA frame sync output > on a GPIO line of a USRP device (and/or any other SDR supported by > osmo-trx). This way it would be much easier to do e.g. BER testing > by using a pure waveform/pattern generator for the "MS side". I recently tested GSM frame triggering with a B210. The UHD code itself for GPIO triggering is fairly straightforward. /* Configure GPIO-0 pin*/ usrp->set_gpio_attr("FP0", "CTRL", 0x00); usrp->set_gpio_attr("FP0", "DDR", 0x01); /* Set rise and fall times */ usrp->set_command_time(TIME_A); usrp->set_gpio_attr("FP0", "OUT", 0x01); usrp->set_command_time(TIME_B); usrp->set_gpio_attr("FP0", "OUT", 0x00); I tested the frame trigger using the B210 with osmo-trx in a new signal generator application (to be announced shortly), which works fine. But, when I attempt to trigger with full-duplex osmo-trx, the trigger becomes unstable for reasons that I do not fully understand. I'm still looking into the cause. So right now we can generate a frame trigger for the BTS downlink, but, unfortunately, not while the uplink receiver is enabled. -TT From tom at tsou.cc Wed Jun 7 18:15:48 2017 From: tom at tsou.cc (Tom Tsou) Date: Wed, 7 Jun 2017 11:15:48 -0700 Subject: osmo-trx: GSM signal generator Message-ID: Hi All, I wrote a GSM signal generator application based on osmo-trx. The new osmo-siggen allows random GSM or EDGE burst generation without using special configurations of osmo-trx or the socket control interface. Frame trigger output through GPIO is also available. I use the application for testing modulation parameters and other PHY level testing. Hopefully it's useful to other developers beyond myself. $ ./osmo-siggen -h Options: -h, --help This text -a, --args UHD device args -l --log Logging level ('err', 'warn', 'notice', 'info', 'debug') -b, --burst Burst type ('normal', 'access', 'freq', 'sync', 'edge') -r, --ref Frequency reference ('internal', 'external', 'gps') -f, --freq Tx RF frequency -g, --gain Tx RF gain -s, --sps Tx samples-per-symbol (only 4 supported) -m, --mod GSMK modulator type ('laurent4', 'laurent2', 'laurent1', 'nco') -p, --ampl Tx amplitude (0.0 - 1.0) -o, --offset Baseband frequency offset -t, --tsc Normal and EDGE burst training sequence (0-7) -S, --swap Swap channels Currently osmo-siggen is located in the below branch. I've tested solely with B210. C++14 availability is also required for now. git://git.osmocom.org/osmo-trx ttsou/siggen -TT From raji.oshin at hotmail.com Wed Jun 7 03:13:03 2017 From: raji.oshin at hotmail.com (Rajitha peiris) Date: Wed, 7 Jun 2017 03:13:03 +0000 Subject: ericsson rbs2308 Message-ID: hello everyone ...... anyone doingwith rbs2308 ? i am doing with dhai and E1 interface but it doesn't come to operational mode ....if anyone got any output from rbs 2308 pls let me thanks rajitha -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Thu Jun 8 08:35:11 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 8 Jun 2017 10:35:11 +0200 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> <20170527184325.GD1882@my.box> Message-ID: Ah, sorry, my bad - I've mixed up osmo-bsc_nat with osmo-nitb. I'm afraid at the moment there's no way to produce TRAP from OsmoNITB. You#ve got to use either OsmoBSC or OpenGGSN ( see also https://projects.osmocom.org/issues/2235 ) for tests related to control interface. As for adding test a way to produce such a trap for testing (via vty command for example) - sure, why not, should be relatively easy. Please make a ticket in https://projects.osmocom.org/ to make sure that it can be properly prioritized and won't be buried in ML archives. On 01.06.2017 23:32, emily mcmilin wrote: > Hi Max, Neels, > >> In case of NITB I >> suggest to use net.0.bsc.N.notification-rejection-v1 where N is the number you've >> used in your NITB config for bts entry (use 0 if unsure). > Is it possible include a programmatic way to test TRAP functionality > for osmo-nitb? As I am not clear on what triggers a > "notification-rejection-v1", I am unable to verify the TRAP > functionality, however I have tried to following: > > while > 1) running bsc_control.py with TRAP option in terminal 1: > `vagrant at endaga-client-osmocom:~$ python > ~/openbsc/openbsc/contrib/bsc_control.py -m -d localhost -p 4249` > > 2) blocking a physical phone that was previously connected: > a) attaching a phone with the auth policy set as: `auth policy accept-all` > b) changing the auth policy to `auth policy closed` and instigating > failed attempts to attach the same phone > > and > > 3) modifying and then deleting an arbitrary subscriber, which did not > appear to be a meaningful test of the issuance of a > "notification-rejection-v1" TRAP message, given failure setup noted > below: > ``` > vagrant at endaga-client-osmocom:~$ python > ~/openbsc/openbsc/contrib/bsc_control.py -s subscriber-modify-v1 > 2620345,445566 -d localhost -p 4249 > Got message: SET_REPLY 2448569608243303391 subscriber-modify-v1 OK > vagrant at endaga-client-osmocom:~$ python > ~/openbsc/openbsc/contrib/bsc_control.py -s subscriber-delete-v1 > 2620345,445566 -d localhost -p 4249 > Got message: ERROR 719581889546954682 Failed to find subscriber > vagrant at endaga-client-osmocom:~$ > ``` > > Nonetheless, neither produced any TRAP message in terminal 1. > > Please let me know your thoughts on a including a programmatic way to > test TRAP functionality for osmo-nitb. > > Thanks, > Emily -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Thu Jun 8 08:49:01 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 8 Jun 2017 10:49:01 +0200 Subject: osmo-trx rach question Message-ID: <7b28e3cd-0650-e2b1-5e5b-de9033fb289d@sysmocom.de> Hi. I'm troubleshooting peculiar use case with packet access and osmo-bts-trx. There are 2 options for ME to acknowledge reception of control packet to PCU according to 3GPP TS 44.060 ? 11.2.2: 1) Packet Control Acknowledgement message 2) 4 identical access bursts The latter can be both 8-bit RACH and 11-bit RACH (not supported by osmo-bts-trx yet). The choice of response format is defined by OpenBSC in SI: 1) is default, 2) can be activated with "gprs control-ack-type-rach" option. The problem is that I don't understand how 2) will be handled by OsmoTRX? Shall I expect 4 consecutive RACH messages via rx_rach_fn() in scheduler_trx.c in osmo-bts-trx? Shall it be some other message/function? Will it be ignored/dropped altogether by OsmoTRX? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From tom at tsou.cc Thu Jun 8 17:58:16 2017 From: tom at tsou.cc (Tom Tsou) Date: Thu, 8 Jun 2017 10:58:16 -0700 Subject: osmo-trx rach question In-Reply-To: <7b28e3cd-0650-e2b1-5e5b-de9033fb289d@sysmocom.de> References: <7b28e3cd-0650-e2b1-5e5b-de9033fb289d@sysmocom.de> Message-ID: Hi Max, On Thu, Jun 8, 2017 at 1:49 AM, Max wrote: > The problem is that I don't understand how 2) will be handled by OsmoTRX? Shall I > expect 4 consecutive RACH messages via rx_rach_fn() in scheduler_trx.c in > osmo-bts-trx? Shall it be some other message/function? Will it be ignored/dropped > altogether by OsmoTRX? I'm not sure about osmo-bts-trx handling, but osmo-trx itself will unconditionally report any RACH bursts detected according to the active channel combination. Those are the only two conditions - that the channel combination indicates to perform RACH detection and that the RACH burst is detected. -TT From mychaela.falconia at gmail.com Sat Jun 10 02:18:37 2017 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 9 Jun 2017 18:18:37 -0800 Subject: Creating GSM Users Association (GSMUA) In-Reply-To: <247401497031472@web42j.yandex.ru> References: <20170529081407.deqbb2gdycpcf7uf@nataraja> <247401497031472@web42j.yandex.ru> Message-ID: thayyil09 yil wrote: > michela are you kidding ( dont worrry iam a kid at twentees) Kidding about what? > calypso bb starts from leaked Docs ( if not sorry ) I don't know what you mean by "calypso bb", but OsmocomBB started from not only leaked docs, but also leaked *source code* for TI's original firmware for the chipset in question. Even though OsmocomBB people have chosen (for license worship reasons) not to make any direct reuse of TI's original code beyond a couple of L1 header files, they have extensively studied those TI firmware source leaks in order to gain the knowledge of how to operate the Calypso hardware and how to command the Calypso's DSP ROM to perform the functions it needs to perform for GSM functionality. See here for more juicy details regarding those two OsmocomBB L1 header files I just mentioned: https://www.freecalypso.org/pipermail/community/2017-April/000361.html > so why qcom code leak is ugly Where did I say that it is ugly? I have not yet had a chance to look at that QC code you keep talking about - I only downloaded it earlier today and don't have time currently to look at it in any depth, thus I am not qualified to judge whether it is ugly or beautiful or somewhere in between. > osmocom is for open softwear not for any specific hardware I am not a member of Osmocom, instead I lead my own project (FreeCalypso) in the same general space, hence the arguments regarding what Osmocom is or is not have no direct applicability to me or to my non-Osmocom project. > keeping updated with mainstream hardware is the way There is no such thing as "the way"; it may be YOUR way, but it is not *my* way. > its happy to know your the mother of freecalypso. > in softwear world you maybe first mom :) Well, some of us (me included) subscribe to the view that our poor planet is *way* overpopulated, hence engaging in biological procreation (imposing more living and resource-consuming humans on the poor planet) is akin to a crime. As a result, those of us with maternal instincts have to find a different outlet for those instincts, such as becoming the mother of a FLOSS project. :) Also leaders of FLOSS projects commonly take on titles such as principal developer, maintainer or even BDFL - but I prefer Mother. :) > and i here for osmocom on qcom == osmodroidbb.wordpress.com I assume you are talking about the QC source leak described on this page: http://syshwid.blogspot.in/2016/10/build-qualcomm-modem-msm8626.html (yes, I can read Russian just fine, it's one of my native languages) When you first posted about it back in April, I went to that page and the https://drop.me/B439WM mirror it talks about was down - appeared to have been taken down. But when I tried it again earlier today while in the process of composing this response to you, it worked, so I was finally able to download this QC source you've been talking about. However, even if this leak is 100% real source and not a semi-src (the Russian hacker says he was able to make a complete build from this source, but it doesn't mean that everything is really rebuilt from source - there could be major important pieces that are in the form of linkable binary objects, and it would take a lot of work to analyze the source to see which is the case), I have my doubts that this MSM8x26 platform would make a good replacement for FreeCalypso. I see the following (potential) problems: * According to the marketing info that I could easily find for this chip(set), it seems to be CDMA/3GPP2-oriented, which is not what I am interested in. That marketing info seems to imply that the chip supports UMTS/WCDMA too, but says nothing about GSM support. I principally refuse to use any chip, chipset or device that does not support GSM, i.e., I am potentially interested in having support for UMTS/WCDMA and maybe even LTE *in addition* to GSM/2G, but never instead of. Furthermore, one of my absolute requirements is to be able to invert the preference order for network search, i.e., have the modem always preferentially choose GSM/2G networks if such service is available, fall back to 3G/UMTS only if no GSM is available, and use LTE (or more properly VoLTE only, *without* LTE Internet service) only as the last resort when neither 2G nor 3G is available. * This MSM8x26 chip(set) has a ton of extra hardware for making those smartphones which I detest: 4 CPU cores, a powerful GPU and gawd knows what other crap. I desire a phone that can only make plain old phone calls and absolutely positively nothing else, based on a processor that has just enough horsepower to make those plain old phone calls and not one iota more, thus having all that extra application processor power would be a problem for me. * Where are the chip datasheets and reference board schematics and so forth that would be needed in order to make our own board with the chip(set) you are advocating for? Being able to build my own hardware starting from just chips is an absolute requirement for me, as I am NOT willing to use an Android slab phone, even it has a liberated baseband - I want a phone in my own personally preferred form factor (a "dumbphone" *without* Android), hence I need to be able to build my own hw in order to package it in the FF I desire. Overall, it is pretty clear to me that we are on different paths with very different interests and goals. M~ From alexander.huemer at xx.vu Sat Jun 10 16:59:09 2017 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Sat, 10 Jun 2017 18:59:09 +0200 Subject: Proposal: Usage of stow in jenkins build scripts In-Reply-To: <20170520100847.GA4327@yade.chaostreff.at> References: <20170515193957.GA2859@yade.chaostreff.at> <20170515201803.GB7018@my.box> <20170515202518.GB2859@yade.chaostreff.at> <20170519120913.GA12444@yade.chaostreff.at> <20170520100847.GA4327@yade.chaostreff.at> Message-ID: <20170610165908.GB16252@yade.chaostreff.at> Hi! On Sat, May 20, 2017 at 12:08:47PM +0200, Alexander Huemer wrote: > I now pushed the patch to gerrit as 2691[1], the change for openbsc is > 2652[2]. > > [1] https://gerrit.osmocom.org/2691 > [2] https://gerrit.osmocom.org/2652 Gentle 'ping'. Neels, are you in favor of change 2691? Kind regards, -Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Sun Jun 11 11:51:19 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Jun 2017 13:51:19 +0200 Subject: vty talloc report In-Reply-To: References: <20170531213456.GA22914@my.box> Message-ID: <20170611115119.hsyvqayy3udtr3p7@nataraja> Hi Vadim, On Thu, Jun 01, 2017 at 02:48:17PM +0700, Vadim Yanitskiy wrote: > Great news, > > > Of course, we can write a new function and register every > > root talloc context using it. What about that? > > I just found, that talloc context may be specified in vty_app_info > structure: I think in general it would be good if applications have to either register their "root" talloc contexts with libosmocore, or even have to obtain their root talloc contexts through a wrapper. This way we could then make sure to iterate all of the talloc context from within generic code in libosmovty. -- - 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 Sun Jun 11 23:55:52 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Jun 2017 01:55:52 +0200 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: <20170529132949.z57kio2ozhaehtg2@nataraja> References: <20170529132949.z57kio2ozhaehtg2@nataraja> Message-ID: <20170611235552.bvnybgyfknf2gmsc@nataraja> Hi all, On Mon, May 29, 2017 at 03:29:49PM +0200, Harald Welte wrote: > Over the weekend I was thinking of yet another method to make this much > simpler: Every phone is supposed to include a voice loop-back mode. In > this mode, the phone siply loops back all voice frames received in the > downlink and sends them back in the uplink. This functionality is > mandatory by the spec, and used to test the receiver performance of the > phone during development, manufacturing and service. IT is specified in > 3GPP TS 44.014 > (http://www.etsi.org/deliver/etsi_ts/144000_144099/144014/14.00.00_60/ts_144014v140000p.pdf) > which used to be GSM TS 04.04 > (http://www.etsi.org/deliver/etsi_ts/101200_101299/101293/08.06.00_60/ts_101293v080600p.pdf) > before. > > The idea is that one puts a special "Test SIM" (as specified in TS > 51.010-1 Annex 4, where EF.AD first byte == 0x80 is the criteria in this > context) into the phone, and then sends some specific commands on Layer3 > to activate the loop. I have now produced such a "test sim". It's as easy as to update the firsrt byte of EF.AD with 0x80, e.g. using the following APDU (after authorizing with proper credentials like ADM1 pin and selecting EF.AD): 00d60000048000ff02 I also have an experimental branch[1] of OsmoNITB which can send the loopback commands. And at least with a K800i I also get an acknowledgement. * first start a silent call to establish a dedicated TCH subscriber imsi 262423203000003 silent-call start tch/f * then send the CLOSE_TCH_LOOP command with loop type A subscriber imsi 262423203000003 ms-test close-loop a * OsmoNITB reports success: <0002> gsm_04_14.c:129 FIXME: Received TEST class message 'CLOSE_TCH_LOOP_ACK' I haven't actually tried yet to see if the voice channel is actually looped back. But at least the results look promising so far. Regards, Harald [1] http://git.osmocom.org/openbsc/log/?h=laforge/ts_04_14 -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Mon Jun 12 10:28:31 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 12 Jun 2017 12:28:31 +0200 Subject: Voice audio testing in osmo-gsm-tester In-Reply-To: <20170611235552.bvnybgyfknf2gmsc@nataraja> References: <20170529132949.z57kio2ozhaehtg2@nataraja> <20170611235552.bvnybgyfknf2gmsc@nataraja> Message-ID: <20170612102831.GB3379@my.box> On Mon, Jun 12, 2017 at 01:55:52AM +0200, Harald Welte wrote: > * first start a silent call to establish a dedicated TCH > subscriber imsi 262423203000003 silent-call start tch/f > > * then send the CLOSE_TCH_LOOP command with loop type A > subscriber imsi 262423203000003 ms-test close-loop a > > * OsmoNITB reports success: > <0002> gsm_04_14.c:129 FIXME: Received TEST class message 'CLOSE_TCH_LOOP_ACK' Nice. And apparently we don't even need ofono to do any voice call signalling for it. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Mon Jun 12 19:37:46 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 12 Jun 2017 21:37:46 +0200 Subject: New Defects reported by Coverity Scan for Osmocom In-Reply-To: <593acd049810e_7b172f330517e4@ss1435.mail> References: <593acd049810e_7b172f330517e4@ss1435.mail> Message-ID: <20170612193746.GD3379@my.box> Max, you fixed the coverity issue in https://gerrit.osmocom.org/2885, but a few lines above that, there is another +1 that seems one +1 too many: if (m_id_len > MAX_BTS_FEATURES/8 + 1) { LOGP(DNM, LOGL_NOTICE, "BTS%u Get Attributes Response: feature vector is truncated to %u bytes\n", bts->nr, MAX_BTS_FEATURES/8); m_id_len = MAX_BTS_FEATURES/8; } I can't claim I understand why this size check is necessary on top of the other one, but certainly "> MAX_BTS_FEATURES/8 + 1" doesn't match setting "m_id_len = MAX_BTS_FEATURES/8". ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 14 01:33:43 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Jun 2017 03:33:43 +0200 Subject: osmo-bts-trx: "No clock from osmo-trx" Message-ID: <20170614013343.GB1120@my.box> Hi Tom and others, in our testing setup, we have sporadic failures (~2 out of 10 times) with: DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx What would be possible reasons for this failure, and how can we go about fixing it? Some more logging around it: 20170614032014399 DRSL <0000> rsl.c:2333 (bts=0,trx=0,ts=0,ss=2) Fwd RLL msg EST_IND from LAPDm to A-bis 20170614032018533 DL1C <0006> scheduler_trx.c:1451 PC clock skew: elapsed uS 4136730 20170614032018533 DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx 20170614032018533 DL1C <0006> scheduler.c:240 Exit scheduler for trx=0 20170614032018533 DL1C <0006> scheduler.c:216 Init scheduler for trx=0 20170614032018533 DOML <0001> oml.c:280 OC=RADIO-CARRIER INST=(00,00,ff) AVAIL STATE OK -> Off line [...] Shutdown timer expired (We're using an external 10MHz OCXO timing source) It appears there's four seconds of nothing from osmo-trx? Most curious is that the next run will be completely fine, until some time later we get this same failure. We wait until osmo-trx logs -- Transceiver active with 1 channel(s) and then we "immediately" or up to a second later launch osmo-bts-trx. Would it help to give it more grace time?? Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From sudhanthiradasan.r at hcl.com Wed Jun 14 10:47:20 2017 From: sudhanthiradasan.r at hcl.com (Sudhanthiradasan R) Date: Wed, 14 Jun 2017 10:47:20 +0000 Subject: osmo-gsm-tester - voice call Message-ID: Hi, Is it possible to perform end-to-end testing like voice calls, sms etc with current osmo-gsm-tester version. I do not see any suites for voice call testing in the suites directory. Thanks Sudhanthiradasan R ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Wed Jun 14 12:25:40 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 14 Jun 2017 14:25:40 +0200 Subject: osmo-gsm-tester - voice call In-Reply-To: References: Message-ID: Hi Sudhanthiradasan, On 14/06/17 12:47, Sudhanthiradasan R wrote: > Hi, > > Is it possible to perform end-to-end testing like voice calls, sms etc > with current osmo-gsm-tester version. > > I do not see any suites for voice call testing in the suites directory. end-to-end sms between MS is already working and a test is being run in osmocom's jenkins instance. See [1] and [2]. A first version of a patch adding support to test SMPP (ESME->SMSC->MS) has been submited and waiting for review. Voice is not there yet but it's definetly in the roadmap and we plan to start working on it soon, probably we will have something there over next weeks. [1] test: http://git.osmocom.org/osmo-gsm-tester/tree/suites/sms/mo_mt_sms.py [2] jenkins job: http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/ Regards, Pau -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From sudhanthiradasan.r at hcl.com Wed Jun 14 13:03:20 2017 From: sudhanthiradasan.r at hcl.com (Sudhanthiradasan R) Date: Wed, 14 Jun 2017 13:03:20 +0000 Subject: osmo-gsm-tester - voice call In-Reply-To: References: Message-ID: Hi Pau Espin Pedrol, Thanks for your quick reply. 1)Just for the confirmation.. for the end-to-end testing with the current version of osmo-gsm-tester we can use only the sms suite? 2)In the suites directory, I can see aoip_debug, aoip_sms, debug, netreg, sms suites. What are all the tests that I can do with these suits? Is there any documentation? 3)If we want to create new suites, is there any document to help us? Thanks, Sudhanthiradasan R -----Original Message----- From: Pau Espin Pedrol [mailto:pespin at sysmocom.de] Sent: Wednesday, June 14, 2017 5:56 PM To: Sudhanthiradasan R ; openbsc at lists.osmocom.org Subject: Re: osmo-gsm-tester - voice call Hi Sudhanthiradasan, On 14/06/17 12:47, Sudhanthiradasan R wrote: > Hi, > > Is it possible to perform end-to-end testing like voice calls, sms etc > with current osmo-gsm-tester version. > > I do not see any suites for voice call testing in the suites directory. end-to-end sms between MS is already working and a test is being run in osmocom's jenkins instance. See [1] and [2]. A first version of a patch adding support to test SMPP (ESME->SMSC->MS) has been submited and waiting for review. Voice is not there yet but it's definetly in the roadmap and we plan to start working on it soon, probably we will have something there over next weeks. [1] test: http://git.osmocom.org/osmo-gsm-tester/tree/suites/sms/mo_mt_sms.py [2] jenkins job: http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/ Regards, Pau -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- From pespin at sysmocom.de Wed Jun 14 13:38:32 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 14 Jun 2017 15:38:32 +0200 Subject: osmo-gsm-tester - voice call In-Reply-To: References: Message-ID: Hi, On 14/06/17 15:03, Sudhanthiradasan R wrote: > > 1)Just for the confirmation.. for the end-to-end testing with the current version of osmo-gsm-tester we can use only the sms suite? > aoip_sms should be working too. It's basically the same as "sms" suite but using the AoverIP version of OpenBSC which will soon deprecate current OsmoNITB platform. > 2)In the suites directory, I can see aoip_debug, aoip_sms, debug, netreg, sms suites. What are all the tests that I can do with these suits? Is there any documentation? You can find the latest manual with general documentation in [1]. Feel free to ask if something is not clear or missing. If you want to improve it, the sources of the manual can be found in [2], patches welcome. * debug: A few minimal tests used during development of osmo-gsm-tester. You may find interesting the "interactive.py" one, which let's you start a test and set-up all the network + modems, then wait in a cmdline prompt waiting for you so you can debug whatever is going on. * aoip_debug: Same as debug, but using AoIP * netreg: A pair of minimal tests which check that the modems (ofono_client.py) can automatically/manually register with the network. It's a subset of what sms.py test is doing, but it's nice to have when willing to specifically test the register part. * sms: Starts the network, starts and registers 2 ofono modems (MS), sends an SMS from one MS to the other and then check's the sms arrived correctly and that the content is correct. * aoip_sms: Same as sms, but using AoIP. > > 3)If we want to create new suites, is there any document to help us? > You can have an idea of the current roadmap but checking at the tasks listed in the issue tracker of the project [3]. If you have any specific interest feel free to add tickets there (check similar ones don't exist before doing so). Incoming patches are welcome too. To know how to write new tests, the best is to check existing tests (sms.py), and you can find the API exported and available for tests in [4]. We extend the API when we implement new features which we see are required for new tests. [1] http://ftp.osmocom.org/docs/latest/osmo-gsm-tester-manual.pdf [2] http://git.osmocom.org/osmo-gsm-manuals/tree/OsmoGSMTester [3] https://osmocom.org/projects/osmo-gsm-tester/issues [4] http://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/test.py -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From axilirator at gmail.com Wed Jun 14 13:48:30 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 14 Jun 2017 20:48:30 +0700 Subject: osmo-bts-trx: "No clock from osmo-trx" Message-ID: Neels, > What would be possible reasons for this failure, > and how can we go about fixing it? As I know, this happens when scheduler detects, that system time is changed. For example, it might be caused by NTP time correction. - Do you have NTP enabled? - Have you specified process realtime priority? With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Jun 14 15:07:51 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Jun 2017 17:07:51 +0200 Subject: osmo-gsm-tester - voice call In-Reply-To: References: Message-ID: <20170614150751.GB4786@my.box> Welcome Sudhanthiradasan, On Wed, Jun 14, 2017 at 01:03:20PM +0000, Sudhanthiradasan R wrote: > 2)In the suites directory, I can see aoip_debug, aoip_sms, debug, netreg, sms suites. What are all the tests that I can do with these suits? Is there any documentation? We don't have specific documentation for the different suites yet. They aren't structured as clearly as I would like, either, given the still early stage of what osmo-gsm-tester is capable of. The 'sms' and 'aoip_sms' can be considered the production parts tested in our jenkins http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/ where the others are more for our own manual testing and debugging. Also as Pau pointed out the roadmap is to drop the 'sms' suite completely, since that is using the OsmoNITB, which will "soon" be discontinued for the benefit of a separate OsmoBSC and OsmoMSC. > 3)If we want to create new suites, is there any document to help us? If you create new tests and suites, we would appreciate if you share your efforts with the community: i.e. instead of creating your separate private project containing test suites, rather submit them back to us with the goal of having a complete collection of test suites upstream at git.osmocom.org. There are two points to this: one of course is that we are spending a rather large amount of effort to make this infrastructure available for free, for which we still need to get support and funding. The other point is that any tests we incorporate in our upstream codebase will be maintained by the community and will be considered in new developments, without you having to catch up with us constantly. If you are willing to provide funding to help us push things forward, that is very welcome. But just as welcome is your support in the form of sharing your own test suites and other patches with us. Same goes for the documentation: the manual can certainly use more/better content, which may also be contributed by anyone. In turn feel free to also share your questions regarding the tester and Osmocom in general, and we will help you find answers to the best of our abilities. Professional support is also available, e.g. from my employer sysmocom. Check out the OsmoGSMTester manual, part of the osmo-gsm-manuals: http://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Manuals Also be aware of numerous issues still open in our tracker, many of which ask for clarification of the structures and extending the features of the tester: http://osmocom.org/projects/osmo-gsm-tester/issues You are welcome to help out with those and/or let us know which of those are of interest to you and/or create new issues. Any feedback from you in form of patches is highly welcome, using our Gerrit patch management; for instructions, see: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit Thank you for your interest, and hoping that you will join the Osmocom community! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 14 15:41:33 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Jun 2017 17:41:33 +0200 Subject: osmo-bts-trx: "No clock from osmo-trx" In-Reply-To: References: Message-ID: <20170614154133.GC4786@my.box> On Wed, Jun 14, 2017 at 08:48:30PM +0700, Vadim Yanitskiy wrote: > Neels, > > > What would be possible reasons for this failure, > > and how can we go about fixing it? > > As I know, this happens when scheduler detects, that > system time is changed. For example, it might be caused > by NTP time correction. > > - Do you have NTP enabled? yes, indeed. But I wouldn't expect that frequent changes of as much as four seconds? We could switch off NTP ... though I enjoy having timestamps identical to my own box's time. > - Have you specified process realtime priority? Yep. Wait, have I? Looking up cmdlines from the log: osmo-trx -x osmo-bts-trx -r 1 -c [...] At least for osmo-bts-trx I have -r 1. Do I need to do the same for osmo-trx? No, it does so by default, right? It seems that these failures have become less frequent again, which could indeed be related to NTP activity. I'll switch off NTP and see if these go away completely. Hmm, doesn't NTP log its clock corrections somewhere? Can't find any... Thanks Vadim! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 14 19:58:06 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Jun 2017 21:58:06 +0200 Subject: osmo-bts-trx: "No clock from osmo-trx" In-Reply-To: <20170614154133.GC4786@my.box> References: <20170614154133.GC4786@my.box> Message-ID: <20170614195806.GD4786@my.box> On Wed, Jun 14, 2017 at 05:41:33PM +0200, Neels Hofmeyr wrote: > It seems that these failures have become less frequent again, which could > indeed be related to NTP activity. I'll switch off NTP and see if these go away > completely. No, despite NTP being switched off, I still see frequent failures due to osmo-bts-trx stopping in mid-air. A recent one was: 20170614170931479 DL1C <0006> scheduler_trx.c:1451 PC clock skew: elapsed uS 328104 20170614170931479 DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx i.e. only a third of a second, much less than the four seconds of last time, but still. Any other ideas? Are these necessarily actual clock skews of the host computer? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Wed Jun 14 22:11:41 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 15 Jun 2017 00:11:41 +0200 Subject: osmo-bts-trx: "No clock from osmo-trx" In-Reply-To: <20170614195806.GD4786@my.box> References: <20170614154133.GC4786@my.box> <20170614195806.GD4786@my.box> Message-ID: <332c07f5-739f-0d4e-701f-10df46d8605b@sysmocom.de> I use -lowlatency kernel on Ubuntu and I do not see this error. Although I use osmo-trx rather irregularly so I'm not really sure if it makes a difference or not. In the absence of other ideas though, it might be worth trying. 14.06.2017 21:58, Neels Hofmeyr ?????: > > Any other ideas? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From alexander.chemeris at gmail.com Wed Jun 14 22:47:00 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 15 Jun 2017 01:47:00 +0300 Subject: osmo-bts-trx: "No clock from osmo-trx" In-Reply-To: <20170614013343.GB1120@my.box> References: <20170614013343.GB1120@my.box> Message-ID: Neels, A reason could be that osmo-trx is losing connection with the SDR. Are you running this on bare metal or a VM? USB based SDRs like USRP B2x0 have hard time keeping the Tx/Rx alignment when there are any disturbances. So osmo-trx features a sophisticated algorithm to maintain this alignment for USB based devices. Thomas has spent? tremendous effort tuning it to perform well, but may be there are edge cases which are not handled there yet. Let's wait for his comments. (That's one the primary reasons we use Ethernet in UmTRX, btw - it's much more robust to issues like this) Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co On Jun 14, 2017 04:34, "Neels Hofmeyr" wrote: > Hi Tom and others, > > in our testing setup, we have sporadic failures (~2 out of 10 times) with: > > DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx > > What would be possible reasons for this failure, and how can we go about > fixing > it? Some more logging around it: > > > 20170614032014399 DRSL <0000> rsl.c:2333 (bts=0,trx=0,ts=0,ss=2) Fwd RLL > msg EST_IND from LAPDm to A-bis > 20170614032018533 DL1C <0006> scheduler_trx.c:1451 PC clock skew: > elapsed uS 4136730 > 20170614032018533 DOML <0001> bts.c:208 Shutting down BTS 0, Reason No > clock from osmo-trx > 20170614032018533 DL1C <0006> scheduler.c:240 Exit scheduler for trx=0 > 20170614032018533 DL1C <0006> scheduler.c:216 Init scheduler for trx=0 > 20170614032018533 DOML <0001> oml.c:280 OC=RADIO-CARRIER INST=(00,00,ff) > AVAIL STATE OK -> Off line > [...] > Shutdown timer expired > > (We're using an external 10MHz OCXO timing source) > > It appears there's four seconds of nothing from osmo-trx? > > Most curious is that the next run will be completely fine, until some time > later we get this same failure. > > We wait until osmo-trx logs > > -- Transceiver active with 1 channel(s) > > and then we "immediately" or up to a second later launch osmo-bts-trx. > Would it > help to give it more grace time?? > > Thanks! > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Wed Jun 14 23:03:44 2017 From: tom at tsou.cc (Tom Tsou) Date: Wed, 14 Jun 2017 16:03:44 -0700 Subject: osmo-bts-trx: "No clock from osmo-trx" In-Reply-To: References: <20170614013343.GB1120@my.box> Message-ID: On Wed, Jun 14, 2017 at 3:47 PM, Alexander Chemeris wrote: > USB based SDRs like USRP B2x0 have hard time keeping the Tx/Rx alignment > when there are any disturbances. So osmo-trx features a sophisticated > algorithm to maintain this alignment for USB based devices. Thomas has spent > tremendous effort tuning it to perform well, but may be there are edge cases > which are not handled there yet. Let's wait for his comments. The 'clock' issue is occurring between osmo-bts and osmo-trx and not between osmo-trx and the device. For the latter, irregular packet timing would appear as underruns, overflows, late packets, etc. - errors non-specific to GSM numerology. There are timing considerations at startup because the device needs time to initialize. In the case of the B200 on first boot, the startup time is especially long because of the FPGA load. Running the uhd_usrp_probe utility will give an indication of the device initialization time. On top of that delay, osmo-trx could add another second for Tx/Rx synchronization purposes. If clock skew is not occurring at startup, then process scheduling is probably related. If the flow of CLK IND stops entirely, as in the case when osmo-trx stops running, the message would be "No clock from osmo-trx". Clock skew could also occur because of variability in calling gettimeofday(), but I have not encountered that on any systems that I run. -TT From axilirator at gmail.com Thu Jun 15 21:43:12 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 16 Jun 2017 04:43:12 +0700 Subject: core/conv: further Viterbi decoder optimizations Message-ID: Dear all, I would like to know your opinions about some optimizations of Viterbi decoder, which were already discussed previously. First of all, I would like to share some benchmarking results. I used the test cases ("osmo-conv-test"), written by Tom Tsou, to ensure that SIMD optimization is integrated correctly. And, shortly speaking, the results are almost equal. Older version of decoder is a little bit faster, but I think it's because one is being compiled with "-march=native". Returning back to the subject, as we allocate and free some memory on every osmo_conv_decode_acc() call, what may happen very frequently and tear down performance on some hardware, there was the following suggestions: 1) Use static memory allocation where it's possible. 2) Use talloc for dynamic allocation. 3) Internal caching: Fri May 9 18:23:03 UTC 2014, Tom Tsou wrote: > Internal caching was in the original implementation, but > stripped from the submitted version mainly for simplicity > and avoiding the need for global variables, though we seem > to be having that discussion anyway ;-) The trellis values > can be cached based on pointer or hashed code. That works well > until threading is involved and cache access needs to be locked. > Those are features I need, but can probably be ignored in this > case. > > Again, I think the API should be kept intact. Internal caching, > can be a topic for later discussion. So, I am open for your ideas, opinions and remarks. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jun 16 06:06:11 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 16 Jun 2017 08:06:11 +0200 Subject: core/conv: further Viterbi decoder optimizations In-Reply-To: References: Message-ID: <20170616060611.yfrtj2twkjsgaxu6@nataraja> Hi Vadim, On Fri, Jun 16, 2017 at 04:43:12AM +0700, Vadim Yanitskiy wrote: > I used the test cases ("osmo-conv-test"), written by Tom Tsou, > to ensure that SIMD optimization is integrated correctly. And, > shortly speaking, the results are almost equal. Older version > of decoder is a little bit faster, but I think it's because > one is being compiled with "-march=native". You can compile the new code with the same optimization flags (specified in CFLAGS at configure time). We just simply cannot do -march=native as a default, as that is not safe. But you can use that to verify your assumption. > Returning back to the subject, as we allocate and free some > memory on every osmo_conv_decode_acc() call, what may happen > very frequently and tear down performance on some hardware, > there was the following suggestions: > > 1) Use static memory allocation where it's possible. That's generally what we do a lot in osmocom code. If it's predictable how much memory a given process takes, we allocate that memory once (statically or dynamically), use that all the time and then release it once that process/procedure/instance is destroyed. When I look at the current API, the decode_init()/decode_deinit() functions are great candidates to perform such allocation/release of memory. If applications use the osmo_conv_decode() convenience wrapper, it simply means they don't care about efficiency, but if they use the real init/scan/flush/deinit API, they would benefit from it. Not sure if scan+flush should/could become one call for simplicity? The viterbi.c code (which by the way chould be renamed to conv_acc.c or the like) would then have to be restructured to plug into init/fini for allocation+release. > 2) Use talloc for dynamic allocation. I doubt this will improve your speed. Feel free to try, but this is more of a clean-up to ensure all the memory allocated within osmocom projects is tracked/accounted for, and you can get talloc usage reports, debug memory leaks, etc. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Fri Jun 16 08:30:46 2017 From: msuraev at sysmocom.de (Max) Date: Fri, 16 Jun 2017 10:30:46 +0200 Subject: core/conv: further Viterbi decoder optimizations In-Reply-To: References: Message-ID: Hi. Microbenchmarking is nice but I'd like to know bigger picture: why do we need to optimize current implementation further? Is it just for the sake of aesthetics and fun of it? Do we have some profiling result showing that in scenario A Viterbi decoder occupies XX% of the time? Don't get me wrong - I'm not against optimizations, just would like to know more about the general context. On 15.06.2017 23:43, Vadim Yanitskiy wrote: > > So, I am open for your ideas, opinions and remarks. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From tom at tsou.cc Fri Jun 16 17:58:19 2017 From: tom at tsou.cc (Tom Tsou) Date: Fri, 16 Jun 2017 10:58:19 -0700 Subject: core/conv: further Viterbi decoder optimizations In-Reply-To: References: Message-ID: Hi Vadim, On Thu, Jun 15, 2017 at 2:43 PM, Vadim Yanitskiy wrote: > Returning back to the subject, as we allocate and free some > memory on every osmo_conv_decode_acc() call, what may happen > very frequently and tear down performance on some hardware, > there was the following suggestions: Max has a valid point of asking whether there is significant value in further optimization when weighted against the cost of a non-trivial API change. There are fielded deployments running the baseline code. Will further optimization make a significant difference in those cases? The answer is system and situation dependent; I can't answer those questions in the general sense. > 1) Use static memory allocation where it's possible. > 2) Use talloc for dynamic allocation. > 3) Internal caching: Persistent allocation is the best solution. Talloc will minimally affect performance if at all. Internal caching is somewhat of a hack to hide static allocation behind an API that does not allow it. > Fri May 9 18:23:03 UTC 2014, Tom Tsou wrote: >> Internal caching was in the original implementation, but >> stripped from the submitted version mainly for simplicity >> and avoiding the need for global variables, though we seem >> to be having that discussion anyway ;-) The trellis values >> can be cached based on pointer or hashed code. That works well >> until threading is involved and cache access needs to be locked. >> Those are features I need, but can probably be ignored in this >> case. Three years ago, which feels like much longer, I was performing brute force RNTI searches on LTE control channels. Convolutional decoding was the limiting factor and maxed out multiple threads; every optimization helped. That was a much different set of requirements. -TT From nhofmeyr at sysmocom.de Fri Jun 16 18:20:35 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 16 Jun 2017 20:20:35 +0200 Subject: osmo-bts-trx: "No clock from osmo-trx" In-Reply-To: References: <20170614013343.GB1120@my.box> Message-ID: <20170616182035.GC3662@my.box> On Wed, Jun 14, 2017 at 04:03:44PM -0700, Tom Tsou wrote: > There are timing considerations at startup because the device needs > time to initialize. In the case of the B200 on first boot, the startup > time is especially long because of the FPGA load. We are specifically wating for the "Transceiver active" on stdout to wait until the FPGA load is done. > Running the uhd_usrp_probe utility will give an indication of the device > initialization time. On top of that delay, osmo-trx could add another second > for Tx/Rx synchronization purposes. Ok, I'll try adding a little head room after receiving the "Transceiver active" message. One point may be that it's not a very powerful machine: an APU with an 800MHz dual core. > If clock skew is not occurring at startup, then process scheduling is > probably related. If the flow of CLK IND stops entirely, as in the case when > osmo-trx stops running, the message would be "No clock from osmo-trx". Clock > skew could also occur because of variability in calling gettimeofday(), but I > have not encountered that on any systems that I run. With NTP switched off I have no idea why the system clock could jump around. I also looked in the root crontab and so on, maybe something is still calling ntpdate on that system... Could also make sense to wipe that OS to be sure. A lot has happened on there in the past... Will keep you posted. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Fri Jun 16 21:03:27 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 16 Jun 2017 23:03:27 +0200 Subject: osmo-bts-trx: "No clock from osmo-trx" In-Reply-To: <20170616182035.GC3662@my.box> References: <20170614013343.GB1120@my.box> <20170616182035.GC3662@my.box> Message-ID: <20170616210327.ycqqlv2nkkdfj5t4@nataraja> Hi Neels and Tom, On Fri, Jun 16, 2017 at 08:20:35PM +0200, Neels Hofmeyr wrote: > One point may be that it's not a very powerful machine: an APU with an 800MHz > dual core. That actually means: An AMD Embedded G-Series T40E APU. We like to use passive cooled, low-end processors whenever possible. > > If clock skew is not occurring at startup, then process scheduling is > > probably related. If the flow of CLK IND stops entirely, as in the case when > > osmo-trx stops running, the message would be "No clock from osmo-trx". Clock > > skew could also occur because of variability in calling gettimeofday(), but I > > have not encountered that on any systems that I run. > > With NTP switched off I have no idea why the system clock could jump around. I > also looked in the root crontab and so on, maybe something is still calling > ntpdate on that system... you can always run a tcpdump on the ntp port, if you're worried about that. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Sun Jun 18 00:47:48 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 18 Jun 2017 02:47:48 +0200 Subject: aoip branch in openbsc.git Message-ID: <20170618004748.GA8906@my.box> Hi Philipp, I have rebased the 'aoip' branch onto openbsc master. A test by the osmo-gsm-tester of this state was successful. Pending is to also verify voice and all of 3G still works there (will then update vlr_2G and vlr_3G branches). Some commits have been amended to, a) adjust libsmpp changes to use vlr_subscr, b) fix the msc_vlr unit tests after your rename of a_tx() and a_page() (don't really know why I didn't hit that earlier). c) add one comment So beware, if you rebase your most recent patches onto the 'aoip' branch, git may want to apply a few patches again because they slightly differ, even though their commit logs are identical. You need to sanity-check with 'rebase -i'. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Sun Jun 18 14:18:58 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 18 Jun 2017 16:18:58 +0200 Subject: jenkins: Osmocom_Sanitizer build fails Message-ID: <20170618141845.GA23104@my.box> Today I noticed that the Osmocom_Sanitizer build has been broken for a long time, failing at libosmocore/src/viterbi_sse.c. But that seems like the fault of the way the Osmocom_Sanitizer builds: When I build libosmocore with --enable-sanitize, everything works out. When I instead build with `make CFLAGS+="..."', some CFLAGS are dropped and the build fails. The working commandline is: ./configure --enable-sanitize make V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -g -O2 -fsanitize=address -fsanitize=undefined -msse3 -msse4.1 -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o The failing one is: ./configure make CFLAGS+="-fsanitize=address -fsanitize=undefined" V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -fsanitize=address -fsanitize=undefined -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o i.e. in the failing build, these cmdline args are missing: -O2 -g -msse3 -msse4.1 So it seems that the CFLAGS+="stuff" is not working as intended. The alternative is to build with the ./configure --enable-sanitize, which I added at some point. But not all libs have this switch, AFAIR. I have added the --enable-sanitize configure option to libosmocore, and asked others to follow up in other repositories in the same fashion. I think this hasn't worked out everywhere yet. Does it make sense to refresh the sanitize build effort?: switch the Osmocom_Sanitizer build to using this configure flag and add it where it is missing. But I guess we should instead add the sanitize switch to each individual build script for the various *osmo* build jobs and switch off the Osmocom_Sanitizer build instead. I repeat myself, but adding --enable-sanitize is not a lot of effort. See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da501eb29b9cd7 I created https://osmocom.org/issues/2330 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Sun Jun 18 16:39:19 2017 From: holger at freyther.de (Holger Freyther) Date: Mon, 19 Jun 2017 00:39:19 +0800 Subject: jenkins: Osmocom_Sanitizer build fails In-Reply-To: <20170618141845.GA23104@my.box> References: <20170618141845.GA23104@my.box> Message-ID: > On 18. Jun 2017, at 22:18, Neels Hofmeyr wrote: Hi! > Today I noticed that the Osmocom_Sanitizer build has been broken for a long > time, failing at libosmocore/src/viterbi_sse.c. But that seems like the fault > of the way the Osmocom_Sanitizer builds: can you think of a way to help us "spot" such things more early? > So it seems that the CFLAGS+="stuff" is not working as intended. Right. The Makefile.am probably should use AM_CFLAGS an do not set CFLAGS directly? > I repeat myself, but adding --enable-sanitize is not a lot of effort. > See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da501eb29b9cd7 I like it as it has helped us to find a build system error. When I debug an issue I most frequently build with CFLAGS+="-ggdb3" and would like this to keep working. :) holger From nhofmeyr at sysmocom.de Sun Jun 18 18:35:52 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 18 Jun 2017 20:35:52 +0200 Subject: jenkins: Osmocom_Sanitizer build fails In-Reply-To: References: <20170618141845.GA23104@my.box> Message-ID: <20170618183552.GB23104@my.box> On Mon, Jun 19, 2017 at 12:39:19AM +0800, Holger Freyther wrote: > can you think of a way to help us "spot" such things more early? our osmocom jenkins is unable to send emails. I once failed to get it working by using my own smtp account (IIRC). Important build failures should be sent to to the "high noise" ML gerrit-log at lists.osmocom.org. That list is a bit of a misnomer, we could create a high-noise@ ML. Or just live with the name. > > So it seems that the CFLAGS+="stuff" is not working as intended. > > Right. The Makefile.am probably should use AM_CFLAGS an do not set > CFLAGS directly? I usually have no clue about automake until you turn up one day and teach me how it's done :) I'd believe you any day. > > I repeat myself, but adding --enable-sanitize is not a lot of effort. > > See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da501eb29b9cd7 > > I like it as it has helped us to find a build system error. When I Wasn't aware that passing CFLAGS+= is a feature that should not be broken, if that is so then let's fix it. libosmocore/$ rgrep CFLAGS |grep Makefile.am | grep -v _CFLAGS src/Makefile.am:29:viterbi_sse.lo : CFLAGS += -msse3 -msse4.1 src/Makefile.am:31:viterbi_sse.lo : CFLAGS += -msse3 src/Makefile.am:37:viterbi_sse_avx.lo : CFLAGS += -msse3 -mavx2 -msse4.1 src/Makefile.am:39:viterbi_sse_avx.lo : CFLAGS += -msse3 -mavx2 It seems to be firmly related to the viterbi build. @vadim, could you fix this to not use CFLAGS? Look around in the Makefile.am s to find the proper way to do it, I guess. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From axilirator at gmail.com Sun Jun 18 19:54:46 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 19 Jun 2017 02:54:46 +0700 Subject: core/conv: further Viterbi decoder optimizations In-Reply-To: <20170616060611.yfrtj2twkjsgaxu6@nataraja> References: <20170616060611.yfrtj2twkjsgaxu6@nataraja> Message-ID: Hi Harald, > When I look at the current API, the decode_init()/decode_deinit() > functions are great candidates to perform such allocation/release of > memory. If applications use the osmo_conv_decode() convenience > wrapper, it simply means they don't care about efficiency, but if they > use the real init/scan/flush/deinit API, they would benefit from it. You are talking about Sylvain's implementation of Viterbi, which is currently used as fail-safe back-end for a new algorithmically and SIMD optimized implementation, written by Tom Tsou. In the Sylvain's implementation (conv.c), init/scan/flush/deinit are exposed for external usage, meanwhile Tom's implementation is transparently integrated into the first one, and doesn't expose anything outside. > The viterbi.c code (which by the way chould be renamed to conv_acc.c or > the like) would then have to be restructured to plug into init/fini for > allocation+release. Do you suggest to expose alloc_vdec, free_vdec and osmo_conv_decode_acc like it is done in the conv.c? Anyway, using init/fini is profitably only if you are doing serial (en/de)coding of the same convolutional code. As soon as you need to (en/de)code another convolutional code, you will have to reallocate and reconfigure the vdec object. > (which by the way chould be renamed to conv_acc.c or the like) I like this idea, already in my TODO list :) > I doubt this will improve your speed. Feel free to try, but this is > more of a clean-up to ensure all the memory allocated within osmocom > projects is tracked/accounted for, and you can get talloc usage > reports, debug memory leaks, etc. Agree with you. But what do you think about talloc memory pools? With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tsou.cc Sun Jun 18 20:13:45 2017 From: tom at tsou.cc (Tom Tsou) Date: Sun, 18 Jun 2017 13:13:45 -0700 Subject: core/conv: further Viterbi decoder optimizations In-Reply-To: References: <20170616060611.yfrtj2twkjsgaxu6@nataraja> Message-ID: On Sun, Jun 18, 2017 at 12:54 PM, Vadim Yanitskiy wrote: > In the Sylvain's implementation (conv.c), init/scan/flush/deinit > are exposed for external usage, meanwhile Tom's implementation > is transparently integrated into the first one, and doesn't > expose anything outside. One note on API usage. Sylvain's init-deinit calls are exposed, but I'm not aware of the those calls being used anywhere - only the all-in-one version exists in osmo-bts. So an API change on the init-deinit or alloc-dealloc of the decoder object probably won't cause many dependency issues. But putting those calls into use involves a large number of changes in the current osmo-bts regardless of which implementation is used. -TT From axilirator at gmail.com Sun Jun 18 20:25:31 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 19 Jun 2017 03:25:31 +0700 Subject: core/conv: further Viterbi decoder optimizations In-Reply-To: References: Message-ID: Hi Max and Tom, > why do we need to optimize current implementation further? > Is it just for the sake of aesthetics and fun of it? You are right, this is for the sake of aesthetics. I had a task: to take some dead code from mailing lists, to make it satisfy the Osmocom coding requirements and merge it part by part. There was some warnings about object visibility (fixed), about naming convention (fixed) and about memory allocation. In the past, the discussion about memory allocation was set aside, until code is merged. So, till now, this task remained in my mind as some kind of unfinished work... > Do we have some profiling result showing that in scenario > A Viterbi decoder occupies XX% of the time? I am not sure that we can profile different parts of code without actual modifications (probably perf can do that, correct me otherwise). But we can profile a whole implementation using the benchmark code from Tom, which I mentioned before. > Don't get me wrong - I'm not against optimizations, > just would like to know more about the general context. It's ok, I am always happy to know your and other opinions :) > Persistent allocation is the best solution. Talloc will minimally > affect performance if at all. Internal caching is somewhat of a hack > to hide static allocation behind an API that does not allow it. I'll try to use persistent allocation where it's possible, e.g. the struct vdecoder in osmo_conv_decode_acc() could be allocated in the stack instead of heap. > Three years ago, which feels like much longer, I was performing brute > force RNTI searches on LTE control channels. Convolutional decoding > was the limiting factor and maxed out multiple threads; every > optimization helped. That was a much different set of requirements. Ok, that is exactly what I need to know. Now I can let internal caching go, as it isn't critical for GSM. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sun Jun 18 20:47:20 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 19 Jun 2017 03:47:20 +0700 Subject: jenkins: Osmocom_Sanitizer build fails In-Reply-To: <20170618183552.GB23104@my.box> References: <20170618141845.GA23104@my.box> <20170618183552.GB23104@my.box> Message-ID: Hi Neels, Holger, > @vadim, could you fix this to not use CFLAGS? > Look around in the Makefile.am s to find the > proper way to do it, I guess. There is the main problem that automake does not support per-object flags :( According to https://www.gnu.org/software/automake/ manual/html_node/Per_002dObject-Flags.html we can only specify per-program and per-library compilation flags. In OsmoTRX we have several static libraries for specific architectures. In libosmocore, we can not go the same way, because it's a shared library. Keeping this in mind, I found a way to use per-object flags on Stack Overflow. The solution was to use the Target-specific Variable Values feature of GNU Make. I thought "CFLAGS +=" will not overwrite anything... So, let me some time to find a proper solution. If you have any ideas, please let me know. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Mon Jun 19 11:09:11 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 19 Jun 2017 13:09:11 +0200 Subject: jenkins and osmo-ci Message-ID: <420e2214-1ba0-5fb3-8429-aec637f05ae0@sysmocom.de> Hi. I've problem figuring out how to use osmo-ci in jenkins: the build steps for osmo-bts-gerrit and osmo-pcu-gerrit look pretty-much the same but osmo-pcu fails with: osmo-layer1-headers.sh: command not found while osmo-bts (which uses other scripts from osmo-ci) works fine. Any ideas where this difference might come from? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Mon Jun 19 13:20:24 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Jun 2017 15:20:24 +0200 Subject: jenkins: Osmocom_Sanitizer build fails In-Reply-To: References: <20170618141845.GA23104@my.box> <20170618183552.GB23104@my.box> Message-ID: <20170619132024.GD23104@my.box> On Mon, Jun 19, 2017 at 03:47:20AM +0700, Vadim Yanitskiy wrote: > So, let me some time to find a proper solution. > If you have any ideas, please let me know. Take a look at https://gerrit.osmocom.org/#/c/2975/ and http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/578/ built with that patch which succeeds for libosmocore (still red because of a later failure) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From dr.blobb at gmail.com Mon Jun 19 13:52:02 2017 From: dr.blobb at gmail.com (=?UTF-8?Q?Andr=C3=A9_Boddenberg?=) Date: Mon, 19 Jun 2017 15:52:02 +0200 Subject: jenkins and osmo-ci In-Reply-To: <420e2214-1ba0-5fb3-8429-aec637f05ae0@sysmocom.de> References: <420e2214-1ba0-5fb3-8429-aec637f05ae0@sysmocom.de> Message-ID: Hi, > Any ideas where this difference might come from? Scripts must be in PATH (e.g. /home/osmocom-build/bin on OsmocomBuild1). Your recently added script might not have been added to PATH yet? Not sure how it's done atm, but no "update-osmo-ci" job or similar on Jenkins' side. From axilirator at gmail.com Mon Jun 19 14:06:24 2017 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 19 Jun 2017 21:06:24 +0700 Subject: jenkins: Osmocom_Sanitizer build fails In-Reply-To: <20170619132024.GD23104@my.box> References: <20170618141845.GA23104@my.box> <20170618183552.GB23104@my.box> <20170619132024.GD23104@my.box> Message-ID: > Take a look at https://gerrit.osmocom.org/#/c/2975/ Looks great to me! So simple change :) With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emily.mcmilin at gmail.com Mon Jun 19 23:52:18 2017 From: emily.mcmilin at gmail.com (emily mcmilin) Date: Mon, 19 Jun 2017 16:52:18 -0700 Subject: how to use the CTRL interface to set TRAPs. In-Reply-To: References: <5e6528b6-0751-353d-dd99-8a4dd3db1d0b@sysmocom.de> <42155885-b2f0-7093-0eb5-224faf788a18@sysmocom.de> <20170527184325.GD1882@my.box> Message-ID: Hi Max, Thanks for your update and sorry for my delayed response. On Thu, Jun 8, 2017 at 1:35 AM, Max wrote: > Ah, sorry, my bad - I've mixed up osmo-bsc_nat with osmo-nitb. I'm afraid at the > moment there's no way to produce TRAP from OsmoNITB. I have created an issue requesting the addition of a TRAP implementation TO the CTRL interface in OsmoNITB: https://projects.osmocom.org/issues/2331 Thanks, Emily From robert.steve07 at gmail.com Tue Jun 20 11:11:25 2017 From: robert.steve07 at gmail.com (robert) Date: Tue, 20 Jun 2017 14:11:25 +0300 Subject: knowing connected subscribers Message-ID: Hello, Is there a way in openBSC to know if a certain phone that previously connected to my BTS is still connected at a given time ? From nhofmeyr at sysmocom.de Tue Jun 20 11:54:40 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 20 Jun 2017 13:54:40 +0200 Subject: jenkins and osmo-ci In-Reply-To: References: <420e2214-1ba0-5fb3-8429-aec637f05ae0@sysmocom.de> Message-ID: <20170620115440.GA1527@my.box> On Mon, Jun 19, 2017 at 03:52:02PM +0200, Andr? Boddenberg wrote: > > Any ideas where this difference might come from? > > Not sure how it's done atm, but no "update-osmo-ci" job or similar on > Jenkins' side. But of course there is: http://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/ It last ran three months ago. Run that and your new script will be available. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Jun 20 12:19:17 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 20 Jun 2017 14:19:17 +0200 Subject: jenkins and osmo-ci In-Reply-To: <20170620115440.GA1527@my.box> References: <420e2214-1ba0-5fb3-8429-aec637f05ae0@sysmocom.de> <20170620115440.GA1527@my.box> Message-ID: <925fb031-051b-399d-4b58-87ece7d4bdc6@sysmocom.de> Now, when osmo-ci is on gerrit as well, can we run this job automatically on every commit to master branch? On 20.06.2017 13:54, Neels Hofmeyr wrote: > > But of course there is: http://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/ > It last ran three months ago. Run that and your new script will be available. > > ~N > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Tue Jun 20 22:33:32 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 00:33:32 +0200 Subject: osmo_sock_get_name() order Message-ID: <20170620223332.GB1527@my.box> In january, osmo_sock_get_name() was introduced and prints the connection info for a given fd, which looks like this: 127.0.0.1:2905<->127.0.0.1:60661 However, when I first saw this in a log, I was confused: I expect the local address and port to be on the left, while in this string it is on the right. Is it only me and I should get used to it, or can we reverse that so the local part is on the left? I could argue that in most GSM graphics and ladder diagrams, the client side is on the left, and that we would typically use this string on the client side to indicate where we connected to. Is this even true? Should there be an arg to pick the preferred order? :P I'll submit a patch if anyone agrees. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 20 22:37:11 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 00:37:11 +0200 Subject: jenkins and osmo-ci In-Reply-To: <925fb031-051b-399d-4b58-87ece7d4bdc6@sysmocom.de> References: <420e2214-1ba0-5fb3-8429-aec637f05ae0@sysmocom.de> <20170620115440.GA1527@my.box> <925fb031-051b-399d-4b58-87ece7d4bdc6@sysmocom.de> Message-ID: <20170620223711.GC1527@my.box> On Tue, Jun 20, 2017 at 02:19:17PM +0200, Max wrote: > Now, when osmo-ci is on gerrit as well, can we run this job automatically on every > commit to master branch? (The question whether we do this is not related to being on gerrit or not.) So far the times I had to run this were extremely rare and I saw no need / preferred to trigger manually to know when it ran. You can configure a "Poll SCM" on that job if you like. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 20 22:44:50 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 00:44:50 +0200 Subject: knowing connected subscribers In-Reply-To: References: Message-ID: <20170620224450.GE1527@my.box> On Tue, Jun 20, 2017 at 02:11:25PM +0300, robert wrote: > Hello, > > Is there a way in openBSC to know if a certain phone that previously connected to my BTS is still connected at a given time ? In OpenBSC not really, the subscription status is typically in the MSC and/or HLR; so if you're using OsmoNITB you can query the subscriber's LAC on the VTY, or use the CTRL command 'subscriber-list-active-v1'. If you're using OpenBSC alone, there's no way AFAIK. It only sees a subscriber when it is actually actively sending/receiving right at this moment. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Jun 20 22:58:59 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 21 Jun 2017 00:58:59 +0200 Subject: osmo_sock_get_name() order In-Reply-To: <20170620223332.GB1527@my.box> References: <20170620223332.GB1527@my.box> Message-ID: <91432b7a-390c-7649-f10f-0cb192ef1b7a@sysmocom.de> I think both variants are bad - instead of guessing which order is saner we should just explicitly mark what is what. Smth like R:127.0.0.1:2905<->L:127.0.0.1:60661 21.06.2017 00:33, Neels Hofmeyr ?????: > Is it only me and I should get used to it, or can we reverse that so the local > part is on the left? > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte From nhofmeyr at sysmocom.de Wed Jun 21 03:12:37 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 05:12:37 +0200 Subject: SCCP/M3UA: PC and routing questions Message-ID: <20170621031237.GG1527@my.box> Trying to get the HNBGW to communicate with the MSC. I receive Iuh from the femto cell as usual, send to the MSC, and end up in an infinite loop where osmo-stp and osmo-hnbgw send the same message back and forth to each other. osmo-hnbgw's local IuCS PC is 23, the MSC is PC 1. It seems when osmo-hnbgw receives a message to PC 23, i.e. to itself, it thinks that its own PC isn't local, finds its own as-clnt-CS in the table of routes, and feeds it to m3ua_tx_xua_as(). osmo-stp then sends it back. repeat. It seems overkill that a "client" like osmo-hnbgw should be capable of routing in the first place. It could switch off routing entirely and receive & handle every message it receives itself. But assuming that this were nonsense: IIUC it should rather decide that its own PC 23 is local, in: bool osmo_ss7_pc_is_local(struct osmo_ss7_instance *inst, uint32_t pc) { OSMO_ASSERT(ss7_initialized); if (pc == inst->cfg.primary_pc) return true; /* FIXME: Secondary and Capability Point Codes */ return false; } Apparently this global primary_pc is set in osmo_sccp_simple_client(). Since in the osmo-hnbgw I'm (so far) creating two simple clients with distinct PCs (IuCS is 23, IuPS is 24), the primary_pc is overwritten with 24. After that we always fail to notice 23 as a local PC and bounce messages for self right back down the SCCP stack, because apparently we find a route for 23 instead. A "matching" route is recognised by osmo_ss7_route_find_dpc(): if ((dpc & rt->cfg.mask) == rt->cfg.pc) My own local client gets entered as route, with rt->cfg.mask == 0 and rt->cfg.pc == 0, so an arbitrary dpc & 0 == 0, matches always. It seems awfully easy to create a fatal infinite loop flooding the network and CPU -- simply send a message to a DPC neither side sees as local. Anyway... Which way to go to serve more than one PC in a program? It appears that either an osmo_sccp_simple_client() call's local PC or an osmo_sccp_user_bind_pc()'s PC should be stored&found as a local PC. ... or both. Is the "right" way to have two PCs: having two osmo_sccp_simple_client()s with an sccp_user each; or rather one osmo_sccp_simple_client with two users? Or, should we for the OsmoHNBGW just have one osmo_sccp_simple_client() and one user, i.e. only one PC to receive both IuCS and IuPS messages? All we do is feed both of them out to Iuh anyway... (This seems an easy way out of the multi PC problem, but our MSC wants to serve one PC for BSSAP=2G and one PC for RANAP=3G, so we will need to solve the multi-PC problem anyway.) There are many directions I could head to, is any one better than the others? Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 21 03:17:18 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 05:17:18 +0200 Subject: osmo_sock_get_name() order In-Reply-To: <91432b7a-390c-7649-f10f-0cb192ef1b7a@sysmocom.de> References: <20170620223332.GB1527@my.box> <91432b7a-390c-7649-f10f-0cb192ef1b7a@sysmocom.de> Message-ID: <20170621031718.GA1965@my.box> On Wed, Jun 21, 2017 at 12:58:59AM +0200, Max wrote: > R:127.0.0.1:2905<->L:127.0.0.1:60661 +1, I'd even favor writing out 'remote:' and 'local:'. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Wed Jun 21 08:25:28 2017 From: msuraev at sysmocom.de (Max) Date: Wed, 21 Jun 2017 10:25:28 +0200 Subject: jenkins and osmo-ci In-Reply-To: <20170620223711.GC1527@my.box> References: <420e2214-1ba0-5fb3-8429-aec637f05ae0@sysmocom.de> <20170620115440.GA1527@my.box> <925fb031-051b-399d-4b58-87ece7d4bdc6@sysmocom.de> <20170620223711.GC1527@my.box> Message-ID: <67157a1d-58a4-c38c-03ed-30580d295ed0@sysmocom.de> Actually I'd prefer this job to be converted into JobDSL so instead of being configured via web UI it could be declaratively described under git (in osmo-ci?) and automatically generated from that description using seed job. It seem like a perfect candidate to begin with: it's rather rarely used, pretty simple (no complex config matrix) etc. Andr?, what do you think? On 21.06.2017 00:37, Neels Hofmeyr wrote: > You can configure a "Poll SCM" on that job if you like. > ~N > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From robert.steve07 at gmail.com Wed Jun 21 09:31:54 2017 From: robert.steve07 at gmail.com (robert) Date: Wed, 21 Jun 2017 12:31:54 +0300 Subject: knowing connected subscribers In-Reply-To: <20170620224450.GE1527@my.box> References: <20170620224450.GE1527@my.box> Message-ID: <5E5D9D32-6381-4438-A19C-62EDCB735D27@gmail.com> On Jun 21, 2017, at 1:44 AM, Neels Hofmeyr wrote: > On Tue, Jun 20, 2017 at 02:11:25PM +0300, robert wrote: >> Hello, >> >> Is there a way in openBSC to know if a certain phone that previously connected to my BTS is still connected at a given time ? > > In OpenBSC not really, the subscription status is typically in the MSC and/or > HLR; so if you're using OsmoNITB you can query the subscriber's LAC on the VTY, > or use the CTRL command 'subscriber-list-active-v1?. I am using OsmoNITB. Does the command ?subscriber-list-active-v1? list the phones that are currently connected or should they be active (for example during a call) ? > > If you're using OpenBSC alone, there's no way AFAIK. It only sees a subscriber > when it is actually actively sending/receiving right at this moment. > > ~N > From oramadan at fb.com Wed Jun 21 10:19:46 2017 From: oramadan at fb.com (Omar Ramadan) Date: Wed, 21 Jun 2017 10:19:46 +0000 Subject: knowing connected subscribers In-Reply-To: <5E5D9D32-6381-4438-A19C-62EDCB735D27@gmail.com> References: <20170620224450.GE1527@my.box>, <5E5D9D32-6381-4438-A19C-62EDCB735D27@gmail.com> Message-ID: You can use the location update timestamp in the HLR. The MS will RACH periodically based on the value of the T3212 timer. This is configurable to multiples of 6 minutes with 6 being the minimum. If a phone hasn't updates it's location after that interval has passed you can assume it's not connected -------- Original Message -------- From: robert Date: Wed, Jun 21, 2017, 12:32 PM To: Neels Hofmeyr CC: OpenBSC Mailing List Subject: Re: knowing connected subscribers On Jun 21, 2017, at 1:44 AM, Neels Hofmeyr wrote: > On Tue, Jun 20, 2017 at 02:11:25PM +0300, robert wrote: >> Hello, >> >> Is there a way in openBSC to know if a certain phone that previously connected to my BTS is still connected at a given time ? > > In OpenBSC not really, the subscription status is typically in the MSC and/or > HLR; so if you're using OsmoNITB you can query the subscriber's LAC on the VTY, > or use the CTRL command 'subscriber-list-active-v1?. I am using OsmoNITB. Does the command ?subscriber-list-active-v1? list the phones that are currently connected or should they be active (for example during a call) ? > > If you're using OpenBSC alone, there's no way AFAIK. It only sees a subscriber > when it is actually actively sending/receiving right at this moment. > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Jun 21 12:45:50 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 14:45:50 +0200 Subject: knowing connected subscribers In-Reply-To: <5E5D9D32-6381-4438-A19C-62EDCB735D27@gmail.com> References: <20170620224450.GE1527@my.box> <5E5D9D32-6381-4438-A19C-62EDCB735D27@gmail.com> Message-ID: <20170621124550.GA2075@my.box> On Wed, Jun 21, 2017 at 12:31:54PM +0300, robert wrote: > I am using OsmoNITB. Does the command ?subscriber-list-active-v1? list the phones that are currently connected or should they be active (for example during a call) ? I would have referred you to the user manual http://ftp.osmocom.org/docs/latest/osmonitb-usermanual.pdf but must notice that it isn't very helpful in describing this CTRL cmd. It returns subscribers that are attached, i.e. no active call or such needs to be going on to be listed. Might also include a subscriber slightly too soon, see http://osmocom.org/issues/2285 For manual access, using the vty 'show subscriber imsi 12345654321' might be easier (a LAC=0 means not attached). ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Wed Jun 21 18:54:40 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 21 Jun 2017 21:54:40 +0300 Subject: osmo_sock_get_name() order In-Reply-To: <20170621031718.GA1965@my.box> References: <20170620223332.GB1527@my.box> <91432b7a-390c-7649-f10f-0cb192ef1b7a@sysmocom.de> <20170621031718.GA1965@my.box> Message-ID: <20170621185440.rwsuedvtabd2bv2u@nataraja> In terms of left/right: I think there is no obvious or correct way. My original idea was that a system administrator would inherently know which of the two sides is the local side of the socket, based on his configuration. Based on the fd it's unfortunately not possible to have an explicit "CLIENT -> SERVER" kind of notation replacing the bi-directional arrow that we currently print. This would require that we keep a lot more state and nothing that can be derived from the fd alone :/ On Wed, Jun 21, 2017 at 05:17:18AM +0200, Neels Hofmeyr wrote: > On Wed, Jun 21, 2017 at 12:58:59AM +0200, Max wrote: > > R:127.0.0.1:2905<->L:127.0.0.1:60661 > > +1, I'd even favor writing out 'remote:' and 'local:'. L/R I can still live with, but please don't make it even longer. -- - 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 Wed Jun 21 19:06:02 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 21 Jun 2017 22:06:02 +0300 Subject: SCCP/M3UA: PC and routing questions In-Reply-To: <20170621031237.GG1527@my.box> References: <20170621031237.GG1527@my.box> Message-ID: <20170621190602.w7xji4z3glry2un6@nataraja> On Wed, Jun 21, 2017 at 05:12:37AM +0200, Neels Hofmeyr wrote: > It seems overkill that a "client" like osmo-hnbgw should be capable of routing > in the first place. It could switch off routing entirely and receive & handle > every message it receives itself. But assuming that this were nonsense: I would rather not restrict this. There are many possible useful configurations, and disabling PC routing "by force" completely right now, before we have any actual practical deployments of this could bite us in the back. > Apparently this global primary_pc is set in osmo_sccp_simple_client(). it is not truly global, but speciic to the SS7 instance. > Since in the osmo-hnbgw I'm (so far) creating two simple clients with > distinct PCs (IuCS is 23, IuPS is 24), the primary_pc is overwritten > with 24. This is where I think it is broken. The simple_client API is intended for a simple use case, and not for more complex configurations. I think you have the following options: a) use different ss7_instances, which is probably the right thing if you really want to assume that MSC and SGSN live in completely separate SS7 networks with no routing/STP in between. At that point, even the point codes may very well be no longer unique, so having two SS7 instances would compltely isolate the two parts. b) add the missing 'secondary point codes' and then have 23 as primary and 24 as secondary, or whatever c) do away with the two separate signaling connections for PS and CS domain. I would assume that an operator typically has one signaling network, with unique point codes and routing in place. So the HNB-GW establishes M3UA to some kind of STP (or multiple STPs in fail-over mode) and then simply let SCCP take care of its job to route the respective messages to either SGSN or MSC. The HNB-GW then only has a single point code in that scenario d) move away from simple-client and introduce the ss7_vty with all its related configuration into the hnb-gw. This is required sooner or later anyway, as even a "simple" client in a real-world scenario would normally have M3UA links to multiple STPs for redundancy or load-sharing reasons. The hack of having two simple clients (and two separate M3UA connections at all) was introduced as we didn't have an STP at the time and we still wanted to make progress on IuCS+IuPS. So my favorite would be option 'c', and if not that, option 'a' and only as a last resort go to option 'b'. 'd' can be done as incremental step to either of the three above. > A "matching" route is recognised by osmo_ss7_route_find_dpc(): > if ((dpc & rt->cfg.mask) == rt->cfg.pc) > My own local client gets entered as route, with rt->cfg.mask == 0 and > rt->cfg.pc == 0, so an arbitrary dpc & 0 == 0, matches always. It seems > awfully easy to create a fatal infinite loop flooding the network and CPU -- > simply send a message to a DPC neither side sees as local. Anyway... that's good to point out and should certainly be adressed. Unfortuantely I think the hop counter information element is not mandatory :/ > Which way to go to serve more than one PC in a program? It appears that either -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Wed Jun 21 20:45:03 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 22:45:03 +0200 Subject: SCCP/M3UA: PC and routing questions In-Reply-To: <20170621031237.GG1527@my.box> References: <20170621031237.GG1527@my.box> Message-ID: <20170621204503.GA7792@my.box> It took me ages yesterday to figure out why the described message loop was happening. Earlier today I experienced the stark opposite: by simply setting both hnbgw clients to the same local PC, IuCS started working immediately :) It's still of course nonsense to have two clients with the same point code, IuPS is hence not working yet. The earlier questions are still valid. The great success here: I have for the first time subscribed a UE via 3G using the AoIP code. USSD works, SMS work, voice calls work! Yay!! Next: fix IuPS, and go on to test parallel operation of 2G + 3G. Exciting. > > Apparently this global primary_pc is set in osmo_sccp_simple_client(). > it is not truly global, but speciic to the SS7 instance. Yes, I see more clearly now that we do ss7 = osmo_ss7_instance_find_or_create(ctx, 1); in osmo_sccp_simple_client(), which ends up using the same ss7 instance. Instead of separate instances, I'm trying to go with: > c) do away with the two separate signaling connections for PS and CS > domain. I would assume that an operator typically has one signaling > network, with unique point codes and routing in place. A problem I hit is that we send: if (cnlink->is_ps) domain = RANAP_CN_DomainIndicator_ps_domain; else domain = RANAP_CN_DomainIndicator_cs_domain; msg = ranap_new_msg_reset(domain, &cause); return osmo_sccp_tx_unitdata_msg(cnlink->sccp_user, &cnlink->gw->sccp_local_addr, &cnlink->remote_addr, msg); when a T_RafC times out. So we send a CS or PS domain RANAP RESET message towards the core network message when this timer for a CN link expires. I will now have one SCCP link with one PC for the HNBGW, and thus will send both CS and PS domain RESET messages when this T_RafC timer expires. I can't claim to have understood this RESET message though, haven't seen it happening. This reset message is the only thing where we compose the domain in the HNBGW. Two functions in ranap_msg_factory.c also set a domain indicator, but these are not used in the hnbgw, only by libosmo-ranap users. Both SGSN and MSC can send their RANAP to the same PC, because they have already encoded the domain indicator in their RANAP messages. We could technically still tell apart who sent it from the SCCP originating PC. (I also tried to have two SCCP users with the same PC on one sccp_instance, which doesn't work because a) the code prevents me from registering two users on the same PC and b) it doesn't make sense anyway; wishful thinking was that a conn_id would trace replies back to the right user and we'd magically know whether it came from the MSC or the SGSN, which might even work in some cases but is surely not what we want, and apparently don't even need at all.) I still wonder the same as with a BSC connecting to the MSC via an STP: we never really know whether the MSC or SGSN are actually present. When we have a link to the STP but the SGSN goes up in smoke, nothing notifies us of a connection being cleared. The STP will fail to route our messages, but we can't really get notified of a link change. IIUC we will only receive info on the first leg to the STP and not beyond. So far it's not that easy to figure out how to properly use SCCP with an STP in the middle. Playing around with this and making wrong choices (based on the previous hnbgw code) I'm starting to gather some experience ... having direct hnbgw<->MSC and hnbgw<->SGSN links was easier :) You mentioned link redundancy, and I guess easy CN-side re-routing is what we get out of using an STP? Aside: using only one link from the HNBGW to the STP kind of makes the HNBGW look useless :) All that it does is "bounce back" the HNBAP stuff. Apart from that, it only translates the IuCS/IuPS domain indicator to an SCCP point code, sticks it to an M3UA message and passes on to the right. Before, it did have two separate CN links to divide up messages to, now it's just a bit of number crunching in a separate process. ... doesn't make sense to let our OsmoSTP talk Iuh directly, does it? :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 21 21:04:25 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Jun 2017 23:04:25 +0200 Subject: osmo_sock_get_name() order In-Reply-To: <20170621185440.rwsuedvtabd2bv2u@nataraja> References: <20170620223332.GB1527@my.box> <91432b7a-390c-7649-f10f-0cb192ef1b7a@sysmocom.de> <20170621031718.GA1965@my.box> <20170621185440.rwsuedvtabd2bv2u@nataraja> Message-ID: <20170621210425.GB7792@my.box> On Wed, Jun 21, 2017 at 09:54:40PM +0300, Harald Welte wrote: > In terms of left/right: I think there is no obvious or correct way. > > > Based on the fd it's unfortunately not possible to have an explicit > "CLIENT -> SERVER" kind of notation replacing the bi-directional arrow > that we currently print. This would require that we keep a lot more > state and nothing that can be derived from the fd alone :/ > > On Wed, Jun 21, 2017 at 05:17:18AM +0200, Neels Hofmeyr wrote: > > On Wed, Jun 21, 2017 at 12:58:59AM +0200, Max wrote: > > > > +1, I'd even favor writing out 'remote:' and 'local:'. > > My original idea was that a system administrator would inherently know > which of the two sides is the local side of the socket, based on his > configuration. In this output: 127.0.0.1:2905<->127.0.0.1:60661 it is always unclear who is using 2905 and who 60661. > L/R I can still live with, but please don't make it even longer. But then it looks like "Left" and "Right", with Left on the right and Right on the left ... I'd still prefer explicit strings, they're not taking up much space. If you guys outvote me on "L" "R", it's still better than nothing... I just posted both variants: https://gerrit.osmocom.org/3000 https://gerrit.osmocom.org/3001 Let your votes decide which one wins. (I picked '=' instead of ':' because ':' is already used as the port number separator.) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 21 23:25:59 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 22 Jun 2017 01:25:59 +0200 Subject: SCCP/M3UA: PC and routing questions In-Reply-To: <20170621204503.GA7792@my.box> References: <20170621031237.GG1527@my.box> <20170621204503.GA7792@my.box> Message-ID: <20170621232559.GC7792@my.box> On Wed, Jun 21, 2017 at 10:45:03PM +0200, Neels Hofmeyr wrote: > This reset message is the only thing where we compose the domain in the HNBGW. Damn, that's not true. I somehow missed the main message dispatch towards Iuh, not sure how I managed that... > Both SGSN and MSC can send their RANAP to the same PC, because they have > already encoded the domain indicator in their RANAP messages. And not true either of course. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Thu Jun 22 07:15:39 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 22 Jun 2017 10:15:39 +0300 Subject: SCCP/M3UA: PC and routing questions In-Reply-To: <20170621204503.GA7792@my.box> References: <20170621031237.GG1527@my.box> <20170621204503.GA7792@my.box> Message-ID: <20170622071539.kqgjmpjamyqd3ymd@nataraja> Hi Neels, On Wed, Jun 21, 2017 at 10:45:03PM +0200, Neels Hofmeyr wrote: > It took me ages yesterday to figure out why the described message loop was > happening. Earlier today I experienced the stark opposite: by simply setting > both hnbgw clients to the same local PC, IuCS started working immediately :) strange. Maybe some unitialized state somewhere making this non-reproducible? > The great success here: I have for the first time subscribed a UE via 3G using > the AoIP code. USSD works, SMS work, voice calls work! Yay!! great! > Instead of separate instances, I'm trying to go with: > > > c) do away with the two separate signaling connections for PS and CS > > domain. I would assume that an operator typically has one signaling > > network, with unique point codes and routing in place. > > A problem I hit is that we send: > > if (cnlink->is_ps) > domain = RANAP_CN_DomainIndicator_ps_domain; > else > domain = RANAP_CN_DomainIndicator_cs_domain; I fear the entire 'cnlink' abstraction is at the wrong layer, or used wrongly. There's one signalling link at MTP-level, but there are multiple sccp_user and local/remote addresses inside. Outlook: In networks with RAN sharing, a single hnb-gw may have to talk with multiple MSCs or SGSNs (of different operators). That could happen over one mtp-level signalling link[set] and separate sccp-addresses for the related MSC/SGSN peers. Or it could happen with separate mtp-level signalling link[sets], one for each operator. > I will now have one SCCP link with one PC for the HNBGW, and thus will send > both CS and PS domain RESET messages when this T_RafC timer expires. yes, I guess you basically need to split cnlink into something like an 'sccp_peer' kind of structure, which contains the related remote sccp_address and a reference to the signalling link. Then multiple sccp_peers can point to one link (or multiple links). > (I also tried to have two SCCP users with the same PC on one sccp_instance, > which doesn't work because a) the code prevents me from registering two users > on the same PC and b) it doesn't make sense anyway; wishful thinking was that a > conn_id would trace replies back to the right user and we'd magically know > whether it came from the MSC or the SGSN, which might even work in some cases > but is surely not what we want, and apparently don't even need at all.) If there are separate SSNs, you can have multiple SCCP users with the same PC. But with same SSN + PC it's like trying to bind two sockets to the same IP-address (PC) and port (SSN): It's not possible. > I still wonder the same as with a BSC connecting to the MSC via an STP: we > never really know whether the MSC or SGSN are actually present. When we have a > link to the STP but the SGSN goes up in smoke, nothing notifies us of a > connection being cleared. Philipp has worked on detecting unresponsive/disconnected MSCs, clearing local state and re-transmitting RESET messages on OsmoBSC recently. Maybe you should coordinate with him. Also, a real STP would implement the actual management procedures and tell you * when a route comes up or goes down * when you send something to an unreachable destination Both parts have not been implemented in OsmoSTP so far, as I didn't consider this the most important feature for us to get started. As a SCCP User, you wuold get N-NOTICE.ind in such cases, as far as I remember. In any case, passive detection of non-responding peers (as done by Philipp in the BSC) is something you would probably want to have anyway. I'm not sure there are plenty of failure cases in which an explicit notification of destination availability/unavailability will not reach you. > The STP will fail to route our messages, but we can't > really get notified of a link change. IIUC we will only receive info on the > first leg to the STP and not beyond. see above. > So far it's not that easy to figure out how to properly use SCCP with an STP in > the middle. Playing around with this and making wrong choices (based on the > previous hnbgw code) I'm starting to gather some experience ... having direct > hnbgw<->MSC and hnbgw<->SGSN links was easier :) You mentioned link > redundancy, and I guess easy CN-side re-routing is what we get out of using an > STP? Interoperability with other BSC/MSC/SGSN/HNB-GW on AoIP and IuCS/IuPS is what we get out of it primarily. > Aside: using only one link from the HNBGW to the STP kind of makes the HNBGW > look useless :) All that it does is "bounce back" the HNBAP stuff. It does exactly what the HNB-GW is specified to do in the architecture. It translates from RUA to M3UA. The rationale is that the HNodeBs's don't have to have SS7 connection (security issues) nor have a SS7 stack (cost issue, for all those people who ignore the fact that implementing related stack as FOSS would remove those royalties). Also, operational procedures like: "How do I assign point codes to all the hNodeB in an organzied fashion?" or "Do I actually have sufficient point codes for the large population of hNodeB that can easily go into the 100k or even millions of units?" -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From ron.menez at entropysolution.com Thu Jun 22 11:07:27 2017 From: ron.menez at entropysolution.com (Ron) Date: Thu, 22 Jun 2017 11:07:27 +0000 Subject: Error encountered using osmo-trx=0.1.9.20170621 Message-ID: <8D81F90E-12CC-401E-B207-2728FB897B74@entropysolution.com> Hi All, We encountered an error upon running the "osmo-trx? using Ubuntu 16.04 OS. We have an existing "osmo-trx? in one of our server and running just fine. Upon checking for the version, the working ?osmo-trx? is running at ?0.1.9.20170530?, while the new one with an error is running at ?0.1.9.20170621?. Kindly see below error for your reference: # osmo-trx osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_GAINSE Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From msuraev at sysmocom.de Thu Jun 22 13:49:49 2017 From: msuraev at sysmocom.de (Max) Date: Thu, 22 Jun 2017 15:49:49 +0200 Subject: jenkins plugin question Message-ID: Hi. I've got add few more parameters to OsmoBTS and OsmoPCU gerrit jobs in jenkins. So far this has been done by manually adding parameter axis and writing combination filter for axis parameters. It's error prone and rather ugly. Much better way would be to use JobDSL and declare entire job programmatically but until that happens there's nice intermediate solution: https://plugins.jenkins.io/matrix-combinations-parameter I'd like to install this plugin onto our jenkins and convert above mentioned jobs to use it. Opinions, other ideas? On a related note: who's responsible for jenkins config/update? Shall I just contact that person directly if I need some plugin in jenkins, or shall I ask in ML? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From tom at tsou.cc Thu Jun 22 18:02:36 2017 From: tom at tsou.cc (Tom Tsou) Date: Thu, 22 Jun 2017 11:02:36 -0700 Subject: Error encountered using osmo-trx=0.1.9.20170621 In-Reply-To: <8D81F90E-12CC-401E-B207-2728FB897B74@entropysolution.com> References: <8D81F90E-12CC-401E-B207-2728FB897B74@entropysolution.com> Message-ID: Hi Ron, On Thu, Jun 22, 2017 at 4:07 AM, Ron wrote: > Kindly see below error for your reference: > > # osmo-trx > osmo-trx: symbol lookup error: osmo-trx: undefined symbol: > _ZN3uhd4usrp10multi_usrp9ALL_GAINSE Can you specify the device and the installed UHD version? There have been a handful of commits recently, though very few of them have been functional changes as opposed to code cleanup and removal. -TT From holger at freyther.de Thu Jun 22 19:24:34 2017 From: holger at freyther.de (Holger Freyther) Date: Thu, 22 Jun 2017 21:24:34 +0200 Subject: jenkins plugin question In-Reply-To: References: Message-ID: <8F15394A-2AC4-4C8A-A5A3-B1C09AB0A538@freyther.de> > On 22. Jun 2017, at 15:49, Max wrote: > > Hi. > > > I'd like to install this plugin onto our jenkins and convert above mentioned jobs to > use it. Opinions, other ideas? See the conversation when blobb proposed to use it? I think many of the arguments still apply? holger From nhofmeyr at sysmocom.de Fri Jun 23 00:27:40 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 23 Jun 2017 02:27:40 +0200 Subject: heads up: no more \brief in libosmocore Message-ID: <20170623002740.GD7792@my.box> I've just merged a patch that enables the AUTOBRIEF function of doxygen, in libosmocore. Every API doc's first sentence up to the first full-stop '.' is now automatically its \brief description. You may omit the \brief. This is so far only in libosmocore, since I'm not aware of us generating doxygen in any other repositories. Either way we can and should avoid the \brief, and in doubt enable the AUTOBRIEF everywhere. I've also shifted around the \file directives across libosmocore, and wrote a wiki page that describes it among other things: https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation Related: the series of "doxygen:" commits that just came into libosmocore master. http://git.osmocom.org/libosmocore/commit/?id=87e4550585c643e97e0003119b254251ac5ed1d4 http://git.osmocom.org/libosmocore/commit/?id=17518fe393a37781c84d09836256bb1a6256032b Do any other code trees need this switching? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Fri Jun 23 02:51:07 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 23 Jun 2017 04:51:07 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester Message-ID: <20170623025107.GE7792@my.box> We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. I have run a tcpdump on the ntp port for the past days, and nothing is doing ntp besides the actual ntp service. Today I started ntp while an osmo-bts-trx run was active and what do you know, the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx shouldn't use wall clock time for precise timing needs. Besides that, I have no idea what could cause the clock skews, except maybe that the CPU or the USB are not fast enough?? I'm wondering, is there still such a thing as a separate linux realtime kernel? We will soon take to productive use another main unit which will be a cleanly installed OS. If we see the same problems on that system and can't find a software fix, we may need to reconsider the tester for osmo-bts-trx... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From domi at tomcsanyi.net Fri Jun 23 06:58:00 2017 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Fri, 23 Jun 2017 08:58:00 +0200 (CEST) Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170623025107.GE7792@my.box> References: <20170623025107.GE7792@my.box> Message-ID: On Ubuntu they maintain a version of the kernel called "lowlatency" (linux-image-lowlatency), it might be worth a try. Regards, Domi 2017. j?n. 23. d?tummal, 4:52 id?pontban Neels Hofmeyr ?rta: > We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. > > I have run a tcpdump on the ntp port for the past days, and nothing is doing > ntp besides the actual ntp service. > > Today I started ntp while an osmo-bts-trx run was active and what do you know, > the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx > shouldn't use wall clock time for precise timing needs. > > Besides that, I have no idea what could cause the clock skews, except maybe > that the CPU or the USB are not fast enough?? I'm wondering, is there still > such a thing as a separate linux realtime kernel? > > We will soon take to productive use another main unit which will be a cleanly > installed OS. If we see the same problems on that system and can't find a > software fix, we may need to reconsider the tester for osmo-bts-trx... > > ~N From laforge at gnumonks.org Fri Jun 23 09:19:10 2017 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 23 Jun 2017 11:19:10 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170623025107.GE7792@my.box> References: <20170623025107.GE7792@my.box> Message-ID: <20170623091910.5odlmpwbdv2h5ddw@nataraja> Hi Neels, On Fri, Jun 23, 2017 at 04:51:07AM +0200, Neels Hofmeyr wrote: > We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. I'm sorry, but I have to ask for more specifics: What exactly is a 'massive stability problem'? How does it manifest itself in detail at the lowest possible interface (i.e. log output of osmo-trx, osmo-bts-trx, ...)? > I have run a tcpdump on the ntp port for the past days, and nothing is doing > ntp besides the actual ntp service. And that service was presumably disabled (before your test described in the next paragraph)? > Today I started ntp while an osmo-bts-trx run was active and what do you know, > the osmo-bts-trx process exits immediately. I think this is bad, osmo-bts-trx > shouldn't use wall clock time for precise timing needs. Yes, I think it's a sign of very poor design if we cannot even sync the local wall clock to a NTP or GPS reference. CLOCK_MONOTONIC_RAW should be used on Linux for use cases like the one in osmo-bts-trx, having to schedule bursts at specific time intervals. In fact, I think the entire TRX<->BTS interface is not all that good an idea to begin with. In OsmoTRX, we have the ADC/DAC sample clock that is driving transmission of samples. Normally, the entire PHY layer runs synchronous to that, and it would drive the "clock" of L2 by means of PH-RTS.ind, so the L2 knows whenever it wants to transmit something. However, the OsmoTRX <-> osmo-bts-trx interface is not at the PHY<->L2 boundary, but it is at an inner boundary between the radio modem (OsmoTRX) and the L1 (in osmo-bts-trx). And those are two separate processes, without any way to synchronously trigger some action based on the ADC/DAC master sample clock. As a result, osmo-bts-trx needs to keep its own clock, based on whatever clock source available in the operating system / hardware, and make sure it sends bursts at the right speed to OsmoTRX. So OsmoTRX and osmo-bts-trx run actually asynchronous, at something that is specified/designed to be a synchronous interface in the GSM architecture. But then, I guess we don't have the luxury of changing all of this, so migrating to something like CLOCK_MONOTONIC_RAW or CLOCK_MONOTONIC. Instead of osmocom timers, using timer_create(CLOCK_MONOTONIC, ..)) sounds like a good idea, or even timerfd_create() which would integrate with our select() loop. Problem is only that those are about periodic timers. While we do want periodicity (once every burst period of 577us), the local clock of the Linux system is >= 1000 times less accurate than the clock of the GSM transmitting hardware, i.e. we need to adjust the expiration of our timer based on clock information provided by osmo-trx. > Besides that, I have no idea what could cause the clock skews, except maybe > that the CPU or the USB are not fast enough?? where is evidence of that? * do we get underruns / overruns in reading/writing from/to the SDR? ** if this is not properly logged yet, we should make sure all such instances are properly logged, and that we have a counter that counts such events since the process start. Printing of related counters could be done at time of sending a signal to the process, or in periodic intervals (every 10s?) on stdout * do we see indications of packet loss between TRX and BTS? ** each UDP on the per-TRX data interface contains frame number and timeslot index in its header, so detecting missing frames is easy, whether or not this is currently already implemented. 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 pespin at sysmocom.de Fri Jun 23 12:23:55 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 23 Jun 2017 14:23:55 +0200 Subject: AddressSanitizer in FreeBSD jenkins builds Message-ID: <6e95869e-237e-e938-d40b-28dde942a7eb@sysmocom.de> Hi, Some of you may have noticed that I have been lately fixing compilation warnings + enabling -Wall and -Werror on jenkins build for several osmocom libraries. While doing so, I noticed that the following lines trying to enable AddressSanitizer support are actually failing when building with the FreeBSD jenkins slave, probably due to it using some other shell without bash support: ./configure: CFLAGS+= -fsanitize=address -fsanitize=undefined: not found ./configure: CPPFLAGS+= -fsanitize=address -fsanitize=undefined: not found The source lines are: CFLAGS+=" -fsanitize=address -fsanitize=undefined" CPPFLAGS+=" -fsanitize=address -fsanitize=undefined" After changing them to support sh and submitting the change in gerrit [1], AddressSanitizer was enabled in FreeBSD for first time, but I started getting lots of link issues with AdressSanitizer (asan) related symbols. I read in several places that there seems to be a known issue with FreeBSD 10.3 and clang-3.4.1 (what we are using) regarding use of AddressSanitizer [2, 3]. I then tried configuring CC in the jenkins slave to use clang37 instead of cc (clang-3.4.1), and then the linking issue seems to be solved, but again a new compiler bug related to usage of __builtin_cpu_supports shows up, preventing compilation of libosmocore [4]. I think the best solution is to disable explicitly AddressSanitizer in contrib/jenkins.sh when running from FreeBSD, so the behaviour is actually the same as before, in which it was implicitly not enabled due to a syntax error. Once we move to FreeBSD11 and clang-3.8 we can try enabling it again. If nobody comes with a better solution or is against this, I will proceed to do so during next hours/days. [1] https://gerrit.osmocom.org/#/c/3024/2/configure.ac [2] https://stackoverflow.com/questions/30085036/linking-clang-address-sanitizer-on-freebsd-10-1-release [3] https://webcache.googleusercontent.com/search?q=cache:CZmrK35zigEJ:ea5faa5po25cf7fb.onion.nu/projects/tor/ticket/19821+&cd=1&hl=ca&ct=clnk&gl=de&client=firefox-b [4] https://bugs.llvm.org//show_bug.cgi?id=25510 -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From tom at tsou.cc Fri Jun 23 18:19:53 2017 From: tom at tsou.cc (Tom Tsou) Date: Fri, 23 Jun 2017 11:19:53 -0700 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170623091910.5odlmpwbdv2h5ddw@nataraja> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> Message-ID: On Fri, Jun 23, 2017 at 2:19 AM, Harald Welte wrote: > Yes, I think it's a sign of very poor design if we cannot even sync the > local wall clock to a NTP or GPS reference. CLOCK_MONOTONIC_RAW should > be used on Linux for use cases like the one in osmo-bts-trx, having to > schedule bursts at specific time intervals. > > In fact, I think the entire TRX<->BTS interface is not all that good an > idea to begin with. I agree that the L1<->L0 socket interface is quite unusual. The historical reason for a distinct mid-PHY split was to create a license shim layer between commercial licensed OpenBTS code and GPL based GNU Radio. I don't believe that there was ever a good technical reason in terms of code or structure for the separation. Currently, the only reason that the socket layer needs to exist is for backwards compatibility with OpenBTS, and I'm not sure how much support there is for that option now. Perhaps there are some fronthaul / C-RAN application benefits, but I'm not aware of that being a popular use case for osmo-trx. So the justification for the the existing TRX<->BTS interface for use with osmo-bts is not very strong. >> Besides that, I have no idea what could cause the clock skews, except maybe >> that the CPU or the USB are not fast enough?? > > where is evidence of that? > * do we get underruns / overruns in reading/writing from/to the SDR? > ** if this is not properly logged yet, we should make sure all such > instances are properly logged, and that we have a counter that counts > such events since the process start. Printing of related counters > could be done at time of sending a signal to the process, or in > periodic intervals (every 10s?) on stdout We do not have overrun / underrun counters in osmo-trx, but I agree that this is a good idea. > * do we see indications of packet loss between TRX and BTS? > ** each UDP on the per-TRX data interface contains frame number and > timeslot index in its header, so detecting missing frames is easy, > whether or not this is currently already implemented. Packet loss between TRX-BTS is definitely a concern, but I think that is unlikely. The skew between OS time and device time is likely driven by scheduling and transient delays in BTS burst processing and/or late UDP arrival from TRX. In that case, a faster machine certainly helps. Another test could be running BTS and TRX on separate machines to isolate process scheduling for each application. -TT From nhofmeyr at sysmocom.de Fri Jun 23 23:11:44 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 24 Jun 2017 01:11:44 +0200 Subject: osmo-bts revert: osmo-bts-trx regression detected by osmo-gsm-tester Message-ID: <20170623231144.GA17301@my.box> Today we faced consistent osmo-bts-trx failures and I submitted a revert of commit "RSL: receive and send multiple SI2q messages". See https://osmocom.org/issues/2338. Why did we not catch it earlier? There was a bug in the osmo-gsm-tester build where the build could get stuck on a local branch instead of building newly pulled changes. That was fixed about a day ago, so we saw the breakage today. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Fri Jun 23 23:34:42 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sat, 24 Jun 2017 01:34:42 +0200 Subject: jenkins plugin question In-Reply-To: References: Message-ID: <20170623233442.GA20445@my.box> On Thu, Jun 22, 2017 at 03:49:49PM +0200, Max wrote: > https://plugins.jenkins.io/matrix-combinations-parameter I added this now. It seems to employ a bit of magic to do so, but all it does is simplify the selection of which matrix combinations should be built, right? Recently I added the Test Results Analyzer plugin to ease viewing which tests caused an osmo-gsm-tester failure, as well as the Rebuilder plugin to avoid having to enter the same parameters over and over. These go in the same category of small making-your-life-easier plugins. We recently had a kind of discussion about jenkins upgrades, to only upgrade if really needed to minimize fallout. Loose fact: I just noticed that scores of jenkins plugins we have on jenkins.osmocom.org have upgrades available. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From ron.menez at entropysolution.com Sun Jun 25 01:10:53 2017 From: ron.menez at entropysolution.com (Ron) Date: Sun, 25 Jun 2017 01:10:53 +0000 Subject: Error encountered using osmo-trx=0.1.9.20170621 In-Reply-To: References: <8D81F90E-12CC-401E-B207-2728FB897B74@entropysolution.com> Message-ID: Hi Tom, The device we?re using is B200 and the UHD (tried both libuhd003 and libuhd-dev) version is 3.9.2-1. I tried to install this version osmo-trx=0~20150325gitf147b17+dfsg-3 and no error were received upon running. Unfortunately, all of my phones were not able to camp. I?m not sure if this is a configuration issue but same configuration files were used (which we only changed the IP Addresses and ipa-unit ID for both osmo-nitb and osmo-bts-trx) to the working and existing test servers. Attached are the configuration files for osmo-nitb and osmo-bts-trx. Best Regard, Ron Menez ron.menez at entropysolution.com On Jun 23, 2017, at 2:02 AM, Tom Tsou > wrote: Hi Ron, On Thu, Jun 22, 2017 at 4:07 AM, Ron > wrote: Kindly see below error for your reference: # osmo-trx osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd4usrp10multi_usrp9ALL_GAINSE Can you specify the device and the installed UHD version? There have been a handful of commits recently, though very few of them have been functional changes as opposed to code cleanup and removal. -TT -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.conf Type: application/octet-stream Size: 6397 bytes Desc: openbsc.conf URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts.cfg Type: application/octet-stream Size: 1812 bytes Desc: osmo-bts.cfg URL: From nhofmeyr at sysmocom.de Sun Jun 25 13:22:06 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 25 Jun 2017 15:22:06 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170623091910.5odlmpwbdv2h5ddw@nataraja> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> Message-ID: <20170625132206.GA9557@my.box> On Fri, Jun 23, 2017 at 11:19:10AM +0200, Harald Welte wrote: > Hi Neels, > > On Fri, Jun 23, 2017 at 04:51:07AM +0200, Neels Hofmeyr wrote: > > We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. > > I'm sorry, but I have to ask for more specifics: > What exactly is a 'massive stability problem'? How does it manifest To quantify: between 30 and 40% of all osmo-gsm-tester runs fail because of: 20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: Frame difference is > 1! 20170625121036320 DL1C <0006> scheduler_trx.c:1527 GSM clock skew: old fn=2289942, new fn=2290004 20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: Frame difference is > 1! Detailed logs in http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/940/artifact/trial-940-run.tgz in /run.2017-06-25_12-05-43/sms:trx/mo_mt_sms.py/osmo-bts-trx/osmo-bts-trx/stderr Related osmo-trx output is in the same tgz at in /run.2017-06-25_12-05-43/sms:trx/mo_mt_sms.py/osmo-bts-trx/osmo-trx/stderr (Number crunching: if 30% of the test runs fail, where each run contains two osmo-bts-trx tests, it means that roughly 15% of osmo-bts-trx tests fail.) (The reason why I say "massive": it's really annoying to have this rate of sporadic failure. Instead of investigating upon first failure, we will only notice a regression when runs fail consistently, i.e. when there are no successful runs for, say, 5 or more runs. We don't take action immediately, yet we have to be careful to not be too late and loose jenkins run logs of the last successful run. The first failing runs in a series can well be just trx failures, so it needs more effort to find out which run introduced an actual regression.) > > I have run a tcpdump on the ntp port for the past days, and nothing is doing > > ntp besides the actual ntp service. > > And that service was presumably disabled (before your test described in > the next paragraph)? Yes, started the tcpdump filtering on the ntp port, saw ntp packets (to verify that it works), disabled the ntp service, saw that packets cease, restarted the tcpdump in a tmux, forgot about it for a couple of days, then came back to the tmux and saw that the tcpdump was completely empty. Then again I started the ntp service, immediately saw ntp packets in the tcpdump and the osmo-bts-trx test run failed promptly. Let me mention that I see myself as "the messenger", relaying the results I see on the tester setup; I will pursue a solution in a limited fashion, to not neglect other tasks. I can of course test things in case anyone has more ideas. Tom mentioned the idea of running osmo-bts-trx on a different machine from osmo-trx -- that is certainly possible in a manual test, but I guess not really an option for the regular tests. It would be a lot of manual supervision to perform a series of tests, like 20 or more, to find out the success rate; or a code and jenkins config change to run the osmo-bts-trx binary on a different build slave, not trivial. It would be much preferred to stay on a single host computer... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Sun Jun 25 15:20:49 2017 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 25 Jun 2017 17:20:49 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170625132206.GA9557@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> Message-ID: <20170625152049.obreyemq7deyh2ls@nataraja> Hi Neels, On Sun, Jun 25, 2017 at 03:22:06PM +0200, Neels Hofmeyr wrote: > On Fri, Jun 23, 2017 at 11:19:10AM +0200, Harald Welte wrote: > > On Fri, Jun 23, 2017 at 04:51:07AM +0200, Neels Hofmeyr wrote: > > > We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. > > > > I'm sorry, but I have to ask for more specifics: > > What exactly is a 'massive stability problem'? How does it manifest > > To quantify: between 30 and 40% of all osmo-gsm-tester runs fail because of: > > 20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: Frame difference is > 1! that's the higher-layer code complaining that the frame number as reported by the lower layer code (osmo-bts-trx) has not incremented by +1. The normal expectation is tha that osmo-bts-* feeds every FN into the common layer (via l1sap). > 20170625121036320 DL1C <0006> scheduler_trx.c:1527 GSM clock skew: old fn=2289942, new fn=2290004 That's 62 frames "missed", which is quite a lot (translating to 285ms). > I can of course test things in case anyone has more ideas. As indicated in the related ticket, I have submitted a patch to gerrit that switches from gettimeofday() based osmo_timer_list to a monotonic timerfd based interval timer for the FN clock inside osmo-bts-trx. It would be good if you can see to this being tested. I am travelling more than I'm at home or at the office (i.e. no access to related equipment), nor do I have insight into how we could test a non-master patch in the osmo-gsm-tester setup. There are more odd parts in osmo-bts-trx that I could imagine having an inpact on this, but we should take it step-by-step. One problem is for example that the UDP sockets for the TRX/BTS communication are not set to non-blocking-mode, so a blocking write could mess a lot with timing. > Tom mentioned the idea of running osmo-bts-trx on a different machine from > osmo-trx -- that is certainly possible in a manual test, but I guess not really > an option for the regular tests. It is an option. However, we need to understand what exactly is the problem here. Rather than adding additional hardware to the osmo-gsm-tester setup in a "trial and error" aka "stumbling in the dark" fashion, I would use the opposite approach: Set up osmo-bts-trx on the same hardware (APU) next to your laptop on your personal desk, and then try to see if and when the above problems can be reproduced, maybe by putting some more CPU load on the APU, or I/O load, or whatever.. If osmo-bts-trx is too unstable for the "production" osmo-gsm-tester, I would simply disable it until we have adressed related bugs. 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 msuraev at sysmocom.de Mon Jun 26 08:34:02 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 26 Jun 2017 10:34:02 +0200 Subject: osmo-trx -m is broken Message-ID: <467a6314-027b-e6e1-e078-f39846d1ba9b@sysmocom.de> Hi. I've got following error in latest osmo-trx: ./Transceiver52M/osmo-trx -x -c 2 -m -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. ALERT 139666585152384 10:32:48.8 UHDDevice.cpp:642:open: Channel setting failed - map::at ALERT 139666585152384 10:32:48.8 UHDDevice.cpp:642:open: Channel setting failed - map::at ALERT 139666585152384 10:32:48.8 osmo-trx.cpp:454:main: Failed to create radio device ALERT 139666585152384 10:32:48.8 osmo-trx.cpp:454:main: Failed to create radio device Shutting down transceiver... If I remove -m than it starts as expected. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From alexander.chemeris at gmail.com Mon Jun 26 10:25:29 2017 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Mon, 26 Jun 2017 19:25:29 +0900 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170625132206.GA9557@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> Message-ID: Hi Neels, Are you running osmo-trx in a single TRX or dual-TRX configuration? Do you have a CPU usage information from the system? Could you try disabling all timeslots but the ones take needed? It won't completely disable them with the current code, but IIRC it will somewhat help with the CPU load which I think is the real issue here. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co On Jun 25, 2017 22:23, "Neels Hofmeyr" wrote: > On Fri, Jun 23, 2017 at 11:19:10AM +0200, Harald Welte wrote: > > Hi Neels, > > > > On Fri, Jun 23, 2017 at 04:51:07AM +0200, Neels Hofmeyr wrote: > > > We're still having massive stability problems with osmo-bts-trx on the > osmo-gsm-tester. > > > > I'm sorry, but I have to ask for more specifics: > > What exactly is a 'massive stability problem'? How does it manifest > > To quantify: between 30 and 40% of all osmo-gsm-tester runs fail because > of: > > 20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: > Frame difference is > 1! > 20170625121036320 DL1C <0006> scheduler_trx.c:1527 GSM clock skew: old > fn=2289942, new fn=2290004 > 20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: > Frame difference is > 1! > > Detailed logs in > http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/ > job/osmo-gsm-tester_run/940/artifact/trial-940-run.tgz > in /run.2017-06-25_12-05-43/sms:trx/mo_mt_sms.py/osmo-bts-trx/ > osmo-bts-trx/stderr > > Related osmo-trx output is in the same tgz at > in /run.2017-06-25_12-05-43/sms:trx/mo_mt_sms.py/osmo-bts-trx/ > osmo-trx/stderr > > (Number crunching: if 30% of the test runs fail, where each run contains > two > osmo-bts-trx tests, it means that roughly 15% of osmo-bts-trx tests fail.) > > (The reason why I say "massive": it's really annoying to have this rate of > sporadic failure. Instead of investigating upon first failure, we will only > notice a regression when runs fail consistently, i.e. when there are no > successful runs for, say, 5 or more runs. We don't take action > immediately, yet > we have to be careful to not be too late and loose jenkins run logs of the > last > successful run. The first failing runs in a series can well be just trx > failures, so it needs more effort to find out which run introduced an > actual > regression.) > > > > I have run a tcpdump on the ntp port for the past days, and nothing is > doing > > > ntp besides the actual ntp service. > > > > And that service was presumably disabled (before your test described in > > the next paragraph)? > > Yes, started the tcpdump filtering on the ntp port, saw ntp packets (to > verify > that it works), disabled the ntp service, saw that packets cease, > restarted the > tcpdump in a tmux, forgot about it for a couple of days, then came back to > the > tmux and saw that the tcpdump was completely empty. Then again I started > the > ntp service, immediately saw ntp packets in the tcpdump and the > osmo-bts-trx > test run failed promptly. > > > Let me mention that I see myself as "the messenger", relaying the results > I see > on the tester setup; I will pursue a solution in a limited fashion, to not > neglect other tasks. > > I can of course test things in case anyone has more ideas. > > Tom mentioned the idea of running osmo-bts-trx on a different machine from > osmo-trx -- that is certainly possible in a manual test, but I guess not > really > an option for the regular tests. It would be a lot of manual supervision to > perform a series of tests, like 20 or more, to find out the success rate; > or a > code and jenkins config change to run the osmo-bts-trx binary on a > different > build slave, not trivial. It would be much preferred to stay on a single > host > computer... > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Jun 26 10:54:59 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Jun 2017 12:54:59 +0200 Subject: osmo-trx -m is broken In-Reply-To: <467a6314-027b-e6e1-e078-f39846d1ba9b@sysmocom.de> References: <467a6314-027b-e6e1-e078-f39846d1ba9b@sysmocom.de> Message-ID: <20170626105459.gl74p5iskij2yjw4@nataraja> Hi Max, it would be great if you could make sure to file bug reports in the bug tracker. If yo in addition follow-up by e-mail, you can simply refer to the bug tracker issue in that mail. Thanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Mon Jun 26 10:58:55 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 26 Jun 2017 12:58:55 +0200 Subject: osmo-trx -m is broken In-Reply-To: <20170626105459.gl74p5iskij2yjw4@nataraja> References: <467a6314-027b-e6e1-e078-f39846d1ba9b@sysmocom.de> <20170626105459.gl74p5iskij2yjw4@nataraja> Message-ID: https://projects.osmocom.org/issues/2341 is created to track this. On 26.06.2017 12:54, Harald Welte wrote: > Hi Max, > > it would be great if you could make sure to file bug reports in the bug > tracker. If yo in addition follow-up by e-mail, you can simply refer to > the bug tracker issue in that mail. > > Thanks. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Mon Jun 26 12:40:06 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 26 Jun 2017 14:40:06 +0200 Subject: .deb build as jenkins test Message-ID: Hi. In a light of https://projects.osmocom.org/issues/2340 I'd like to add .deb build as an additional step for jenkins jobs triggered by gerrit push. It'll mean longer build times but it'll prevent breaking changes from reaching master. It won't guarantee that we won't see occasional arch/version specific breakage in https://build.opensuse.org/project/monitor/network:osmocom:nightly but it should make nightly builds more stable and easier to maintain. What do you think? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Mon Jun 26 15:59:37 2017 From: msuraev at sysmocom.de (Max) Date: Mon, 26 Jun 2017 17:59:37 +0200 Subject: access grant channel on osmo(-bts)-trx Message-ID: Hi. The number of blocks reserved for access grant channel is determined by BS-AG-BLKS-RES sent by BSC in SI3: see 3GPP TS 44.018 Table 10.5.2.11.1. In case of sysmobts and lc15 it's used as lch_par->agch.u8NbrOfAgch. Unfortunately, I'm unable to find appropriate counterpart for scheduler.c/osmo-bts-trx. Any ideas as to how can we apply BS-AG-BLKS-RES to osmo-bts-trx (and, of course test that the proper setting was indeed applied) would be appreciated. -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Mon Jun 26 18:39:45 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 26 Jun 2017 20:39:45 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170625152049.obreyemq7deyh2ls@nataraja> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170625152049.obreyemq7deyh2ls@nataraja> Message-ID: <20170626183945.GA3407@my.box> On Sun, Jun 25, 2017 at 05:20:49PM +0200, Harald Welte wrote: > Hi Neels, > > On Sun, Jun 25, 2017 at 03:22:06PM +0200, Neels Hofmeyr wrote: > > On Fri, Jun 23, 2017 at 11:19:10AM +0200, Harald Welte wrote: > > > On Fri, Jun 23, 2017 at 04:51:07AM +0200, Neels Hofmeyr wrote: > > > > We're still having massive stability problems with osmo-bts-trx on the osmo-gsm-tester. > > > > > > I'm sorry, but I have to ask for more specifics: > > > What exactly is a 'massive stability problem'? How does it manifest > > > > To quantify: between 30 and 40% of all osmo-gsm-tester runs fail because of: > > > > 20170625121036320 DL1P <0007> l1sap.c:423 Invalid condition detected: Frame difference is > 1! > > that's the higher-layer code complaining that the frame number as > reported by the lower layer code (osmo-bts-trx) has not incremented by > +1. The normal expectation is tha that osmo-bts-* feeds every FN into > the common layer (via l1sap). > > > 20170625121036320 DL1C <0006> scheduler_trx.c:1527 GSM clock skew: old fn=2289942, new fn=2290004 > > That's 62 frames "missed", which is quite a lot (translating to 285ms). > > > I can of course test things in case anyone has more ideas. > > As indicated in the related ticket, I have submitted a patch to gerrit > that switches from gettimeofday() based osmo_timer_list to a monotonic > timerfd based interval timer for the FN clock inside osmo-bts-trx. It > would be good if you can see to this being tested. I have put your trx patches on a branch and built a binary from it, from http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/976 the patches are being tested on the gsm-tester. branch: osmo-bts:neels/trx_test (it actually started from 973, which failed because 'settsc' config is removed by one of the patches but was still in the osmo-bts-trx config file) 976 has a different failure in *one* of two trx tests: 20170626171713445 DOML <0001> oml.c:333 OC=CHANNEL INST=(00,00,07) AVAIL STATE Dependency -> OK 20170626171713445 DOML <0001> oml.c:340 OC=CHANNEL INST=(00,00,07) OPER STATE Disabled -> Enabled 20170626171713445 DOML <0001> oml.c:301 OC=CHANNEL INST=(00,00,07) Tx STATE CHG REP 20170626171713513 DL1C <0006> scheduler_trx.c:1704 We were 47 FN faster than TRX, compensating 20170626171713514 DL1C <0006> scheduler_trx.c:1704 We were 47 FN faster than TRX, compensating 20170626171713515 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713517 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713517 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713519 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713519 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating 20170626171713727 DL1C <0006> scheduler_trx.c:1600 PC clock skew: elapsed_us=614659, error_us=610044 20170626171713727 DOML <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx [...] Shutdown timer expired The next run, 977, is successful. All following runs until now (982) are failing. See http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/test_results_analyzer/ and click once on the (+) to expand one level of child nodes. So at first glance it appears that the patches make things worse. Starting from build #983, we are testing an osmo-bts-trx with *only* the CLOCK_MONOTONIC patch applied. Notably we have removed the settsc config option from the osmo-bts-trx config, but then again settsc seems to not have any effect in the code. > fashion, I would use the opposite approach: Set up osmo-bts-trx on the > same hardware (APU) next to your laptop on your personal desk, and then > try to see if and when the above problems can be reproduced, maybe by > putting some more CPU load on the APU, or I/O load, or whatever.. Yes, may be something Pau should take on? > If osmo-bts-trx is too unstable for the "production" osmo-gsm-tester, I > would simply disable it until we have adressed related bugs. We'll see about disabling soon. We *did* catch a regression with it recently... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Mon Jun 26 19:30:16 2017 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Jun 2017 21:30:16 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> Message-ID: <20170626193016.6irlege5v2zslgrf@nataraja> Hi Tom, thanks for your input. On Fri, Jun 23, 2017 at 11:19:53AM -0700, Tom Tsou wrote: > On Fri, Jun 23, 2017 at 2:19 AM, Harald Welte wrote: > > I agree that the L1<->L0 socket interface is quite unusual. The > historical reason for a distinct mid-PHY split was to create a license > shim layer between commercial licensed OpenBTS code and GPL based GNU > Radio. I don't believe that there was ever a good technical reason in > terms of code or structure for the separation. ah, I didn't know (or remember) there was actually any gnuradio dependency in the OpenBTS transceiver. > Currently, the only reason that the socket layer needs to exist is for > backwards compatibility with OpenBTS, and I'm not sure how much > support there is for that option now. I also don't think there is much value in this. I'm not aware anyone regularly testing that configuration, and I don't think there is value to support something that nobody is testing. > Perhaps there are some fronthaul / C-RAN application benefits, but I'm > not aware of that being a popular use case for osmo-trx. not yet, at least. Maybe once such systems become more deployed in regions where GSM is not phased out. But even in such cases, I would expect that actual I/Q baseband samples are required (e.g. in CPRI or OBSAI), and not unmodulated/demodulated symbols. > So the justification for the the existing TRX<->BTS interface for use > with osmo-bts is not very strong. Agreed. On the other hand, changing it would be quite some amount of work, so we might just as well keep it. > > where is evidence of that? > > * do we get underruns / overruns in reading/writing from/to the SDR? > > ** if this is not properly logged yet, we should make sure all such > > instances are properly logged, and that we have a counter that counts > > such events since the process start. Printing of related counters > > could be done at time of sending a signal to the process, or in > > periodic intervals (every 10s?) on stdout > > We do not have overrun / underrun counters in osmo-trx, but I agree > that this is a good idea. I think the should definitely be added. It might also make sense to do some runtime evaluation of how long it typically takes us to process a burst in uplink and downlink, to get an idea about how much margin there is. I'm thinking of something like taking a timestamp when we read from the UDP socket to the time we go back to sleep (and the same in the inverse direction, from samples to UDP. > Packet loss between TRX-BTS is definitely a concern, but I think that > is unlikely. The skew between OS time and device time is likely driven > by scheduling and transient delays in BTS burst processing and/or late > UDP arrival from TRX. In that case, a faster machine certainly helps. The problem I have is that right now there is no clear indication of whta's happening. If a given machine is unable to provide sufficient CPU to operate, we should fail gracefully with some explicit message on that regard. Looking into under/overruns on the SDR side as well as keeping an eye on (and exporting/reporting) the "margin" in terms of how soon we finish our processing before the next burst period happens would improve the situation here. Thisis true for both the OsmoTRX doing modulation/demodulation, but probably even more so for osmo-bts-trx doing convolutional decoding, etc. It might also be worthwhile to consider whether short, occasional drop-outs are acceptable, and whether we can recover from that in a more meaningful way - short of exiting the process and having it re-spawned by systemd. Individual missing samples at some occasions shouldn't be that critical, I guess? Sure, they will increase BER when they happen, but beyond that? And in terms of osmo-bts-trx missing received UDP burst data, it is basically FER. In both cases, it might make sense to accept this in rare intervals + raise a related OML ALERT to the BSC. I'm likely going to look a bit more into the osmo-bts-trx side soon (beyond the CLOCK_MONOTONIC patches under review), but for OsmoTRX I have no current plans to do any of the above improvements myself. 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 tom at tsou.cc Mon Jun 26 20:21:00 2017 From: tom at tsou.cc (Tom Tsou) Date: Mon, 26 Jun 2017 13:21:00 -0700 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170625132206.GA9557@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> Message-ID: On Sun, Jun 25, 2017 at 6:22 AM, Neels Hofmeyr wrote: > Tom mentioned the idea of running osmo-bts-trx on a different machine from > osmo-trx -- that is certainly possible in a manual test, but I guess not really > an option for the regular tests. It would be a lot of manual supervision to > perform a series of tests, like 20 or more, to find out the success rate; or a > code and jenkins config change to run the osmo-bts-trx binary on a different > build slave, not trivial. It would be much preferred to stay on a single host > computer... To be clear, I am not advocating the use of a separate machines as a permanent solution, which I agree is not ideal, but as a method to confirm that the issue is directly related to process scheduling. -TT From tom at tsou.cc Mon Jun 26 21:35:46 2017 From: tom at tsou.cc (Tom Tsou) Date: Mon, 26 Jun 2017 14:35:46 -0700 Subject: osmo-trx -m is broken In-Reply-To: References: <467a6314-027b-e6e1-e078-f39846d1ba9b@sysmocom.de> <20170626105459.gl74p5iskij2yjw4@nataraja> Message-ID: On Mon, Jun 26, 2017 at 3:58 AM, Max wrote: > https://projects.osmocom.org/issues/2341 is created to track this. Fixed. https://gerrit.osmocom.org/#/c/3062/ -TT From laforge at gnumonks.org Tue Jun 27 08:21:12 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 27 Jun 2017 10:21:12 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170626183945.GA3407@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170625152049.obreyemq7deyh2ls@nataraja> <20170626183945.GA3407@my.box> Message-ID: <20170627082112.7ftswdkugte4gvmx@nataraja> On Mon, Jun 26, 2017 at 08:39:45PM +0200, Neels Hofmeyr wrote: > 976 has a different failure in *one* of two trx tests: > > 20170626171713513 DL1C <0006> scheduler_trx.c:1704 We were 47 FN faster than TRX, compensating > 20170626171713514 DL1C <0006> scheduler_trx.c:1704 We were 47 FN faster than TRX, compensating > 20170626171713515 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713517 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713517 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713518 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713519 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating > 20170626171713519 DL1C <0006> scheduler_trx.c:1704 We were 44 FN faster than TRX, compensating the above are all very odd, as they indicate that the 4.6ms timer expires constantly way faster than actual 4.6ms as per the clock we receive from the TRX. And it's not an occasional frame every so often, but lots (44*4.6=202.4ms) within one second, that's a 20% clock deviation. > 20170626171713727 DL1C <0006> scheduler_trx.c:1600 PC clock skew: elapsed_us=614659, error_us=610044 This means that the Linux kernel was supposed to scheudle us after 4.6ms, but actually took 610ms longer, i.e. more than half a second. This is highly unusual. Something really odd must be happening to the system here. What other tasks with realtime priority (SCHED_RR) are running on the system? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From msuraev at sysmocom.de Tue Jun 27 08:24:21 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 27 Jun 2017 10:24:21 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <20170626183945.GA3407@my.box> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170625152049.obreyemq7deyh2ls@nataraja> <20170626183945.GA3407@my.box> Message-ID: <5b766ed5-572d-1576-b311-ee1c90dca995@sysmocom.de> On a related note: what kernel are you running - could you share "uname -a" output from that system? -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From pespin at sysmocom.de Tue Jun 27 09:42:37 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 27 Jun 2017 11:42:37 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <5b766ed5-572d-1576-b311-ee1c90dca995@sysmocom.de> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170625152049.obreyemq7deyh2ls@nataraja> <20170626183945.GA3407@my.box> <5b766ed5-572d-1576-b311-ee1c90dca995@sysmocom.de> Message-ID: <400b3b33-53d9-eb07-c984-71bb2ea624b4@sysmocom.de> On 27/06/17 10:24, Max wrote: > On a related note: what kernel are you running - could you share "uname -a" output > from that system? > Linux osmo-gsm-tester-rnd 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From msuraev at sysmocom.de Tue Jun 27 09:49:24 2017 From: msuraev at sysmocom.de (Max) Date: Tue, 27 Jun 2017 11:49:24 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: <400b3b33-53d9-eb07-c984-71bb2ea624b4@sysmocom.de> References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170625152049.obreyemq7deyh2ls@nataraja> <20170626183945.GA3407@my.box> <5b766ed5-572d-1576-b311-ee1c90dca995@sysmocom.de> <400b3b33-53d9-eb07-c984-71bb2ea624b4@sysmocom.de> Message-ID: It's been suggested by few people (me included) here to use -lowlatency kernels from Ubuntu. If there's particular reason why we can't use Ubuntu instead of Debian for osmo-gsm-tester than we could try installing kernels from https://liquorix.net/ repository. On 27.06.2017 11:42, Pau Espin Pedrol wrote: > > Linux osmo-gsm-tester-rnd 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 > (2016-10-19) x86_64 GNU/Linux > -- Max Suraev http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Tue Jun 27 10:54:05 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 27 Jun 2017 12:54:05 +0200 Subject: .deb build as jenkins test In-Reply-To: References: Message-ID: <20170627105405.iftpz2u4icqbjm6r@nataraja> Hi Max, On Mon, Jun 26, 2017 at 02:40:06PM +0200, Max wrote: > In a light of https://projects.osmocom.org/issues/2340 I'd like to add .deb build as > an additional step for jenkins jobs triggered by gerrit push. > It'll mean longer build times but it'll prevent breaking changes from reaching > master. I don't like that idea. At least not unless somebody donates a Ryzen/Threadripper with sufficient RAM so we can do the build testing in a ram/tmpfs there . What we need to make sure though is that somehow (e.g. by a nightly build) the culprit of introducing a change is notified if it breaks the package build. I don't think it's a big issue if we have an occasional dpkg build error that then gets resolved within 24 hours. > breakage in https://build.opensuse.org/project/monitor/network:osmocom:nightly but it > should make nightly builds more stable and easier to maintain. I think the problem is that right now the "culprit" of breaking the nightly pacakges is not informed. If we can change that (either within OBS or by the clumsy approach of havin to set up another nightly jenkins job for packae builds), I think it's sufficient. -- - 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 Tue Jun 27 10:56:32 2017 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 27 Jun 2017 12:56:32 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> <20170625152049.obreyemq7deyh2ls@nataraja> <20170626183945.GA3407@my.box> <5b766ed5-572d-1576-b311-ee1c90dca995@sysmocom.de> <400b3b33-53d9-eb07-c984-71bb2ea624b4@sysmocom.de> Message-ID: <20170627105632.g5cms5kkmxxdqfhj@nataraja> Hi Max, On Tue, Jun 27, 2017 at 11:49:24AM +0200, Max wrote: > It's been suggested by few people (me included) here to use -lowlatency kernels from > Ubuntu. If there's particular reason why we can't use Ubuntu instead of Debian for > osmo-gsm-tester than we could try installing kernels from https://liquorix.net/ > repository. I would appreciate if we would invest our time and energy into actually *debugging* the issue and finding what the problem, rather than a very high level trial+error approach with swapping distributions and kernels. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Tue Jun 27 16:27:26 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 27 Jun 2017 18:27:26 +0200 Subject: osmo-bts-trx fails frequently on osmo-gsm-tester In-Reply-To: References: <20170623025107.GE7792@my.box> <20170623091910.5odlmpwbdv2h5ddw@nataraja> <20170625132206.GA9557@my.box> Message-ID: <20170627162726.GA10812@my.box> On Mon, Jun 26, 2017 at 07:25:29PM +0900, Alexander Chemeris wrote: > Hi Neels, > > Are you running osmo-trx in a single TRX or dual-TRX configuration? Single TRX. > Do you have a CPU usage information from the system? Like load average? It doesn't really give hard information... I like Harald's suggestion to put load on the system and try to trigger the failure. In the sense of trying to make the failure more frequent to be able to figure out the cause more easily. @pespin, can you probe in that direction? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Jun 27 23:58:27 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 28 Jun 2017 01:58:27 +0200 Subject: aoip branch Message-ID: <20170627235827.GB10812@my.box> I successfully tested some new patches on the AoIP branch locally and pushed them to the openbsc.git/aoip branch. They allow using 3G with AoIP. @pespin: if aoip tester runs fail now, that's probably the cause. @pmaier: I tried to apply all patches found on the pmaier/aoip branch, but excluded the commits started with "MSC side reset" because of build failure. The failure is the same I saw a few days ago, still unchanged: CCLD osmo-bsc_nat ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_go_parent': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:130: undefined reference to `osmo_ss7_vty_go_parent' ../../src/libcommon/libcommon.a(common_vty.o): In function `bsc_vty_is_config_node': /n/s/osmo/git/openbsc/openbsc/build-3G/src/libcommon/../../../src/libcommon/common_vty.c:140: undefined reference to `osmo_ss7_is_config_node' collect2: error: ld returned 1 exit status I suspect you still have some of your work not pushed to libosmo-sccp? I can't find a private branch or patches on gerrit about osmo_ss7_vty. In general I think it would be good to always keep your work on a private branch and push it frequently (doing anything you like on it, amending and so forth). For collaboration, but also to have a backup of your patches...? If you like, we can have a call soon to figure out a rebase of your work onto aoip. A merge conflict is solved on the neels/pmaier_aoip branch ('git fetch' first), but I get above build failure. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pmaier at sysmocom.de Wed Jun 28 08:07:04 2017 From: pmaier at sysmocom.de (Philipp Maier) Date: Wed, 28 Jun 2017 10:07:04 +0200 Subject: aoip branch In-Reply-To: <20170627235827.GB10812@my.box> References: <20170627235827.GB10812@my.box> Message-ID: <595363A8.6010903@sysmocom.de> Hello Neels, > I suspect you still have some of your work not pushed to libosmo-sccp? This looks to me like a linker problem. The two functions are a normal part of libosmo-sccp vty. I had to change the vty code in libcommon so that the VTY can traverse the nodes correctly again. This must be the top commit of my branch. I think you can just leave it out: wip: vty: make msc sccp addressesconfigurable I wonder why it is building fine for me. Maybe libcommon lacks a $(LIBOSMOSIGTRAN_LIBS) in the LADD section? regards. Philipp -- Philipp Maier http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From pespin at sysmocom.de Wed Jun 28 08:49:03 2017 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 28 Jun 2017 10:49:03 +0200 Subject: aoip branch In-Reply-To: <20170627235827.GB10812@my.box> References: <20170627235827.GB10812@my.box> Message-ID: <67dd5532-2da9-5f64-2d76-6f0c6868667d@sysmocom.de> On 28/06/17 01:58, Neels Hofmeyr wrote: > I successfully tested some new patches on the AoIP branch locally and pushed > them to the openbsc.git/aoip branch. They allow using 3G with AoIP. > > @pespin: if aoip tester runs fail now, that's probably the cause. > Hi, this morning I enabled again the osmo-gsm-tester_run job and seems to be working fine: http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/1001/ (and 1002). -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Wed Jun 28 13:40:56 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 28 Jun 2017 15:40:56 +0200 Subject: aoip branch In-Reply-To: <595363A8.6010903@sysmocom.de> References: <20170627235827.GB10812@my.box> <595363A8.6010903@sysmocom.de> Message-ID: <20170628134056.GA3238@my.box> On Wed, Jun 28, 2017 at 10:07:04AM +0200, Philipp Maier wrote: > I wonder why it is building fine for me. Maybe libcommon lacks a > $(LIBOSMOSIGTRAN_LIBS) in the LADD section? libraries don't have an LDADD section :) Ah now I remember that we talked about this before, sorry for the noise. It's clear now: I build with --enable-nat, hence the osmo-bsc_nat binary is built. You're probably not building it and hence don't see that this program lacks the sigtran LDADD. I should have noticed that before. Adding it. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Jun 28 16:27:36 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 28 Jun 2017 18:27:36 +0200 Subject: SS7 / SCCP design question: one or several SCCP instances? Message-ID: <20170628162736.GB3238@my.box> We need to decide which way to go with point codes, sccp- and ss7-instances. pmaier and I have reached different conclusions and wrote patches going in opposite directions, now we need to decide and cosolidate: The MSC has various connections over SCCP: it serves BSSAP for several BSCs, and RANAP for several HNBGWs. BSC - A MSC: BSC -}----------> BSSAP BSC - -----> RANAP / HNBGW -}-/ IuCS HNBGW - 1) I went for exactly one point code at the MSC (say PC=1). There is exactly one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up(). When comparing to the TCP/IP model, the paradigm here is that a PC is like an IP address and the SSN like a port number. At the server, the MSC, I have one PC (IP address) and listen on one SSN (port) per protocol served, and clients all connect to the same PC+SSN, receiving separate connection IDs. I can also use the calling address to know which client I'm talking to. Hence I moved the osmo_sccp_instance creation up to "the top" and created two sccp_user_bind()s, one for BSSAP and one for RANAP. This works in practice. I can tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses. An pseudocode MSC VTY config for this scenario could look something like this: msc sccp local-pc 0.0.1 ssn-iucs $OSMO_SSN_RANAP ! -> to IuCS rx cb ssn-a $OSMO_SSN_BSSAP ! -> to A rx cb remote-bsc 1 pc 1.0.1 remote-bsc 2 pc 1.0.2 remote-hnbgw 1 pc 2.0.2 i.e. one local PC is configured, each protocol has its separate SSN, each sccp_user_bind() serves all clients for that SSN. This is the direction I took to add IuCS to AoIP. 2) pmaier added VTY configuration for various point codes, and went the other way: the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is told the addresses of all known BSCs and) every time a BSC is configured via VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a distinct local PC for each BSC, and for each HNBGW. In this model there still is a code problem I noticed while adding IuCS to AoIP in OsmoMSC: if I call osmo_sccp_simple_client() a second time with a different PC, the osmo_ss7_instance used is still the same (still id=1), and notes this second PC as its global local PC. The messages received for the first client's PC are then seen as remote and routed back out -> infinite message loop. A solution here would be to either a) use a separate osmo_ss7_instance per osmo_sccp_simpe_client() (simply add an ss7 instance id parameter to osmo_sccp_simpe_client() and increment by one each time) or b) implement the routing algorithm so that it notices the local PCs of several local SCCP clients. A VTY config for this scenario so far looks like this: ! define some addresses, referenced below cs7 instance 1 sccp-address msc_local subsystem-number 254 point-code 0.0.1 routing-indicator PC sccp-address bsc_remote subsystem-number 254 point-code 0.0.2 routing-indicator PC sccp-address bsc_remote2 subsystem-number 254 point-code 0.0.3 routing-indicator PC msc bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote bsc cs7-instance 1 calling-addr msc_local called-addr bsc_remote2 (I'm not sure whether it is possible to have several sccp_instances with the same msc_local address, but we would find solutions for these petty issues once we've decided which way to go.) (I also think 'calling-addr' and 'called-addr' should rather be named 'local-addr' and 'remote-addr': depending on who calls who, the calling-addr can be the remote or the local one. That's also besides the point for now.) My personal idea is that 1) is simpler: we have one ss7 instance per program, no matter how many clients are served. I can still tear down and set up individual sccp_users (i.e. disable/enable IuCS or A separately), and handling different clients per SSN is done by the conn_ids and possibly keeping distinct osmo_sccp_addresses of the clients. 2) seems to me easier to misconfigure and it sounds to me like a paradigm of creating a whole new server for each client that connects, so instead of using an ss7_instance's routing, we create separate instances, each sending to only one counterpart. But is 2) maybe the correct way to go for reasons I'm not aware of? I notice that what I wrote is biased towards 1) because that's my POV, but this is indended to be a neutral question. We need a choice for 1) or 2) so that pmaier and I can adjust and merge our patches accordingly. Can you help us decide, hopefully with some background knowledge on how an SCCP network is intended to be set up? Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Wed Jun 28 18:00:06 2017 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 28 Jun 2017 20:00:06 +0200 Subject: SS7 / SCCP design question: one or several SCCP instances? In-Reply-To: <20170628162736.GB3238@my.box> References: <20170628162736.GB3238@my.box> Message-ID: <20170628180006.56ovb66fflh5g4ur@nataraja> Hi Neels, On Wed, Jun 28, 2017 at 06:27:36PM +0200, Neels Hofmeyr wrote: > 1) > I went for exactly one point code at the MSC (say PC=1). There is exactly > one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate > sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to > the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up(). This makes sense to me. If one wanted to do it even more flexible, then an option to use separate SS7 instances for each of the users (i.e. one for BSSAP and one for RANAP) makes sense. It could be conceived that the 2G/A/BSSAP and 3G/Iu/RANAP live in different SS7 networks with different point code spaces, or simply the fact that one wants to use different MTP-level signalling link(set)s for either of the two. > An pseudocode MSC VTY config for this scenario could look something like this: > > msc > sccp local-pc 0.0.1 > ssn-iucs $OSMO_SSN_RANAP ! -> to IuCS rx cb > ssn-a $OSMO_SSN_BSSAP ! -> to A rx cb > remote-bsc 1 > pc 1.0.1 > remote-bsc 2 > pc 1.0.2 > remote-hnbgw 1 > pc 2.0.2 I am not sure you generally want (to require) to manually configure each BSC on the MSC side. As the BSCs register to the MSC, I think by default, the MSC should simply allow any BSC to register to it, without having to manually create configuration for that. Manual config would serve no purpose other than as some kind of 'access control list' for security, and I think that's best kept out of the MSC and handled by some external STP or other device. > 2) > pmaier added VTY configuration for various point codes, and went the other way: > the MSC creates a separate osmo_sccp_instance per BSC connection. (The MSC is > told the addresses of all known BSCs and) every time a BSC is configured via > VTY, a new osmo_sccp_simple_client() is created. IIUC the MSC then has a > distinct local PC for each BSC, and for each HNBGW. I don't think this makes sense, and I think it might be the result of a misunderstanding. Configuring the MSC this way on the BSC makes sense. Configuring multiple MSCs on the BSC this way also makes sense (possible future multi-operator core network (MOCN), or the existing dual-MSC support in OsmoBSC). However, on the MSC side, there is no reason why we would want to have one sccp_instance and/or ss7_instance for each BSC - nor for manually configuring each BSC (see above). > (I also think 'calling-addr' and 'called-addr' should rather be named > 'local-addr' and 'remote-addr': depending on who calls who, the calling-addr > can be the remote or the local one. That's also besides the point for now.) yes, 'calling' and 'called' address can be quite confusing, as they change their meaning depending on the specific SCCP message you look at (in case of connection oriented SCCP). For the Connection Request, "Calling" is the sender, but for the Connection Confirm, "Calling" is the receiver. > My personal idea is that 1) is simpler: we have one ss7 instance per program, > no matter how many clients are served. I think this is sufficient. More elegant would though be (optionally) one ss7_instance + sccp_instance for each user, see above. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu Jun 29 00:45:21 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 29 Jun 2017 02:45:21 +0200 Subject: SS7 / SCCP design question: one or several SCCP instances? In-Reply-To: <20170628180006.56ovb66fflh5g4ur@nataraja> References: <20170628162736.GB3238@my.box> <20170628180006.56ovb66fflh5g4ur@nataraja> Message-ID: <20170629004521.GD3238@my.box> Thanks for the clarification. > If one wanted to do it even more flexible, then > an option to use separate SS7 instances for each of the users (i.e. one > for BSSAP and one for RANAP) makes sense. It could be conceived that > the 2G/A/BSSAP and 3G/Iu/RANAP live in different SS7 networks with > different point code spaces, or simply the fact that one wants to use > different MTP-level signalling link(set)s for either of the two. If we have separate ss7+sccp instances, we need to run each instance on its own IP address or port. And for routing both also need a separate point code. Have I got this correctly? MSC BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP BSC --/ ^ \ / ---> ss7-instance at 5.6.7.8: PC=2,SSN=RANAP HNBGW ---PC=2,SSN=RANAP-/ Ah, or completely separate STP, then allowing the same PC: MSC BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP BSC --/ -> ss7-instance at 5.6.7.8: PC=1,SSN=RANAP HNBGW ---PC=1,SSN=RANAP-> STP -/ One ss7+sccp instance means we have same IP address and PC: MSC BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4:--> PC=1,SSN=BSSAP BSC --/ ^ \-> PC=1,SSN=RANAP / HNBGW ---PC=1,SSN=RANAP-/ I imagine we could make this configurable in the way that pmaier has begun, like: cs7-instance 1 bind addr 1.2.3.4 pc 0.0.1 cs7-instance 2 bind addr 5.6.7.8 pc 0.0.2 msc iface-a cs7-instance 1 ssn $BSSAP iface-iucs cs7-instance 2 ssn $RANAP ! instance 2 != 1 vs. cs7-instance 1 bind addr 1.2.3.4 pc 0.0.1 msc iface-a cs7-instance 1 ssn $BSSAP iface-iucs cs7-instance 1 ssn $RANAP ! instance 1 again Then we can allow entirely separate transports, but most "normal" users would simply use one instance and hence one IP address + port for receiving any SCCP connections at the MSC. I believe the implementation to allow this duality is fairly trivial: have a list of sccp_instances each on a distinct ss7_instance; then pass a specific sccp_instance pointer when creating the osmo_sccp_user_bind(). > I am not sure you generally want (to require) to manually configure each > BSC on the MSC side. As the BSCs register to the MSC, I think by > default, the MSC should simply allow any BSC to register to it, without > having to manually create configuration for that. That's how I imagined it, but it complicates the MSC-side BSSAP Reset, which the MSC sends to the BSCs to signal a restart. If the MSC knows which BSCs exist by config, it can right away send a BSSAP Reset when it (re)starts. We can also decide to not tell the MSC about the BSCs, and send the BSSAP Reset whenever we first hear about a given BSC. But that means a BSC will not know that the MSC has restarted until it sends the next message to the MSC. Upon receiving a Reset, a BSC can tear down ongoing calls. If the Reset comes late, it might be considered a feature that an ongoing call can still continue and conclude, but an operator that does billing may have a different opinion. We could again have two modes configured by VTY, an "open access" that allows any BSC that might come along, with a "lazy" MSC side Reset; or an explicit list of BSCs that are allowed exclusively, and receive a Reset immediately. This duality is not as trivial as above, I guess. Planning of the network requires that no two BSCs share the same point code, so that replies to its requests are guaranteed to go back to the same. So one could argue that having to tell the MSC which BSCs exists might help there? I could also just put a list of BSCs in the MSC config whether they exist or not -- at least as soon as we ensure that a message to an unknown PC doesn't cause an endless message loop :P I'm not sure how important MSC-side Reset vs. "open access" for BSCs are. I believe it makes sense to go with pmaier's code state and require explicit BSC config with the MSC until we see a need to change that. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From pmaier at sysmocom.de Thu Jun 29 09:58:10 2017 From: pmaier at sysmocom.de (Philipp Maier) Date: Thu, 29 Jun 2017 11:58:10 +0200 Subject: SS7 / SCCP design question: one or several SCCP instances? In-Reply-To: <20170628180006.56ovb66fflh5g4ur@nataraja> References: <20170628162736.GB3238@my.box> <20170628180006.56ovb66fflh5g4ur@nataraja> Message-ID: <5954CF32.40906@sysmocom.de> Hello Harald and Neels, > >> I went for exactly one point code at the MSC (say PC=1). There is exactly >> one osmo_ss7_instance and one osmo_sccp_instance. The MSC has separate >> sccp_user_bind()s for the BSSAP and the RANAP SSNs. So PC=1,SSN=BSSAP goes to >> the A-interface sap_up(), and PC=1,SSN=RANAP goes to the IuCS sap_up(). > This makes sense to me. If one wanted to do it even more flexible, then > an option to use separate SS7 instances for each of the users (i.e. one > for BSSAP and one for RANAP) makes sense. It could be conceived that > the 2G/A/BSSAP and 3G/Iu/RANAP live in different SS7 networks with > different point code spaces, or simply the fact that one wants to use > different MTP-level signalling link(set)s for either of the two. I think this makes sense too. Then we would call the osmo_sccp_simple_client() in some central place to get the sccp_instance. This would mean that we define one address for the MSC, that is then used by RANAP and BSSAP at the same time Next an initalizer function would reserve exactly one sccp_user for the A-Interface using osmo_sccp_user_bind() and another one for for RANAP After that we can add BSCs using a_init() (which I still think is necessary, see below) I do not see any problems with that solution and I think it is also the simplest one. Having separate sccp_instance, or even separate ss7 instances would make the system more complicated for no good reason. However, I see some problems with defining the sccp addresses in the VTY. An sccp address also gets an SSN. If we use one address for BSSAP and RANAP at the same time. We need to define the SSN separately, because we need two different ones. So I will have to define the ssn separately via another VTY command. cs7 instance 1 sccp-address msc_local point-code 0.0.1 routing-indicator PC sccp-address bsc_remote point-code 0.0.2 routing-indicator PC msc ssn-bssmap 254 ssn-ranap 142 calling-addr msc_local bsc cs7-instance 1 called-addr bsc_remote But maybe we can also skip the SSN and leave it hardcoded. I do not know how hard the standard dictates those numbers. If it is "law" to use e.g. 254 only and always for BSSAP, we can leave it hardcoded for sure. This will eliminate the need for a separate VTY command here. > I don't think this makes sense, and I think it might be the result of a > misunderstanding. I am not sure about this. The specification (3GPP TS 48.008 3.1.4.1.2 Reset at the MSC) says: "In the event of a failure at the MSC which has resulted in the loss of transaction reference information, a RESET message is sent to the BSS. This message is used by the BSS to release affected calls and erase all affected references and to put all circuits into the idle state." I do not know how that should work if the MSC has no configuration where to send the reset. Failure means crash/restart to me. The MSC has lost all knowledge about the BSS, so that needs to come from somewhere. Do we know how other vendors handle the problem? regards, Philipp -- Philipp Maier http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Thu Jun 29 11:11:46 2017 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 29 Jun 2017 13:11:46 +0200 Subject: SS7 / SCCP design question: one or several SCCP instances? In-Reply-To: <20170629004521.GD3238@my.box> References: <20170628162736.GB3238@my.box> <20170628180006.56ovb66fflh5g4ur@nataraja> <20170629004521.GD3238@my.box> Message-ID: <20170629111146.voj2syfqzs2ed7pu@nataraja> Hi Neels, On Thu, Jun 29, 2017 at 02:45:21AM +0200, Neels Hofmeyr wrote: > If we have separate ss7+sccp instances, we need to run each instance on its own > IP address or port. And for routing both also need a separate point code. Have > I got this correctly? > > MSC > BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP > BSC --/ ^ \ > / ---> ss7-instance at 5.6.7.8: PC=2,SSN=RANAP > HNBGW ---PC=2,SSN=RANAP-/ this is a less likely configuration. The point of having different SS7 instances is that we want to participate in e.g. two separate signalling netwokrs, which have overlapping point code spaces (like two private IP networks that use the same IP addresses). > Ah, or completely separate STP, then allowing the same PC: > > MSC > BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP > BSC --/ > -> ss7-instance at 5.6.7.8: PC=1,SSN=RANAP > HNBGW ---PC=1,SSN=RANAP-> STP -/ yes, that's the more likely configuration. > One ss7+sccp instance means we have same IP address and PC: > > MSC > BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4:--> PC=1,SSN=BSSAP > BSC --/ ^ \-> PC=1,SSN=RANAP > / > HNBGW ---PC=1,SSN=RANAP-/ corect. > I imagine we could make this configurable in the way that pmaier has begun, > like: > > cs7-instance 1 > bind addr 1.2.3.4 > pc 0.0.1 > cs7-instance 2 > bind addr 5.6.7.8 > pc 0.0.2 It should use the sccp address book that pmaier implemented. * There we define the SCCP address of the MSC-side BSSAP or RANAP * There we define in which SCCP instance this address resides The MSC code then simply refers to those "named sccp addresses" and uses them. The MTP-level link(set), ASP, ... definition should not be mixed with the SCCP addresses. Both the VTY config of the link(sets) and the SCCP address book should come from libosmo-sigtran, while the MSC simply refers to certain named SCCP addresses. > msc > iface-a cs7-instance 1 ssn $BSSAP > iface-iucs cs7-instance 2 ssn $RANAP ! instance 2 != 1 The SSN should be hard-coded, I think allowing users to change it is just calling for them to shoot themselves in the foot. > > I am not sure you generally want (to require) to manually configure each > > BSC on the MSC side. As the BSCs register to the MSC, I think by > > default, the MSC should simply allow any BSC to register to it, without > > having to manually create configuration for that. > We can also decide to not tell the MSC about the BSCs, and send the BSSAP Reset > whenever we first hear about a given BSC. I like that approach. > But that means a BSC will not know > that the MSC has restarted until it sends the next message to the MSC. I think that's fine. If there's no traffic ongoing, then the reset would serve no purpose. And if there is traffic, then the reset will be triggered by the first related message from BSC->MSC. Pleae also note that sooner or later a disapparing MSC will trigger "destination unavailable" notifications via the N-NOTICE.ind primitive at the SCCP-User-SAP, so there will be notification to the BSC in this case. > Upon receiving a Reset, a BSC can tear down ongoing calls. If the Reset comes > late, it might be considered a feature that an ongoing call can still continue > and conclude, but an operator that does billing may have a different opinion. I think we can ignore that. If really needed, you can make sure the call is unusable by terminating the MSC-side MGW when restating the MSC. > We could again have two modes configured by VTY, an "open access" that allows > any BSC that might come along, with a "lazy" MSC side Reset; or an explicit > list of BSCs that are allowed exclusively, and receive a Reset immediately. seems a bit too complex for my taste. If we do this, then "open" should be the default. I'm not worried about having complex configuration for the classic uperators who understand MTP, SIGTRAN and SCCP. But I'm worried about making it too difficult to set up a small network for those people who don't. So the default should be "make it easy for non-experts". > Planning of the network requires that no two BSCs share the same point code, so > that replies to its requests are guaranteed to go back to the same. People dealing with classic SS7 networks are used to that. I'm still considering adding a "DHCP server Style" point code allocation to OsmoSTP to make it simple for people who lack that background, and who simply want to run a self-contained osmocom network. > I'm not sure how important MSC-side Reset vs. "open access" for BSCs are. I > believe it makes sense to go with pmaier's code state and require explicit BSC > config with the MSC until we see a need to change that. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu Jun 29 15:15:41 2017 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 29 Jun 2017 17:15:41 +0200 Subject: SS7 / SCCP design question: one or several SCCP instances? In-Reply-To: <5954CF32.40906@sysmocom.de> References: <20170628162736.GB3238@my.box> <20170628180006.56ovb66fflh5g4ur@nataraja> <5954CF32.40906@sysmocom.de> Message-ID: <20170629151541.GA534@my.box> On Thu, Jun 29, 2017 at 11:58:10AM +0200, Philipp Maier wrote: > I see some problems with defining the sccp addresses in the VTY. An > sccp address also gets an SSN. > So I will have to define the ssn separately via another VTY command. Not necessarily. Your address book VTY code allows to set only a PC, omitting an SSN. Later on we can add an SSN according to which protocol is served, by taking the address book entry, copying the address and adding an SSN. We can then of course not modify an SCCP address on-the-fly. I believe this anyway needs a restart of the sccp_user_bind, so I think we should not bother to support that. (restarting e.g. the BSSAP would allow changes on-the-fly.) (I notice also that the VTY code "manually" sets the address parts like PC and SSN, placing presence flags. I guess it would make sense to have API functions that do this, in the sense of osmo_sccp_addr_set_{pc,ssn}(); and to copy.) > Then we would call the osmo_sccp_simple_client() in some central place to get > the sccp_instance. I understand the discussion to conclude differently: we use your SCCP address book, making it possible to use either a single osmo_sccp_simple_client() or separate ones, depending on the VTY config. We assign the addresses so defined to BSSAP and RANAP, with the SSNs hardcoded (by addr copy). That allows two scenarios depending on vty config, for example something like: MSC BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4: PC=1,SSN=BSSAP BSC --/ 10.9.8.7 -> ss7-instance at 5.6.7.8: PC=1,SSN=RANAP HNBGW ---PC=1,SSN=RANAP-> STP -/ 6.5.4.3 cs7 instance 1 sccp bind-addr 1.2.3.4 remote-stp 10.9.8.7 ! add simple_client? sccp-address msc_local_a point-code 0.0.1 routing-indicator PC cs7 instance 2 sccp bind-addr 5.6.7.8 remote-stp 6.5.4.3 ! add simple_client? sccp-address msc_local_iucs point-code 0.0.1 routing-indicator PC msc local-addr a ss7-instance 1 msc_local_a ! SSN added implicitly local-addr iu ss7-instance 2 msc_local_iucs ! by copying the address book entry (Could we also omit the 'ss7-instance 1', instead implied by the address name?) Or this: MSC BSC ---PC=1,SSN=BSSAP---> STP ---> ss7-instance at 1.2.3.4:--> PC=1,SSN=BSSAP BSC --/ 10.9.8.7 \-> PC=1,SSN=RANAP ^ / HNBGW ---PC=1,SSN=RANAP-/ cs7 instance 1 sccp bind-addr 1.2.3.4 remote-stp 10.9.8.7 ! add simple_client? sccp-address msc_local point-code 0.0.1 routing-indicator PC msc local-addr a ss7-instance 1 msc_local ! same address for both, SSN added implicitly local-addr iu ss7-instance 1 msc_local ! by copying the address book entry (Could we also omit the 'ss7-instance 1', instead implied by the address name?) To allow the above, we need to add an id argument to osmo_sccp_simple_client() to indicate the ss7 instance id. Possibly, the ss7 instance could be created automatically by calling osmo_sccp_simple_client() with a before unused id. Though, the only reason so far to have separate ss7 instances seems to me that the ss7 instance records its local PC "globally". It seems that an ss7 instance can have separate AS with separate local bind IP addresses and so forth. So I guess we will have one ss7 instance per osmo_sccp_simple_client(), but it seems that's not strictly necessary, besides our missing routing feature? Not sure. > Next an initalizer function would reserve exactly one sccp_user for the > A-Interface using osmo_sccp_user_bind() and another one for for RANAP yes. > After that we can add BSCs using a_init() (which I still think is necessary, > see below) a_init() should happen only once, e.g. upon above suggested: msc local-addr a msc_local We will not have separate SCCP clients per BSC. MSC side BSSAP Reset: > I am not sure about this. The specification (3GPP TS 48.008 3.1.4.1.2 Reset > at the MSC) says: "In the event of a failure at the MSC which has resulted > in the loss of transaction reference information, a RESET message is sent to > the BSS. This message is used by the BSS to release affected calls and erase > all affected references and to put all circuits into the idle state." > > I do not know how that should work if the MSC has no configuration where to > send the reset. Failure means crash/restart to me. The MSC has lost all > knowledge about the BSS, so that needs to come from somewhere. Do we know > how other vendors handle the problem? Send a Reset to each BSC that shows up for the first time. I'm also not sure about this, but Harald sounds pretty certain, so I'm willing to follow that lead. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From robert.steve07 at gmail.com Thu Jun 29 15:20:02 2017 From: robert.steve07 at gmail.com (robert) Date: Thu, 29 Jun 2017 18:20:02 +0300 Subject: openBSC encryption Message-ID: <2D6042FB-6174-44F1-9B50-4098824B58BC@gmail.com> Hi, Till now I have always worked with simcards without knowing their ki so I was not using any encryption. I have recently bought some programmable simcards and gave them an IMSI and KI and tried to have them working with ?encryption a5 1? and ?encryption a5 3? and I faced some problems. First if I choose 'a5 3' the phone cannot connect to the BTS and nothing can be done, while if I set the encryption to 'a5 1?, the phone connects normally and can make and receive calls but sometimes the call fails for a reason that I don?t know. I have then tried the following setup: I have connected 3 phones A, B and C. A and B have no KI related to them so no encryption is applied while C was given a KI. If I call from A to B or from B to A, the call is done successfully every time, while if I call from either A or B to C or from C to A or B the call might work and might not. Is there something in the configuration that should be changed when adding the encryption support ? And how to enable the a5 3 encryption ? Best regards, From domi at tomcsanyi.net Thu Jun 29 15:23:59 2017 From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=) Date: Thu, 29 Jun 2017 17:23:59 +0200 Subject: openBSC encryption In-Reply-To: <2D6042FB-6174-44F1-9B50-4098824B58BC@gmail.com> References: <2D6042FB-6174-44F1-9B50-4098824B58BC@gmail.com> Message-ID: <1E123A85-C130-4B57-8436-60B8DC6CA44A@tomcsanyi.net> Please, as a general guideline: anytime you are facing problems attach logs and configuration files of all components. Thank you! Domi > 2017. j?n. 29. d?tummal, 17:20 id?pontban robert ?rta: > > Hi, > > Till now I have always worked with simcards without knowing their ki so I was not using any encryption. I have recently bought some programmable simcards and gave them an IMSI and KI and tried to have them working with ?encryption a5 1? and ?encryption a5 3? and I faced some problems. First if I choose 'a5 3' the phone cannot connect to the BTS and nothing can be done, while if I set the encryption to 'a5 1?, the phone connects normally and can make and receive calls but sometimes the call fails for a reason that I don?t know. I have then tried the following setup: > I have connected 3 phones A, B and C. A and B have no KI related to them so no encryption is applied while C was given a KI. > If I call from A to B or from B to A, the call is done successfully every time, while if I call from either A or B to C or from C to A or B the call might work and might not. Is there something in the configuration that should be changed when adding the encryption support ? And how to enable the a5 3 encryption ? > > Best regards, From thayyil at yandex.com Fri Jun 9 18:11:41 2017 From: thayyil at yandex.com (thayyil09 yil) Date: Fri, 09 Jun 2017 18:11:41 -0000 Subject: Creating GSM Users Association (GSMUA) In-Reply-To: References: <20170529081407.deqbb2gdycpcf7uf@nataraja> Message-ID: <247401497031472@web42j.yandex.ru> michela are you kidding ( dont worrry iam a kid at twentees) calypso bb starts from leaked Docs ( if not sorry ) so why qcom code leak is ugly osmocom is for open softwear not for any specific hardware so keeping updated with mainstream hardware is the way so we may have to throw old one ( realy i never bcos i love it like my pet .old is Gold for me ) but in concept its the way ( hope you understand it ) greetings for your GSMUA . iam sure and will there for any help. i hope they will host your project. its happy to know your the mother of freecalypso. in softwear world you maybe first mom :) and i here for osmocom on qcom == osmodroidbb.wordpress.com if you mind helping me just put your hands on qcom leaked code i stucked at understanding code. still now i cant find where tmsi like layer3 things handling in qcom modem proc leaked code