From michael at usehover.com Thu Oct 4 18:51:18 2018 From: michael at usehover.com (Michael Benedict) Date: Thu, 4 Oct 2018 11:51:18 -0700 Subject: UHD make failed with OsmoTRX/B210/Ubuntu 18.04 Message-ID: Hi all, I'm trying to get OsmoTRX working with a B210 on Ubuntu 18.04. I recently posted to the USRP Users list but haven't had success yet, so posting here. Since the message below I've tried both the osmo-trx and osmo-trx-uhd binaries with several example config files on github. My next step will be to compile from source and try to debug the "UHD make" issue, but these binaries have worked for others so I hope I'm just missing something. Sincere thanks for any info. I'm new to this area but very excited to learn more. --Michael ---------------- .... Running the binary for osmo-trx on Ubuntu 18.04, I see: :~$ sudo osmo-trx linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown opening configuration table from path :memory: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Detected Device: B210 -- Operating over USB 3. ALERT 140391490980800 13:45:44.2 UHDDevice.cpp:799:open: UHD make failed, device ALERT 140391490980800 13:45:44.2 UHDDevice.cpp:799:open: UHD make failed, device ALERT 140391490980800 13:45:44.2 osmo-trx.cpp:530:main: Failed to create radio device ALERT 140391490980800 13:45:44.2 osmo-trx.cpp:530:main: Failed to create radio device Shutting down transceiver... The output is similar with `sudo osmo-trx -a serial=31502DD`, and the output of uhd_find_devices looks normal to me: :~$ uhd_find_devices [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.1-release -------------------------------------------------- -- UHD Device 0 -------------------------------------------------- Device Address: serial: 31502DD name: MyB210 product: B210 type: b200 I get similar results with or without the suggested udev rules[1]. Looking at the osmo-trx source[2] I am confused why it would identify the device and then fail the UHD make step. It seems like `uhd::usrp::multi_usrp::make` throws exceptions if the device is not found. I've been stuck on this for a while and would appreciate any pointers or ideas of what else to try. In case it helps I'll include the output of uhd_usrp_probe. Thanks, --Michael [1] https://files.ettus.com/manual/page_transport.html [2] https://github.com/osmocom/osmo-trx/blob/74bcc562a9403e224c40a9db77753b81cd412a70/Transceiver52M/device/uhd/UHDDevice.cpp#L632 ----- :~$ sudo uhd_usrp_probe [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.1-release [INFO] [B200] Detected Device: B210 [INFO] [B200] Operating over USB 3. [INFO] [B200] Detecting internal GPSDO.... [INFO] [GPS] No GPSDO found [INFO] [B200] Initialize CODEC control... [INFO] [B200] Initialize Radio control... [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Performing register loopback test... [INFO] [B200] Register loopback test passed [INFO] [B200] Setting master clock rate selection to 'automatic'. [INFO] [B200] Asking for clock rate 16.000000 MHz... [INFO] [B200] Actually got clock rate 16.000000 MHz. _____________________________________________________ / | Device: B-Series Device | _____________________________________________________ | / | | Mboard: B210 | | revision: 4 | | product: 2 | | serial: 31502DD | | name: MyB210 | | FW Version: 8.0 | | FPGA Version: 15.0 | | | | Time sources: none, internal, external, gpsdo | | Clock sources: internal, external, gpsdo | | Sensors: ref_locked | | _____________________________________________________ | | / | | | RX DSP: 0 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | RX DSP: 1 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | RX Dboard: A | | | _____________________________________________________ | | | / | | | | RX Frontend: A | | | | Name: FE-RX2 | | | | Antennas: TX/RX, RX2 | | | | Sensors: temp, rssi, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Frontend: B | | | | Name: FE-RX1 | | | | Antennas: TX/RX, RX2 | | | | Sensors: temp, rssi, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 76.0 step 1.0 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Codec: A | | | | Name: B210 RX dual ADC | | | | Gain Elements: None | | _____________________________________________________ | | / | | | TX DSP: 0 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | TX DSP: 1 | | | | | | Freq range: -8.000 to 8.000 MHz | | _____________________________________________________ | | / | | | TX Dboard: A | | | _____________________________________________________ | | | / | | | | TX Frontend: A | | | | Name: FE-TX2 | | | | Antennas: TX/RX | | | | Sensors: temp, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Frontend: B | | | | Name: FE-TX1 | | | | Antennas: TX/RX | | | | Sensors: temp, lo_locked | | | | Freq range: 50.000 to 6000.000 MHz | | | | Gain range PGA: 0.0 to 89.8 step 0.2 dB | | | | Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: A | | | | Name: B210 TX dual DAC | | | | Gain Elements: None From daniel.dogaru at mail.ru Fri Oct 5 22:44:56 2018 From: daniel.dogaru at mail.ru (=?UTF-8?B?0JTQsNC90LjQuNC7INCU0L7Qs9Cw0YDRgw==?=) Date: Sat, 06 Oct 2018 01:44:56 +0300 Subject: =?UTF-8?B?TGltZVNEUitPU01PQ09NIChPU01PLUJUUywgT1NNTy1CVFMtVFJYLCBzaXAs?= =?UTF-8?B?IGV0Yy4pIG9uIFdpbm9kd3MvTGludXg=?= Message-ID: <1538779496.145041183@f193.i.mail.ru> Hello! Please help me to run projects like GSM Base Station and others on my LimeSDR. I have only notebook on Windows (can lauch Linux on VirtualBox) and LimeSDR. I have spent much days and nights and even still cant run anything! I am very new to Linux, its strange builds, dependences, cross-compliers etc. I just can do something in terminal (CMD) step-by-step. Please I need a full step-by-step guide or ready IMAGE to run PREBUILD LIVE-CD so I can run .iso at virtual box. Please help me,I am very need to do things like in this videos: https://youtu.be/LV-CRJWC5_o??? or??? https://youtu.be/QOu3xNahmqI -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at usehover.com Sat Oct 6 02:05:47 2018 From: michael at usehover.com (Michael Benedict) Date: Fri, 5 Oct 2018 19:05:47 -0700 Subject: UHD make failed with OsmoTRX/B210/Ubuntu 18.04 In-Reply-To: References: Message-ID: Hi all, Building osmo-trx from source resolved the issue. Unfortunately I wasn't able to find the root cause, but I suspect I had conflicting or outdated versions of some dependencies. Thanks also to ?? 0xroot for emailing with some helpful suggestions off list. Cheers, --Michael From renxianyuanqi at gmail.com Sat Oct 6 04:30:24 2018 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Sat, 6 Oct 2018 12:30:24 +0800 Subject: UHD make failed with OsmoTRX/B210/Ubuntu 18.04 In-Reply-To: References: Message-ID: You are welcome :) Michael Benedict ?2018?10?6??? ??10:06??? > Hi all, > > Building osmo-trx from source resolved the issue. Unfortunately I > wasn't able to find the root cause, but I suspect I had conflicting or > outdated versions of some dependencies. > > Thanks also to ?? 0xroot for emailing with some helpful suggestions off > list. > > Cheers, > --Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Sat Oct 6 05:17:30 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Sat, 6 Oct 2018 12:17:30 +0700 Subject: LimeSDR-USB experience with New Splits Solved! In-Reply-To: References: Message-ID: All is fine now with all master. C117/118 also works fine now. and osmo-trx-lms with LimeSDR with newest latest branch 18.10 also doing great. best, DUO On Fri, Sep 14, 2018 at 7:27 PM Vadim Yanitskiy wrote: > > Are you referring to the ones from 2015 or so with > > Russian titles? Those are the only ones I am aware of > > Yes. There are few. Check out this one: > > https://youtu.be/jw-63aOOPk0 > > > how do you know that phone was running against an > > Osmocom network [...] > > I know the author. Also, you can see the logs of OpenBSC > on the background of the mentioned video. > > > The relation is simple: if phones like Mot C1xx running > > Motorola's original factory fw don't work with Osmocom > > networks, [...] > > In order to confirm, I just tested a Motorola C118 running > the original firmware with Osmocom-based network. LimeSDR-Mini > was used as PHY for OsmoTRX. Everything works fine, including: > > SDCCH: SMS, USSD, other signaling > TCH/H: both HR and AMR codecs > TCH/F: FR, AMR and EFR codecs > > Probably, the author of this topic has some problems > with codec / network configuration. > > With best regards, > Vadim Yanitskiy. > -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Sat Oct 6 10:33:01 2018 From: keith at rhizomatica.org (Keith) Date: Sat, 6 Oct 2018 11:33:01 +0100 Subject: Persistent VTY history? Message-ID: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> Hi all. Was just thinking today about if it was ever considered to write the VTY history out to a file on exiting (and load it on startup) I'm quite the fan of the up arrow and it's been something that sometimes annoys that I have no history after leaving the VTY. It would seem reasonably trivial to implement, and I suppose you could write out to files in $HOME/.osmo-bsc_history or $HOME/.config or somesuch. Just wondering if this was ever discussed before, if there's any unforseen problem with it on my part + if it would be a desirable feature for anybody else? k/ From laforge at gnumonks.org Sat Oct 6 10:46:43 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 6 Oct 2018 12:46:43 +0200 Subject: osmocom.org server upgrades Message-ID: <20181006104643.GB20261@nataraja> Dear all, I've just done one round of upgrades to our infrastructure, including gerrit, gitolite, cgit, patchwork, redmine, jenkins. Casual manual testing showed everything worked as expected at first sight. Particularly the jenkins upgrae might have some fall-out, as we're jumping 6 months of jenkins LTS releases in one step. Please report any issues to http://osmocom.org/projects/osmocom-servers/issues [or if that is broken, by e-mail here]. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From stsp at stsp.name Sat Oct 6 10:52:07 2018 From: stsp at stsp.name (Stefan Sperling) Date: Sat, 6 Oct 2018 12:52:07 +0200 Subject: Persistent VTY history? In-Reply-To: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> Message-ID: <20181006105206.GD36246@ted.stsp.name> On Sat, Oct 06, 2018 at 11:33:01AM +0100, Keith wrote: > Hi all. > > Was just thinking today about if it was ever considered to write the VTY > history out to a file on exiting (and load it on startup) > > I'm quite the fan of the up arrow and it's been something that sometimes > annoys that I have no history after leaving the VTY. > > It would seem reasonably trivial to implement, and I suppose you could > write out to files in $HOME/.osmo-bsc_history or $HOME/.config or somesuch. > > Just wondering if this was ever discussed before, if there's any > unforseen problem with it on my part + if it would be a desirable > feature for anybody else? > > k/ I like the idea. I have also missed this feature at times. It should probably be opt-in because creating ever-growing files by default is a bit unfriendly to embedded platforms. Also, some commands accept crypto secrets in parameters, and people will not expect those to be saved by default under $HOME where any program could easily read them. I don't see any other potential issues. From laforge at gnumonks.org Sat Oct 6 10:54:04 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 6 Oct 2018 12:54:04 +0200 Subject: Persistent VTY history? In-Reply-To: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> Message-ID: <20181006105404.GC20261@nataraja> Hi Keith, On Sat, Oct 06, 2018 at 11:33:01AM +0100, Keith wrote: > Was just thinking today about if it was ever considered to write the VTY > history out to a file on exiting (and load it on startup) Interesting idea! > I'm quite the fan of the up arrow and it's been something that sometimes > annoys that I have no history after leaving the VTY. > > It would seem reasonably trivial to implement, and I suppose you could > write out to files in $HOME/.osmo-bsc_history or $HOME/.config or somesuch. Not sure if $HOME is such a good idea for "system services/daemons" like the osmocom daemons. I wouldn't be surprised if that would either point to a read-only mount or /tmp in various configurations. So it would probably rather be something in /var/lib/osmocom/$program-vty_history.txt or whatever... $HOME/... would work better if we had an actual client program rather than just telnet. In that case, of course, it would be logical to store the history with the client, and not the server. > Just wondering if this was ever discussed before, if there's any > unforseen problem with it on my part + if it would be a desirable > feature for anybody else? I don't think it has been discussed before. The only problem that I can see is that there can be any number of users using any number of VTY sessions in parallel. So which history do we store? How do we keep them separate/disentangled? Or should we create one shared history? Slighty unrelated: zebra/quagga also has many programs and each with their own VTY. They then introduced something called vtysh, whihc I only read about but never used myself. It supposedly allows you to talk to all of the various daemons from one frontend: https://www.systutorials.com/docs/linux/man/1-vtysh/ Definitely worth investigating if somebody is lookning for VTY usability improvements.. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sat Oct 6 11:06:01 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 6 Oct 2018 13:06:01 +0200 Subject: Persistent VTY history? In-Reply-To: <20181006105206.GD36246@ted.stsp.name> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105206.GD36246@ted.stsp.name> Message-ID: <20181006110601.GD20261@nataraja> On Sat, Oct 06, 2018 at 12:52:07PM +0200, Stefan Sperling wrote: > It should probably be opt-in because creating ever-growing files > by default is a bit unfriendly to embedded platforms. you can just limit the size of those files and keep the last $N commands. Every shell manages quite fine with their history on that regard... > Also, some commands accept crypto secrets in parameters, and people will not > expect those to be saved by default under $HOME where any program > could easily read them. As indicated $HOME is $HOME of the daemon, not the user. Anyone who has those privileges can just as well access the HLR database directly... -- - 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 Mon Oct 8 08:38:18 2018 From: ron.menez at entropysolution.com (Ron) Date: Mon, 8 Oct 2018 08:38:18 +0000 Subject: OSMO-MSC/OSMO-HLR Auto Provisioning Message-ID: <13D474C8-1818-40A5-83B0-6BD4776667FE@entropysolution.com> Hi Community, Is the auto provisioning (subscriber-create-on-demand) of OSMO-NITB is still present or available in OSMO-BSC/OSMO-MSC/OSMO-HLR version? We tried to use the ?authentication optional? under OSMO-MSC configuration but still, it checks if the subscriber is provisioned in OSMO-HLR. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From djks74 at gmail.com Mon Oct 8 08:56:59 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 8 Oct 2018 15:56:59 +0700 Subject: OSMO-MSC/OSMO-HLR Auto Provisioning In-Reply-To: <13D474C8-1818-40A5-83B0-6BD4776667FE@entropysolution.com> References: <13D474C8-1818-40A5-83B0-6BD4776667FE@entropysolution.com> Message-ID: It is not available anymore for new splits. Hope this feature will have in future updates. Best, DUO On Mon, Oct 8, 2018, 15:38 Ron wrote: > Hi Community, > > Is the auto provisioning (subscriber-create-on-demand) of OSMO-NITB is > still present or available in OSMO-BSC/OSMO-MSC/OSMO-HLR version? > > We tried to use the ?authentication optional? under OSMO-MSC configuration > but still, it checks if the subscriber is provisioned in OSMO-HLR. > > Best Regard, > > Ron Menez > ron.menez at entropysolution.com > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmith at sysmocom.de Mon Oct 8 09:08:59 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 8 Oct 2018 11:08:59 +0200 Subject: OSMO-MSC/OSMO-HLR Auto Provisioning In-Reply-To: References: <13D474C8-1818-40A5-83B0-6BD4776667FE@entropysolution.com> Message-ID: Hello Ron, here is the related issue: https://osmocom.org/issues/2542 Best regards, Oliver -- - Oliver Smith https://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 Mon Oct 8 09:25:37 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Oct 2018 11:25:37 +0200 Subject: OSMO-MSC/OSMO-HLR Auto Provisioning In-Reply-To: <13D474C8-1818-40A5-83B0-6BD4776667FE@entropysolution.com> References: <13D474C8-1818-40A5-83B0-6BD4776667FE@entropysolution.com> Message-ID: <20181008092537.GP20261@nataraja> Hi Ron, On Mon, Oct 08, 2018 at 08:38:18AM +0000, Ron wrote: > Is the auto provisioning (subscriber-create-on-demand) of OSMO-NITB is still present or available in OSMO-BSC/OSMO-MSC/OSMO-HLR version? No, it is not. As the feature is only relevant to quite non-standard use cases, it has not been a priority. See http://osmocom.org/issues/2542 In general, operating a network without your own SIM cards is highly discouraged in just about any environment. You cannot authenticate the subscriber, threfore you're vulnerable to all kinds of spoofing, impersonation attacks and fraud. Also, you never know where such cards with IMSIs from third party operators will try to register. they might get rejected with "illegal sim card" from another operator, resulting in extremely unreliable and dissatisfactory user experience. -- - 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 Oct 8 12:07:56 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 8 Oct 2018 14:07:56 +0200 Subject: Persistent VTY history? In-Reply-To: <20181006105404.GC20261@nataraja> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105404.GC20261@nataraja> Message-ID: <20181008120756.GA14840@my.box> On Sat, Oct 06, 2018 at 12:54:04PM +0200, Harald Welte wrote: > On Sat, Oct 06, 2018 at 11:33:01AM +0100, Keith wrote: > > Was just thinking today about if it was ever considered to write the VTY > > history out to a file on exiting (and load it on startup) I've had the desire to implement this a number of times before. Especially because during testing, of course the vty session is closed with every program restart, and it takes extra effort to just call the same commands again... > Not sure if $HOME is such a good idea for "system services/daemons" like > the osmocom daemons. I wouldn't be surprised if that would either point > to a read-only mount or /tmp in various configurations. [...] > The only problem that I can see is that there can be any number of users > using any number of VTY sessions in parallel. So which history do we store? I think it would have made more sense to do it per-user, but that isn't possible from the server process. We don't know which user is connected via telnet. We could also toss up a telnet client that manages the history externally; osmo_interact_vty.py comes to mind, so far used mostly for transcript tests. With a few tweaks that could become a usable shell. Then we don't need to bother the server process with I/O of writing history files, and keep out the complexity of interleaving parallel VTY sessions. Such a client could also have a bit of convenience for VTY port number lookups, like that tip of naming the ports in /etc/services, just without the need to edit that file. Which sounds a lot like: > Slighty unrelated: zebra/quagga also has many programs and each with their > own VTY. They then introduced something called vtysh, whihc I only read > about but never used myself. It supposedly allows you to talk > to all of the various daemons from one frontend: > https://www.systutorials.com/docs/linux/man/1-vtysh/ > Definitely worth investigating if somebody is lookning for VTY usability > improvements.. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From axilirator at gmail.com Mon Oct 8 12:50:43 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 8 Oct 2018 19:50:43 +0700 Subject: SMS handing in the Osmocom CNI Message-ID: Dear all, In this mail I would like to negotiate and discuss some details about further development of the Osmocom CNI, in particular the way of handling of SMS messages. At this time, all SMS messages within the Osmocom CNI are terminated at OsmoMSC. There we have some basic routing configuration, either internal, or SMPP. This approach has some disadvantages, at least: - MSC is not a proper place for terminating SMS messages, in commercial networks it's usually done by SMS Center; - in case if a network based on the Osmocom CNI does contain multiple MSCs, one has to configure / update the SMS routing configuration for each MSC individually; - one would have to use SMPP in order to deliver SMS messages to / from commercial networks, which in most cases "speak" either MAP, or DIAMETER, or even both, but not SMPP; - using SMPP (as it's the only external interface available) involves the need to encode and decode complex SMS protocol, what is not desired in some situations. This is why it was decided to rip the SMS routing out of OsmoMSC, and use generic (for Osmocom CNI) GSUP protocol as the transport. Please see OS#3587 for more details about "SMS over GSUP". So, we actually need a separate process, let's call it "OsmoSMSC" in quotes for now, as I am not sure about the proper name. It should implement at least basic functionality of the SMS Center. Since we are using OsmoHLR as the main / central gateway in the Osmocom CNI for all GSUP communications, this to be discussed "OsmoSMSC" should basically be connected to OsmoHLR. What I would like to discuss is how should we implement "OsmoSMSC"? I think there are two possible ways: either write it from scratch, or fork some existing project. Implementing from scratch would require much more efforts and time than forking an existing SMSC implementation, for sure. I've recently discovered a project called Kannel - an Open Source WAP and SMS gateway written in C and distributed under the Kannel Software License, please see: https://www.kannel.org/index.shtml What do I personally like: - helpers for OTA configuration (e.g. WAP, MMS settings) messages; - written in C and using automake as the build system; - high performance (hundreds of messages per second); - 7-bit, 8-bit and Unicode message coding. So we could fork this project as "OsmoSMSC", and extend in the following way: - integrate generic Osmocom logging; - integrate VTY interface and generic configuration; - implement GSUP client from OsmoHLR. I already started to read the source code and documentation. If anyone has any experience with Kannel, please share! And finally, how should we name "OsmoSMSC"? :) With best regards, Vadim Yanitskiy. From ron.menez at entropysolution.com Tue Oct 9 02:05:44 2018 From: ron.menez at entropysolution.com (Ron) Date: Tue, 9 Oct 2018 02:05:44 +0000 Subject: OSMO-MSC/OSMO-HLR Auto Provisioning In-Reply-To: <20181008092537.GP20261@nataraja> References: <13D474C8-1818-40A5-83B0-6BD4776667FE@entropysolution.com> <20181008092537.GP20261@nataraja> Message-ID: <7D9BE721-8731-4B45-BE08-512F8222026F@entropysolution.com> Noted on this Harald and thanks for the information community. Best Regard, Ron Menez ron.menez at entropysolution.com On Oct 8, 2018, at 5:25 PM, Harald Welte > wrote: Hi Ron, On Mon, Oct 08, 2018 at 08:38:18AM +0000, Ron wrote: Is the auto provisioning (subscriber-create-on-demand) of OSMO-NITB is still present or available in OSMO-BSC/OSMO-MSC/OSMO-HLR version? No, it is not. As the feature is only relevant to quite non-standard use cases, it has not been a priority. See http://osmocom.org/issues/2542 In general, operating a network without your own SIM cards is highly discouraged in just about any environment. You cannot authenticate the subscriber, threfore you're vulnerable to all kinds of spoofing, impersonation attacks and fraud. Also, you never know where such cards with IMSIs from third party operators will try to register. they might get rejected with "illegal sim card" from another operator, resulting in extremely unreliable and dissatisfactory user experience. -- - Harald Welte > http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Oct 9 03:35:46 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 9 Oct 2018 05:35:46 +0200 Subject: SMS handing in the Osmocom CNI In-Reply-To: References: Message-ID: <20181009033546.GA10793@my.box> On Mon, Oct 08, 2018 at 07:50:43PM +0700, Vadim Yanitskiy wrote: > So we could fork this project as "OsmoSMSC", Is there a hard reason to fork it? Couldn't we just contribute the GSUP connection to upstream and use that then? I mean, it would be nice to have the same logging and config scheme as other osmo programs, but unless Kannel is completely non-maintained, I don't think that's worth considering a fork for...? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Tue Oct 9 12:32:01 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 9 Oct 2018 13:32:01 +0100 Subject: SMS handing in the Osmocom CNI In-Reply-To: References: Message-ID: On 08/10/18 13:50, Vadim Yanitskiy wrote: > If anyone has any experience with Kannel, please share! Hi Vadim. Rhizomatica still uses kannel fairly extensively in the "RCCN", although our plan is to remove it ASAP. It was chosen initially as a FOSS possibility to link the osmo-nitb SMPP interface to python. We setup a kannel ESME that receives SMS and forwards them to a REST service listener (the python daemon) The python daemon then processes the message, (checks authorisation, routing) and forwards it to a kannel HTTP listener which forwards the message on to the SMPP side of the nitb. Now, i haven't looked much at the code, although I did once take a look at something to see why multipart messages were getting messed up internally. The reason is that kannel concats multipart messages received by the kannel ESME and forwards them using the charset of the first message part, which may not be necessarily the same as any subsequent message part :(( Character set translation support seemed incomplete, and support for GSM 03.38 shift tables is totally absent! :(( Your mail prompts me to look at the kannel website, and I note that a new stable version is relatively recently released. So some work has been done, previous to that it seemed to be abandoned. What I did spent quite a lot of time with in relation to kannel, was reading documentation (which I initially found somewhat inaccessible), testing configuration and general usage. During this time, I got the impression that kannel is far from being a SMSC, but is a "WAP gateway"? - rather a kind of bulk SMS processor, a HTTP gateway to submit (spammy) SMS, or for working with things like short code processing. I'm not aware of any Core Network SMS center type functionality within kannel. Kannel can connect to other SMSC but there's no SMSC as such within. IIRC there isn't even any non-volatile store and forward support. I think (again from memory) that there is some database storage but only for delivery reports. Maybe something has been added in the 2018 work. I therefore have been working scantly on a python based ESME, using python-smpplib. I'm not a python programmer though so it's very much prototype work, and probably very bad python, but I'll publish something "soon" :-/ Also python-smpplib is not perfect, (mainly I think because of a lack of real world implementations based on it) and I got held up sometimes by having to fix things in python-smpplib. The maintainer is sometimes active, and sometimes quite absent. Pau did some work on python-smpplib for the osmo-gsm-tester (i think) and although he submitted some patches, I think there was some suggestion that it could do with a complete re-write. I'd maybe consider forking and fixing python-smpplib, and writing an SMSC in python. If one wanted to work on OsmoSMSC in C, there may be many things of use in the kannel code that could be of used (instead of the libsmpp in the case of SMPP), but I don't know if that's helping in terms of effort? Also, I think then that the resulting product would not really be? "fork" of kannel, but rather a completely different product, so we'ld probably spend a lot of time stripping out what we don't want. Maybe that still makes sense? There is also Holger's smalltalk SMSC, which I think was written to be an actual SMSC. Keith. ? ? . From keith at rhizomatica.org Tue Oct 9 12:46:53 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 9 Oct 2018 13:46:53 +0100 Subject: Persistent VTY history? In-Reply-To: <20181008120756.GA14840@my.box> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105404.GC20261@nataraja> <20181008120756.GA14840@my.box> Message-ID: <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> Hi all, thanks for the replies on this thread. good to see some other people have considered it, and for pretty much the same reasons it occurred to me. I tried rlwrap (the readline wrapper) with telnet, and of course it works, in that you get full readline support with saved history in your telnet session, on the client/user side) but you lose the [TAB] and [?] command completion of the vty. I had a quick go and re-implementing the command completion using an rlwrap plugin, but my rusty perl skills did not allow me to complete that quickly, and I felt like whatever I might come up with would be klunky and hack-ish anyway, but It's probably possible. I think you have to stop rlwarp from sending a newline along with the command completion TAB though, and I'm not sure this is doable from the plugin. I'll have another look if I can find time. I took a very quick look at zebra, (seems it's using sockets rather than tcp) and is making full use of readline. I guess a full "command and control centre" client application for the split osmo stack, might be an idea, but that's more effort than what I was proposing to do here, but I'd wonder if maybe a configurable "write history" option is not. Of course, In my introspective viewpoint, I forgot that the server doesn't know which user is on the vty, and that there might be multiple users, I was only thinking of myslef, on my own local box. :/ But for such situations (which are quite common for devs?), would it make sense, to (as an option) just write the history on client disconnect to /var/lib/osmocom/[daemon-name].history or something. I'll take a look at the python vty interact. I haven't looked at it. Thanks! k/ From nhofmeyr at sysmocom.de Tue Oct 9 14:50:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 9 Oct 2018 16:50:23 +0200 Subject: Persistent VTY history? In-Reply-To: <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105404.GC20261@nataraja> <20181008120756.GA14840@my.box> <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> Message-ID: <20181009145023.GD3145@my.box> On Tue, Oct 09, 2018 at 01:46:53PM +0100, Keith wrote: > Hi all, thanks for the replies on this thread. > > good to see some other people have considered it, and for pretty much > the same reasons it occurred to me. > > I tried rlwrap (the readline wrapper) with telnet, and of course it > works, in that you get full readline support with saved history in your > telnet session, on the client/user side) but you lose the [TAB] and [?] > command completion of the vty. All that needs to happen is that the tab and ? are sent to the telnet immediately, without waiting for the newline. Then it would reply with the completion / online doc output. > I had a quick go and re-implementing the command completion using an > rlwrap plugin you mean like navigate the vty tree and figure out what commands exist? that's not going to work, at least not like the real vty behaves. There is lots of magic going on there, argument range checking and whatnot. > I think you have > to stop rlwarp from sending a newline along with the command completion > TAB though, and I'm not sure this is doable from the plugin. I'll have > another look if I can find time. that sounds more like it. If we could only make all of [\n\t?] terminate a readline like \n does... > I'll take a look at the python vty interact. I haven't looked at it. That would also need the don't-wait-for-newline stuff, and it currently also omits the prompts. What works already is a kind of pseudo interactive shell: e.g. run osmo-bsc, then $ osmo_interact_vty.py -p 4242 ? show Show running system information list Print command list exit Exit current mode and down to previous mode help Description of the interactive help system enable Turn on privileged mode command terminal Set terminal line parameters who Display who is on vty logging Configure logging no Negate a command or set its defaults Needs to * show the prompt * change it to treat all of [\n\t?] as line-end; I hope that doesn't need re-invention of libreadline -- that's the biggest uncertainty. * write/read the history... Hm, looks like it might end up a considerable effort after all. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From stsp at stsp.name Wed Oct 10 07:17:52 2018 From: stsp at stsp.name (Stefan Sperling) Date: Wed, 10 Oct 2018 09:17:52 +0200 Subject: Persistent VTY history? In-Reply-To: <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105404.GC20261@nataraja> <20181008120756.GA14840@my.box> <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> Message-ID: <20181010071752.GO77736@ted.stsp.name> On Tue, Oct 09, 2018 at 01:46:53PM +0100, Keith wrote: > Of course, In my introspective viewpoint, I forgot that the server > doesn't know which user is on the vty, and that there might be multiple > users, I was only thinking of myslef, on my own local box. :/ Multi-user history support could be left for later. For now, we could simply have the server write the history of any connected session to the file when command history is enabled. It is the simplest solution and works well for the most obvious use case, which is making repeated testing/debugging easier to do. If multiple users are connected then their command histories will be combined. That's no different from what some shells are doing when a user opens multiple terminal windows at the same time. A client-side history solution could still be added later, independently of any server-side solution. From nhofmeyr at sysmocom.de Wed Oct 10 11:09:17 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 10 Oct 2018 13:09:17 +0200 Subject: Persistent VTY history? In-Reply-To: <20181010071752.GO77736@ted.stsp.name> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105404.GC20261@nataraja> <20181008120756.GA14840@my.box> <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> <20181010071752.GO77736@ted.stsp.name> Message-ID: <20181010110917.GB3782@my.box> On Wed, Oct 10, 2018 at 09:17:52AM +0200, Stefan Sperling wrote: > Multi-user history support could be left for later. ...is impossible to do server-side, without adding the concept of a user name, which I'd -1. > For now, we could simply have the server write the history of any > connected session to the file when command history is enabled. when a telnet vty closes, append all history to $history_path/$program_name.history ok, simple enough. Yet it adds potentially large I/O to the server process, which would block until the history is written. That might be undesirable... Could also flush the history to file every time it reaches a given size to make sure of light I/O load. I sometimes invoke the vty with 'watch', or otherwise scripted, to keep showing the lchan summary, for example. That would produce a history entry for every single invocation, cause disk I/O and spam the history file. Do we need to enable history explicitly in each vty session? Or a a "no history" command per vty-session? A client-side impl is much simpler from that angle. It just keeps so much cruft out of the server process, and "all we need" is a readline() that knows vty special characters. > A client-side history solution could still be added later, independently > of any server-side solution. I doubt we will have the other when one is already there. So I guess it's up to who will contribute code first. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Wed Oct 10 11:18:39 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 10 Oct 2018 13:18:39 +0200 Subject: IuUP, aka voice between 2G and 3G Message-ID: <20181010111839.GC3782@my.box> [private hacking hat on] Thinking ahead to the 35C3, I have tinkered with IuUP a bit. I'm at the point where I have an IuUP core net node in the osmo-mgw, which auto-detects IuUP peers and removes IuUP headers coming from a 3G RNC, and inserts IuUP headers in RTP going to a 3G RNC. So far we were merely hacking over the IuUP header to mimick an Initialization ACK, and were otherwise just handing the IuUP headers through from one 3G peer to the other. I realized now that hacking up an Initialization ACK like we currently do on osmo-mgw master produces a header CRC error, which the femto cells we currently tested completely don't care about, thankfully. Ok, so now I am de/encapsulating the IuUP from/to RTP, so that IuUP is present only on the last leg to/from an RNC. 3G to 3G calls still work well with that, now also having correct IuUP header CRCs. And, the naive idea was that now the 2G would simply understand the RTP from the 3G and vice versa. But that's not the case, apparently. The phones at best crackle some random artifacts. I picked a codec-list of fr3 hr3 in osmo-bsc, and tried a few AMR rates (12.2k, 5.9k, 5.2k). So I think there's still some fundamental concept that I'm lacking. Is there anyone more familiar with AMR and/or the way 3G encodes audio, and whether there's a simple way to make them match? Where should I read on? Would a call router like we use in the C3 POC be able to transcode when the IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP with GSM.) I've noticed the laforge/iu_up branch in libosmocore only later, which includes an FSM that apparently does only state transitions so far. My patch has no FSM yet, since all I see on the wire is Init->InitAck, then Data PDUs, and maybe an occasional error report. Do those FSM states convey a secret of making 3G encoding readable by 2G? Various pcaps of the status quo are here: http://kleinekatze.de/eeD0ouCo/ My IuUP branch: osmo-mgw neels/iuup http://git.osmocom.org/osmo-mgw/log/?h=neels/iuup IuUP protocol spec: 3GPP TS 25.415 (I've so far ignored most of it) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Wed Oct 10 14:33:23 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Oct 2018 16:33:23 +0200 Subject: Persistent VTY history? In-Reply-To: <20181010110917.GB3782@my.box> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105404.GC20261@nataraja> <20181008120756.GA14840@my.box> <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> <20181010071752.GO77736@ted.stsp.name> <20181010110917.GB3782@my.box> Message-ID: <20181010143323.GI12217@nataraja> On Wed, Oct 10, 2018 at 01:09:17PM +0200, Neels Hofmeyr wrote: > when a telnet vty closes, append all history to > $history_path/$program_name.history > ok, simple enough. > > Yet it adds potentially large I/O to the server process, which would block > until the history is written. That might be undesirable... you cannot do a blocking write. The "history save procedure" would not be different and should be written via non-blocking file writes using the select() loop abstraction. > Could also flush the history to file every time it reaches a given size to make > sure of light I/O load. I don't expect the history of a human user at the VTY session every to reach a size where one would have to worry about that. We're talking about kilobytes here. > I sometimes invoke the vty with 'watch', or otherwise scripted, to keep showing > the lchan summary, for example. That would produce a history entry for every > single invocation, cause disk I/O and spam the history file. Do we need to > enable history explicitly in each vty session? Or a a "no history" command per > vty-session? I would say explicit "no history" > A client-side impl is much simpler from that angle. It just keeps so much cruft > out of the server process, and "all we need" is a readline() that knows vty > special characters. ACK. And we already have a [special] telnet client for nanoBTSs around on git.osmocom.org in http://git.osmocom.org/libtelnet/ I would currently argue more in favor of a client based solution -- - 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 Oct 10 14:50:16 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Oct 2018 16:50:16 +0200 Subject: IuUP, aka voice between 2G and 3G In-Reply-To: <20181010111839.GC3782@my.box> References: <20181010111839.GC3782@my.box> Message-ID: <20181010145016.GJ12217@nataraja> Hi Neels, thanks for looking into this. On Wed, Oct 10, 2018 at 01:18:39PM +0200, Neels Hofmeyr wrote: > So I think there's still some fundamental concept that I'm lacking. Is there > anyone more familiar with AMR and/or the way 3G encodes audio, and whether > there's a simple way to make them match? Where should I read on? The fundamental part that you're lacking is the fact that the codec payload for 3G and 2G is completely different. You will need lots of bit re-shuffling in order to make this work. >From the MGW point of view, IuUP and the 3G-style codec payload should be seen as a different codec, and an endpoint with two connections of two different codec requires "transcoding". The only difference here is that in case of AMR on both the IuUP and the 2G side, you don't actually transcode to PCM and re-encode, but you're really just shuffling around the bits. > Would a call router like we use in the C3 POC be able to transcode when the > IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP > with GSM.) Nobody outside a 3G network will have any idea what IuUP is. Even more so, I think nobody on the planet will be able to process codec payload that is in IuUP payload format without the IuUP header. Basically either a) you have IuUP and the related payload format, or b) you have no IuUP and native RTP [AMR] payload format Going in between by just removing the IuUP header you would create yet another derivative that doesn't exist so far. > I've noticed the laforge/iu_up branch in libosmocore only later, It would have been great to first catch up about this, before investing time on an implementation. I had mentioned this branch in http://osmocom.org/issues/1936 when I wrote it close to a year ago. > which includes an FSM that apparently does only state transitions so far. It does a bit more, such as both header and payload CRC computation / verification and should actually implement pretty much everything between the TNL and the RNL SAP and implement all primitives on both sides. It hasn't been tested yet, though. To do that, I first implemented RTP source/sink in TTCN3 and then IuUP in TTCN3, but then got distracted before putting the full setup together and write actual test cases against the libosmocore iu_up impementation. You should be able to * feed primitives from the transport layer (RTP) up into it using osmo_iuup_tnl_prim_up() * feed primitives from the upper layer down into it using osmo_iuup_rnl_prim_down() The transformations are done inside the FSM using tnl_to_rnl_data() as well as rnl_to_tnl_data(). Only SMpSDU mode is implemented, which is what's used in our case. > My patch has no FSM yet, since all I see on the wire is Init->InitAck, > then Data PDUs, and maybe an occasional error report. Do those FSM > states convey a secret of making 3G encoding readable by 2G? The state machines are required as soon as you actually have changes between the AMR codec rates, i.e. the actual *adaptive* part of AMR. Also, once you are actually re-ordering ("transcoding") the payload bits, you will have to recompute the CRC. I do think the FSM should be used, rather than some other approach. -- - 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 Oct 10 15:18:44 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 10 Oct 2018 17:18:44 +0200 Subject: IuUP, aka voice between 2G and 3G In-Reply-To: <20181010111839.GC3782@my.box> References: <20181010111839.GC3782@my.box> Message-ID: <20181010151844.GL12217@nataraja> Hi Neels, in terms of the actual payload, I believe (IIRC), that AMR over IuUP used three sub-flows. They are encoded after each other, see TS 25.415 6.6.3.27 / Figure 27a for an illustration. Thse SDUs of each sub-flow contain the bits of one class. The rationale for teh above lies in the structure of the RAB and the channel bundles on the Iu radio layer. Both on the radio and on the IuFP side between NodeB and RNC, there are actually three independent streams of bits, one for each of the classes. For IuUP, it seems they are then re-combined in the RNC into one IuUP payload, but still the three separate chunks accordign to their class. In order to get the regular RTP-AMR payload, they need to be mixed/mangled into the order specified by whatever RFC specifies the AMR payload format, I think it as https://tools.ietf.org/html/rfc3267 - whcih then refers to the IF1 format as specified in 3GPP TS 26.101, where IF1 is described in Section 4. The order of the fields here is "logical", so if there's a given parameter that has 6 bits, then those 6 bits are consecutive. In the air interface, you may want to transmit the first two (MSB) bits in class A, the middle two in class B and the last two bits in class C. This is so the most improtant bits for speech recovery are given higher amount of forward error correction than the less important bits. I believe the tables in Annex B of 26.101 is what's needed in terms of re-ordering. Still, there's plenty of things that can go wrong in terms of bit-order within a byte, byte ordering, ..., and hence I think it's good to start with writing functions and unit tests for this first. GAPK might be a good place for prototyping, as it already understands the concept of different representations/bit-orders/formats for one given codec, and it has support for playback via alsa, ... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Wed Oct 10 16:35:50 2018 From: keith at rhizomatica.org (Keith) Date: Wed, 10 Oct 2018 18:35:50 +0200 Subject: Persistent VTY history? In-Reply-To: <20181009145023.GD3145@my.box> References: <7b30d5cc-17c9-587d-aeca-aea19b4c3e79@rhizomatica.org> <20181006105404.GC20261@nataraja> <20181008120756.GA14840@my.box> <75b5791b-8b19-d376-685b-359f9403ed26@rhizomatica.org> <20181009145023.GD3145@my.box> Message-ID: <229afb8f-389d-5807-e033-e7923c3813c6@rhizomatica.org> On 09/10/18 16:50, Neels Hofmeyr wrote: > On Tue, Oct 09, 2018 at 01:46:53PM +0100, Keith wrote: >> >> I tried rlwrap (the readline wrapper) with telnet, and of course it >> works, in that you get full readline support with saved history in your >> telnet session, on the client/user side) but you lose the [TAB] and [?] >> command completion of the vty. > All that needs to happen is that the tab and ? are sent to the telnet > immediately, without waiting for the newline. Then it would reply with the > completion / online doc output. The rlwrap plugin calls a function when TAB is pressed, completion_handler() and from there you can send what you will to the other side, and fill an array with completion words, that will be displayed and can be used for completion (and therefore sent with [CR]) https://github.com/hanslub42/rlwrap/wiki/RlwrapFilter.pm-manpage I think it can be done, but you need to get the parsing of the vty output response to [TAB] right, and you need to avoid sending a [CR] along with the [TAB] or [?], which might require a patch to rlwrap. From nhofmeyr at sysmocom.de Thu Oct 11 11:31:32 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 11 Oct 2018 13:31:32 +0200 Subject: IuUP, aka voice between 2G and 3G In-Reply-To: <20181010151844.GL12217@nataraja> References: <20181010111839.GC3782@my.box> <20181010151844.GL12217@nataraja> Message-ID: <20181011113132.xudch4f3twktdiao@ass40.sysmocom.de> (continuing this thread in https://osmocom.org/issues/1936#change-12154 ) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Thu Oct 11 19:59:08 2018 From: keith at rhizomatica.org (Keith) Date: Thu, 11 Oct 2018 21:59:08 +0200 Subject: BSC / MSC volatile state / restart handling Message-ID: Hi All. This is very brief, but something that's been on my mind to make a ticket about. I realise maybe it's better to ask first if there is a plan. The issue is about restarting MSC or BSC (or both). I still really haven't looked at the split setup enough yet, in terms of getting familiar with all the info available from logging in both programs, so I don't have a good analysis of what's going on. Sorry. But my point here is not to describe a bug to be fixed but just asking in general what is the strategy to deal with daemon restarts, intentional or not. Is there a plan to implement some kind of non-volatile state? The problem in terms of usability, from simple observation: In the case of restarting the MSC with two phones connected, of course the phones don't notice anything. One now needs to attempt a call setup at least 3 times, including a call setup attempt from the "callee" phone before we can even call it. I tried restarting both BSC and MSC, in various orders, and I did not get a satisfactory result. Of course, restarting the BSC restarts osmo-bts which causes (some) phones to notice the temporary loss of BCCH, but of course no LUR or anything as LAC doesn't change, so there's some state that is not getting set right someplace on restart, as I said. both phones need to interact before one of them can be called. Yeah, so, sorry for the lame analysis, but I think this should be pretty easy to reproduce, and at this time there are people who are MUCH more familiar with osmo-msc and osmo-bsc than me, who probably know what I'm talking about and can comment. Thanks! k/ From keith at rhizomatica.org Thu Oct 11 20:30:17 2018 From: keith at rhizomatica.org (Keith) Date: Thu, 11 Oct 2018 22:30:17 +0200 Subject: SS requests do bad things. Message-ID: Hi all Another one not quite ready for a ticket, but maybe worth mentioning here. A while back I noticed a phone of mine was holding channels open all the time. Turns out in does checks for call forwarding status and such on camping. This got fixed in Legacy OpenBSC: https://gerrit.osmocom.org/#/c/openbsc/+/503/ I noticed this, or something similar is back with the split setup. Try dialing *#21# for example. or pick a code from here: http://www.geckobeach.com/cellular/secrets/gsmcodes.php Then make a call. On some phones you can't, but if it does proceed, then hangup. On all the phones I tried you now have not only a lingering SDCCH, but also a TCH/F and on one phone, it doesn't ever go away, until you turn off the phone, or drop the BCCH. sorry again for the lame bug report. I don't want to forget it and I can't pay it due attention in the coming days. k/ From laforge at gnumonks.org Fri Oct 12 06:59:30 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Oct 2018 08:59:30 +0200 Subject: SS requests do bad things. In-Reply-To: References: Message-ID: <20181012065930.GJ9979@nataraja> Hi Keith, On Thu, Oct 11, 2018 at 10:30:17PM +0200, Keith wrote: > Another one not quite ready for a ticket, but maybe worth mentioning here. Why is it not ready? All that is missing to create a ticket is to include a pcap of Abis/A/GSUP from when you do the test... > A while back I noticed a phone of mine was holding channels open all the > time. Turns out in does checks for call forwarding status and such on > camping. Was this before or after the external SS interface was introduced, particularly commit 8a6ef55ec5838bdac3b5780bfc404c9b732d944f Author: Vadim Yanitskiy Date: Tue Jun 12 08:21:20 2018 +0700 ? In theory, all non-call related SS (NC_SS) should now be handled at the HLR, and the HLR should reject any of those. The codes you refer to are, however, call related SS. I never looked into those much. Please file an issue including protocol traces. tHanks. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Oct 12 06:55:03 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Oct 2018 08:55:03 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: References: Message-ID: <20181012065503.GI9979@nataraja> Hi Keith, On Thu, Oct 11, 2018 at 09:59:08PM +0200, Keith wrote: > The issue is about restarting MSC or BSC (or both). That's something that classic telecom doesn't typically consider very well. In terms of the functional specs, it is assumed that restarting a network element, particularly a core network element is a super rare occasion, and hence nothing to be really considering as a general problem. > I still really haven't looked at the split setup enough yet, OsmoNITB shouldn't really be any different. Is it? > Is there a plan to implement some kind of non-volatile state? What you're referring to is basically the loss of VLR information. The 3GPP specs explciitly consider it volatile and non-persistent. Holger and I were brainstorming about this some time ago, and we came up with the idea of using a System V shared memory segment for the actual VLR data. SysV SHM has the nice property that it's regular mapped memory, but it is independent of processes, i.e. you can restart a process while keeping whatever is in that shared memory segment. The devil is of course in the detail: 1) you may not be able to map it to the same address after each restart? Needs further investigation and might require some pointer fix-up, or the use of relative/offset addressing rather than absolute pointers. 2) what do you do if you're actually upgrading the software and the VLR related structures have been modified? There either needs to be an explicit conversion function, or at least a mechanism to detect this safely and discard all the data in such situations 3) if the restart is a crash: What if some corrupted VLR data was actually the cause of the crash? In that case you'd end up in a re-start loop. You'd have persistent crashes, rather than a one-off crash with recovery. I've done some research on the web at that time (maybe 2 years ago) but unfortunately couldn't find any library/tool/infrastructure for having persistent data in SysV SHM, and also no other FOSS programs that did so. Maybe I didn't look closely enough? To me, it seems like the most obvious solution to persist state across crashes/restarts of C programs on unix-type systems. We explicitly don't want to use some kind of database system, as the VLR data needs to be accessed all over the code directly/synchronously/non-blockingly. We cannot wait for it to be retrieved from somewhere. That's what is done with HLR data. > In the case of restarting the MSC with two phones connected, of course > the phones don't notice anything. One now needs to attempt a call setup > at least 3 times, including a call setup attempt from the "callee" phone > before we can even call it. The alternative is to wait for any location update, either due to the periodic location update timer expirign, or due to the phones actually moving geographic location. > I tried restarting both BSC and MSC, in various orders, and I did not > get a satisfactory result. Of course, restarting the BSC restarts > osmo-bts which causes (some) phones to notice the temporary loss of > BCCH, but of course no LUR or anything as LAC doesn't change, so there's > some state that is not getting set right someplace on restart, as I > said. both phones need to interact before one of them can be called. A BSC restart will always loose all active connections/channels/calls, and I think there's nothing wrong with that. Persisting that state makes little sense, as the phones will all have closed their radio channels at the time your BSC recovers. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mia at mob5g.net Fri Oct 12 07:08:20 2018 From: mia at mob5g.net (Michael Andersen) Date: Fri, 12 Oct 2018 09:08:20 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <20181012065503.GI9979@nataraja> References: <20181012065503.GI9979@nataraja> Message-ID: <01cf01d461fa$5bd85710$13890530$@net> Hi Harald, >We explicitly don't want to use some kind of database system, as the VLR >data needs to be accessed all over the code >directly/synchronously/non-blockingly. We cannot wait for it to be >retrieved from somewhere. That's what is done with HLR data. Lightning Memory-Mapped Database (https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database) is designed for exactly these requirements. It gives non-blocking access to the data - directly in-memory. Yet it also persists the data to disk in the background. So in case the software is restarted, it can pick off exactly where it left its dataset. LMDB is highly recommended. BR, Michael A From laforge at gnumonks.org Fri Oct 12 07:50:53 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Oct 2018 09:50:53 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <01cf01d461fa$5bd85710$13890530$@net> References: <20181012065503.GI9979@nataraja> <01cf01d461fa$5bd85710$13890530$@net> Message-ID: <20181012075053.GL9979@nataraja> Hi Michael, On Fri, Oct 12, 2018 at 09:08:20AM +0200, Michael Andersen wrote: > >We explicitly don't want to use some kind of database system, as the VLR > >data needs to be accessed all over the code > >directly/synchronously/non-blockingly. We cannot wait for it to be > >retrieved from somewhere. That's what is done with HLR data. > > Lightning Memory-Mapped Database > (https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database) is designed > for exactly these requirements. Thanks for your suggestion. After reading through the documentation I could find, I am not convinced it actually is applicable to our use case / requirements. Osmocom programs, like OsmoMSC are non-blocking single-threaded event-loop driven designs. We cannot at any point run into a situation where there is a blocking read or blocking write to disk/file. Doing so would kill performance for all other concurrent transactions in progress. > It gives non-blocking access to the data - directly in-memory. Yet it also > persists the data to disk in the background. So in case the software is > restarted, it can pick off exactly where it left its dataset. AFAICT from a very quick look at the source code, the writing-to-disk is not performed "in the background" but it is rather performed as blocking write() calls in the process/context at which the data is acessed? So to me, LMDB more looks like BerkeleyDB or SQLite but with a layer of zero-copy memory cache/access at runtime on top of it? We don't want blocking/IO. We don't want disk I/O at all. We don't want persistency across system reboots or the like, but only persistency across restarts/respawns of the specific process. Hence my argument in favor of a SysV SHM segment, which fullfills the criteria. If anyone has any pointers for examples of FOSS programs or libraries where that has been done before, it would be much appreciated. 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 mia at mob5g.net Fri Oct 12 09:23:23 2018 From: mia at mob5g.net (Michael Andersen) Date: Fri, 12 Oct 2018 11:23:23 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <20181012075053.GL9979@nataraja> References: <20181012065503.GI9979@nataraja> <01cf01d461fa$5bd85710$13890530$@net> <20181012075053.GL9979@nataraja> Message-ID: <01de01d4620d$394e59c0$abeb0d40$@net> Hi Harald, >> It gives non-blocking access to the data - directly in-memory. Yet it also >> persists the data to disk in the background. So in case the software is >> restarted, it can pick off exactly where it left its dataset. > >AFAICT from a very quick look at the source code, the writing-to-disk is not >performed "in the background" but it is rather performed as blocking write() >calls in the process/context at which the data is acessed? We use it in MDB_NOSYNC mode. In practice this seems to result in no waiting for writes in the user thread at any point. Waiting for reads is never an issue because the LMDB design does not support reading from disk. The LMDB benchmarks talk about many thousands of transactions per second. I can confirm that these benchmarks are not lying. >So to me, LMDB more looks like BerkeleyDB or SQLite but with a layer of zero-copy >memory cache/access at runtime on top of it? The cool thing about LMDB is that it has no cache, no layers. The "database" is an area of memory that the LMDB functions help access using key/value functions. BR, Michael A From laforge at gnumonks.org Fri Oct 12 09:32:11 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Oct 2018 11:32:11 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <01de01d4620d$394e59c0$abeb0d40$@net> References: <20181012065503.GI9979@nataraja> <01cf01d461fa$5bd85710$13890530$@net> <20181012075053.GL9979@nataraja> <01de01d4620d$394e59c0$abeb0d40$@net> Message-ID: <20181012093211.GR9979@nataraja> Hi Michael, On Fri, Oct 12, 2018 at 11:23:23AM +0200, Michael Andersen wrote: > We use it in MDB_NOSYNC mode. In practice this seems to result in no waiting > for writes in the user thread at any point. Waiting for reads is never an > issue because the LMDB design does not support reading from disk. Thanks for your clafifications. Defnitely worth further investigation. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Fri Oct 12 10:10:25 2018 From: keith at rhizomatica.org (Keith) Date: Fri, 12 Oct 2018 12:10:25 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <20181012065503.GI9979@nataraja> References: <20181012065503.GI9979@nataraja> Message-ID: <74067f7c-899a-70d6-801d-8d8ca8399915@rhizomatica.org> On 12/10/18 08:55, Harald Welte wrote: > Hi Keith, Hi Harald, thanks for getting back on this so quick. > > On Thu, Oct 11, 2018 at 09:59:08PM +0200, Keith wrote: >> The issue is about restarting MSC or BSC (or both). > That's something that classic telecom doesn't typically consider very well. > > In terms of the functional specs, it is assumed that restarting a network > element, particularly a core network element is a super rare occasion, and > hence nothing to be really considering as a general problem. Understood, so I guess the question here is do we want to and/or can we do anything differently. I'm thinking that if I want to upgrade osmo-msc in place on a production system, I obviously have to restart it. There's also the case of power (AC) outage. Currently with osmo-nitb, upgrade involves a temporary (some seconds) loss of BCCH that some phones do not even appear to react to at all. (I have a script that waits for 0 calls before restarting) With the split setup it involves a complete loss of service, basically, as you say, until location update timeout. > >> I still really haven't looked at the split setup enough yet, > OsmoNITB shouldn't really be any different. Is it? It is, in that, if you have a network up, and phones camped, you kill and restart osmo-nitb, the osmo-bts restarts, and basically from there things continue as normal, that is to say, a camped phone can still has service as before. > >> Is there a plan to implement some kind of non-volatile state? > What you're referring to is basically the loss of VLR information. Yes, those three call attempts I mentioned display different error messages, which indicate progressive restoration of VLR info, although the 1st one IIRC, is something like "BSC unknown to this MSC" > Holger and I > were brainstorming about this some time ago, and we came up with the idea > of using a System V shared memory segment for the actual VLR data. From reading what you wrote and the subsequent discussion it sounds feasible but complicated. > > We explicitly don't want to use some kind of database system, as the VLR > data needs to be accessed all over the code > directly/synchronously/non-blockingly. We cannot wait for it to be > retrieved from somewhere. That's what is done with HLR data. Would there be some way to have the MSC be able to restore it's VLR state on startup from the HLR, or is that going to potentially cause too much traffic on the GSUP i/f, or be just too far away from spec? > >> In the case of restarting the MSC with two phones connected, of course >> the phones don't notice anything. One now needs to attempt a call setup >> at least 3 times, including a call setup attempt from the "callee" phone >> before we can even call it. > The alternative is to wait for any location update, either due to the > periodic location update timer expirign, or due to the phones actually > moving geographic location. Moving in our case is probably not going to happen, and waiting for the LUR timeout.. well it's possible of course. In the case of these common say 5 minute losses of power, where the entire system reboots, the phones are not going to all LUR when the BTS comes back on, so restoration of service will be very gradual. And Yes, of course, there should be UPS and all!!? But you know.. batteries wear out, stuff stops working and doesn't get replaced.. it's all extra cost :(( I'd love to just say, look, the UPS is as system critical as the antenna.. but it's hard to make that stick. I guess maybe when people start noticing the outage of service after power restoration, we could say "fix your UPS!!". > > A BSC restart will always loose all active connections/channels/calls, > and I think there's nothing wrong with that. Persisting that state > makes little sense, as the phones will all have closed their radio > channels at the time your BSC recovers. Sure! I wasn't considering active channels, and of course you're right there's nothing wrong with that, and I'm not suggesting in anyway to try and persist that state. keith. From nhofmeyr at sysmocom.de Fri Oct 12 10:34:27 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 12 Oct 2018 12:34:27 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <01de01d4620d$394e59c0$abeb0d40$@net> References: <20181012065503.GI9979@nataraja> <01cf01d461fa$5bd85710$13890530$@net> <20181012075053.GL9979@nataraja> <01de01d4620d$394e59c0$abeb0d40$@net> Message-ID: <20181012103427.GC10974@my.box> No matter which mechanism, in general, using a key-value store or having to rewire pointers / struct versions / recover corrupted state could end up being considerable effort: the code would look exactly like asking a DB layer for the data, even if that DB layer is super fast. Is an MSC restart really that common? Restarting the BSC should be fine in that regard, BTW. As soon as it's back, and as soon as the LAC has been associated with that BSC (on the first L3 operation for any subscriber), paging should work out again. We could also add explicit LAC<->point-code mappings in the config to remove that gap, so that the BSC's LACs are known right from the time the BSC is connected. On Fri, Oct 12, 2018 at 11:23:23AM +0200, Michael Andersen wrote: > We use it in MDB_NOSYNC mode. In practice this seems to result in no waiting > for writes in the user thread at any point. so... if LMDB uses disk for pesistent storage, and if you never sync to disk ... how can this possibly work? https://symas.com/understanding-lmdb-database-file-sizes-and-memory-utilization/ explains that LMDB is using memory-mapped files. Elsewhere MDB_NOSYNC is explained to not do fsync() after a commit. So I assume some file system I/O is still happening at some point, but I assume done by the kernel. I have no idea about mem-mapped files, whether that is done blocking. It also says "The memory area occupied by the database file is marked read-only"; so, writing a new entry requires immediate disk I/O? (Or disk I/O cached by the kernel until the next fsync). What if we kept the LMDB db file on a ramdisk? :) (I'm still reluctant to key-value-ize the VLR though.) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Fri Oct 12 10:38:46 2018 From: keith at rhizomatica.org (Keith) Date: Fri, 12 Oct 2018 12:38:46 +0200 Subject: SS requests do bad things. In-Reply-To: <20181012065930.GJ9979@nataraja> References: <20181012065930.GJ9979@nataraja> Message-ID: On 12/10/18 08:59, Harald Welte wrote: > All that is missing to create a ticket is to include > a pcap of Abis/A/GSUP from when you do the test... You're right. I wanted to check a few more things.. to avoid questions like the below. I'll get to it when I can.. this ML post was just a note..? > >> A while back I noticed a phone of mine was holding channels open all the >> time. Turns out in does checks for call forwarding status and such on >> camping. > Was this before or after the external SS interface was introduced, > particularly > > commit 8a6ef55ec5838bdac3b5780bfc404c9b732d944f It was with legacy. I haven't done any bisect test on osmo-msc. > > In theory, all non-call related SS (NC_SS) should now be handled at the HLR, > and the HLR should reject any of those. > > The codes you refer to are, however, call related SS. I never looked into > those much. There is some log output on the HLR. > Please file an issue including protocol traces. tHanks. Yep.. From nhofmeyr at sysmocom.de Fri Oct 12 10:39:11 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 12 Oct 2018 12:39:11 +0200 Subject: SS requests do bad things. In-Reply-To: References: Message-ID: <20181012103911.GD10974@my.box> On Thu, Oct 11, 2018 at 10:30:17PM +0200, Keith wrote: > A while back I noticed a phone of mine was holding channels open all the > time. Turns out in does checks for call forwarding status and such on > camping. > > This got fixed in Legacy OpenBSC: > > https://gerrit.osmocom.org/#/c/openbsc/+/503/ > > I noticed this, or something similar is back with the split setup. > > Try dialing *#21# for example. or pick a code from here: > http://www.geckobeach.com/cellular/secrets/gsmcodes.php > > Then make a call. On some phones you can't, but if it does proceed, then > hangup. On all the phones I tried you now have not only a lingering > SDCCH, but also a TCH/F and on one phone, it doesn't ever go away, until > you turn off the phone, or drop the BCCH. ^ I think even that, even without a pcap, would qualify as a non-lame new issue, easier to track than a loose mail thread. Fear not, if an issue turns out lame, we can always Reject it. I do that all the time: create a vague issue, add info later; possibly see my own failure to understand what was going on, and drop them. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Fri Oct 12 10:45:50 2018 From: keith at rhizomatica.org (Keith) Date: Fri, 12 Oct 2018 12:45:50 +0200 Subject: SS requests do bad things. In-Reply-To: <20181012103911.GD10974@my.box> References: <20181012103911.GD10974@my.box> Message-ID: On 12/10/18 12:39, Neels Hofmeyr wrote: > ^ I think even that, even without a pcap, would qualify as a non-lame new > issue, easier to track than a loose mail thread. Fear not, if an issue turns > out lame, we can always Reject it. > > :) I guess after "agonizing" over whether to make a ticket or an ML post about the MSC volatile state issue, I was all out of creativity for issue titles. perfectionism! it's a curse. And now.. here I am wasting productive time writing to the ML.. argghhh. :) k/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Fri Oct 12 10:43:19 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Oct 2018 12:43:19 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <74067f7c-899a-70d6-801d-8d8ca8399915@rhizomatica.org> References: <20181012065503.GI9979@nataraja> <74067f7c-899a-70d6-801d-8d8ca8399915@rhizomatica.org> Message-ID: <20181012104319.GS9979@nataraja> Hi Keith, On Fri, Oct 12, 2018 at 12:10:25PM +0200, Keith wrote: > Currently with osmo-nitb, upgrade involves a temporary (some seconds) > loss of BCCH that some phones do not even appear to react to at all. > (I have a script that waits for 0 calls before restarting) > > With the split setup it involves a complete loss of service, basically, > as you say, until location update timeout. ah, that's because OsmoNITB stores the location area in the database, which is "wrong" as per GSM spec, as the VLR information is specified/defined as volatile, and only the HLR information is persistent. > > Holger and I > > were brainstorming about this some time ago, and we came up with the idea > > of using a System V shared memory segment for the actual VLR data. > > From reading what you wrote and the subsequent discussion it sounds > feasible but complicated. I'm not saying it neccessarily is. There are just some considerations that need to be taken. Also, it wouldn't help for power outages. Our ideas were mostly related to recovery from crashes, where the hardware and OS keeps running and we just want to keep state persistent in RAM for the fraction of a second between crash and respawn. Using something like LMDB would allow for both options: 1) run it on a tmpfs and get only in-RAM persistence as long as the system runs 2) run it on a SDD/HDD and get persistence across reboots However, LMDB will have blocking writes/flushes of pages on write access such as location updates, which will impact performance. However, I would guess/hope those would be insignificant when you run it on a tmpfs. So for large deployments where you care about performance, tmpfs. For small deployments where you care about power outages for a few subscribers: sdd/flash based. > Would there be some way to have the MSC be able to restore it's VLR > state on startup from the HLR, or is that going to potentially cause too > much traffic on the GSUP i/f, or be just too far away from spec? It's not within spec, and the HLR doesn't know the location area in which a MS was camped. It should know/store the VLR address (global title in real networks) where the last LU was received. > > The alternative is to wait for any location update, either due to the > > periodic location update timer expirign, or due to the phones actually > > moving geographic location. > > Moving in our case is probably not going to happen, and waiting for the > LUR timeout.. well it's possible of course. You could just increment the LAC of the cell[s] every time the MSC is disconnected/unavailable. Or in case of a "NITB style" setup, basically at every system boot. That would force all phones to perform a location update, which populates the VLR. This will of course trigger a huge load spike at that time, but that should be manageable, particularly with the load mitigation mechanisms we have put in place such as ACC ramping, power ramping, ... > And Yes, of course, there should be UPS and all!!? But you know.. > batteries wear out, stuff stops working and doesn't get replaced.. it's > all extra cost :(( I think it boils down to what kind of computer is used. Small, low-power embedded systems (think of beaglebone, raspi, ...) can easily bridge outages of way ore than 5 minutes of power loss from small Li-Ion batteries. Of course you don't want a traditional UPS with AC inverters, lead-acid batteries, and keep all the equipment powered (including BTSs). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From neels at hofmeyr.de Tue Oct 9 03:29:18 2018 From: neels at hofmeyr.de (Neels Hofmeyr) Date: Tue, 9 Oct 2018 05:29:18 +0200 Subject: IuUP, aka voice between 2G and 3G Message-ID: <20181009032918.GA10517@dub> Thinking ahead to the 35C3, I have tinkered with IuUP a bit. I'm at the point where I have an IuUP FSM which auto-detects IuUP peers and removes IuUP headers coming from a 3G RNC, and inserts IuUP headers in RTP going to a 3G RNC. So far we were merely hacking over the IuUP header to mimick an Initialization ACK, and were otherwise just handing the IuUP headers through from one 3G peer to the other. I realized now that hacking up an Initialization ACK like we currently do on osmo-mgw master produces a header CRC error, which the femto cells we currently tested completely don't care about, thankfully. Ok, so now I am de/encapsulating the IuUP from/to RTP, so that IuUP is present only on the last leg to/from an RNC. 3G to 3G calls still work well with that, now also having correct IuUP header CRCs. And, the naive idea was that now the 2G would simply understand the RTP from the 3G and vice versa. But that's not the case, apparently. The phones at best crackle some random artifacts. I picked a codec-list of fr3 hr3 in osmo-bsc, and tried a few AMR rates (12.2k, 5.9k, 5.2k). So I think there's still some fundamental concept that I'm lacking. Is there anyone more familiar with AMR and/or the way 3G encodes audio, and whether there's a simple way to make them match? Where should I read on? Would a call router like we use in the C3 POC be able to transcode when the IuUP is stripped? (I'm not even sure what the POC side is doing to connect SIP with GSM.) Various pcaps of the status quo are here: http://kleinekatze.de/eeD0ouCo/ My IuUP branch: osmo-mgw neels/iuup http://git.osmocom.org/osmo-mgw/log/?h=neels/iuup IuUP protocol spec: 3GPP TS 25.415 (I've so far ignored most of it) ~N From andrew.voce at gmail.com Thu Oct 11 18:54:41 2018 From: andrew.voce at gmail.com (Andrew Voce) Date: Thu, 11 Oct 2018 14:54:41 -0400 Subject: BS-11 Firmware Message-ID: Hi, I'm wondering where I can source the Siemens BS11 firmware. It looks like OpenBSC is not providing any firmware images. # bs11_config -p /dev/ttyUSB0 bs11_config (C) 2009-2010 by Harald Welte and Dieter Spaar This is FREE SOFTWARE with ABSOLUTELY NO WARRANTY LMT LOGON: ACK PHASE: 1 Software required Abis-link: Down No valid Safety Load file "BTSBMC76.SWI" Thanks, Andrew From laforge at gnumonks.org Fri Oct 12 11:42:16 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Oct 2018 13:42:16 +0200 Subject: BS-11 Firmware In-Reply-To: References: Message-ID: <20181012114216.GT9979@nataraja> Hi Andrew, On Thu, Oct 11, 2018 at 02:54:41PM -0400, Andrew Voce wrote: > I'm wondering where I can source the Siemens BS11 firmware. I wonder where you got a BS-11 [in 2018] without firmware installed :P > It looks like OpenBSC is not providing any firmware images. How could we? The firmware is a copyrighted work and property of Siemens and/or third parties. To my knowledge, it was made available only under NDA. Even without NDA, distributing it is copyright infringement. It sucks, but that's unfortunately the situation :( Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From rafael at rhizomatica.org Fri Oct 12 13:00:14 2018 From: rafael at rhizomatica.org (Rafael Diniz) Date: Fri, 12 Oct 2018 10:00:14 -0300 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <20181012065503.GI9979@nataraja> References: <20181012065503.GI9979@nataraja> Message-ID: Hi all, > I've done some research on the web at that time (maybe 2 years ago) but > unfortunately couldn't find any library/tool/infrastructure for having > persistent data in SysV SHM, and also no other FOSS programs that did > so. Maybe I didn't look closely enough? To me, it seems like the most > obvious solution to persist state across crashes/restarts of C programs > on unix-type systems. > > We explicitly don't want to use some kind of database system, as the VLR > data needs to be accessed all over the code > directly/synchronously/non-blockingly. We cannot wait for it to be > retrieved from somewhere. That's what is done with HLR data. May be I'm missing something, but SysV SHM provides system calls you certainly can create a shared memory segment that is persistent. You just create / get the reference to a memory segment with shmget, then having the shmid of the segment, it can be shmat'ed as many times you want, attaching the memory segment to the address space of a process. You can do queries, using the ipc* tools - ipcmk, ipcs, ipcrm - in the shell. I already did this many times to load the state of entire the data segment of a process. Regards, Rafael Diniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Fri Oct 12 13:28:01 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Oct 2018 15:28:01 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: References: <20181012065503.GI9979@nataraja> Message-ID: <20181012132801.GW9979@nataraja> Hi Rafael, On Fri, Oct 12, 2018 at 10:00:14AM -0300, Rafael Diniz wrote: > Hi all, > > > I've done some research on the web at that time (maybe 2 years ago) but > > unfortunately couldn't find any library/tool/infrastructure for having > > persistent data in SysV SHM, and also no other FOSS programs that did > > so. Maybe I didn't look closely enough? To me, it seems like the most > > obvious solution to persist state across crashes/restarts of C programs > > on unix-type systems. > > > > We explicitly don't want to use some kind of database system, as the VLR > > data needs to be accessed all over the code > > directly/synchronously/non-blockingly. We cannot wait for it to be > > retrieved from somewhere. That's what is done with HLR data. > > May be I'm missing something, but SysV SHM provides system calls you > certainly can create a shared memory segment that is persistent. yes, that is what I'm saying and why we have been brainstorming about this approach at all. That's what I've been talking about in the first paragraph you quoted, and what we've been pondering to do. The second paragraph is about embedded or external databases which we don't want to use, and whihc are not useful within the current osmocom architecture. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From m.ordean at cs.bham.ac.uk Fri Oct 12 15:35:04 2018 From: m.ordean at cs.bham.ac.uk (Mihai Ordean) Date: Fri, 12 Oct 2018 16:35:04 +0100 Subject: help need with the silent_call function in OsmoMSC/BSC Message-ID: <9cf0da62-bf2b-bc22-41b6-d4ac78957469@cs.bham.ac.uk> Hey, I am trying to set up test bench for base-band fuzzing using the Osmocom stack and a couple of SDRs (b210 and bladerf). I have managed to setup everything to my liking in terms of a functional network using the tutorial (https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box) and the latest stable packages from https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds Now I want to enable the silent_call functionality to begin testing but I can't seem able to do so. I have reverted the silent_call patch (https://gerrit.osmocom.org/#/c/openbsc/+/1930/) for OpenBSC inside the "new" OsmoMSC but unfortunately that did not work. I have then started trying to figure out how the silent_call interacts with the rest of the state machine, but I don't seem to be making much progress. Please see attached a log for the communication between OsmoMSC (which triggers silent_call) and OsmoBSC. The connection seems to fail due to issues related to either "Congestion" (if GPRS is enabled) or a timeout of T0 (if GPRS is disabled). Can anyone help? Thanks -- Mihai -------------- next part -------------- Oct 12 16:29:58 cca-132016 osmo-bsc[16394]: DHODEC <0009> handover_decision_2.c:1632 (BTS 0) No congestion check: no minimum for free TCH/F nor TCH/H set Oct 12 16:29:58 cca-132016 osmo-bsc[16394]: DHODEC <0009> handover_decision_2.c:138 HO algorithm 2: next periodical congestion check in 10 seconds Oct 12 16:29:58 cca-132016 osmo-bsc[16394]: BTS 0 reported connected PCU version 0.5.1 Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLGSUP <001b> gsup_client.c:242 GSUP ping callback (connected, got PONG) Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLGSUP <001b> gsup_client.c:262 GSUP sending PING Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:142 127.0.0.1:4222 connected write Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:92 127.0.0.1:4222 sending data Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:142 127.0.0.1:4222 connected write Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:92 127.0.0.1:4222 sending data Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:138 127.0.0.1:4222 connected read Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:56 127.0.0.1:4222 message received Oct 12 16:29:58 cca-132016 osmo-msc[16399]: DLGSUP <001b> gsup_client.c:199 GSUP receiving PONG Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DMM <0002> gsm_subscriber.c:158 Subscriber MSISDN:4090 not paged yet, start paging. Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface.c:216 Tx BSSMAP paging message from MSC RI=SSN_PC,PC=0.23.1,SSN=BSSAP to BSC RI=SSN_PC,PC=0.23.1,SSN=BSSAP (imsi=001010000024090, tmsi=0x23d988ea, lac=23) Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1615 Received SCCP User Primitive N-UNITDATA.request) Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSS7 <001d> sccp_scrc.c:420 sccp_scrc_rx_sclc_msg: HDR=(CL:CLDT,V=0,LEN=0), Oct 12 16:30:02 cca-132016 osmo-msc[16399]: PART(T=Routing Context,L=4,D=00000000), Oct 12 16:30:02 cca-132016 osmo-msc[16399]: PART(T=Protocol Class,L=4,D=00000000), Oct 12 16:30:02 cca-132016 osmo-msc[16399]: PART(T=Source Address,L=20,D=0002000380020008000000b980030008000000fe), Oct 12 16:30:02 cca-132016 osmo-msc[16399]: PART(T=Destination Address,L=20,D=0002000380020008000000bb80030008000000fe), Oct 12 16:30:02 cca-132016 osmo-msc[16399]: PART(T=Sequence Control,L=4,D=00000000), Oct 12 16:30:02 cca-132016 osmo-msc[16399]: PART(T=Data,L=24,D=00165208080910100000200409090423d988ea1a03050017) Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 bb 80 03 00 08 00 00 00 fe Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 bb 80 03 00 08 00 00 00 fe Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=187=0.23.3 not local, message is for routing Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:227 Found route for dpc=187=0.23.3: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A proto=m3ua Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:233 rt->dest.as proto is M3UA for dpc=187=0.23.3 Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLSS7 <001d> m3ua.c:507 XUA_AS(as-clnt-OsmoMSC-A)[0x55f605317960]{AS_ACTIVE}: Received Event AS-TRANSFER.req Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:02 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:275 connected read Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:189 message received Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7.c:1549 asp-asp-clnt-msc-0: xua_cli_read_cb(): sctp_recvmsg() returned 72 (flags=0x80) Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:722 asp-asp-clnt-msc-0: Received M3UA Message (XFER:DATA) Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:541 asp-asp-clnt-msc-0: m3ua_rx_xfer Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:580 asp-asp-clnt-msc-0: m3ua_rx_xfer(): M3UA data header: opc=185=0.23.1 dpc=187=0.23.3 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:274 m3ua_hmdc_rx_from_l2(): found dpc=187=0.23.3 as local Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sccp2sua.c:333 IEI 259: Parsed Addr: RI=2,PC=187,SSN=254 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sccp2sua.c:333 IEI 258: Parsed Addr: RI=2,PC=185,SSN=254 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSS7 <001c> sccp_scrc.c:449 scrc_rx_mtp_xfer_ind_xua: HDR=(CL:CLDT,V=0,LEN=0), Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: PART(T=Protocol Class,L=4,D=00000000), Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: PART(T=Destination Address,L=20,D=0002000380020008000000bb80030008000000fe), Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: PART(T=Source Address,L=20,D=0002000380020008000000b980030008000000fe), Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: PART(T=Data,L=24,D=00165208080910100000200409090423d988ea1a03050017) Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 bb 80 03 00 08 00 00 00 fe Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 bb 80 03 00 08 00 00 00 fe Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:385 sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_user.c:156 Delivering N-UNITDATA.indication to SCCP User 'msc-0' Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:167 N-UNITDATA.ind(00 16 52 08 08 09 10 10 00 00 20 04 09 09 04 23 d9 88 ea 1a 03 05 00 17 ) Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_bssap.c:864 Rx MSC UDT: 00 16 52 08 08 09 10 10 00 00 20 04 09 09 04 23 d9 88 ea 1a 03 05 00 17 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_bssap.c:750 Rx MSC UDT BSSMAP PAGING Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_bssap.c:92 Paging request from MSC BTS: 0 IMSI: '001010000024090' TMSI: '0x23d988ea/601458922' LAC: 0x17 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DPAG <0005> paging.c:310 (bts=0) Start paging of subscriber IMSI:001010000024090 Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:721 (bts=0) channel load average is 0.00% Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:734 (bts=0) T3122 wait indicator set to 10 seconds Oct 12 16:30:02 cca-132016 osmo-bsc[16394]: DPAG <0005> paging.c:88 (bts=0) Going to send paging commands: imsi: 001010000024090 tmsi: 0x23d988ea for ch. type 0 (attempt 0) Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DPAG <0005> paging.c:88 (bts=0) Going to send paging commands: imsi: 001010000024090 tmsi: 0x23d988ea for ch. type 0 (attempt 1) Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: BTS 0 reported connected PCU version 0.5.1 Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DPAG <0005> paging.c:88 (bts=0) Going to send paging commands: imsi: 001010000024090 tmsi: 0x23d988ea for ch. type 0 (attempt 2) Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1877 (bts=0) CHAN RQD: reason: answer to paging (ra=0x91, neci=0x00, chreq_reason=0x01) Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:329 (bts=0) lchan_alloc(SDCCH) Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:271 looking for lchan CCCH+SDCCH4 as CCCH+SDCCH4: (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) ss=0 is available Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:462 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1965 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(128) SS(0) lctype SDCCH r=PAGING ra=0x91 ta=0 Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:582 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:611 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1630 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK Oct 12 16:30:03 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1277 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DPAG <0005> paging.c:88 (bts=0) Going to send paging commands: imsi: 001010000024090 tmsi: 0x23d988ea for ch. type 0 (attempt 3) Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DRLL <0000> abis_rsl.c:2180 (bts=0,trx=0,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> fsm.c:299 SUBSCR_CONN[0x556b9f76ec90]{INIT}: Allocated Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLCLS <000f> fsm.c:299 LCLS[0x556b9f76fbe0]{NO_LCLS}: Allocated Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLCLS <000f> fsm.c:329 LCLS[0x556b9f76fbe0]{NO_LCLS}: is child of SUBSCR_CONN[0x556b9f76ec90] Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_api.c:219 Tx MSC COMPL L3 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DRR <0002> osmo_bsc_filter.c:77 PAGING RESPONSE: MI(TMSI)=601458922 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:250 Initializing resources for new SIGTRAN connection to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP... Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DRR <0002> osmo_bsc_filter.c:77 PAGING RESPONSE: MI(TMSI)=601458922 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DPAG <0005> paging.c:374 (bts=0) Stop paging IMSI:001010000024090 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_api.c:290 SUBSCR_CONN[0x556b9f76ec90]{INIT}: Received Event MO-CONNECT.req Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:292 Allocated new connection id: 3 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:296 Opening new SIGTRAN connection (id=3) to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1615 Received SCCP User Primitive N-CONNECT.request) Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> fsm.c:299 SCCP-SCOC(3)[0x556b9f76eb60]{IDLE}: Allocated Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1657 SCCP-SCOC(3)[0x556b9f76eb60]{IDLE}: Received Event N-CONNECT.req Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CORE,V=0,LEN=0), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Routing Context,L=4,D=00000000), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Protocol Class,L=4,D=00000002), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Source Reference,L=4,D=00000003), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Destination Address,L=20,D=0002000380020008000000b980030008000000fe), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Sequence Control,L=4,D=00000000), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Source Address,L=20,D=0002000380020008000000bb80030008000000fe), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Data,L=28,D=001a5705080032f82000170000170d0627000353189205f423d988ea) Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:385 sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 00 bb 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sua.c:439 SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:227 Found route for dpc=185=0.23.1: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-msc-0 proto=m3ua Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:233 rt->dest.as proto is M3UA for dpc=185=0.23.1 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x556b9f75fce0]{AS_ACTIVE}: Received Event AS-TRANSFER.req Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:732 SCCP-SCOC(3)[0x556b9f76eb60]{IDLE}: state_chg to CONN_PEND_OUT Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:335 SUBSCR_CONN[0x556b9f76ec90]{INIT}: state_chg to WAIT_CC Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:279 connected write Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:204 sending data Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:279 connected write Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:204 sending data Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:275 connected read Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:189 message received Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7.c:1549 asp-asp-clnt-OsmoMSC-A: xua_cli_read_cb(): sctp_recvmsg() returned 84 (flags=0x80) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:722 asp-asp-clnt-OsmoMSC-A: Received M3UA Message (XFER:DATA) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:541 asp-asp-clnt-OsmoMSC-A: m3ua_rx_xfer Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:580 asp-asp-clnt-OsmoMSC-A: m3ua_rx_xfer(): M3UA data header: opc=187=0.23.3 dpc=185=0.23.1 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:274 m3ua_hmdc_rx_from_l2(): found dpc=185=0.23.1 as local Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sccp2sua.c:333 IEI 259: Parsed Addr: RI=2,PC=185,SSN=254 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sccp2sua.c:333 IEI 258: Parsed Addr: RI=2,PC=187,SSN=254 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> sccp_scrc.c:449 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CORE,V=0,LEN=0), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Protocol Class,L=4,D=00000002), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Source Reference,L=4,D=00000003), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Destination Address,L=20,D=0002000380020008000000b980030008000000fe), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Source Address,L=20,D=0002000380020008000000bb80030008000000fe), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Data,L=28,D=001a5705080032f82000170000170d0627000353189205f423d988ea) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> fsm.c:299 SCCP-SCOC(2)[0x55f60531c0f0]{IDLE}: Allocated Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1548 Received CO:CORE for local reference 2 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1581 SCCP-SCOC(2)[0x55f60531c0f0]{IDLE}: Received Event RCOC-CONNECT.ind Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 00 bb 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:775 SCCP-SCOC(2)[0x55f60531c0f0]{IDLE}: state_chg to CONN_PEND_IN Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_user.c:156 Delivering N-CONNECT.indication to SCCP User 'OsmoMSC-A' Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1615 Received SCCP User Primitive N-CONNECT.response) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1657 SCCP-SCOC(2)[0x55f60531c0f0]{CONN_PEND_IN}: Received Event N-CONNECT.resp Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:COAK,V=0,LEN=0), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Routing Context,L=4,D=00000000), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Protocol Class,L=4,D=00000002), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Destination Reference,L=4,D=00000003), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Source Reference,L=4,D=00000002), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Sequence Control,L=4,D=00000000), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Source Address,L=20,D=0002000380020008000000b980030008000000fe), Oct 12 16:30:04 cca-132016 osmo-msc[16399]: PART(T=Destination Address,L=20,D=0002000380020008000000bb80030008000000fe) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 00 bb 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:385 sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 00 b9 80 03 00 08 00 00 00 fe Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSUA <001f> sua.c:439 SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=187=0.23.3 not local, message is for routing Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:227 Found route for dpc=187=0.23.3: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A proto=m3ua Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:233 rt->dest.as proto is M3UA for dpc=187=0.23.3 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSS7 <001d> m3ua.c:507 XUA_AS(as-clnt-OsmoMSC-A)[0x55f605317960]{AS_ACTIVE}: Received Event AS-TRANSFER.req Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:802 SCCP-SCOC(2)[0x55f60531c0f0]{CONN_PEND_IN}: state_chg to ACTIVE Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface.c:535 N-CONNECT.ind(2, 00 1a 57 05 08 00 32 f8 20 00 17 00 00 17 0d 06 27 00 03 53 18 92 05 f4 23 d9 88 ea ) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface_bssap.c:268 Rx BSSMAP COMPLETE L3 INFO (conn_id=2) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMSC <0006> a_iface_bssap.c:55 Allocating A-Interface subscriber conn: lac 23, conn_id 2 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMM <0002> fsm.c:299 Subscr_Conn[0x55f60531c2c0]{SUBSCR_CONN_S_NEW}: Allocated Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface_bssap.c:68 (subscr unknown, conn_id 2) A-Interface subscriber connection successfully allocated! Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DRLL <0000> gsm_04_08.c:3481 Dispatching 04.08 message GSM48_MT_RR_PAG_RESP (0x6:0x27) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DRR <0003> gsm_04_08.c:1184 PAGING RESPONSE: MI(TMSI)=601458922 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:587 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_NEW}: Updated ID Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:275 connected read Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:189 message received Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7.c:1549 asp-asp-clnt-msc-0: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:722 asp-asp-clnt-msc-0: Received M3UA Message (XFER:DATA) Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:541 asp-asp-clnt-msc-0: m3ua_rx_xfer Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:580 asp-asp-clnt-msc-0: m3ua_rx_xfer(): M3UA data header: opc=185=0.23.1 dpc=187=0.23.3 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:274 m3ua_hmdc_rx_from_l2(): found dpc=187=0.23.3 as local Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSUA <001e> sccp2sua.c:333 IEI 259: Parsed Addr: RI=2,PC=185,SSN=254 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSS7 <001c> sccp_scrc.c:449 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:COAK,V=0,LEN=0), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Protocol Class,L=4,D=00000002), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Destination Reference,L=4,D=00000003), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Source Reference,L=4,D=00000002), Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: PART(T=Destination Address,L=20,D=0002000380020008000000b980030008000000fe) Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1548 Received CO:COAK for local reference 3 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1581 SCCP-SCOC(3)[0x556b9f76eb60]{CONN_PEND_OUT}: Received Event RCOC-CONNECT_CONFIRM.ind Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:883 SCCP-SCOC(3)[0x556b9f76eb60]{CONN_PEND_OUT}: state_chg to ACTIVE Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_user.c:156 Delivering N-CONNECT.confirm to SCCP User 'msc-0' Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:186 N-CONNECT.cnf(3, ) Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:189 SUBSCR_CONN[0x556b9f76ec90]{WAIT_CC}: Received Event MO-CONNECT.cfm Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:368 SUBSCR_CONN[0x556b9f76ec90]{WAIT_CC}: state_chg to ACTIVE Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> fsm.c:299 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: Allocated Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> fsm.c:329 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: is child of Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0] Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:669 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: rev=R99 net=GERAN (no Auth) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:694 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:328 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi() Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:280 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: _proc_arq_vlr_node2() Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:246 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: _proc_arq_vlr_node2_post_ciph() Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:218 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: _proc_arq_vlr_node2_post_vlr() Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:203 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: _proc_arq_vlr_post_pres() Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:187 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: _proc_arq_vlr_post_trace() Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:165 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: _proc_arq_vlr_post_imei() Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:178 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: proc_arq_fsm_done(PASSED) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:101 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_DONE Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DVLR <000e> vlr_access_req_fsm.c:110 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_DONE}: Process Access Request result: PASSED Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMM <0002> vlr_access_req_fsm.c:149 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_NEW}: Received Event SUBSCR_CONN_E_ACCEPTED Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DPAG <0005> gsm_subscriber.c:73 Paging success for MSISDN:4090 (event=0) Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DPAG <0005> osmo_msc.c:338 Paging can stop for MSISDN:4090 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DPAG <0005> gsm_subscriber.c:100 Calling paging cbfn. Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLSMS <0017> silent_call.c:46 paging_cb_silent: DMM <0002> subscr_conn.c:122 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_NEW}: state_chg to SUBSCR_CONN_S_ACCEPTED Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:172 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_ACCEPTED}: subscr_conn_fsm_has_active_transactions: silent call still active Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:450 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_ACCEPTED}: Received Event SUBSCR_CONN_E_COMPLETE_LAYER_3 Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:450 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_ACCEPTED}: Event SUBSCR_CONN_E_COMPLETE_LAYER_3 not permitted Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DMSC <0006> a_iface_bssap.c:351 User has been accepted by MSC. Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:04 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=1 meas_rep_last_seen_nr=0 Oct 12 16:30:04 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=2 meas_rep_last_seen_nr=1 Oct 12 16:30:05 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=3 meas_rep_last_seen_nr=2 Oct 12 16:30:05 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=4 meas_rep_last_seen_nr=3 Oct 12 16:30:06 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=5 meas_rep_last_seen_nr=4 Oct 12 16:30:06 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=6 meas_rep_last_seen_nr=5 Oct 12 16:30:07 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=7 meas_rep_last_seen_nr=6 Oct 12 16:30:07 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=8 meas_rep_last_seen_nr=7 Oct 12 16:30:08 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=9 meas_rep_last_seen_nr=8 Oct 12 16:30:08 cca-132016 osmo-bsc[16394]: DHODEC <0009> handover_decision_2.c:1632 (BTS 0) No congestion check: no minimum for free TCH/F nor TCH/H set Oct 12 16:30:08 cca-132016 osmo-bsc[16394]: DHODEC <0009> handover_decision_2.c:138 HO algorithm 2: next periodical congestion check in 10 seconds Oct 12 16:30:08 cca-132016 osmo-bsc[16394]: BTS 0 reported connected PCU version 0.5.1 Oct 12 16:30:08 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1528 (bts=0,trx=0,ts=0,ss=0): meas_rep_count++=10 meas_rep_last_seen_nr=9 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DMM <0002> fsm.c:189 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_ACCEPTED}: Timeout of T0 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:257 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_ACCEPTED}: Received Event SUBSCR_CONN_E_CN_CLOSE Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:110 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_ACCEPTED}: Close event, cause: CONGESTION Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:221 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_ACCEPTED}: state_chg to SUBSCR_CONN_S_RELEASING Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface.c:419 (subscr MSISDN:4090, conn_id 2) Tx BSSMAP CLEAR COMMAND to BSC Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1615 Received SCCP User Primitive N-DATA.request) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1657 SCCP-SCOC(2)[0x55f60531c0f0]{ACTIVE}: Received Event N-DATA.req Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CODT,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Routing Context,L=4,D=00000000), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Destination Reference,L=4,D=00000003), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Data,L=6,D=000420040109) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=187=0.23.3 not local, message is for routing Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:227 Found route for dpc=187=0.23.3: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A proto=m3ua Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:233 rt->dest.as proto is M3UA for dpc=187=0.23.3 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> m3ua.c:507 XUA_AS(as-clnt-OsmoMSC-A)[0x55f605317960]{AS_ACTIVE}: Received Event AS-TRANSFER.req Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:275 connected read Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:189 message received Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7.c:1549 asp-asp-clnt-msc-0: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:722 asp-asp-clnt-msc-0: Received M3UA Message (XFER:DATA) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:541 asp-asp-clnt-msc-0: m3ua_rx_xfer Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:580 asp-asp-clnt-msc-0: m3ua_rx_xfer(): M3UA data header: opc=185=0.23.1 dpc=187=0.23.3 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:274 m3ua_hmdc_rx_from_l2(): found dpc=187=0.23.3 as local Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> sccp_scrc.c:449 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CODT,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Destination Reference,L=4,D=00000003), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Segmentation,L=4,D=00000000), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Data,L=6,D=000420040109) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1548 Received CO:CODT for local reference 3 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1581 SCCP-SCOC(3)[0x556b9f76eb60]{ACTIVE}: Received Event RCOC-DT1.ind Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_user.c:156 Delivering N-DATA.indication to SCCP User 'msc-0' Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:203 N-DATA.ind(3, 00 04 20 04 01 09 ) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> a_reset.c:190 A-RESET(msc-0)[0x556b9f760a80]{CONN}: Received Event EV_N_CONNECT Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_bssap.c:782 Rx MSC DT1 BSSMAP CLEAR COMMAND Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_bssap.c:786 SUBSCR_CONN[0x556b9f76ec90]{ACTIVE}: Received Event CLEAR_CMD Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:966 SUBSCR_CONN[0x556b9f76ec90]{ACTIVE}: state_chg to CLEARING Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:596 (bts=0,trx=0,ts=0,ss=0) starting release sequence Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DRSL <0003> chan_alloc.c:597 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE REQUESTED Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DRR <0002> gsm_04_08_utils.c:250 Sending Channel Release: Chan: Number: 0 Type: 1 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:769 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:295 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: tossing all MGCP connections... Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:978 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: Received Event RSL_CLEAR_COMPLETE Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:325 Tx MSC CLEAR COMPLETE Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:275 connected read Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:189 message received Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7.c:1549 asp-asp-clnt-OsmoMSC-A: xua_cli_read_cb(): sctp_recvmsg() returned 44 (flags=0x80) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:722 asp-asp-clnt-OsmoMSC-A: Received M3UA Message (XFER:DATA) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:541 asp-asp-clnt-OsmoMSC-A: m3ua_rx_xfer Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:580 asp-asp-clnt-OsmoMSC-A: m3ua_rx_xfer(): M3UA data header: opc=187=0.23.3 dpc=185=0.23.1 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:274 m3ua_hmdc_rx_from_l2(): found dpc=185=0.23.1 as local Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> sccp_scrc.c:449 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CODT,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Destination Reference,L=4,D=00000002), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Segmentation,L=4,D=00000000), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Data,L=3,D=000121) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1548 Received CO:CODT for local reference 2 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1581 SCCP-SCOC(2)[0x55f60531c0f0]{ACTIVE}: Received Event RCOC-DT1.ind Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_user.c:156 Delivering N-DATA.indication to SCCP User 'OsmoMSC-A' Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface.c:564 N-DATA.ind(2, 00 01 21 ) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DMSC <0006> a_iface_bssap.c:80 Looking for A subscriber: conn_id 2 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface_bssap.c:88 (subscr MSISDN:4090, conn_id 2) Found A subscriber for conn_id 2 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface_bssap.c:587 (subscr MSISDN:4090, conn_id 2) Rx BSSMAP DT1 CLEAR COMPLETE Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface_bssap.c:241 (subscr MSISDN:4090, conn_id 2) Rx BSSMAP CLEAR COMPLETE, releasing SCCP connection Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1615 Received SCCP User Primitive N-DISCONNECT.request) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1657 SCCP-SCOC(2)[0x55f60531c0f0]{ACTIVE}: Received Event N-DISCONNECT.req Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:RELRE,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Routing Context,L=4,D=00000000), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:346 Sending connection (id=3) oriented data to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP (00 01 21 ) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1615 Received SCCP User Primitive N-DATA.request) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1657 SCCP-SCOC(3)[0x556b9f76eb60]{ACTIVE}: Received Event N-DATA.req Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CODT,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Routing Context,L=4,D=00000000), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Destination Reference,L=4,D=00000002), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Data,L=3,D=000121) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:227 Found route for dpc=185=0.23.1: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-msc-0 proto=m3ua Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:233 rt->dest.as proto is M3UA for dpc=185=0.23.1 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x556b9f75fce0]{AS_ACTIVE}: Received Event AS-TRANSFER.req Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:275 connected read Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:189 message received Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7.c:1549 asp-asp-clnt-msc-0: xua_cli_read_cb(): sctp_recvmsg() returned 44 (flags=0x80) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:722 asp-asp-clnt-msc-0: Received M3UA Message (XFER:DATA) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:541 asp-asp-clnt-msc-0: m3ua_rx_xfer Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLM3UA <001f> m3ua.c:580 asp-asp-clnt-msc-0: m3ua_rx_xfer(): M3UA data header: opc=185=0.23.1 dpc=187=0.23.3 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:274 m3ua_hmdc_rx_from_l2(): found dpc=187=0.23.3 as local Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> sccp_scrc.c:449 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:RELRE,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Destination Reference,L=4,D=00000003), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Source Reference,L=4,D=00000002), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Cause,L=4,D=00000300) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1548 Received CO:RELRE for local reference 3 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:1581 SCCP-SCOC(3)[0x556b9f76eb60]{ACTIVE}: Received Event RCOC-RELEASED.ind Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Destination Reference,L=4,D=00000003), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Source Reference,L=4,D=00000002), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Cause,L=4,D=00000300) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=187=0.23.3 not local, message is for routing Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:227 Found route for dpc=187=0.23.3: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A proto=m3ua Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:233 rt->dest.as proto is M3UA for dpc=187=0.23.3 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> m3ua.c:507 XUA_AS(as-clnt-OsmoMSC-A)[0x55f605317960]{AS_ACTIVE}: Received Event AS-TRANSFER.req Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:956 SCCP-SCOC(2)[0x55f60531c0f0]{ACTIVE}: state_chg to DISCONN_PEND Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DBSSAP <0010> a_iface.c:90 (conn_id 2) Removing A-interface conn Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:275 connected read Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLINP <0013> stream.c:189 message received Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7.c:1549 asp-asp-clnt-OsmoMSC-A: xua_cli_read_cb(): sctp_recvmsg() returned 40 (flags=0x80) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:722 asp-asp-clnt-OsmoMSC-A: Received M3UA Message (XFER:DATA) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:541 asp-asp-clnt-OsmoMSC-A: m3ua_rx_xfer Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLM3UA <0020> m3ua.c:580 asp-asp-clnt-OsmoMSC-A: m3ua_rx_xfer(): M3UA data header: opc=187=0.23.3 dpc=185=0.23.1 Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> osmo_ss7_hmrt.c:274 m3ua_hmdc_rx_from_l2(): found dpc=185=0.23.1 as local Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSS7 <001d> sccp_scrc.c:449 scrc_rx_mtp_xfer_ind_xua: HDR=(CO:RELCO,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Destination Reference,L=4,D=00000002), Oct 12 16:30:09 cca-132016 osmo-msc[16399]: PART(T=Source Reference,L=4,D=00000003) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1548 Received CO:RELCO for local reference 2 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_user.c:156 Delivering N-DISCONNECT.indication to SCCP User 'msc-0' Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:216 N-DISCONNECT.ind(3, , cause=768) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> osmo_bsc_sigtran.c:223 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: Received Event DISCONNET.ind Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:983 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: Terminating (cause = OSMO_FSM_TERM_REGULAR) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:295 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: tossing all MGCP connections... Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLCLS <000f> bsc_subscr_conn_fsm.c:1064 LCLS[0x556b9f76fbe0]{NO_LCLS}: Terminating (cause = OSMO_FSM_TERM_REGULAR) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLCLS <000f> bsc_subscr_conn_fsm.c:1064 LCLS[0x556b9f76fbe0]{NO_LCLS}: Removing from parent SUBSCR_CONN[0x556b9f76ec90] Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLCLS <000f> bsc_subscr_conn_fsm.c:1064 LCLS[0x556b9f76fbe0]{NO_LCLS}: Freeing instance Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLCLS <000f> fsm.c:381 LCLS[0x556b9f76fbe0]{NO_LCLS}: Deallocated Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:1064 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: Received Event LCLS_FAIL Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:1045 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: Putting bsc_subscr Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> bsc_subscr_conn_fsm.c:983 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: Freeing instance Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DMSC <0007> fsm.c:381 SUBSCR_CONN[0x556b9f76ec90]{CLEARING}: Deallocated Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> sccp_scrc.c:398 sccp_scrc_rx_scoc_conn_msg: HDR=(CO:RELCO,V=0,LEN=0), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Routing Context,L=4,D=00000000), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Destination Reference,L=4,D=00000002), Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: PART(T=Source Reference,L=4,D=00000003) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:227 Found route for dpc=185=0.23.1: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-msc-0 proto=m3ua Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> osmo_ss7_hmrt.c:233 rt->dest.as proto is M3UA for dpc=185=0.23.1 Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSS7 <001c> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x556b9f75fce0]{AS_ACTIVE}: Received Event AS-TRANSFER.req Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:972 SCCP-SCOC(3)[0x556b9f76eb60]{ACTIVE}: state_chg to IDLE Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1581 SCCP-SCOC(2)[0x55f60531c0f0]{DISCONN_PEND}: Received Event RCOC-RELEASE_COMPLETE.ind Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:1060 SCCP-SCOC(2)[0x55f60531c0f0]{DISCONN_PEND}: state_chg to IDLE Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:420 SCCP-SCOC(2)[0x55f60531c0f0]{IDLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST) Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> sccp_scoc.c:420 SCCP-SCOC(2)[0x55f60531c0f0]{IDLE}: Freeing instance Oct 12 16:30:09 cca-132016 osmo-msc[16399]: DLSCCP <001e> fsm.c:381 SCCP-SCOC(2)[0x55f60531c0f0]{IDLE}: Deallocated Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:420 SCCP-SCOC(3)[0x556b9f76eb60]{IDLE}: Terminating (cause = OSMO_FSM_TERM_REQUEST) Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> sccp_scoc.c:420 SCCP-SCOC(3)[0x556b9f76eb60]{IDLE}: Freeing instance Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLSCCP <001d> fsm.c:381 SCCP-SCOC(3)[0x556b9f76eb60]{IDLE}: Deallocated Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:279 connected write Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DLINP <0012> stream.c:204 sending data Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1462 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel Oct 12 16:30:09 cca-132016 osmo-bsc[16394]: DRLL <0000> abis_rsl.c:2180 (bts=0,trx=0,ts=0,ss=0) SAPI=0 RELEASE INDICATION Oct 12 16:30:10 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:721 (bts=0) channel load average is 7.00% Oct 12 16:30:10 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:734 (bts=0) T3122 wait indicator set to 10 seconds Oct 12 16:30:11 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:1764 (bts=0,trx=0,ts=0,ss=0) T3111 expired: releasing RF Channel Oct 12 16:30:11 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:861 (bts=0,trx=0,ts=0,ss=0) RF Channel Release Oct 12 16:30:11 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:931 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK Oct 12 16:30:11 cca-132016 osmo-bsc[16394]: DRSL <0003> abis_rsl.c:82 (bts=0,trx=0,ts=0,ss=0) state RELEASE REQUESTED -> NONE Oct 12 16:30:13 cca-132016 osmo-bsc[16394]: BTS 0 reported connected PCU version 0.5.1 Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DMM <0002> fsm.c:189 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_RELEASING}: Timeout of T0 Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:253 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_RELEASING}: Timeout while releasing, discarding right now Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:254 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_RELEASING}: Terminating (cause = OSMO_FSM_TERM_TIMEOUT) Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DVLR <000e> subscr_conn.c:254 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT) Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DVLR <000e> subscr_conn.c:254 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_DONE}: Removing from parent Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0] Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DVLR <000e> subscr_conn.c:254 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_DONE}: Freeing instance Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DVLR <000e> fsm.c:381 Process_Access_Request_VLR(PAGING_RESP:601458922)[0x55f60531dc20]{PR_ARQ_S_DONE}: Deallocated Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:172 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_RELEASING}: subscr_conn_fsm_has_active_transactions: silent call still active Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:426 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_RELEASING}: Deallocating despite active transactions Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DRLL <0000> subscr_conn.c:434 MSISDN:4090: Freeing subscriber connection Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DMM <0002> subscr_conn.c:254 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_RELEASING}: Freeing instance Oct 12 16:30:14 cca-132016 osmo-msc[16399]: DMM <0002> fsm.c:381 Subscr_Conn(PAGING_RESP:601458922)[0x55f60531c2c0]{SUBSCR_CONN_S_RELEASING}: Deallocated Oct 12 16:30:18 cca-132016 osmo-bsc[16394]: DHODEC <0009> handover_decision_2.c:1632 (BTS 0) No congestion check: no minimum for free TCH/F nor TCH/H set Oct 12 16:30:18 cca-132016 osmo-bsc[16394]: DHODEC <0009> handover_decision_2.c:138 HO algorithm 2: next periodical congestion check in 10 seconds Oct 12 16:30:18 cca-132016 osmo-bsc[16394]: BTS 0 reported connected PCU version 0.5.1 Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLGSUP <001b> gsup_client.c:242 GSUP ping callback (connected, got PONG) Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLGSUP <001b> gsup_client.c:262 GSUP sending PING Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:142 127.0.0.1:4222 connected write Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:92 127.0.0.1:4222 sending data Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:142 127.0.0.1:4222 connected write Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:92 127.0.0.1:4222 sending data Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:138 127.0.0.1:4222 connected read Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLINP <0013> input/ipa.c:56 127.0.0.1:4222 message received Oct 12 16:30:18 cca-132016 osmo-msc[16399]: DLGSUP <001b> gsup_client.c:199 GSUP receiving PONG Oct 12 16:30:18 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:721 (bts=0) channel load average is 0.20% Oct 12 16:30:18 cca-132016 osmo-bsc[16394]: DRLL <0000> chan_alloc.c:734 (bts=0) T3122 wait indicator set to 10 seconds -------------- next part -------------- A non-text attachment was scrubbed... Name: m_ordean.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: From holger at freyther.de Sat Oct 13 17:44:22 2018 From: holger at freyther.de (Holger Freyther) Date: Sat, 13 Oct 2018 18:44:22 +0100 Subject: BSC / MSC volatile state / restart handling In-Reply-To: References: Message-ID: <0A516E54-7734-4F81-8C7F-926F83FF2919@freyther.de> > On 11. Oct 2018, at 20:59, Keith wrote: > > Hi All. Hi! > This is very brief, but something that's been on my mind to make a > ticket about. > > I realise maybe it's better to ask first if there is a plan. no plans but just some other generic approaches... If we ignore "crashes" and think of managed restarts then one can... * Have a BTS to connect to one of the BSCs * Have a BSC to connect to one of the MSCs * When wanting to update to block BSC/MSC from taking new connections * Restart if drained or impatient... ;) The next iteration comes with separating state from a TCP connection between BSC and MSC. * Segment id's between two MSCs (upsizing would be difficult but our software should scale to some degree). * Have a level of indirection that routes SCCP connections to A or B * Have a config to drain A, B (or both...) I think these are easier to implement than fully externalizing the state (or more advanced state transfer topics. I do like how minix3 is updating a server though). From rafael at rhizomatica.org Sat Oct 13 19:11:03 2018 From: rafael at rhizomatica.org (Rafael Diniz) Date: Sat, 13 Oct 2018 16:11:03 -0300 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <20181012132801.GW9979@nataraja> References: <20181012065503.GI9979@nataraja> <20181012132801.GW9979@nataraja> Message-ID: <6fba050e-3e39-fcab-9652-0b48da63ca51@rhizomatica.org> Hi Harald, Thanks for clarifying, and sorry about myself missing some parts of the whole thread. But if there is nothing yet implemented, I could do a proof of concept. I wrote a system for a company in the past for a DTV ISDB-T encoder which was multi-processes which used shared memory and locks (residing inside the shared segment) for access to it. We can talk in person next week. Rafael On 10/12/2018 10:28 AM, Harald Welte wrote: > Hi Rafael, > > > On Fri, Oct 12, 2018 at 10:00:14AM -0300, Rafael Diniz wrote: >> Hi all, >> >>> I've done some research on the web at that time (maybe 2 years ago) but >>> unfortunately couldn't find any library/tool/infrastructure for having >>> persistent data in SysV SHM, and also no other FOSS programs that did >>> so. Maybe I didn't look closely enough? To me, it seems like the most >>> obvious solution to persist state across crashes/restarts of C programs >>> on unix-type systems. >>> >>> We explicitly don't want to use some kind of database system, as the VLR >>> data needs to be accessed all over the code >>> directly/synchronously/non-blockingly. We cannot wait for it to be >>> retrieved from somewhere. That's what is done with HLR data. >> >> May be I'm missing something, but SysV SHM provides system calls you >> certainly can create a shared memory segment that is persistent. > > yes, that is what I'm saying and why we have been brainstorming about > this approach at all. That's what I've been talking about in the first > paragraph you quoted, and what we've been pondering to do. > > The second paragraph is about embedded or external databases which we > don't want to use, and whihc are not useful within the current osmocom > architecture. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rafael at riseup.net Sat Oct 13 17:57:40 2018 From: rafael at riseup.net (Rafael Diniz) Date: Sat, 13 Oct 2018 14:57:40 -0300 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <20181012132801.GW9979@nataraja> References: <20181012065503.GI9979@nataraja> <20181012132801.GW9979@nataraja> Message-ID: <87d93629-75fb-5140-d972-b0d48bcc15eb@riseup.net> Hi Harald, Thanks for clarifying, and sorry about myself missing some parts of the whole thread. But if there is nothing yet implemented, I could do a proof of concept. I wrote a system for a company in the past for a DTV ISDB-T encoder which was multi-processes which used shared memory and locks (residing inside the shared segment) for access to it. We can talk in person next week. Rafael On 10/12/2018 10:28 AM, Harald Welte wrote: > Hi Rafael, > > > On Fri, Oct 12, 2018 at 10:00:14AM -0300, Rafael Diniz wrote: >> Hi all, >> >>> I've done some research on the web at that time (maybe 2 years ago) but >>> unfortunately couldn't find any library/tool/infrastructure for having >>> persistent data in SysV SHM, and also no other FOSS programs that did >>> so. Maybe I didn't look closely enough? To me, it seems like the most >>> obvious solution to persist state across crashes/restarts of C programs >>> on unix-type systems. >>> >>> We explicitly don't want to use some kind of database system, as the VLR >>> data needs to be accessed all over the code >>> directly/synchronously/non-blockingly. We cannot wait for it to be >>> retrieved from somewhere. That's what is done with HLR data. >> >> May be I'm missing something, but SysV SHM provides system calls you >> certainly can create a shared memory segment that is persistent. > > yes, that is what I'm saying and why we have been brainstorming about > this approach at all. That's what I've been talking about in the first > paragraph you quoted, and what we've been pondering to do. > > The second paragraph is about embedded or external databases which we > don't want to use, and whihc are not useful within the current osmocom > architecture. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Mon Oct 15 10:40:58 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Oct 2018 12:40:58 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <74067f7c-899a-70d6-801d-8d8ca8399915@rhizomatica.org> References: <20181012065503.GI9979@nataraja> <74067f7c-899a-70d6-801d-8d8ca8399915@rhizomatica.org> Message-ID: <20181015104058.GA25021@my.box> On Fri, Oct 12, 2018 at 12:10:25PM +0200, Keith wrote: > With the split setup it involves a complete loss of service, basically, > as you say, until location update timeout. Not complete loss of service: * any phone that contacts the network to get something done will be told to re-attach. So sending things and calling out (MO) will work. * paging (MT) will not work, so contacting a phone from the core is broken until periodic LU time has passed. But actually only because the VLR thinks the phone is not attached to any cell, and so we don't even try to page it. An easy way out of this would be to enable a BSS-wide (MSC wide?) paging mechanism, until the first periodic location updating time has passed -- after osmo-msc startup, just page any subscriber everywhere, if we think it is not attached, until the first periodic LU time has passed. That could be enabled by config (not on by compile time default, but on in Rhizomatica's cfg). Upon paging response, the phone would re-attach and things should work again. That would be considerably less effort than persisting the VLR storage. Another (less elegant) idea I'm having is that we do have some notion of which IMSIs were attached in the HLR database. They have the VLR number stored to match the MSC's identification. If we could employ some tool to graze the HLR db, and over a period of time invoke pagings for all those subscribers, we could blanket re-attach everyone within a short time. I think I'd make that an external tool using the CTRL interface, with some spread over time to not insanely load the network. The one mild problem with this is, it doesn't look like we notify the HLR on phones detaching. That could be resolved by also storing a timestamp of when a subscriber was last attached in the HLR, which I suggest makes sense anyway. The first idea, "page on all cells until first periodic LU time has passed", is more elegant because we don't blanket page everyone and don't need external tools nor changes to the HLR. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Oct 15 10:57:08 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 15 Oct 2018 12:57:08 +0200 Subject: help need with the silent_call function in OsmoMSC/BSC In-Reply-To: <9cf0da62-bf2b-bc22-41b6-d4ac78957469@cs.bham.ac.uk> References: <9cf0da62-bf2b-bc22-41b6-d4ac78957469@cs.bham.ac.uk> Message-ID: <20181015105708.GB25021@my.box> On Fri, Oct 12, 2018 at 04:35:04PM +0100, Mihai Ordean wrote: > Now I want to enable the silent_call functionality to begin testing but > I can't seem able to do so. Historically, the silent call feature was an important part of the Osmocom heritage: IIRC demonstrating a silent call to locate a phone was one of the important early goals of implementing osmo-nitb aka bsc_hack in the first place, and from there things have evolved to the multi component externally compatible stack we have today. But, these days, I don't know of anyone testing on a regular basis whether silent call works, be it manually or automatically. Typically that is a guarantee for bit rot and breakage. I'm fairly certain that is, sadly, the case with the silent call feature. It should work, but one refactoring or the other has broken it. Looking at the log, I believe the fix is fairly trivial: Today's MSC strictly monitors connections by subscribers, and first ensures they get accepted (in terms of authentication), and then ensures that they establish some sort of meaningful request/response interaction. So I think all we need is that in paging_cb_silent(), we transition the conn FSM from SUBSCR_CONN_S_ACCEPTED to SUBSCR_CONN_S_COMMUNICATING, to stop the timer that watches validity. See msc_subscr_conn_communicating(). It would be excellent if you could try to implement and test yourself. If you need help, do ask again. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Tue Oct 16 12:11:08 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 16 Oct 2018 14:11:08 +0200 Subject: Location Updating failure due to Speech Codec Message-ID: <20181016121108.GA3885@my.box> Recently, dexter has added this commit: http://git.osmocom.org/osmo-bsc/commit/?id=b9d3c71af347906cef2bb54be57418a948d17b14 Our osmo-gsm-tester tests fail to pass since this commit thwarts all L3 Complete. The commit refuses to compose a Layer-3-Complete message if the speech codecs supported by the BSS cannot be included, either because none are configured, or because none remain after all the criteria of finding codecs permitted. It may be mandatory to include the speech codecs or not, what bugs me is that we even refuse a mere attach to the network just because speech codecs are not available. Those only become interesting much much later, only for voice. The backwards-compatibility consideration: configurations that have always worked well are suddenly likely to fail. Users will wonder what happened, and we need to avoid that. I think instead of thwarting L3 Complete entirely, we should loudly error-log, but still send out an L3 Complete while simply omitting the speech codec list. It might be a spec violation for AoIP, but practically works fine, AFAICT. Again, the way to handle this spec violation should be to log an error, not to break all access. The alternative would be, IMHO, to abort osmo-bsc startup right away, complaining about misconfiguration, if that is possible at all. But no. Let's allow L3 Complete even in the absence of speech codecs that all participants support. There are USSD and SMS and GPRS that are all going to be broken just because codecs don't match. The commit right after sets, apparently, the full list of codecs as supported by default. Is that not working? Do we override that in the osmo-gsm-tester config? Either way, even if the allowed codecs are all configured properly, but there is simply no match between MS,BTS,BSC,MSC, we would still refuse LU, right? Hence I would like to revert above commit / replace with error logging. @dexter, what do you think? Am I making sense, or am I missing something? Thanks! ~N P.S.: in that commit log, it would have been nice to mention the config items that would help solve the situation. It's not entirely clear to me yet what the misconfigured items are on the osmo-gsm-tester setup. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pmaier at sysmocom.de Tue Oct 16 12:38:18 2018 From: pmaier at sysmocom.de (Philipp Maier) Date: Tue, 16 Oct 2018 14:38:18 +0200 Subject: Location Updating failure due to Speech Codec In-Reply-To: <20181016121108.GA3885@my.box> References: <20181016121108.GA3885@my.box> Message-ID: Hello Neels, See 3GPP_TS_48.008, 3.2.1.32 COMPLETE LAYER 3 INFORMATION : Note 4: "Codec List (BSS Supported) shall be included, if the radio access network supports an IP based user plane interface." See also: 3GPP_TS_48.008, 3.2.2.103 Speech Codec List "The length indicator (octet 2) is a binary number indicating the absolute length of the contents after the length indicator. The length depends on the number and type of Speech Codec Elements to be included. The minimum length of one Speech Codec Element is 1 octet and the maximum length is 3 octets. The maximum number of Speech Codec Elements within the Speech Codec List is not defined." I think there is no way in leaving the Codec List (BSS Supported) away. The spec is clear on this. I think the reason is because to decide one would have to look into the detap messages and check if the request is about a call or an LU, or an SMS etc. I am not sure with 3GPP_TS_48.008, 3.2.2.103, the minimum length requirement refers to one item only. So having 0 items in the speech codec list is an allowed situation? If yes, that wold be the correct solution. Including the speech codec list, but with 0 elements. I can make a patch for libosmocore for this. It wouln't take long. Regarding the warning I don't think that start abortion is a good idea. This could lock out users that want to configure via telnet. Best 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 keith at rhizomatica.org Tue Oct 16 12:47:36 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 16 Oct 2018 14:47:36 +0200 Subject: BSC / MSC volatile state / restart handling In-Reply-To: <20181015104058.GA25021@my.box> References: <20181012065503.GI9979@nataraja> <74067f7c-899a-70d6-801d-8d8ca8399915@rhizomatica.org> <20181015104058.GA25021@my.box> Message-ID: <0a940a80-c1b0-c0c8-d13b-703f46e1d1f6@rhizomatica.org> On 15/10/18 12:40, Neels Hofmeyr wrote: > On Fri, Oct 12, 2018 at 12:10:25PM +0200, Keith wrote: >> With the split setup it involves a complete loss of service, basically, >> as you say, until location update timeout. > Not complete loss of service: > > * any phone that contacts the network to get something done will be told to > re-attach. So sending things and calling out (MO) will work. Ah! Well that's something I did not know,? I'm not sure it is what I observed (memory tells me not), but I'll check it all out again. > > Another (less elegant) idea I'm having is that we do have some notion of which > IMSIs were attached in the HLR database. They have the VLR number stored to > match the MSC's identification. If we could employ some tool to graze the HLR > db, and over a period of time invoke pagings for all those subscribers, we > could blanket re-attach everyone within a short time. I think I'd make that an > external tool using the CTRL interface, with some spread over time to not > insanely load the network. The one mild problem with this is, it doesn't look > like we notify the HLR on phones detaching. That could be resolved by also > storing a timestamp of when a subscriber was last attached in the HLR, which I > suggest makes sense anyway. I suggest it does too. In fact, I think it is 100% necessary for the distributed GSM idea where we send broadcast probes to various HLRs asking them for the timestamps of the last seen LUR of an apparently attached (t)IMSI. thanks! k/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From pmaier at sysmocom.de Tue Oct 16 13:23:59 2018 From: pmaier at sysmocom.de (Philipp Maier) Date: Tue, 16 Oct 2018 15:23:59 +0200 Subject: Location Updating failure due to Speech Codec In-Reply-To: References: <20181016121108.GA3885@my.box> Message-ID: <551e7eaf-7cfb-89bc-7a7a-040f3a368a95@sysmocom.de> Hello Neels, i have checked back with pau. A codec list with 0 elekents is indeed permitted. So I will now change this. In osmo-bsc I will then remove the check, so if the config does not permit any codecs the codec list will have 0 elements. However, we could also just interpret the spec differently. If we support 0 codecs the network wouln't be able to support an IP based user plane interface and therefore the codec list does not have to be included. So in fact we found a solution now. I will keep you posted on this. best 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 pmaier at sysmocom.de Tue Oct 16 15:26:07 2018 From: pmaier at sysmocom.de (Philipp Maier) Date: Tue, 16 Oct 2018 17:26:07 +0200 Subject: Location Updating failure due to Speech Codec In-Reply-To: References: <20181016121108.GA3885@my.box> Message-ID: <9b1a5468-25c5-cdf2-9800-995eb9e50c1d@sysmocom.de> Hello Neels, I think I have now fixed the problem. There is also a ticket, please see: http://osmocom.org/issues/3657 best 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 naif8 at riseup.net Tue Oct 16 15:33:00 2018 From: naif8 at riseup.net (naif8) Date: Tue, 16 Oct 2018 15:33:00 +0000 Subject: Network interconnection over VPN/SIP Message-ID: Hello everybody, I hope I'm in the right place here, for my question, if not please ignore or maybe point me to a better place. For start, I'm quit new to the whole GSM stack and still in the process of understanding it, so please if you have the feeling I maybe misunderstood something horrible, I probably have! Feel free to point that out :D. I working together with other peoble on a project witch aims to connect refugee camps in the middle east, to enable easy, safer and non profit communication between them, this is often a big need for example to find relatives, but also to communicate with in the camps because sometimes they are huge etc.. One part (an at the moment my part) of this is to build up independent GSM Networks per camp witch are interconnected with the other camps. The idea is to build GSM networks with in the camp witch are autonomous. If there is power they run, if there is internet peoble can call the other camps (if they have internet). Every thing need's to be done without any central entity (like an HLR for all camps, run on a Server in Frankfurt) so that when, let say government xy decides to only allow nation wide networking an cut's the internet (happened since I'm here 2 times, it's annoying as f**k), the camp's within the country and in the camp it self can still communicate. The question is how to do this interconnection? As fare as I understand in classical GSM infrastructure, this is done by SS7, but since we are not interested (at least by know) to interconnect with "big" providers, and also I did not found an open source implementation (but maybe I missed it) this seems not an option, so the plan now is to do this over VPN's and SIP/VOIP Server (probably asterisk). We like to be able to scale the camps number, and to be relative easy to maintain so we can enable people to run this them self (after we learned to run this our self of course ;)). And these protocols are fare better documented then SS7 so also much more esay to learn and to debug. We are still testing and researching and so I thought it is maybe a good time to ask her if this is a valid way or I missing something, or maybe you can point me towards some documentations where people did some similar things. We are all not professionals and do this more or less with learning by doing, but we don't need to do all the mistakes other did before us :D (maybe some but not all) thx in advance and for this great project witch enabled us to do stuff like this naif -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1749 bytes Desc: not available URL: From pespin at sysmocom.de Tue Oct 16 15:54:00 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 16 Oct 2018 17:54:00 +0200 Subject: Network interconnection over VPN/SIP In-Reply-To: References: Message-ID: <01e87ef0-52a2-701d-94a1-5930010c0cf4@sysmocom.de> Hi, you can find a related thread started a few days ago which may be of interest to you here: https://lists.osmocom.org/pipermail/openbsc/2018-September/012149.html 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 andrew.voce at gmail.com Tue Oct 16 16:40:19 2018 From: andrew.voce at gmail.com (Andrew) Date: Tue, 16 Oct 2018 12:40:19 -0400 Subject: BS-11 Firmware In-Reply-To: <20181012114216.GT9979@nataraja> References: <20181012114216.GT9979@nataraja> Message-ID: <4F5C6D12-4350-47C5-B1E7-B4E53EFA9446@gmail.com> Hi Harald, I wasn?t asking for anyone to distribute copyrighted software. I?m wondering if anyone knows a vendor that still sells it or another legal place to acquire the firmware. Thanks, Andrew > On Oct 12, 2018, at 7:42 AM, Harald Welte wrote: > > Hi Andrew, > >> On Thu, Oct 11, 2018 at 02:54:41PM -0400, Andrew Voce wrote: >> I'm wondering where I can source the Siemens BS11 firmware. > > I wonder where you got a BS-11 [in 2018] without firmware installed :P > >> It looks like OpenBSC is not providing any firmware images. > > How could we? The firmware is a copyrighted work and property of > Siemens and/or third parties. To my knowledge, it was made available > only under NDA. Even without NDA, distributing it is copyright > infringement. > > It sucks, but that's unfortunately the situation :( > > Regards, > Harald > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Oct 17 07:12:53 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 17 Oct 2018 09:12:53 +0200 Subject: FOSS SIM applets for sysmoUSIM-SJS1 In-Reply-To: References: <20180411202208.GD28162@nataraja> Message-ID: <20181017071253.GD3445@nataraja> Hi J. Felix, On Tue, Oct 16, 2018 at 07:45:42PM +0200, J. F?lix Onta?on Podsystem wrote: > Hi Osmocom community. Pretty happy to attend this year and looking forward > to see you in a few days. Same here! > We've been for some time developing some open source (gplv3) applets for > the sysmoUSIM units. Still simple experiments, yet promising: > > https://github.com/PodgroupConnectivity/sim-applet-apn-autoconf > https://github.com/PodgroupConnectivity/sim-applet-data-heartbeat > https://github.com/PodgroupConnectivity/sim-applet-sms-im-alive This is great, thanks a lot for sharing. It has been many years since we (particularly Dieter, based on prior work by shadytel) have been releasing a "Hello World" for writing Java Cardlets for the sysmoUSIM-SJS1, but we never really saw anyone doing much with it beyond reproducing getting the "Hello World" to run - at least not in the public. It's great that this is changing now. Do you have an account on osmocom.org? Please let me know your user name so I can give you wiki editing permission. You can then add links to your projects to e.g. http://osmocom.org/projects/cellular-infrastructure/wiki/SysmoUSIM-SJS1 @pmaier: Please also include links to the related projects into the sysmoUSIM manual in the related section about Java capabilities. 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 nhofmeyr at sysmocom.de Wed Oct 17 13:06:07 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 17 Oct 2018 15:06:07 +0200 Subject: Network interconnection over VPN/SIP In-Reply-To: References: Message-ID: <20181017130607.GA15741@my.box> Hi naif, your requirements sound a lot alike those that Rhizomatica are solving in Oaxaca. Running independent GSM networks is the easy part, the hard part is to connect them to each other in a failure-tolerant way. The basic concept is, usually you would have one MSC+HLR for all of your cells, and calls would easily get routed between the different cells. But if the connection to the MSC fails, then all is lost. So you want completely separate network infrastructure for each location. I'm not closely familiar with this aspect, but I imagine using SIP call routing between the otherwise independent networks is one solution (think osmo-sip-connector and an external call router program). The other problem space is that if you want to manage a common subscriber database (HLR), so that e.g. one SIM (phone) can travel freely around and use any of the network cells and always be reachable by the same number wherever it happens to be, then you need some synchronization of the HLR databases. To illustrate, if I want to be reachable by one given phone number in all the cells, something has to know which cell to route that number to. If I show up in a cell, we need to tell the previous cell that I am now over here instead... You would have an easier time if each network is managed separately with its own HLR on-location, in the sense that a SIM card can have a different phone number in each of them. I'm making this up as I go, I hope Rhizomatica folks can flesh out some more details. Note, we're currently working on improving the network setup for Rhizomatica, and you're likely to benefit from that, sooner or later. Either way it would be excellent if you stay in touch and contribute documentation and/or patches back to Osmocom. Also possible would be to book support hours from a professional support vendor, if you have some grant that allows you to, so that your specific needs can be addressed with higher priority than volunteer work can provide (which would also benefit Osmocom at large, to pay for maintenance etc.). None of this is required, of course, but Free Software lives by contribution. All kinds of contribution are welcome. Looking forward to hearing more about your progress! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From felix.ontanon at podgroup.com Tue Oct 16 17:45:42 2018 From: felix.ontanon at podgroup.com (=?UTF-8?Q?J=2E_F=C3=A9lix_Onta=C3=B1on_Podsystem?=) Date: Tue, 16 Oct 2018 19:45:42 +0200 Subject: Save the Date: OsmoCon 2018 on October 18-19, 2018 In-Reply-To: <20180411202208.GD28162@nataraja> References: <20180411202208.GD28162@nataraja> Message-ID: Hi Osmocom community. Pretty happy to attend this year and looking forward to see you in a few days. Considering there's a talk about sysmoUSIM (Philipp Maier), and regarding the contributions with "third-party open source utilities to be used with Osmocom projects" as Harald said, I'd like to introduce you something: We've been for some time developing some open source (gplv3) applets for the sysmoUSIM units. Still simple experiments, yet promising: https://github.com/PodgroupConnectivity/sim-applet-apn-autoconf https://github.com/PodgroupConnectivity/sim-applet-data-heartbeat https://github.com/PodgroupConnectivity/sim-applet-sms-im-alive I wanted to let you know as I'd really appreciate finding people with the same interests during the conference. See ya in a few days. On Wed, 11 Apr 2018 at 22:23, Harald Welte wrote: > == OsmoCon 2018 == > > OsmoCon (Osmocom Conference) 2018 is the technical conference for > Osmocom users, operators and developers! > > We are happy to announce the date of OsmoCon 2018. It has been scheduled > on October 18 + 19, 2018 and will happen in Berlin, Germany. > > For the second time, the Osmocom Conference brings together users, > operators and developers of the Osmocom Open Source cellular > infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN > and others. > > Join us for two days of presentations and discussions with the main > developers behind Open Source Mobile Communications, as well as > commercial and non-profit users of the Osmocom cellular infrastructure > software. > > You can find some initial information in our wiki at > http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 > which will be updated as more information becomes available. > > > == Call for Participation == > > We're also at the same time announcing the Call for Participation and > call on everyone with experiences to share around the Osmocom member > projects to submit talks, workshops, discussions or other proposals. > > You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp > > We are particularly looking for contributions about: > > * updates on features/functionality/status of individual Osmocom projects > * success stories on how Osmocom projects are deployed in practice > * migration from OsmoNITB to the post-NITB architecture > * tutorials / workshops on how to setup / analyze Osmocom projects > * statistics, reporting, operations aspects of Osmocom projects > * third-party open source utilities to be used with Osmocom projects > > Looking forward to meeting many existing and new Osmocom users at OsmCon > this October! > > Regards, > Harald Welte > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- *J. F?lix Onta??n* Director of Research and Innovation Pod Group felix.ontanon at podgroup.com www.podgroup.com www.podm2m.com www.pod.solutions UK: +44 (0)1223 850 900 <+44%201223%20850900> USA: +1 415 7070 500 Spain: +34 954 050 200 <+34%20954%2005%2002%2000> [image: Facebook] [image: Twitter] [image: LinkedIn] [image: Instagram] *Sign up for a demo of our hierarchical billing engine, Pod Billing * *Sales*: sales at podgroup.com *Support*: support at podgroup.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.ontanon at podgroup.com Wed Oct 17 21:08:13 2018 From: felix.ontanon at podgroup.com (=?UTF-8?Q?J=2E_F=C3=A9lix_Onta=C3=B1on_Podsystem?=) Date: Wed, 17 Oct 2018 23:08:13 +0200 Subject: FOSS SIM applets for sysmoUSIM-SJS1 In-Reply-To: <20181017071253.GD3445@nataraja> References: <20180411202208.GD28162@nataraja> <20181017071253.GD3445@nataraja> Message-ID: Hi Harald, It will be a pleasure to contribute with this project to the osmocom community. Please register the account for me with username "fontanon" and another for my colleague Diego with "dielenram". See you tomorrow! El mi?., 17 oct. 2018 9:20, Harald Welte escribi?: > Hi J. Felix, > > On Tue, Oct 16, 2018 at 07:45:42PM +0200, J. F?lix Onta?on Podsystem wrote: > > Hi Osmocom community. Pretty happy to attend this year and looking > forward > > to see you in a few days. > > Same here! > > > We've been for some time developing some open source (gplv3) applets for > > the sysmoUSIM units. Still simple experiments, yet promising: > > > > https://github.com/PodgroupConnectivity/sim-applet-apn-autoconf > > https://github.com/PodgroupConnectivity/sim-applet-data-heartbeat > > https://github.com/PodgroupConnectivity/sim-applet-sms-im-alive > > This is great, thanks a lot for sharing. It has been many years since > we (particularly Dieter, based on prior work by shadytel) have been > releasing a "Hello World" for writing Java Cardlets for the > sysmoUSIM-SJS1, but we never really saw anyone doing much with it beyond > reproducing getting the "Hello World" to run - at least not in the > public. > > It's great that this is changing now. Do you have an account on > osmocom.org? Please let me know your user name so I can give you wiki > editing permission. You can then add links to your projects to e.g. > http://osmocom.org/projects/cellular-infrastructure/wiki/SysmoUSIM-SJS1 > > @pmaier: Please also include links to the related projects into the > sysmoUSIM manual in the related section about Java capabilities. > > Regards, > Harald > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Fri Oct 19 12:46:31 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 19 Oct 2018 14:46:31 +0200 Subject: FOSS SIM applets for sysmoUSIM-SJS1 In-Reply-To: References: <20180411202208.GD28162@nataraja> <20181017071253.GD3445@nataraja> Message-ID: <20181019124631.GA8450@my.box> On Wed, Oct 17, 2018 at 11:08:13PM +0200, J. F?lix Onta?on Podsystem wrote: > Please register the account for me with username "fontanon" and another for > my colleague Diego with "dielenram". Those user names currently don't exist. It works like this: you register on the osmocom.org redmine yourself, then let us know to enable permissions on it. Thanks! ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From michael at usehover.com Fri Oct 19 17:56:38 2018 From: michael at usehover.com (Michael Benedict) Date: Fri, 19 Oct 2018 10:56:38 -0700 Subject: Status of external USSD applications? Message-ID: Hi all, This is my second email here so I will start with a quick introduction before a question: I?m part of of an early stage company called Hover (www.usehover.com). We offer an Android software development kit written in Java that helps smartphone app developers automate USSD sessions in the background of native apps. A typical use case is to build a nicer user interface for, eg. mobile money transfers or airtime top-up. Colleagues at the University of Washington pointed me to this exciting project, and I have a B210 set up so I can register a phone on an Osmocom network and run *#100# to see my MSISDN from OsmoHLR. Which brings me to my question: I see that Rowan Phipps at UW has modified an earlier version of the Osmocom stack to run arbitrary USSD sessions from a Python web server. It looks like related work was started in 9658 and 9661 [1], [2]. Are these commits working, and what would be the best way for me to contribute to or test this work? I would prefer to run the newer Osmo* projects rather than try to use OsmoNITB. I am in the process of reading Rowan and Fairwaves' work and will happily share anything I learn. As context, we have 50k+ USSD session logs (i.e. menu text, not Wireshark traces) from various markets. My end goal is to be able to test new apps against these logs and otherwise experiment with arbitrary USSD sessions locally. Thank you for any suggestions you can offer. ?Michael [1] https://gerrit.osmocom.org/#/c/osmo-msc/+/9658/ [2] https://gerrit.osmocom.org/#/c/osmo-msc/+/9661/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Oct 19 20:43:23 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 19 Oct 2018 22:43:23 +0200 Subject: Status of external USSD applications? In-Reply-To: References: Message-ID: <20181019204323.GW25900@nataraja> Hi Michael, On Fri, Oct 19, 2018 at 10:56:38AM -0700, Michael Benedict wrote: > I see that Rowan Phipps at UW has modified an earlier version of the > Osmocom stack to run arbitrary USSD sessions from a Python web server. I currently don't recall any such work being discusesd here or being submitted for mainline? Maybe I forgot, my apologies. > It looks like related work was started in 9658 and 9661 [1], [2]. Are these > commits working, and what would be the best way for me to contribute to or > test this work? The commits are working and are actually automatically continuously tested against latest master of OsmoMSC, see the test cases starting at http://git.osmocom.org/osmo-ttcn3-hacks/tree/msc/MSC_Tests.ttcn#n2146 and those against OsmoHLR at http://git.osmocom.org/osmo-ttcn3-hacks/tree/hlr/HLR_Tests.ttcn#n778 The test results analyzer of our jenkins at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/test_results_analyzer/ also shows that all ussd related tests are passing. Please see https://media.ccc.de/v/osmocon2018-61-external-ss-ussd-interface#t=0 for a very current video abut the feature (recorded today at the Osmocom Conference). Also refer to Section 7.1 of the OsmoHLR user manual at http://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf 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 michael at usehover.com Sun Oct 21 16:47:34 2018 From: michael at usehover.com (Michael Benedict) Date: Sun, 21 Oct 2018 09:47:34 -0700 Subject: Status of external USSD applications? In-Reply-To: <20181019204323.GW25900@nataraja> References: <20181019204323.GW25900@nataraja> Message-ID: Hi Harald, Thank you for the thorough explanation, it's very helpful and gives me a clear path forward. All the best, --Michael From keith at rhizomatica.org Mon Oct 22 07:57:28 2018 From: keith at rhizomatica.org (Keith) Date: Mon, 22 Oct 2018 09:57:28 +0200 Subject: Status of external USSD applications? In-Reply-To: <20181019204323.GW25900@nataraja> References: <20181019204323.GW25900@nataraja> Message-ID: <60bb3302-8b54-5b3f-527e-133657672c86@rhizomatica.org> On 19/10/2018 22:43, Harald Welte wrote: > Hi Michael, > > On Fri, Oct 19, 2018 at 10:56:38AM -0700, Michael Benedict wrote: >> I see that Rowan Phipps at UW has modified an earlier version of the >> Osmocom stack to run arbitrary USSD sessions from a Python web server. Hi Michael! Where do you see this? I'd be interested in some links to this related work I think it's nice to also post some link to sources if at all possible when one makes a reference to related work on an open source project mailing list ;-) I found some references to the UW investigation on vulnerabilities in USSD, but Rowan Phipps seems somewhat absent from the public internet. Many Thanks! From kheimerl at cs.washington.edu Mon Oct 22 08:18:41 2018 From: kheimerl at cs.washington.edu (Kurtis Heimerl) Date: Mon, 22 Oct 2018 01:18:41 -0700 Subject: Status of external USSD applications? In-Reply-To: <60bb3302-8b54-5b3f-527e-133657672c86@rhizomatica.org> References: <20181019204323.GW25900@nataraja> <60bb3302-8b54-5b3f-527e-133657672c86@rhizomatica.org> Message-ID: The details of the implementation were posted here in January ( https://www.mail-archive.com/openbsc at lists.osmocom.org/msg08419.html). Our understanding was that the recently accepted USSD patches would match much of our functionality so the branch has not seen much active development. I am unsure of the difficulties of integrating ussd-airflow into the current implementation. On Mon, Oct 22, 2018 at 12:57 AM Keith wrote: > > On 19/10/2018 22:43, Harald Welte wrote: > > Hi Michael, > > > > On Fri, Oct 19, 2018 at 10:56:38AM -0700, Michael Benedict wrote: > >> I see that Rowan Phipps at UW has modified an earlier version of the > >> Osmocom stack to run arbitrary USSD sessions from a Python web server. > > Hi Michael! > > Where do you see this? I'd be interested in some links to this related work > > I think it's nice to also post some link to sources if at all possible > when one makes a reference to related work on an open source project > mailing list ;-) > > I found some references to the UW investigation on vulnerabilities in > USSD, but Rowan Phipps seems somewhat absent from the public internet. > > Many Thanks! > > > > > -- Public Key: https://flowcrypt.com/pub/kheimerl at cs.washington.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Mon Oct 22 10:19:52 2018 From: keith at rhizomatica.org (Keith) Date: Mon, 22 Oct 2018 12:19:52 +0200 Subject: Status of external USSD applications? In-Reply-To: References: <20181019204323.GW25900@nataraja> <60bb3302-8b54-5b3f-527e-133657672c86@rhizomatica.org> Message-ID: On 22/10/2018 10:18, Kurtis Heimerl wrote: > The details of the implementation were posted here in January > (https://www.mail-archive.com/openbsc at lists.osmocom.org/msg08419.html). Ah Thanks Kurtis! I remember seeing that now. > > Our understanding was that the recently accepted USSD patches would > match much of our functionality so the branch has not seen much active > development. I am unsure of the difficulties of integrating > ussd-airflow into the current implementation. I guess the key might be Rowan's sup_airflow https://github.com/rowanphipps/sup_airflow as the new osmo-hlr external USSD handler basically passes GSUP through from the MSC, IIUC It's now on my list of TODO. Thanks! k From lprehn at inet.tu-berlin.de Mon Oct 22 14:37:27 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Mon, 22 Oct 2018 16:37:27 +0200 Subject: STP and SGSN communication Message-ID: <72641b2b-5639-309d-3f2b-cf383bfad77f@inet.tu-berlin.de> Hi everyone, I'm currently struggling with getting the NITB example (https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box) running. My problem looks as follows: I do see messages reaching the HNBGW component but whenever the HNBGW tries to reach the SGSN component I get the following error: DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=188=0.23.4 not local, message is for routing DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 188: no route! Using the VTY interface I can see that only HNBGW and MSC annouced their code points towards STP. : as-rkm-1???? AS_ACTIVE??? 1????????? 0.23.5 as-rkm-2???? AS_ACTIVE??? 2????????? 0.23.1 However, I can not see the code point 0.23.4 (SGSN). In addition, I'm also not sure if the routes are valid as they are: 7.255.7??????????????????? 0 as-rkm-1??????????? ??????? ? ? 7.255.7??????????????????? 0 as-rkm-2 ?????????? ??????? ? ? Here are my configurations (without the logging parts): ################### osmo-hnbgw.cfg ################### cs7 instance 0 ?# HNBGW's local point code ?point-code 0.23.5 ?# Address book entries, used below ?sccp-address my_msc ? point-code 0.23.1 ?sccp-address my_sgsn ? point-code 0.23.4 hnbgw ?iucs ? remote-addr my_msc ?iups ? remote-addr my_sgsn ?iuh ? local-ip 10.1.1.1 ? hnbap-allow-tmsi 1 ################### osmo-sgsn.cfg ################### sgsn ?gtp local-ip 10.1.1.1 ?ggsn 0 remote-ip 10.1.1.2 ?ggsn 0 gtp-version 1 ?!auth-policy accept-all ?auth-policy remote ?gsup remote-ip 127.0.0.1 ?gsup remote-port 4222 ns ?timer tns-block 3 ?timer tns-block-retries 3 ?timer tns-reset 3 ?timer tns-reset-retries 3 ?timer tns-test 30 ?timer tns-alive 3 ?timer tns-alive-retries 10 ?encapsulation udp local-ip 127.0.0.1 ?encapsulation udp local-port 23000 ?encapsulation framerelay-gre enabled 0 bssgp ################### osmo-hnbgw.cfg ################### network ?network country code 901 ?mobile network code 98 ?short name OsmoMSC ?long name OsmoMSC ?encryption a5 0 ?rrlp mode none ?mm info 1 msc ?mgw remote-ip 10.1.1.2 ?mgw endpoint-range 1 32 ################### osmo-stp.cfg ################### cs7 instance 0 ?xua rkm routing-key-allocation dynamic-permitted ?listen m3ua 2905 ? accept-asp-connections dynamic-permitted I hope someone can spot my mistake! Best regards, Lars From m.ordean at cs.bham.ac.uk Mon Oct 22 18:39:39 2018 From: m.ordean at cs.bham.ac.uk (Mihai Ordean) Date: Mon, 22 Oct 2018 19:39:39 +0100 Subject: help need with the silent_call function in OsmoMSC/BSC In-Reply-To: <20181015105708.GB25021@my.box> References: <9cf0da62-bf2b-bc22-41b6-d4ac78957469@cs.bham.ac.uk> <20181015105708.GB25021@my.box> Message-ID: Hey Thanks for the suggestion! I finally had some time for a bit more debugging and was able to make silent_call work. As it turns out, aside from reverting the silent call patch from (https://gerrit.osmocom.org/#/c/openbsc/+/1930/) some changes had to be made to subscr_conn.c to enable the fsm transitions suggested for silent_call i.e. SUBSCR_CONN_S_NEW to SUBSCR_CONN_S_COMMUNICATING. If anyone is interested, I'm attaching the patch against the latest git version (f6400737). Mihai On 15/10/2018 11:57, nhofmeyr at sysmocom.de wrote: > On Fri, Oct 12, 2018 at 04:35:04PM +0100, Mihai Ordean wrote: >> Now I want to enable the silent_call functionality to begin testing but >> I can't seem able to do so. > > Historically, the silent call feature was an important part of the Osmocom > heritage: IIRC demonstrating a silent call to locate a phone was one of the > important early goals of implementing osmo-nitb aka bsc_hack in the first > place, and from there things have evolved to the multi component externally > compatible stack we have today. > > But, these days, I don't know of anyone testing on a regular basis whether > silent call works, be it manually or automatically. Typically that is a > guarantee for bit rot and breakage. > > I'm fairly certain that is, sadly, the case with the silent call feature. It > should work, but one refactoring or the other has broken it. > > Looking at the log, I believe the fix is fairly trivial: > > Today's MSC strictly monitors connections by subscribers, and first ensures > they get accepted (in terms of authentication), and then ensures that they > establish some sort of meaningful request/response interaction. > > So I think all we need is that in paging_cb_silent(), we transition the conn > FSM from SUBSCR_CONN_S_ACCEPTED to SUBSCR_CONN_S_COMMUNICATING, to stop the > timer that watches validity. See msc_subscr_conn_communicating(). > > It would be excellent if you could try to implement and test yourself. If you > need help, do ask again. > > ~N > -------------- next part -------------- --- a/src/libmsc/silent_call.c +++ b/src/libmsc/silent_call.c @@ -74,7 +74,7 @@ return rc; } -#if 0 + /* receive a layer 3 message from a silent call */ int silent_call_rx(struct gsm_subscriber_connection *conn, struct msgb *msg) { @@ -117,7 +117,7 @@ LOGP(DLSMS, LOGL_INFO, "Rerouting L3 message from a silent call.\n"); return 1; } -#endif + /* initiate a silent call with a given subscriber */ --- a/include/osmocom/msc/silent_call.h +++ b/include/osmocom/msc/silent_call.h @@ -7,9 +7,7 @@ void *data, int type); extern int gsm_silent_call_stop(struct vlr_subscr *vsub); -#if 0 extern int silent_call_rx(struct gsm_subscriber_connection *conn, struct msgb *msg); extern int silent_call_reroute(struct gsm_subscriber_connection *conn, struct msgb *msg); -#endif #endif /* _SILENT_CALL_H */ --- a/src/libmsc/gsm_04_08.c +++ a/src/libmsc/gsm_04_08.c @@ -1470,10 +1470,8 @@ return -EACCES; } -#if 0 if (silent_call_reroute(conn, msg)) return silent_call_rx(conn, msg); -#endif switch (pdisc) { case GSM48_PDISC_CC: --- a/src/libmsc/subscr_conn.c +++ b/src/libmsc/subscr_conn.c @@ -111,8 +111,12 @@ LOGPFSML(fi, LOGL_NOTICE, "Close event, cause: %s\n", gsm48_reject_value_name(*cause)); } + + static void subscr_conn_fsm_new(struct osmo_fsm_inst *fi, uint32_t event, void *data) { + struct gsm_subscriber_connection *conn = fi->priv; + switch (event) { case SUBSCR_CONN_E_COMPLETE_LAYER_3: osmo_fsm_inst_state_chg(fi, SUBSCR_CONN_S_AUTH_CIPH, SUBSCR_CONN_TIMEOUT, 0); @@ -120,8 +124,14 @@ case SUBSCR_CONN_E_ACCEPTED: evaluate_acceptance_outcome(fi, true); - osmo_fsm_inst_state_chg(fi, SUBSCR_CONN_S_ACCEPTED, SUBSCR_CONN_TIMEOUT, 0); - return; + if (conn->silent_call == 1){ + osmo_fsm_inst_state_chg(fi, SUBSCR_CONN_S_COMMUNICATING, 0, 0); + return; + } + else { + osmo_fsm_inst_state_chg(fi, SUBSCR_CONN_S_ACCEPTED, SUBSCR_CONN_TIMEOUT, 0); + return; + } case SUBSCR_CONN_E_MO_CLOSE: case SUBSCR_CONN_E_CN_CLOSE: @@ -309,6 +319,10 @@ /* no-op */ return; + case SUBSCR_CONN_E_COMPLETE_LAYER_3: + /* no-op */ + return; + case SUBSCR_CONN_E_MO_CLOSE: case SUBSCR_CONN_E_CN_CLOSE: log_close_event(fi, event, data); @@ -408,11 +422,13 @@ [SUBSCR_CONN_S_NEW] = { .name = OSMO_STRINGIFY(SUBSCR_CONN_S_NEW), .in_event_mask = S(SUBSCR_CONN_E_COMPLETE_LAYER_3) | + S(SUBSCR_CONN_E_COMMUNICATING) | S(SUBSCR_CONN_E_ACCEPTED) | S(SUBSCR_CONN_E_MO_CLOSE) | S(SUBSCR_CONN_E_CN_CLOSE) | S(SUBSCR_CONN_E_UNUSED), .out_state_mask = S(SUBSCR_CONN_S_AUTH_CIPH) | + S(SUBSCR_CONN_S_COMMUNICATING) | S(SUBSCR_CONN_S_ACCEPTED) | S(SUBSCR_CONN_S_RELEASING), .action = subscr_conn_fsm_new, @@ -443,7 +459,7 @@ /* allow everything to release for any odd behavior */ .in_event_mask = S(SUBSCR_CONN_E_COMPLETE_LAYER_3) | S(SUBSCR_CONN_E_COMMUNICATING) | - S(SUBSCR_CONN_E_RELEASE_WHEN_UNUSED) | + S(SUBSCR_CONN_E_RELEASE_WHEN_UNUSED) | S(SUBSCR_CONN_E_ACCEPTED) | S(SUBSCR_CONN_E_MO_CLOSE) | S(SUBSCR_CONN_E_CN_CLOSE) | @@ -457,6 +473,7 @@ .name = OSMO_STRINGIFY(SUBSCR_CONN_S_COMMUNICATING), /* allow everything to release for any odd behavior */ .in_event_mask = S(SUBSCR_CONN_E_RELEASE_WHEN_UNUSED) | + S(SUBSCR_CONN_E_COMPLETE_LAYER_3) | S(SUBSCR_CONN_E_ACCEPTED) | S(SUBSCR_CONN_E_COMMUNICATING) | S(SUBSCR_CONN_E_MO_CLOSE) | -------------- next part -------------- A non-text attachment was scrubbed... Name: m_ordean.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: From matt9j at cs.washington.edu Mon Oct 22 18:51:32 2018 From: matt9j at cs.washington.edu (Matthew Johnson) Date: Mon, 22 Oct 2018 11:51:32 -0700 Subject: Network interconnection over VPN/SIP In-Reply-To: <20181017130607.GA15741@my.box> References: <20181017130607.GA15741@my.box> Message-ID: Hello naif, There is an open source project here: https://github.com/co-cell/ccm that attempts to provide a system for doing the kind of coordination between independent community networks. It is based on Osmocom under the hood, but uses the older osmo-nitb stack (before components were split). The networks are able to operate independently offline, and use a combination of sip call routing as suggested by Neels above, SMPP, and a web api to synchronize usage when connected to the cloud for centralized billing and to interconnect through the cloud for community to community, or community to public voip network communication. The project was originally run by the Telecom Infra Project, but was abandoned by them last year after they moved to a new (unfortunately private) internal tool https://github.com/facebookarchive/CommunityCellularManager . CCM is still actively used by the PCARI Vbts project ( https://www.up.edu.ph/index.php/up-globe-sign-moa-for-village-base-station-project/) with a number of local communities in the Philippines, and they run and maintain their own instance of the CCM cloud. It might be something to look at as a potential starting point, or something to learn from if you want to make different architectural decisions when connecting the networks! Regards, -Matt J. On Wed, Oct 17, 2018 at 6:06 AM Neels Hofmeyr wrote: > Hi naif, > > your requirements sound a lot alike those that Rhizomatica are solving in > Oaxaca. > > Running independent GSM networks is the easy part, the hard part is to > connect > them to each other in a failure-tolerant way. > > The basic concept is, usually you would have one MSC+HLR for all of your > cells, > and calls would easily get routed between the different cells. But if the > connection to the MSC fails, then all is lost. So you want completely > separate > network infrastructure for each location. I'm not closely familiar with > this > aspect, but I imagine using SIP call routing between the otherwise > independent > networks is one solution (think osmo-sip-connector and an external call > router > program). The other problem space is that if you want to manage a common > subscriber database (HLR), so that e.g. one SIM (phone) can travel freely > around and use any of the network cells and always be reachable by the same > number wherever it happens to be, then you need some synchronization of > the HLR > databases. To illustrate, if I want to be reachable by one given phone > number > in all the cells, something has to know which cell to route that number > to. If > I show up in a cell, we need to tell the previous cell that I am now over > here > instead... You would have an easier time if each network is managed > separately > with its own HLR on-location, in the sense that a SIM card can have a > different > phone number in each of them. > > I'm making this up as I go, I hope Rhizomatica folks can flesh out some > more > details. > > Note, we're currently working on improving the network setup for > Rhizomatica, > and you're likely to benefit from that, sooner or later. > > Either way it would be excellent if you stay in touch and contribute > documentation and/or patches back to Osmocom. Also possible would be to > book > support hours from a professional support vendor, if you have some grant > that > allows you to, so that your specific needs can be addressed with higher > priority than volunteer work can provide (which would also benefit Osmocom > at > large, to pay for maintenance etc.). None of this is required, of course, > but > Free Software lives by contribution. All kinds of contribution are welcome. > > Looking forward to hearing more about your progress! > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Oct 22 19:59:15 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 22 Oct 2018 21:59:15 +0200 Subject: CommunityCellularManager (Re: Network interconnection over VPN/SIP) In-Reply-To: References: <20181017130607.GA15741@my.box> Message-ID: <20181022195915.GS3958@nataraja> Hi Matthew, On Mon, Oct 22, 2018 at 11:51:32AM -0700, Matthew Johnson wrote: > to public voip network communication. The project was originally run by the > Telecom Infra Project, but was abandoned by them last year It's sad to hear that it has been officially abandoned :( It was more or less apparent to me that priorities had somewhat changed/shifted and that none of the more or less expected steps (like porting it to the post-NITB osmocom stack) have happened. > after they moved to a new (unfortunately private) internal tool This is the first time I'm hearing about some private internal tool that replaces CCM. Are you able to share more information about this? I've asked the OpenCellular project to clarify this in their forum, see http://ocforum.telecominfraproject.com/t/status-of-communitycellularmanager/86 Unfortunately the Forum doesn't [yet] seem to be very active. 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 kheimerl at cs.washington.edu Mon Oct 22 21:41:02 2018 From: kheimerl at cs.washington.edu (Kurtis Heimerl) Date: Mon, 22 Oct 2018 14:41:02 -0700 Subject: CommunityCellularManager (Re: Network interconnection over VPN/SIP) In-Reply-To: <20181022195915.GS3958@nataraja> References: <20181017130607.GA15741@my.box> <20181022195915.GS3958@nataraja> Message-ID: Some clarifications: On Mon, Oct 22, 2018 at 1:06 PM Harald Welte wrote: > Hi Matthew, > > On Mon, Oct 22, 2018 at 11:51:32AM -0700, Matthew Johnson wrote: > > to public voip network communication. The project was originally run by > the > > Telecom Infra Project, but was abandoned by them last year > > It's sad to hear that it has been officially abandoned :( > > It was more or less apparent to me that priorities had somewhat > changed/shifted > and that none of the more or less expected steps (like porting it to the > post-NITB osmocom stack) have happened. > Couple clarifications, CCM was never part of TIP and was instead an FB project. Abandoned is also maybe the wrong term; internal development at FB ended and development was transferred out of the company. There isn't a lot of activity now though, aside from the ongoing deployments. > > > after they moved to a new (unfortunately private) internal tool > > This is the first time I'm hearing about some private internal tool that > replaces CCM. Are you able to share more information about this? > > As is the nature of private internal tools, no. It's not really a replacement for CCM though, interests have moved in a different direction (or had when I was still there). > > I've asked the OpenCellular project to clarify this in their forum, see > > http://ocforum.telecominfraproject.com/t/status-of-communitycellularmanager/86 > > Unfortunately the Forum doesn't [yet] seem to be very active. > > Regards, > Harald > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -- Public Key: https://flowcrypt.com/pub/kheimerl at cs.washington.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt9j at cs.washington.edu Mon Oct 22 22:01:18 2018 From: matt9j at cs.washington.edu (Matthew Johnson) Date: Mon, 22 Oct 2018 15:01:18 -0700 Subject: CommunityCellularManager (Re: Network interconnection over VPN/SIP) In-Reply-To: References: <20181017130607.GA15741@my.box> <20181022195915.GS3958@nataraja> Message-ID: Unfortunately I have no info about new development, only speculation from the site being archived and things heard thirdhand about people getting reassigned with no details. I should be more conservative/specific when putting assertions onto public mailing lists : ) Kurtis is right, that CCM was never officially brought into TIP, and was just a Facebook incubated project too. There are a couple of us using CCM in the community, but we haven?t had the time or resources to do much work on it over the last few months. People are open do doing code review and accepting patches on the co-cell/ccm repo, but facebookincubator/CommunityCellularManager has been officially archived with no plan for future work. -Matt J. On Mon, Oct 22, 2018 at 14:41 Kurtis Heimerl wrote: > Some clarifications: > > On Mon, Oct 22, 2018 at 1:06 PM Harald Welte wrote: > >> Hi Matthew, >> >> On Mon, Oct 22, 2018 at 11:51:32AM -0700, Matthew Johnson wrote: >> > to public voip network communication. The project was originally run by >> the >> > Telecom Infra Project, but was abandoned by them last year >> >> It's sad to hear that it has been officially abandoned :( >> >> It was more or less apparent to me that priorities had somewhat >> changed/shifted >> and that none of the more or less expected steps (like porting it to the >> post-NITB osmocom stack) have happened. >> > > Couple clarifications, CCM was never part of TIP and was instead an FB > project. Abandoned is also maybe the wrong term; internal development at FB > ended and development was transferred out of the company. There isn't a lot > of activity now though, aside from the ongoing deployments. > > >> >> > after they moved to a new (unfortunately private) internal tool >> >> This is the first time I'm hearing about some private internal tool that >> replaces CCM. Are you able to share more information about this? >> >> > As is the nature of private internal tools, no. It's not really a > replacement for CCM though, interests have moved in a different direction > (or had when I was still there). > > >> >> I've asked the OpenCellular project to clarify this in their forum, see >> >> http://ocforum.telecominfraproject.com/t/status-of-communitycellularmanager/86 >> >> Unfortunately the Forum doesn't [yet] seem to be very active. >> >> Regards, >> Harald >> >> -- >> - Harald Welte >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > > > -- > Public Key: https://flowcrypt.com/pub/kheimerl at cs.washington.edu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaddih at gmail.com Mon Oct 22 22:36:14 2018 From: shaddih at gmail.com (Shaddi Hasan) Date: Tue, 23 Oct 2018 11:36:14 +1300 Subject: CommunityCellularManager (Re: Network interconnection over VPN/SIP) In-Reply-To: References: <20181017130607.GA15741@my.box> <20181022195915.GS3958@nataraja> Message-ID: Hi folks, Thanks for your clarifications Kurtis and Matt. The project was not abandoned, but we transitioned the project to community-driven development a few weeks ago. It's quiet now but at least a couple of us have discussed how to continue driving development forward. Adopting the new post-NITB stack is probably highest on the priority list after supporting ongoing deployments (given limited resources, support of existing deployments has meant no new feature work). There is no "internal tool" replacing CCM, not sure where that info came from. Shaddi sent from a phone On Tue, Oct 23, 2018, 11:01 Matthew Johnson wrote: > Unfortunately I have no info about new development, only speculation from > the site being archived and things heard thirdhand about people getting > reassigned with no details. I should be more conservative/specific when > putting assertions onto public mailing lists : ) > > Kurtis is right, that CCM was never officially brought into TIP, and was > just a Facebook incubated project too. There are a couple of us using CCM > in the community, but we haven?t had the time or resources to do much work > on it over the last few months. People are open do doing code review and > accepting patches on the co-cell/ccm repo, but > facebookincubator/CommunityCellularManager has been officially archived > with no plan for future work. > -Matt J. > On Mon, Oct 22, 2018 at 14:41 Kurtis Heimerl > wrote: > >> Some clarifications: >> >> On Mon, Oct 22, 2018 at 1:06 PM Harald Welte >> wrote: >> >>> Hi Matthew, >>> >>> On Mon, Oct 22, 2018 at 11:51:32AM -0700, Matthew Johnson wrote: >>> > to public voip network communication. The project was originally run >>> by the >>> > Telecom Infra Project, but was abandoned by them last year >>> >>> It's sad to hear that it has been officially abandoned :( >>> >>> It was more or less apparent to me that priorities had somewhat >>> changed/shifted >>> and that none of the more or less expected steps (like porting it to the >>> post-NITB osmocom stack) have happened. >>> >> >> Couple clarifications, CCM was never part of TIP and was instead an FB >> project. Abandoned is also maybe the wrong term; internal development at FB >> ended and development was transferred out of the company. There isn't a lot >> of activity now though, aside from the ongoing deployments. >> >> >>> >>> > after they moved to a new (unfortunately private) internal tool >>> >>> This is the first time I'm hearing about some private internal tool that >>> replaces CCM. Are you able to share more information about this? >>> >>> >> As is the nature of private internal tools, no. It's not really a >> replacement for CCM though, interests have moved in a different direction >> (or had when I was still there). >> >> >>> >>> I've asked the OpenCellular project to clarify this in their forum, see >>> >>> http://ocforum.telecominfraproject.com/t/status-of-communitycellularmanager/86 >>> >>> Unfortunately the Forum doesn't [yet] seem to be very active. >>> >>> Regards, >>> Harald >>> >>> -- >>> - Harald Welte >>> http://laforge.gnumonks.org/ >>> >>> ============================================================================ >>> "Privacy in residential applications is a desirable marketing option." >>> (ETSI EN 300 175-7 Ch. >>> A6) >>> >> >> >> -- >> Public Key: https://flowcrypt.com/pub/kheimerl at cs.washington.edu >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kheimerl at cs.washington.edu Tue Oct 23 06:04:03 2018 From: kheimerl at cs.washington.edu (Kurtis Heimerl) Date: Mon, 22 Oct 2018 23:04:03 -0700 Subject: Status of external USSD applications? In-Reply-To: References: <20181019204323.GW25900@nataraja> <60bb3302-8b54-5b3f-527e-133657672c86@rhizomatica.org> Message-ID: If you make any progress let us know! We're not spending cycles there now but it would be nice to not have our custom fork anymore. On Mon, Oct 22, 2018 at 3:20 AM Keith wrote: > > On 22/10/2018 10:18, Kurtis Heimerl wrote: > > The details of the implementation were posted here in January > > (https://www.mail-archive.com/openbsc at lists.osmocom.org/msg08419.html). > > Ah Thanks Kurtis! I remember seeing that now. > > > > > > Our understanding was that the recently accepted USSD patches would > > match much of our functionality so the branch has not seen much active > > development. I am unsure of the difficulties of integrating > > ussd-airflow into the current implementation. > > I guess the key might be Rowan's sup_airflow > https://github.com/rowanphipps/sup_airflow > > as the new osmo-hlr external USSD handler basically passes GSUP through > from the MSC, IIUC > > It's now on my list of TODO. > > Thanks! > > k > > > -- Public Key: https://flowcrypt.com/pub/kheimerl at cs.washington.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Oct 24 09:40:01 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 24 Oct 2018 11:40:01 +0200 Subject: OC-2G merge to osmo-bts Message-ID: <20181024094001.GJ27815@nataraja> Dear Osmocom team, Omar has thankfully submitted patches for inclusion of OC-2G support to gerrit, see https://gerrit.osmocom.org/#/c/osmo-bts/+/11447/ for the bulk of the code. An initial review showed there are *many* parts that are identical to osmo-bts-litecell15, and we generally don't like "copy+paste" programming. In the end we have multiple compies of essentially the same source files, becoming a maintenance problem over time, when fixes are applied to one copy, but not the other. I've manually looked through each of the files and looked at the differences between the oc2g and the lc15 counterpart. == 100% identical to osmo-bts-sysmo or osmo-bts-lc15: oml_router.c oml_router.h misc/oc2gbts_nl.c == 99% identical to lc15 (just names changed) hw_misc.h hw_misc.c l1_transp.h l1_trans_hw.c oc2gbts.c / lc15bts.c oc2gbts_vty.c / lc15bts_vty.c oml.c tch.c utils.c utils.h l1_if.h misc/oc2gbts_bts.h misc/oc2gbts_bid.h misc/oc2gbts_clock.h misc/oc2gbts_clock.c misc/oc2gbts_led.c misc/oc2gbts_swd.c misc/oc2gbts_swd.h == 80% identical to lc15 (some small changes) l1_if.c misc/oc2gbts_bts.c misc/oc2gbts_mgr.c misc/oc2gbts_mgr.h misc/oc2gbts_mgr_nl.c misc/oc2gbts_temp.c misc/oc2gbts_temp.h == more differences compared to lc15, possibly not intentional? / what to do? misc/oc2gbts_temp.c misc/oc2gbts_mgr_vty.c misc/oc2gbts_misc.c misc/oc2gbts_par.c misc/oc2gbts_power.c misc/oc2gbts_util.c So we have to discuss how to go about this. The 100% identical files are easy, one can simply lik the existing implementation. We could also introduce a "src/nuran-common" directory for common code between the different models. For those parts with less similarity, this may require some refactoring, so that common/shared code goes to common/shared files and really only those bits that differ are handled in the respective implementations. Given that osmo-bts-litecell15 also started as copy of osmo-bts-sysmo, there may be room for further unification, but let's not conflate those two discussions. In terms of process, * we could first merge all the copies and then further unify the code, or * we could first modify the existing core/lc15 code to be able to merge OC2G coe without introducing lots of copied code. Any comments/suggestions/ideas? 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 Wed Oct 24 10:41:19 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 24 Oct 2018 12:41:19 +0200 Subject: OC-2G merge to osmo-bts In-Reply-To: <20181024094001.GJ27815@nataraja> References: <20181024094001.GJ27815@nataraja> Message-ID: Hi, We should add another point into the discussion. Who and how are going to test these changes? If I understand correctly code from Omar is rebased on top of current osmo-bts master, and has been tested at least in some general scenarios? If that's the case, it probably makes sense to merge them as it is now, and then either or both: * Do the refactoring and ask someone with an OC-2G to test again after refactoring * Add automatic testing for OC-2G to make sure we don't break stuff ** Add support for OC-2G in osmo-gsm-tester ** Add support for OC-2G in TTCN3(+osmo-gsm-tester) Once it's merged, we can create a ticket with information from your e-mail on how to do the refactor. 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 laforge at gnumonks.org Wed Oct 24 11:01:41 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 24 Oct 2018 13:01:41 +0200 Subject: OC-2G merge to osmo-bts In-Reply-To: References: <20181024094001.GJ27815@nataraja> Message-ID: <20181024110141.GO27815@nataraja> On Wed, Oct 24, 2018 at 12:41:19PM +0200, Pau Espin Pedrol wrote: > We should add another point into the discussion. Who and how are going to > test these changes? Using actual OC-2G hardware with both osmo-gsm-tester as well as with BTS_Tests.ttcn, even with an extended version of BTS_Tests.ttcn addressing its various gaps in coverage so far. > If I understand correctly code from Omar is rebased on top of current > osmo-bts master, and has been tested at least in some general scenarios? I don't know anything about that, sorry. I would presume some basic manual testing with a few phones was performed? -- - 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 Oct 24 20:00:18 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 24 Oct 2018 22:00:18 +0200 Subject: OsmoDevCon 2019 date poll Message-ID: <20181024200018.GA27815@nataraja> Dear all, I would like to get your input as to when we should schedule OsmoDevCon 2019. NOTE: OsmoDevCon is our "for developers by developers" event, not to be confused with OsmoCon, our public conference. If we want to stay with the usual "Friday through Monday in April" arrangement, we have the following options: April 05-08, 2019 April 12-15, 2019 April 26-29, 2019 The one missing weekend in the list above is the easter weekend, which is probably a good idea to exclude as flights and hotels are more expensive during that time, and people might have other plans during holidays. I would like to invite anyone planning to attend the Osmocom Developer Conference 2019 to participate in the poll at https://dudle.inf.tu-dresden.de/OsmoDevCon2019/ to state their availability/preference. The Dudle only shows the first day of the four days of OsmoDevCon. Looking forward to your feedback so we can settle on a date soon. Thanks! Kind 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 renxianyuanqi at gmail.com Fri Oct 26 07:10:01 2018 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Fri, 26 Oct 2018 15:10:01 +0800 Subject: [openbsc 0.15.0.776-3824] testsuite: 13 15 25 26 27 28 29 30 31 32 33 failed Message-ID: Dear all? When I build osmocom 3G [ https://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G] , openbsc branch?vlr_3g make check failed : ERROR: 32 tests were run, > 11 failed unexpectedly. > 1 test was skipped. Clone and build with 3G-config-example from: script: 3G-config-example.tar Anybody can help me fix it? Thanks! ---------------------------------------------------------------------------- ??0xroot https:// cn0xroot.com ---------------------------------------------------------------------------- more info from openbsc's testsuite.log : | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" > > | | #define PACKAGE_URL "" > > | | #define PACKAGE "openbsc" > > | | #define VERSION "0.15.0.776-3824" > > | | #define BUILD_SMPP 1 > > | | #define BUILD_IU 1 > > | | /* end confdefs.h. */ > > | | #include > > | configure:6147: result: gcc -E > > | configure:6167: gcc -E conftest.c > > | configure:6167: $? = 0 > > | configure:6181: gcc -E conftest.c > > | conftest.c:13:28: fatal error: ac_nonexistent.h: No such file or >> directory > > | compilation terminated. > > | configure:6181: $? = 1 > > | configure: failed program was: > > | | /* confdefs.h */ > > | | #define PACKAGE_NAME "openbsc" > > | | #define PACKAGE_TARNAME "openbsc" > > | | #define PACKAGE_VERSION "0.15.0.776-3824" > > | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" > > | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" > > | | #define PACKAGE_URL "" > > | | #define PACKAGE "openbsc" > > | | #define VERSION "0.15.0.776-3824" > > | | #define BUILD_SMPP 1 > > | | #define BUILD_IU 1 > > | | /* end confdefs.h. */ > > | | #include > > | configure:6210: checking for grep that handles long lines and -e > > | configure:6268: result: /bin/grep > > | configure:6273: checking for egrep > > | configure:6335: result: /bin/grep -E > > | configure:6340: checking for ANSI C header files > > | configure:6360: gcc -c -g -O2 conftest.c >&5 > > | configure:6360: $? = 0 > > | configure:6433: gcc -o conftest -g -O2 conftest.c >&5 > > | configure:6433: $? = 0 > > | configure:6433: ./conftest > > | configure:6433: $? = 0 > > | configure:6444: result: yes > > | configure:6457: checking for sys/types.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for sys/stat.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for stdlib.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for string.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for memory.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for strings.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for inttypes.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for stdint.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6457: checking for unistd.h > > | configure:6457: gcc -c -g -O2 conftest.c >&5 > > | configure:6457: $? = 0 > > | configure:6457: result: yes > > | configure:6471: checking dbi/dbd.h usability > > | configure:6471: gcc -c -g -O2 conftest.c >&5 > > | configure:6471: $? = 0 > > | configure:6471: result: yes > > | configure:6471: checking dbi/dbd.h presence > > | configure:6471: gcc -E conftest.c > > | configure:6471: $? = 0 > > | configure:6471: result: yes > > | configure:6471: checking for dbi/dbd.h > > | configure:6471: result: yes > > | configure:6487: checking pcap/pcap.h usability > > | configure:6487: gcc -c -g -O2 conftest.c >&5 > > | configure:6487: $? = 0 > > | configure:6487: result: yes > > | configure:6487: checking pcap/pcap.h presence > > | configure:6487: gcc -E conftest.c > > | configure:6487: $? = 0 > > | configure:6487: result: yes > > | configure:6487: checking for pcap/pcap.h > > | configure:6487: result: yes > > | configure:6511: checking cdk/cdk.h usability > > | configure:6511: gcc -c -g -O2 conftest.c >&5 > > | conftest.c:58:21: fatal error: cdk/cdk.h: No such file or directory > > | compilation terminated. > > | configure:6511: $? = 1 > > | configure: failed program was: > > | | /* confdefs.h */ > > | | #define PACKAGE_NAME "openbsc" > > | | #define PACKAGE_TARNAME "openbsc" > > | | #define PACKAGE_VERSION "0.15.0.776-3824" > > | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" > > | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" > > | | #define PACKAGE_URL "" > > | | #define PACKAGE "openbsc" > > | | #define VERSION "0.15.0.776-3824" > > | | #define BUILD_SMPP 1 > > | | #define BUILD_IU 1 > > | | #define STDC_HEADERS 1 > > | | #define HAVE_SYS_TYPES_H 1 > > | | #define HAVE_SYS_STAT_H 1 > > | | #define HAVE_STDLIB_H 1 > > | | #define HAVE_STRING_H 1 > > | | #define HAVE_MEMORY_H 1 > > | | #define HAVE_STRINGS_H 1 > > | | #define HAVE_INTTYPES_H 1 > > | | #define HAVE_STDINT_H 1 > > | | #define HAVE_UNISTD_H 1 > > | | #define HAVE_DBI_DBD_H 1 > > | | #define HAVE_PCAP_PCAP_H 1 > > | | /* end confdefs.h. */ > > | | #include > > | | #ifdef HAVE_SYS_TYPES_H > > | | # include > > | | #endif > > | | #ifdef HAVE_SYS_STAT_H > > | | # include > > | | #endif > > | | #ifdef STDC_HEADERS > > | | # include > > | | # include > > | | #else > > | | # ifdef HAVE_STDLIB_H > > | | # include > > | | # endif > > | | #endif > > | | #ifdef HAVE_STRING_H > > | | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H > > | | # include > > | | # endif > > | | # include > > | | #endif > > | | #ifdef HAVE_STRINGS_H > > | | # include > > | | #endif > > | | #ifdef HAVE_INTTYPES_H > > | | # include > > | | #endif > > | | #ifdef HAVE_STDINT_H > > | | # include > > | | #endif > > | | #ifdef HAVE_UNISTD_H > > | | # include > > | | #endif > > | | #include > > | configure:6511: result: no > > | configure:6511: checking cdk/cdk.h presence > > | configure:6511: gcc -E conftest.c > > | conftest.c:25:21: fatal error: cdk/cdk.h: No such file or directory > > | compilation terminated. > > | configure:6511: $? = 1 > > | configure: failed program was: > > | | /* confdefs.h */ > > | | #define PACKAGE_NAME "openbsc" > > | | #define PACKAGE_TARNAME "openbsc" > > | | #define PACKAGE_VERSION "0.15.0.776-3824" > > | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" > > | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" > > | | #define PACKAGE_URL "" > > | | #define PACKAGE "openbsc" > > | | #define VERSION "0.15.0.776-3824" > > | | #define BUILD_SMPP 1 > > | | #define BUILD_IU 1 > > | | #define STDC_HEADERS 1 > > | | #define HAVE_SYS_TYPES_H 1 > > | | #define HAVE_SYS_STAT_H 1 > > | | #define HAVE_STDLIB_H 1 > > | | #define HAVE_STRING_H 1 > > | | #define HAVE_MEMORY_H 1 > > | | #define HAVE_STRINGS_H 1 > > | | #define HAVE_INTTYPES_H 1 > > | | #define HAVE_STDINT_H 1 > > | | #define HAVE_UNISTD_H 1 > > | | #define HAVE_DBI_DBD_H 1 > > | | #define HAVE_PCAP_PCAP_H 1 > > | | /* end confdefs.h. */ > > | | #include > > | configure:6511: result: no > > | configure:6511: checking for cdk/cdk.h > > | configure:6511: result: no > > | configure:6535: checking for SQLITE3 > > | configure:6542: $PKG_CONFIG --exists --print-errors "sqlite3" > > | configure:6545: $? = 0 > > | configure:6559: $PKG_CONFIG --exists --print-errors "sqlite3" > > | configure:6562: $? = 0 > > | configure:6600: result: yes > > | configure:6619: checking if gcc supports -fvisibility=hidden > > | configure:6625: gcc -c -g -O2 -fvisibility=hidden conftest.c >&5 > > | configure:6625: $? = 0 > > | configure:6626: result: yes > > | configure:6637: checking whether C compiler accepts -Werror=implicit > > | configure:6656: gcc -c -g -O2 -Werror=implicit conftest.c >&5 > > | configure:6656: $? = 0 > > | configure:6664: result: yes > > | configure:6672: checking whether C compiler accepts >> -Werror=maybe-uninitialized > > | configure:6691: gcc -c -g -O2 -Werror=implicit >> -Werror=maybe-uninitialized conftest.c >&5 > > | configure:6691: $? = 0 > > | configure:6699: result: yes > > | configure:6707: checking whether C compiler accepts >> -Werror=memset-transposed-args > > | configure:6726: gcc -c -g -O2 -Werror=implicit >> -Werror=maybe-uninitialized -Werror=memset-transposed-args conftest.c >&5 > > | configure:6726: $? = 0 > > | configure:6734: result: yes > > | configure:6742: checking whether C compiler accepts >> -Werror=null-dereference > > | configure:6761: gcc -c -g -O2 -Werror=implicit >> -Werror=maybe-uninitialized -Werror=memset-transposed-args >> -Werror=null-dereference conftest.c >&5 > > | cc1: error: -Werror=null-dereference: no option -Wnull-dereference > > | configure:6761: $? = 1 > > | configure: failed program was: > > | | /* confdefs.h */ > > | | #define PACKAGE_NAME "openbsc" > > | | #define PACKAGE_TARNAME "openbsc" > > | | #define PACKAGE_VERSION "0.15.0.776-3824" > > | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" > > | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" > > | | #define PACKAGE_URL "" > > | | #define PACKAGE "openbsc" > > | | #define VERSION "0.15.0.776-3824" > > | | #define BUILD_SMPP 1 > > | | #define BUILD_IU 1 > > | | #define STDC_HEADERS 1 > > | | #define HAVE_SYS_TYPES_H 1 > > | | #define HAVE_SYS_STAT_H 1 > > | | #define HAVE_STDLIB_H 1 > > | | #define HAVE_STRING_H 1 > > | | #define HAVE_MEMORY_H 1 > > | | #define HAVE_STRINGS_H 1 > > | | #define HAVE_INTTYPES_H 1 > > | | #define HAVE_STDINT_H 1 > > | | #define HAVE_UNISTD_H 1 > > | | #define HAVE_DBI_DBD_H 1 > > | | #define HAVE_PCAP_PCAP_H 1 > > | | /* end confdefs.h. */ > > | | > > | | int > > | | main () > > | | { > > | | > > | | ; > > | | return 0; > > | | } > > | configure:6769: result: no > > | configure:6777: checking whether C compiler accepts >> -Werror=sizeof-array-argument > > | configure:6796: gcc -c -g -O2 -Werror=implicit >> -Werror=maybe-uninitialized -Werror=memset-transposed-args >> -Werror=sizeof-array-argument conftest.c >&5 > > | configure:6796: $? = 0 > > | configure:6804: result: yes > > | configure:6812: checking whether C compiler accepts >> -Werror=sizeof-pointer-memaccess > > | configure:6831: gcc -c -g -O2 -Werror=implicit >> -Werror=maybe-uninitialized -Werror=memset-transposed-args >> -Werror=sizeof-array-argument -Werror=sizeof-pointer-memaccess conftest.c >> >&5 > > | configure:6831: $? = 0 > > | configure:6839: result: yes > > | configure:6849: checking whether to enable code coverage support > > | configure:6858: result: no > > | configure:6870: checking whether struct tm has tm_gmtoff member > > | configure:6894: gcc -o conftest -g -O2 -Werror=implicit >> -Werror=maybe-uninitialized -Werror=memset-transposed-args >> -Werror=sizeof-array-argument -Werror=sizeof-pointer-memaccess >> conftest.c >&5 > > | configure:6894: $? = 0 > > | configure:6904: result: yes > > | configure:7176: checking whether to enable VTY/CTRL tests > > | configure:7178: result: no > > | configure:7302: checking that generated files are newer than configure > > | configure:7308: result: done > > | configure:7375: creating ./config.status > > | > > | ## ---------------------- ## > > | ## Running config.status. ## > > | ## ---------------------- ## > > | > > | This file was extended by openbsc config.status 0.15.0.776-3824, which >> was > > | generated by GNU Autoconf 2.69. Invocation command line was > > | > > | CONFIG_FILES = > > | CONFIG_HEADERS = > > | CONFIG_LINKS = > > | CONFIG_COMMANDS = > > | $ ./config.status > > | > > | on ubuntu > > | > > | config.status:994: creating openbsc.pc > > | config.status:994: creating include/openbsc/Makefile > > | config.status:994: creating include/Makefile > > | config.status:994: creating src/Makefile > > | config.status:994: creating src/libtrau/Makefile > > | config.status:994: creating src/libbsc/Makefile > > | config.status:994: creating src/libmsc/Makefile > > | config.status:994: creating src/libvlr/Makefile > > | config.status:994: creating src/libmgcp/Makefile > > | config.status:994: creating src/libcommon/Makefile > > | config.status:994: creating src/libfilter/Makefile > > | config.status:994: creating src/libiu/Makefile > > | config.status:994: creating src/libcommon-cs/Makefile > > | config.status:994: creating src/osmo-msc/Makefile > > | config.status:994: creating src/osmo-bsc/Makefile > > | config.status:994: creating src/osmo-bsc_nat/Makefile > > | config.status:994: creating src/osmo-bsc_mgcp/Makefile > > | config.status:994: creating src/ipaccess/Makefile > > | config.status:994: creating src/utils/Makefile > > | config.status:994: creating src/gprs/Makefile > > | config.status:994: creating tests/Makefile > > | config.status:994: creating tests/atlocal > > | config.status:994: creating tests/libiudummy/Makefile > > | config.status:994: creating tests/gsm0408/Makefile > > | config.status:994: creating tests/channel/Makefile > > | config.status:994: creating tests/bsc/Makefile > > | config.status:994: creating tests/bsc-nat/Makefile > > | config.status:994: creating tests/bsc-nat-trie/Makefile > > | config.status:994: creating tests/mgcp/Makefile > > | config.status:994: creating tests/gprs/Makefile > > | config.status:994: creating tests/gbproxy/Makefile > > | config.status:994: creating tests/abis/Makefile > > | config.status:994: creating tests/smpp/Makefile > > | config.status:994: creating tests/trau/Makefile > > | config.status:994: creating tests/sgsn/Makefile > > | config.status:994: creating tests/subscr/Makefile > > | config.status:994: creating tests/oap/Makefile > > | config.status:994: creating tests/gtphub/Makefile > > | config.status:994: creating tests/mm_auth/Makefile > > | config.status:994: creating tests/xid/Makefile > > | config.status:994: creating tests/sndcp_xid/Makefile > > | config.status:994: creating tests/slhc/Makefile > > | config.status:994: creating tests/v42bis/Makefile > > | config.status:994: creating tests/nanobts_omlattr/Makefile > > | config.status:994: creating tests/vlr/Makefile > > | config.status:994: creating tests/sms_queue/Makefile > > | config.status:994: creating tests/msc_vlr/Makefile > > | config.status:994: creating doc/Makefile > > | config.status:994: creating doc/examples/Makefile > > | config.status:994: creating Makefile > > | config.status:994: creating bscconfig.h > > | config.status:1223: executing tests/atconfig commands > > | config.status:1223: executing depfiles commands > > | > > | ## ---------------- ## > > | ## Cache variables. ## > > | ## ---------------- ## > > | > > | ac_cv_c_compiler_gnu=yes > > | ac_cv_env_CC_set= > > | ac_cv_env_CC_value= > > | ac_cv_env_CFLAGS_set= > > | ac_cv_env_CFLAGS_value= > > | ac_cv_env_CPPFLAGS_set= > > | ac_cv_env_CPPFLAGS_value= > > | ac_cv_env_CPP_set= > > | ac_cv_env_CPP_value= > > | ac_cv_env_LDFLAGS_set= > > | ac_cv_env_LDFLAGS_value= > > | ac_cv_env_LIBASN1C_CFLAGS_set= > > | ac_cv_env_LIBASN1C_CFLAGS_value= > > | ac_cv_env_LIBASN1C_LIBS_set= > > | ac_cv_env_LIBASN1C_LIBS_value= > > | ac_cv_env_LIBBCG729_CFLAGS_set= > > | ac_cv_env_LIBBCG729_CFLAGS_value= > > | ac_cv_env_LIBBCG729_LIBS_set= > > | ac_cv_env_LIBBCG729_LIBS_value= > > | ac_cv_env_LIBCARES_CFLAGS_set= > > | ac_cv_env_LIBCARES_CFLAGS_value= > > | ac_cv_env_LIBCARES_LIBS_set= > > | ac_cv_env_LIBCARES_LIBS_value= > > | ac_cv_env_LIBCRYPTO_CFLAGS_set= > > | ac_cv_env_LIBCRYPTO_CFLAGS_value= > > | ac_cv_env_LIBCRYPTO_LIBS_set= > > | ac_cv_env_LIBCRYPTO_LIBS_value= > > | ac_cv_env_LIBGTP_CFLAGS_set= > > | ac_cv_env_LIBGTP_CFLAGS_value= > > | ac_cv_env_LIBGTP_LIBS_set= > > | ac_cv_env_LIBGTP_LIBS_value= > > | ac_cv_env_LIBOSMOABIS_CFLAGS_set= > > | ac_cv_env_LIBOSMOABIS_CFLAGS_value= > > | ac_cv_env_LIBOSMOABIS_LIBS_set= > > | ac_cv_env_LIBOSMOABIS_LIBS_value= > > | ac_cv_env_LIBOSMOCORE_CFLAGS_set= > > | ac_cv_env_LIBOSMOCORE_CFLAGS_value= > > | ac_cv_env_LIBOSMOCORE_LIBS_set= > > | ac_cv_env_LIBOSMOCORE_LIBS_value= > > | ac_cv_env_LIBOSMOCTRL_CFLAGS_set= > > | ac_cv_env_LIBOSMOCTRL_CFLAGS_value= > > | ac_cv_env_LIBOSMOCTRL_LIBS_set= > > | ac_cv_env_LIBOSMOCTRL_LIBS_value= > > | ac_cv_env_LIBOSMOGB_CFLAGS_set= > > | ac_cv_env_LIBOSMOGB_CFLAGS_value= > > | ac_cv_env_LIBOSMOGB_LIBS_set= > > | ac_cv_env_LIBOSMOGB_LIBS_value= > > | ac_cv_env_LIBOSMOGSM_CFLAGS_set= > > | ac_cv_env_LIBOSMOGSM_CFLAGS_value= > > | ac_cv_env_LIBOSMOGSM_LIBS_set= > > | ac_cv_env_LIBOSMOGSM_LIBS_value= > > | ac_cv_env_LIBOSMONETIF_CFLAGS_set= > > | ac_cv_env_LIBOSMONETIF_CFLAGS_value= > > | ac_cv_env_LIBOSMONETIF_LIBS_set= > > | ac_cv_env_LIBOSMONETIF_LIBS_value= > > | ac_cv_env_LIBOSMORANAP_CFLAGS_set= > > | ac_cv_env_LIBOSMORANAP_CFLAGS_value= > > | ac_cv_env_LIBOSMORANAP_LIBS_set= > > | ac_cv_env_LIBOSMORANAP_LIBS_value= > > | ac_cv_env_LIBOSMOSCCP_CFLAGS_set= > > | ac_cv_env_LIBOSMOSCCP_CFLAGS_value= > > | ac_cv_env_LIBOSMOSCCP_LIBS_set= > > | ac_cv_env_LIBOSMOSCCP_LIBS_value= > > | ac_cv_env_LIBOSMOSIGTRAN_CFLAGS_set= > > | ac_cv_env_LIBOSMOSIGTRAN_CFLAGS_value= > > | ac_cv_env_LIBOSMOSIGTRAN_LIBS_set= > > | ac_cv_env_LIBOSMOSIGTRAN_LIBS_value= > > | ac_cv_env_LIBOSMOVTY_CFLAGS_set= > > | ac_cv_env_LIBOSMOVTY_CFLAGS_value= > > | ac_cv_env_LIBOSMOVTY_LIBS_set= > > | ac_cv_env_LIBOSMOVTY_LIBS_value= > > | ac_cv_env_LIBSMPP34_CFLAGS_set= > > | ac_cv_env_LIBSMPP34_CFLAGS_value= > > | ac_cv_env_LIBSMPP34_LIBS_set= > > | ac_cv_env_LIBSMPP34_LIBS_value= > > | ac_cv_env_LIBS_set= > > | ac_cv_env_LIBS_value= > > | ac_cv_env_PKG_CONFIG_LIBDIR_set= > > | ac_cv_env_PKG_CONFIG_LIBDIR_value= > > | ac_cv_env_PKG_CONFIG_PATH_set= > > | ac_cv_env_PKG_CONFIG_PATH_value= > > | ac_cv_env_PKG_CONFIG_set= > > | ac_cv_env_PKG_CONFIG_value= > > | ac_cv_env_PYTHON_set= > > | ac_cv_env_PYTHON_value= > > | ac_cv_env_SQLITE3_CFLAGS_set= > > | ac_cv_env_SQLITE3_CFLAGS_value= > > | ac_cv_env_SQLITE3_LIBS_set= > > | ac_cv_env_SQLITE3_LIBS_value= > > | ac_cv_env_build_alias_set= > > | ac_cv_env_build_alias_value= > > | ac_cv_env_host_alias_set= > > | ac_cv_env_host_alias_value= > > | ac_cv_env_target_alias_set= > > | ac_cv_env_target_alias_value= > > | ac_cv_header_cdk_cdk_h=no > > | ac_cv_header_dbi_dbd_h=yes > > | ac_cv_header_inttypes_h=yes > > | ac_cv_header_memory_h=yes > > | ac_cv_header_pcap_pcap_h=yes > > | ac_cv_header_stdc=yes > > | ac_cv_header_stdint_h=yes > > | ac_cv_header_stdlib_h=yes > > | ac_cv_header_string_h=yes > > | ac_cv_header_strings_h=yes > > | ac_cv_header_sys_stat_h=yes > > | ac_cv_header_sys_types_h=yes > > | ac_cv_header_unistd_h=yes > > | ac_cv_objext=o > > | ac_cv_path_EGREP='/bin/grep -E' > > | ac_cv_path_GREP=/bin/grep > > | ac_cv_path_PKG_CONFIG_INSTALLED=/usr/bin/pkg-config > > | ac_cv_path_ac_pt_PKG_CONFIG=/usr/bin/pkg-config > > | ac_cv_path_install='/usr/bin/install -c' > > | ac_cv_path_mkdir=/bin/mkdir > > | ac_cv_prog_AWK=mawk > > | ac_cv_prog_CPP='gcc -E' > > | ac_cv_prog_ac_ct_CC=gcc > > | ac_cv_prog_ac_ct_RANLIB=ranlib > > | ac_cv_prog_cc_c89= > > | ac_cv_prog_cc_g=yes > > | ac_cv_prog_make_make_set=yes > > | ac_cv_search_dlopen=-ldl > > | am_cv_CC_dependencies_compiler_type=gcc3 > > | am_cv_make_support_nested_variables=yes > > | am_cv_prog_cc_c_o=yes > > | ax_cv_check_cflags___Werror_implicit=yes > > | ax_cv_check_cflags___Werror_maybe_uninitialized=yes > > | ax_cv_check_cflags___Werror_memset_transposed_args=yes > > | ax_cv_check_cflags___Werror_null_dereference=no > > | ax_cv_check_cflags___Werror_sizeof_array_argument=yes > > | ax_cv_check_cflags___Werror_sizeof_pointer_memaccess=yes > > | osmo_cv_tm_includes_tm_gmtoff=yes > > | pkg_cv_LIBASN1C_CFLAGS='-I/usr/local/include/ -I/usr/local/include/asn1c' > > | pkg_cv_LIBASN1C_LIBS='-L/usr/local/lib -ltalloc -lasn1c' > > | pkg_cv_LIBCARES_CFLAGS= > > | pkg_cv_LIBCARES_LIBS=-lcares > > | pkg_cv_LIBCRYPTO_CFLAGS= > > | pkg_cv_LIBCRYPTO_LIBS=-lcrypto > > | pkg_cv_LIBGTP_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBGTP_LIBS='-L/usr/local/lib -lgtp' > > | pkg_cv_LIBOSMOABIS_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMOABIS_LIBS='-L/usr/local/lib -losmoabis' > > | pkg_cv_LIBOSMOCORE_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMOCORE_LIBS='-L/usr/local/lib -ltalloc -losmocore' > > | pkg_cv_LIBOSMOCTRL_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMOCTRL_LIBS='-L/usr/local/lib -ltalloc -losmoctrl -losmogsm >> -losmocore' > > | pkg_cv_LIBOSMOGB_CFLAGS='-fno-strict-aliasing -I/usr/local/include/' > > | pkg_cv_LIBOSMOGB_LIBS='-L/usr/local/lib -ltalloc -losmogb -losmovty >> -losmocore' > > | pkg_cv_LIBOSMOGSM_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMOGSM_LIBS='-L/usr/local/lib -ltalloc -losmogsm -losmocore' > > | pkg_cv_LIBOSMONETIF_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMONETIF_LIBS='-L/usr/local/lib -losmonetif' > > | pkg_cv_LIBOSMORANAP_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMORANAP_LIBS='-L/usr/local/lib -losmo-ranap' > > | pkg_cv_LIBOSMOSCCP_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMOSCCP_LIBS='-L/usr/local/lib -lsccp' > > | pkg_cv_LIBOSMOSIGTRAN_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMOSIGTRAN_LIBS='-L/usr/local/lib -losmo-sigtran' > > | pkg_cv_LIBOSMOVTY_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBOSMOVTY_LIBS='-L/usr/local/lib -ltalloc -losmovty -losmocore' > > | pkg_cv_LIBSMPP34_CFLAGS=-I/usr/local/include/ > > | pkg_cv_LIBSMPP34_LIBS='-L/usr/local/lib -lsmpp34' > > | pkg_cv_SQLITE3_CFLAGS= > > | pkg_cv_SQLITE3_LIBS=-lsqlite3 > > | > > | ## ----------------- ## > > | ## Output variables. ## > > | ## ----------------- ## > > | > > | ACLOCAL='${SHELL} >> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing >> aclocal-1.15' > > | AMDEPBACKSLASH='\' > > | AMDEP_FALSE='#' > > | AMDEP_TRUE='' > > | AMTAR='$${TAR-tar}' > > | AM_BACKSLASH='\' > > | AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)' > > | AM_DEFAULT_VERBOSITY='0' > > | AM_V='$(V)' > > | AUTOCONF='${SHELL} >> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing autoconf' > > | AUTOHEADER='${SHELL} >> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing >> autoheader' > > | AUTOMAKE='${SHELL} >> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing >> automake-1.15' > > | AWK='mawk' > > | BUILD_BSC_FALSE='#' > > | BUILD_BSC_TRUE='' > > | BUILD_IU_FALSE='#' > > | BUILD_IU_TRUE='' > > | BUILD_MGCP_TRANSCODING_FALSE='' > > | BUILD_MGCP_TRANSCODING_TRUE='#' > > | BUILD_NAT_FALSE='#' > > | BUILD_NAT_TRUE='' > > | BUILD_SMPP_FALSE='#' > > | BUILD_SMPP_TRUE='' > > | CC='gcc' > > | CCDEPMODE='depmode=gcc3' > > | CFLAGS='-g -O2 -Werror=implicit -Werror=maybe-uninitialized >> -Werror=memset-transposed-args -Werror=sizeof-array-argument >> -Werror=sizeof-pointer-memaccess' > > | COVERAGE_CFLAGS='' > > | COVERAGE_LDFLAGS='' > > | CPP='gcc -E' > > | CPPFLAGS='' > > | CYGPATH_W='echo' > > | DEFS='-DHAVE_CONFIG_H' > > | DEPDIR='.deps' > > | ECHO_C='' > > | ECHO_N='-n' > > | ECHO_T='' > > | EGREP='/bin/grep -E' > > | ENABLE_EXT_TESTS_FALSE='' > > | ENABLE_EXT_TESTS_TRUE='#' > > | EXEEXT='' > > | GREP='/bin/grep' > > | HAVE_LIBCARES_FALSE='#' > > | HAVE_LIBCARES_TRUE='' > > | HAVE_LIBCDK_FALSE='' > > | HAVE_LIBCDK_TRUE='#' > > | HAVE_LIBGTP_FALSE='#' > > | HAVE_LIBGTP_TRUE='' > > | HAVE_PCAP_FALSE='#' > > | HAVE_PCAP_TRUE='' > > | HAVE_SQLITE3_FALSE='#' > > | HAVE_SQLITE3_TRUE='' > > | INSTALL_DATA='${INSTALL} -m 644' > > | INSTALL_PROGRAM='${INSTALL}' > > | INSTALL_SCRIPT='${INSTALL}' > > | INSTALL_STRIP_PROGRAM='$(install_sh) -c -s' > > | LDFLAGS='' > > | LIBASN1C_CFLAGS='-I/usr/local/include/ -I/usr/local/include/asn1c' > > | LIBASN1C_LIBS='-L/usr/local/lib -ltalloc -lasn1c' > > | LIBBCG729_CFLAGS='' > > | LIBBCG729_LIBS='' > > | LIBCARES_CFLAGS='' > > | LIBCARES_LIBS='-lcares' > > | LIBCRYPTO_CFLAGS='' > > | LIBCRYPTO_LIBS='-lcrypto' > > | LIBGTP_CFLAGS='-I/usr/local/include/' > > | LIBGTP_LIBS='-L/usr/local/lib -lgtp' > > | LIBOBJS='' > > | LIBOSMOABIS_CFLAGS='-I/usr/local/include/' > > | LIBOSMOABIS_LIBS='-L/usr/local/lib -losmoabis' > > | LIBOSMOCORE_CFLAGS='-I/usr/local/include/' > > | LIBOSMOCORE_LIBS='-L/usr/local/lib -ltalloc -losmocore' > > | LIBOSMOCTRL_CFLAGS='-I/usr/local/include/' > > | LIBOSMOCTRL_LIBS='-L/usr/local/lib -ltalloc -losmoctrl -losmogsm >> -losmocore' > > | LIBOSMOGB_CFLAGS='-fno-strict-aliasing -I/usr/local/include/' > > | LIBOSMOGB_LIBS='-L/usr/local/lib -ltalloc -losmogb -losmovty -losmocore' > > | LIBOSMOGSM_CFLAGS='-I/usr/local/include/' > > | LIBOSMOGSM_LIBS='-L/usr/local/lib -ltalloc -losmogsm -losmocore' > > | LIBOSMONETIF_CFLAGS='-I/usr/local/include/' > > | LIBOSMONETIF_LIBS='-L/usr/local/lib -losmonetif' > > | LIBOSMORANAP_CFLAGS='-I/usr/local/include/' > > | LIBOSMORANAP_LIBS='-L/usr/local/lib -losmo-ranap' > > | LIBOSMOSCCP_CFLAGS='-I/usr/local/include/' > > | LIBOSMOSCCP_LIBS='-L/usr/local/lib -lsccp' > > | LIBOSMOSIGTRAN_CFLAGS='-I/usr/local/include/' > > | LIBOSMOSIGTRAN_LIBS='-L/usr/local/lib -losmo-sigtran' > > | LIBOSMOVTY_CFLAGS='-I/usr/local/include/' > > | LIBOSMOVTY_LIBS='-L/usr/local/lib -ltalloc -losmovty -losmocore' > > | LIBRARY_DL='-ldl ' > > | LIBRARY_GSM='' > > | LIBS='' > > | LIBSMPP34_CFLAGS='-I/usr/local/include/' > > | LIBSMPP34_LIBS='-L/usr/local/lib -lsmpp34' > > | LTLIBOBJS='' > > | MAKEINFO='${SHELL} >> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing makeinfo' > > | MKDIR_P='/bin/mkdir -p' > > | OBJEXT='o' > > | OSMOTESTEXT_CHECK='' > > | PACKAGE='openbsc' > > | PACKAGE_BUGREPORT='openbsc at lists.osmocom.org' > > | PACKAGE_NAME='openbsc' > > | PACKAGE_STRING='openbsc 0.15.0.776-3824' > > | PACKAGE_TARNAME='openbsc' > > | PACKAGE_URL='' > > | PACKAGE_VERSION='0.15.0.776-3824' > > | PATH_SEPARATOR=':' > > | PKG_CONFIG='/usr/bin/pkg-config' > > | PKG_CONFIG_INSTALLED='/usr/bin/pkg-config' > > | PKG_CONFIG_LIBDIR='' > > | PKG_CONFIG_PATH='' > > | PYTHON='' > > | PYTHON_EXEC_PREFIX='' > > | PYTHON_PLATFORM='' > > | PYTHON_PREFIX='' > > | PYTHON_VERSION='' > > | RANLIB='ranlib' > > | SET_MAKE='' > > | SHELL='/bin/bash' > > | SQLITE3_CFLAGS='' > > | SQLITE3_LIBS='-lsqlite3' > > | STRIP='' > > | SYMBOL_VISIBILITY='-fvisibility=hidden' > > | VERSION='0.15.0.776-3824' > > | ac_ct_CC='gcc' > > | am__EXEEXT_FALSE='' > > | am__EXEEXT_TRUE='#' > > | am__fastdepCC_FALSE='#' > > | am__fastdepCC_TRUE='' > > | am__include='include' > > | am__isrc='' > > | am__leading_dot='.' > > | am__nodep='_no' > > | am__quote='' > > | am__tar='$${TAR-tar} chof - "$$tardir"' > > | am__untar='$${TAR-tar} xf -' > > | bindir='${exec_prefix}/bin' > > | build_alias='' > > | datadir='${datarootdir}' > > | datarootdir='${prefix}/share' > > | docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' > > | dvidir='${docdir}' > > | exec_prefix='${prefix}' > > | found_libcares='yes' > > | found_libgtp='yes' > > | found_libgtp_and_libcares='yes' > > | found_sqlite3='yes' > > | host_alias='' > > | htmldir='${docdir}' > > | includedir='${prefix}/include' > > | infodir='${datarootdir}/info' > > | install_sh='${SHELL} >> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/install-sh' > > | libdir='${exec_prefix}/lib' > > | libexecdir='${exec_prefix}/libexec' > > | localedir='${datarootdir}/locale' > > | localstatedir='${prefix}/var' > > | mandir='${datarootdir}/man' > > | mkdir_p='$(MKDIR_P)' > > | oldincludedir='/usr/include' > > | osmo_ac_build_bsc='yes' > > | osmo_ac_build_nat='yes' > > | osmo_ac_build_smpp='yes' > > | osmo_ac_iu='yes' > > | osmo_ac_mgcp_transcoding='no' > > | pdfdir='${docdir}' > > | pkgpyexecdir='' > > ## ----------------------------------- ## > > ## openbsc 0.15.0.776-3824 test suite. ## > > ## ----------------------------------- ## > > >> testsuite: command line was: > > $ ./testsuite > > >> ## --------- ## > > ## Platform. ## > > ## --------- ## > > >> hostname = ubuntu > > uname -m = x86_64 > > uname -r = 4.15.0-36-generic > > uname -s = Linux > > uname -v = #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC 2018 > > >> /usr/bin/uname -p = unknown > > /bin/uname -X = unknown > > >> /bin/arch = unknown > > /usr/bin/arch -k = unknown > > /usr/convex/getsysinfo = unknown > > /usr/bin/hostinfo = unknown > > /bin/machine = unknown > > /usr/bin/oslevel = unknown > > /bin/universe = unknown > > >> PATH: /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests > > PATH: /usr/local/sbin > > PATH: /usr/local/bin > > PATH: /usr/sbin > > PATH: /usr/bin > > PATH: /sbin > > PATH: /bin > > PATH: /usr/games > > PATH: /usr/local/games > > >> testsuite: atconfig: > > | # Configurable variable values for building test suites. > > | # Generated by ./config.status. > > | # Copyright (C) 2012 Free Software Foundation, Inc. > > | > > | # The test suite will define top_srcdir=/../.. etc. > > | at_testdir='tests' > > | >> abs_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' > > "tests/testsuite.log" 11793L, 778307C >> 1,1 ?? > > | osmo_ac_mgcp_transcoding='no' > > | pdfdir='${docdir}' > > | pkgpyexecdir='' > > | pkgpythondir='' > > | prefix='/usr/local' > > | program_transform_name='s,x,x,' > > | psdir='${docdir}' > > | pyexecdir='' > > | pythondir='' > > | runstatedir='${localstatedir}/run' > > | sbindir='${exec_prefix}/sbin' > > | sharedstatedir='${prefix}/com' > > | sysconfdir='${prefix}/etc' > > | target_alias='' > > | > > | ## ----------- ## > > | ## confdefs.h. ## > > | ## ----------- ## > > | > > | /* confdefs.h */ > > | #define PACKAGE_NAME "openbsc" > > | #define PACKAGE_TARNAME "openbsc" > > | #define PACKAGE_VERSION "0.15.0.776-3824" > > | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" > > | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" > > | #define PACKAGE_URL "" > > | #define PACKAGE "openbsc" > > | #define VERSION "0.15.0.776-3824" > > | #define BUILD_SMPP 1 > > | #define BUILD_IU 1 > > | #define STDC_HEADERS 1 > > | #define HAVE_SYS_TYPES_H 1 > > | #define HAVE_SYS_STAT_H 1 > > | #define HAVE_STDLIB_H 1 > > | #define HAVE_STRING_H 1 > > | #define HAVE_MEMORY_H 1 > > | #define HAVE_STRINGS_H 1 > > | #define HAVE_INTTYPES_H 1 > > | #define HAVE_STDINT_H 1 > > | #define HAVE_UNISTD_H 1 > > | #define HAVE_DBI_DBD_H 1 > > | #define HAVE_PCAP_PCAP_H 1 > > | #define HAVE_TM_GMTOFF_IN_TM 1 > > | > > | configure: exit 0 > > >> >> 11754,1 ?? > > | pkgpythondir='' > > | prefix='/usr/local' > > | program_transform_name='s,x,x,' > > | psdir='${docdir}' > > | pyexecdir='' > > | pythondir='' > > | runstatedir='${localstatedir}/run' > > | sbindir='${exec_prefix}/sbin' > > | sharedstatedir='${prefix}/com' > > | sysconfdir='${prefix}/etc' > > | target_alias='' > > | > > | ## ----------- ## > > | ## confdefs.h. ## > > | ## ----------- ## > > | > > | /* confdefs.h */ > > | #define PACKAGE_NAME "openbsc" > > | #define PACKAGE_TARNAME "openbsc" > > | #define PACKAGE_VERSION "0.15.0.776-3824" > > | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" > > | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" > > | #define PACKAGE_URL "" > > | #define PACKAGE "openbsc" > > | #define VERSION "0.15.0.776-3824" > > | #define BUILD_SMPP 1 > > | #define BUILD_IU 1 > > | #define STDC_HEADERS 1 > > | #define HAVE_SYS_TYPES_H 1 > > | #define HAVE_SYS_STAT_H 1 > > | #define HAVE_STDLIB_H 1 > > | #define HAVE_STRING_H 1 > > | #define HAVE_MEMORY_H 1 > > | #define HAVE_STRINGS_H 1 > > | #define HAVE_INTTYPES_H 1 > > | #define HAVE_STDINT_H 1 > > | #define HAVE_UNISTD_H 1 > > | #define HAVE_DBI_DBD_H 1 > > | #define HAVE_PCAP_PCAP_H 1 > > | #define HAVE_TM_GMTOFF_IN_TM 1 > > | > > | configure: exit 0 > > >> root at ubuntu:/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc# >> ls -la tests/testsuite.log > > -rw-r--r-- 1 root root 778307 10? 25 23:53 tests/testsuite.log > > root at ubuntu:/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc# >> vim tests/testsuite.log > > root at ubuntu:/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc# >> cat tests/testsuite.log |more > > ## ----------------------------------- ## > > ## openbsc 0.15.0.776-3824 test suite. ## > > ## ----------------------------------- ## > > >> testsuite: command line was: > > $ ./testsuite > > >> ## --------- ## > > ## Platform. ## > > ## --------- ## > > >> hostname = ubuntu > > uname -m = x86_64 > > uname -r = 4.15.0-36-generic > > uname -s = Linux > > uname -v = #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC 2018 > > >> /usr/bin/uname -p = unknown > > /bin/uname -X = unknown > > >> /bin/arch = unknown > > /usr/bin/arch -k = unknown > > /usr/convex/getsysinfo = unknown > > /usr/bin/hostinfo = unknown > > /bin/machine = unknown > > /usr/bin/oslevel = unknown > > /bin/universe = unknown > > >> PATH: /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests > > PATH: /usr/local/sbin > > PATH: /usr/local/bin > > PATH: /usr/sbin > > PATH: /usr/bin > > PATH: /sbin > > PATH: /bin > > PATH: /usr/games > > PATH: /usr/local/games > > >> testsuite: atconfig: > > | # Configurable variable values for building test suites. > > | # Generated by ./config.status. > > | # Copyright (C) 2012 Free Software Foundation, Inc. > > | > > | # The test suite will define top_srcdir=/../.. etc. > > | at_testdir='tests' > > | >> abs_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' > > | at_srcdir='.' > > | >> abs_srcdir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' > > | at_top_srcdir='..' > > | >> abs_top_srcdir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc' > > | at_top_build_prefix='../' > > | >> abs_top_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc' > > | > > | # Backward compatibility with Autotest <= 2.59b: > > | at_top_builddir=$at_top_build_prefix > > | > > | AUTOTEST_PATH='tests' > > | > > | SHELL=${CONFIG_SHELL-'/bin/bash'} > > >> testsuite: atlocal: > > | enable_nat_test='yes' > > | enable_smpp_test='yes' > > | enable_bsc_test='yes' > > | enable_mgcp_transcoding_test='no' > > | enable_sgsn_test='yes' > > | enable_oap_test='yes' > > | enable_gtphub_test='yes' > > >> ## ---------------- ## > > ## Tested programs. ## > > ## ---------------- ## > > >> ## ------------------ ## > > ## Running the tests. ## > > ## ------------------ ## > > testsuite: starting at: Thu Oct 25 23:53:55 PDT 2018 > > 1. gsm0408 (testsuite.at:4): ok (0m0.344s 0m0.000s) > > 2. bsc_subscr (testsuite.at:10): ok (0m0.005s 0m0.001s) > > 3. channel (testsuite.at:17): ok (0m0.005s 0m0.001s) > > 4. mgcp (testsuite.at:23): ok (0m0.002s 0m0.007s) > > 5. mgcp-trans (testsuite.at:29): skipped (testsuite.at:31) > > 6. mgcpgw_client (testsuite.at:36): ok (0m0.006s 0m0.001s) > > 7. gprs (testsuite.at:43): ok (0m0.003s 0m0.000s) > > 8. bsc-nat (testsuite.at:49): ok (0m0.009s 0m0.004s) > > 9. smpp (testsuite.at:59): ok (0m0.003s 0m0.003s) > > 10. bsc-nat-trie (testsuite.at:67): ok (0m0.006s 0m0.001s) > > 11. abis (testsuite.at:75): ok (0m0.002s 0m0.003s) > > 12. bsc (testsuite.at:81): ok (0m0.006s 0m0.000s) > > 14. trau (testsuite.at:94): ok (0m0.005s 0m0.000s) > > 16. oap (testsuite.at:107): ok (0m0.003s 0m0.003s) > > 17. gtphub (testsuite.at:115): ok (0m0.003s 0m0.006s) > > 18. mm_auth (testsuite.at:122): ok (0m0.006s 0m0.000s) > > 19. xid (testsuite.at:128): ok (0m0.006s 0m0.001s) > > 20. sndcp_xid (testsuite.at:135): ok (0m0.006s 0m0.000s) > > 21. slhc (testsuite.at:142): ok (0m0.004s 0m0.001s) > > 22. v42bis (testsuite.at:149): ok (0m0.009s 0m0.001s) > > 23. nanobts_omlattr (testsuite.at:156): ok (0m0.006s 0m0.000s) > > 24. sms_queue_test (testsuite.at:162): ok (0m0.005s 0m0.001s) > > testsuite: ending at: Thu Oct 25 23:53:57 PDT 2018 > > testsuite: test suite duration: 0h 0m 2s > > >> ## ------------- ## > > ## Test results. ## > > ## ------------- ## > > >> ERROR: 32 tests were run, > > 11 failed unexpectedly. > > 1 test was skipped. > > >> ## ------------------------ ## > > ## Summary of the failures. ## > > ## ------------------------ ## > > Failed tests: > > openbsc 0.15.0.776-3824 test suite test groups: > > >> NUM: FILE-NAME:LINE TEST-GROUP-NAME > > KEYWORDS > > >> 13: testsuite.at:88 gbproxy > > gbproxy > > 15: testsuite.at:100 sgsn > > sgsn > > 25: testsuite.at:169 msc_vlr_test_no_authen > > msc_vlr_test_no_authen > > 26: testsuite.at:176 msc_vlr_test_gsm_authen > > msc_vlr_test_gsm_authen > > 27: testsuite.at:183 msc_vlr_test_gsm_ciph > > msc_vlr_test_gsm_ciph > > 28: testsuite.at:190 msc_vlr_test_umts_authen > > msc_vlr_test_umts_authen > > 29: testsuite.at:197 msc_vlr_test_hlr_reject > > msc_vlr_test_hlr_reject > > 30: testsuite.at:204 msc_vlr_test_hlr_timeout > > msc_vlr_test_hlr_timeout > > 31: testsuite.at:211 msc_vlr_test_ms_timeout > > msc_vlr_test_ms_timeout > > 32: testsuite.at:218 msc_vlr_test_reject_concurrency > > msc_vlr_test_reject_concurrency > > 33: testsuite.at:225 msc_vlr_test_rest > > msc_vlr_test_rest > > >> Skipped tests: > > openbsc 0.15.0.776-3824 test suite test groups: > > >> NUM: FILE-NAME:LINE TEST-GROUP-NAME > > KEYWORDS > > >> 5: testsuite.at:29 mgcp-trans > > mgcp-trans > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renxianyuanqi at gmail.com Fri Oct 26 07:29:22 2018 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Fri, 26 Oct 2018 15:29:22 +0800 Subject: [openbsc 0.15.0.776-3824] testsuite: 13 15 25 26 27 28 29 30 31 32 33 failed Message-ID: Dear all? When I build osmocom 3G [ https://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G] , openbsc branch?vlr_3g make check failed : /bin/bash './testsuite' > > ## ----------------------------------- ## > > ## openbsc 0.15.0.776-3824 test suite. ## > > ## ----------------------------------- ## > > >> Regression tests. > > >> 1: gsm0408 ok > > 2: bsc_subscr ok > > 3: channel ok > > 4: mgcp ok > > 5: mgcp-trans skipped ( >> testsuite.at:31) > > 6: mgcpgw_client ok > > 7: gprs ok > > 8: bsc-nat ok > > 9: smpp ok > > 10: bsc-nat-trie ok > > 11: abis ok > > 12: bsc ok > > 13: gbproxy FAILED ( >> testsuite.at:91) > > 14: trau ok > > 15: sgsn FAILED ( >> testsuite.at:104) > > 16: oap ok > > 17: gtphub ok > > 18: mm_auth ok > > 19: xid ok > > 20: sndcp_xid ok > > 21: slhc ok > > 22: v42bis ok > > 23: nanobts_omlattr ok > > 24: sms_queue_test ok > > 25: msc_vlr_test_no_authen FAILED ( >> testsuite.at:173) > > 26: msc_vlr_test_gsm_authen FAILED ( >> testsuite.at:180) > > 27: msc_vlr_test_gsm_ciph FAILED ( >> testsuite.at:187) > > 28: msc_vlr_test_umts_authen FAILED ( >> testsuite.at:194) > > 29: msc_vlr_test_hlr_reject FAILED ( >> testsuite.at:201) > > 30: msc_vlr_test_hlr_timeout FAILED ( >> testsuite.at:208) > > 31: msc_vlr_test_ms_timeout FAILED ( >> testsuite.at:215) > > 32: msc_vlr_test_reject_concurrency FAILED ( >> testsuite.at:222) > > 33: msc_vlr_test_rest FAILED ( >> testsuite.at:229) > > >> ## ------------- ## > > ## Test results. ## > > ## ------------- ## > > >> ERROR: 32 tests were run, > > 11 failed unexpectedly. > > 1 test was skipped. > > ## -------------------------- ## > > ## testsuite.log was created. ## > > ## -------------------------- ## > > Clone and build with 3G-config-example from: script: 3G-config-example.tar Anybody can help me fix it? Thanks! ---------------------------------------------------------------------------- ??0xroot https:// cn0xroot.com ---------------------------------------------------------------------------- more info from openbsc's testsuite.log : > cat tests/testsuite.log |more > > ## ----------------------------------- ## > > ## openbsc 0.15.0.776-3824 test suite. ## > > ## ----------------------------------- ## > > >> testsuite: command line was: > > $ ./testsuite > > >> ## --------- ## > > ## Platform. ## > > ## --------- ## > > >> hostname = ubuntu > > uname -m = x86_64 > > uname -r = 4.15.0-36-generic > > uname -s = Linux > > uname -v = #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC 2018 > > >> /usr/bin/uname -p = unknown > > /bin/uname -X = unknown > > >> /bin/arch = unknown > > /usr/bin/arch -k = unknown > > /usr/convex/getsysinfo = unknown > > /usr/bin/hostinfo = unknown > > /bin/machine = unknown > > /usr/bin/oslevel = unknown > > /bin/universe = unknown > > >> PATH: /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests > > PATH: /usr/local/sbin > > PATH: /usr/local/bin > > PATH: /usr/sbin > > PATH: /usr/bin > > PATH: /sbin > > PATH: /bin > > PATH: /usr/games > > PATH: /usr/local/games > > >> testsuite: atconfig: > > | # Configurable variable values for building test suites. > > | # Generated by ./config.status. > > | # Copyright (C) 2012 Free Software Foundation, Inc. > > | > > | # The test suite will define top_srcdir=/../.. etc. > > | at_testdir='tests' > > | >> abs_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' > > | at_srcdir='.' > > | >> abs_srcdir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' > > | at_top_srcdir='..' > > | >> abs_top_srcdir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc' > > | at_top_build_prefix='../' > > | >> abs_top_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc' > > | > > | # Backward compatibility with Autotest <= 2.59b: > > | at_top_builddir=$at_top_build_prefix > > | > > | AUTOTEST_PATH='tests' > > | > > | SHELL=${CONFIG_SHELL-'/bin/bash'} > > >> testsuite: atlocal: > > | enable_nat_test='yes' > > | enable_smpp_test='yes' > > | enable_bsc_test='yes' > > | enable_mgcp_transcoding_test='no' > > | enable_sgsn_test='yes' > > | enable_oap_test='yes' > > | enable_gtphub_test='yes' > > >> ## ---------------- ## > > ## Tested programs. ## > > ## ---------------- ## > > >> ## ------------------ ## > > ## Running the tests. ## > > ## ------------------ ## > > testsuite: starting at: Fri Oct 26 00:21:33 PDT 2018 > > 1. gsm0408 (testsuite.at:4): ok (0m0.334s 0m0.004s) > > 2. bsc_subscr (testsuite.at:10): ok (0m0.005s 0m0.000s) > > 3. channel (testsuite.at:17): ok (0m0.005s 0m0.000s) > > 4. mgcp (testsuite.at:23): ok (0m0.007s 0m0.000s) > > 5. mgcp-trans (testsuite.at:29): skipped (testsuite.at:31) > > 6. mgcpgw_client (testsuite.at:36): ok (0m0.005s 0m0.000s) > > 7. gprs (testsuite.at:43): ok (0m0.003s 0m0.000s) > > 8. bsc-nat (testsuite.at:49): ok (0m0.010s 0m0.002s) > > 9. smpp (testsuite.at:59): ok (0m0.008s 0m0.000s) > > 10. bsc-nat-trie (testsuite.at:67): ok (0m0.007s 0m0.000s) > > 11. abis (testsuite.at:75): ok (0m0.007s 0m0.001s) > > 12. bsc (testsuite.at:81): ok (0m0.002s 0m0.004s) > > 14. trau (testsuite.at:94): ok (0m0.005s 0m0.000s) > > 16. oap (testsuite.at:107): ok (0m0.005s 0m0.000s) > > 17. gtphub (testsuite.at:115): ok (0m0.003s 0m0.006s) > > 18. mm_auth (testsuite.at:122): ok (0m0.002s 0m0.003s) > > 19. xid (testsuite.at:128): ok (0m0.002s 0m0.005s) > > 20. sndcp_xid (testsuite.at:135): ok (0m0.010s 0m0.001s) > > 21. slhc (testsuite.at:142): ok (0m0.003s 0m0.001s) > > 22. v42bis (testsuite.at:149): ok (0m0.008s 0m0.001s) > > 23. nanobts_omlattr (testsuite.at:156): ok (0m0.006s 0m0.000s) > > 24. sms_queue_test (testsuite.at:162): ok (0m0.008s 0m0.000s) > > testsuite: ending at: Fri Oct 26 00:21:35 PDT 2018 > > testsuite: test suite duration: 0h 0m 2s > > >> ## ------------- ## > > ## Test results. ## > > ## ------------- ## > > >> ERROR: 32 tests were run, > > 11 failed unexpectedly. > > 1 test was skipped. > > >> ## ------------------------ ## > > ## Summary of the failures. ## > > ## ------------------------ ## > > Failed tests: > > openbsc 0.15.0.776-3824 test suite test groups: > > >> NUM: FILE-NAME:LINE TEST-GROUP-NAME > > KEYWORDS > > >> 13: testsuite.at:88 gbproxy > > gbproxy > > 15: testsuite.at:100 sgsn > > sgsn > > 25: testsuite.at:169 msc_vlr_test_no_authen > > msc_vlr_test_no_authen > > 26: testsuite.at:176 msc_vlr_test_gsm_authen > > msc_vlr_test_gsm_authen > > 27: testsuite.at:183 msc_vlr_test_gsm_ciph > > msc_vlr_test_gsm_ciph > > 28: testsuite.at:190 msc_vlr_test_umts_authen > > msc_vlr_test_umts_authen > > 29: testsuite.at:197 msc_vlr_test_hlr_reject > > msc_vlr_test_hlr_reject > > 30: testsuite.at:204 msc_vlr_test_hlr_timeout > > msc_vlr_test_hlr_timeout > > 31: testsuite.at:211 msc_vlr_test_ms_timeout > > msc_vlr_test_ms_timeout > > 32: testsuite.at:218 msc_vlr_test_reject_concurrency > > msc_vlr_test_reject_concurrency > > 33: testsuite.at:225 msc_vlr_test_rest > > msc_vlr_test_rest > > >> Skipped tests: > > openbsc 0.15.0.776-3824 test suite test groups: > > >> NUM: FILE-NAME:LINE TEST-GROUP-NAME > > KEYWORDS > > >> 5: testsuite.at:29 mgcp-trans > > mgcp-trans > > >> ## ---------------------- ## > > ## Detailed failed tests. ## > > ## ---------------------- ## > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From renxianyuanqi at gmail.com Fri Oct 26 07:33:12 2018 From: renxianyuanqi at gmail.com (=?UTF-8?B?6Zuq56KnIDB4cm9vdA==?=) Date: Fri, 26 Oct 2018 15:33:12 +0800 Subject: [openbsc 0.15.0.776-3824] testsuite: 13 15 25 26 27 28 29 30 31 32 33 failed In-Reply-To: References: Message-ID: I am apologize for put error testsuite.log info, already send a new email with userfull info just now. Withdraw this email please. Thanks? ?? 0xroot ?2018?10?26??? ??3:10??? > Dear all? > When I build osmocom 3G [ > https://osmocom.org/projects/cellular-infrastructure/wiki/Getting_Started_with_3G] > , openbsc branch?vlr_3g make check failed : > > ERROR: 32 tests were run, >> 11 failed unexpectedly. >> 1 test was skipped. > > > Clone and build with 3G-config-example from: > script: 3G-config-example.tar > > > Anybody can help me fix it? > > Thanks! > > ---------------------------------------------------------------------------- > ??0xroot https:// cn0xroot.com > > ---------------------------------------------------------------------------- > > more info from openbsc's testsuite.log : > > | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" >> >> | | #define PACKAGE_URL "" >> >> | | #define PACKAGE "openbsc" >> >> | | #define VERSION "0.15.0.776-3824" >> >> | | #define BUILD_SMPP 1 >> >> | | #define BUILD_IU 1 >> >> | | /* end confdefs.h. */ >> >> | | #include >> >> | configure:6147: result: gcc -E >> >> | configure:6167: gcc -E conftest.c >> >> | configure:6167: $? = 0 >> >> | configure:6181: gcc -E conftest.c >> >> | conftest.c:13:28: fatal error: ac_nonexistent.h: No such file or >>> directory >> >> | compilation terminated. >> >> | configure:6181: $? = 1 >> >> | configure: failed program was: >> >> | | /* confdefs.h */ >> >> | | #define PACKAGE_NAME "openbsc" >> >> | | #define PACKAGE_TARNAME "openbsc" >> >> | | #define PACKAGE_VERSION "0.15.0.776-3824" >> >> | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" >> >> | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" >> >> | | #define PACKAGE_URL "" >> >> | | #define PACKAGE "openbsc" >> >> | | #define VERSION "0.15.0.776-3824" >> >> | | #define BUILD_SMPP 1 >> >> | | #define BUILD_IU 1 >> >> | | /* end confdefs.h. */ >> >> | | #include >> >> | configure:6210: checking for grep that handles long lines and -e >> >> | configure:6268: result: /bin/grep >> >> | configure:6273: checking for egrep >> >> | configure:6335: result: /bin/grep -E >> >> | configure:6340: checking for ANSI C header files >> >> | configure:6360: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6360: $? = 0 >> >> | configure:6433: gcc -o conftest -g -O2 conftest.c >&5 >> >> | configure:6433: $? = 0 >> >> | configure:6433: ./conftest >> >> | configure:6433: $? = 0 >> >> | configure:6444: result: yes >> >> | configure:6457: checking for sys/types.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for sys/stat.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for stdlib.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for string.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for memory.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for strings.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for inttypes.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for stdint.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6457: checking for unistd.h >> >> | configure:6457: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6457: $? = 0 >> >> | configure:6457: result: yes >> >> | configure:6471: checking dbi/dbd.h usability >> >> | configure:6471: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6471: $? = 0 >> >> | configure:6471: result: yes >> >> | configure:6471: checking dbi/dbd.h presence >> >> | configure:6471: gcc -E conftest.c >> >> | configure:6471: $? = 0 >> >> | configure:6471: result: yes >> >> | configure:6471: checking for dbi/dbd.h >> >> | configure:6471: result: yes >> >> | configure:6487: checking pcap/pcap.h usability >> >> | configure:6487: gcc -c -g -O2 conftest.c >&5 >> >> | configure:6487: $? = 0 >> >> | configure:6487: result: yes >> >> | configure:6487: checking pcap/pcap.h presence >> >> | configure:6487: gcc -E conftest.c >> >> | configure:6487: $? = 0 >> >> | configure:6487: result: yes >> >> | configure:6487: checking for pcap/pcap.h >> >> | configure:6487: result: yes >> >> | configure:6511: checking cdk/cdk.h usability >> >> | configure:6511: gcc -c -g -O2 conftest.c >&5 >> >> | conftest.c:58:21: fatal error: cdk/cdk.h: No such file or directory >> >> | compilation terminated. >> >> | configure:6511: $? = 1 >> >> | configure: failed program was: >> >> | | /* confdefs.h */ >> >> | | #define PACKAGE_NAME "openbsc" >> >> | | #define PACKAGE_TARNAME "openbsc" >> >> | | #define PACKAGE_VERSION "0.15.0.776-3824" >> >> | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" >> >> | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" >> >> | | #define PACKAGE_URL "" >> >> | | #define PACKAGE "openbsc" >> >> | | #define VERSION "0.15.0.776-3824" >> >> | | #define BUILD_SMPP 1 >> >> | | #define BUILD_IU 1 >> >> | | #define STDC_HEADERS 1 >> >> | | #define HAVE_SYS_TYPES_H 1 >> >> | | #define HAVE_SYS_STAT_H 1 >> >> | | #define HAVE_STDLIB_H 1 >> >> | | #define HAVE_STRING_H 1 >> >> | | #define HAVE_MEMORY_H 1 >> >> | | #define HAVE_STRINGS_H 1 >> >> | | #define HAVE_INTTYPES_H 1 >> >> | | #define HAVE_STDINT_H 1 >> >> | | #define HAVE_UNISTD_H 1 >> >> | | #define HAVE_DBI_DBD_H 1 >> >> | | #define HAVE_PCAP_PCAP_H 1 >> >> | | /* end confdefs.h. */ >> >> | | #include >> >> | | #ifdef HAVE_SYS_TYPES_H >> >> | | # include >> >> | | #endif >> >> | | #ifdef HAVE_SYS_STAT_H >> >> | | # include >> >> | | #endif >> >> | | #ifdef STDC_HEADERS >> >> | | # include >> >> | | # include >> >> | | #else >> >> | | # ifdef HAVE_STDLIB_H >> >> | | # include >> >> | | # endif >> >> | | #endif >> >> | | #ifdef HAVE_STRING_H >> >> | | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H >> >> | | # include >> >> | | # endif >> >> | | # include >> >> | | #endif >> >> | | #ifdef HAVE_STRINGS_H >> >> | | # include >> >> | | #endif >> >> | | #ifdef HAVE_INTTYPES_H >> >> | | # include >> >> | | #endif >> >> | | #ifdef HAVE_STDINT_H >> >> | | # include >> >> | | #endif >> >> | | #ifdef HAVE_UNISTD_H >> >> | | # include >> >> | | #endif >> >> | | #include >> >> | configure:6511: result: no >> >> | configure:6511: checking cdk/cdk.h presence >> >> | configure:6511: gcc -E conftest.c >> >> | conftest.c:25:21: fatal error: cdk/cdk.h: No such file or directory >> >> | compilation terminated. >> >> | configure:6511: $? = 1 >> >> | configure: failed program was: >> >> | | /* confdefs.h */ >> >> | | #define PACKAGE_NAME "openbsc" >> >> | | #define PACKAGE_TARNAME "openbsc" >> >> | | #define PACKAGE_VERSION "0.15.0.776-3824" >> >> | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" >> >> | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" >> >> | | #define PACKAGE_URL "" >> >> | | #define PACKAGE "openbsc" >> >> | | #define VERSION "0.15.0.776-3824" >> >> | | #define BUILD_SMPP 1 >> >> | | #define BUILD_IU 1 >> >> | | #define STDC_HEADERS 1 >> >> | | #define HAVE_SYS_TYPES_H 1 >> >> | | #define HAVE_SYS_STAT_H 1 >> >> | | #define HAVE_STDLIB_H 1 >> >> | | #define HAVE_STRING_H 1 >> >> | | #define HAVE_MEMORY_H 1 >> >> | | #define HAVE_STRINGS_H 1 >> >> | | #define HAVE_INTTYPES_H 1 >> >> | | #define HAVE_STDINT_H 1 >> >> | | #define HAVE_UNISTD_H 1 >> >> | | #define HAVE_DBI_DBD_H 1 >> >> | | #define HAVE_PCAP_PCAP_H 1 >> >> | | /* end confdefs.h. */ >> >> | | #include >> >> | configure:6511: result: no >> >> | configure:6511: checking for cdk/cdk.h >> >> | configure:6511: result: no >> >> | configure:6535: checking for SQLITE3 >> >> | configure:6542: $PKG_CONFIG --exists --print-errors "sqlite3" >> >> | configure:6545: $? = 0 >> >> | configure:6559: $PKG_CONFIG --exists --print-errors "sqlite3" >> >> | configure:6562: $? = 0 >> >> | configure:6600: result: yes >> >> | configure:6619: checking if gcc supports -fvisibility=hidden >> >> | configure:6625: gcc -c -g -O2 -fvisibility=hidden conftest.c >&5 >> >> | configure:6625: $? = 0 >> >> | configure:6626: result: yes >> >> | configure:6637: checking whether C compiler accepts -Werror=implicit >> >> | configure:6656: gcc -c -g -O2 -Werror=implicit conftest.c >&5 >> >> | configure:6656: $? = 0 >> >> | configure:6664: result: yes >> >> | configure:6672: checking whether C compiler accepts >>> -Werror=maybe-uninitialized >> >> | configure:6691: gcc -c -g -O2 -Werror=implicit >>> -Werror=maybe-uninitialized conftest.c >&5 >> >> | configure:6691: $? = 0 >> >> | configure:6699: result: yes >> >> | configure:6707: checking whether C compiler accepts >>> -Werror=memset-transposed-args >> >> | configure:6726: gcc -c -g -O2 -Werror=implicit >>> -Werror=maybe-uninitialized -Werror=memset-transposed-args conftest.c >&5 >> >> | configure:6726: $? = 0 >> >> | configure:6734: result: yes >> >> | configure:6742: checking whether C compiler accepts >>> -Werror=null-dereference >> >> | configure:6761: gcc -c -g -O2 -Werror=implicit >>> -Werror=maybe-uninitialized -Werror=memset-transposed-args >>> -Werror=null-dereference conftest.c >&5 >> >> | cc1: error: -Werror=null-dereference: no option -Wnull-dereference >> >> | configure:6761: $? = 1 >> >> | configure: failed program was: >> >> | | /* confdefs.h */ >> >> | | #define PACKAGE_NAME "openbsc" >> >> | | #define PACKAGE_TARNAME "openbsc" >> >> | | #define PACKAGE_VERSION "0.15.0.776-3824" >> >> | | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" >> >> | | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" >> >> | | #define PACKAGE_URL "" >> >> | | #define PACKAGE "openbsc" >> >> | | #define VERSION "0.15.0.776-3824" >> >> | | #define BUILD_SMPP 1 >> >> | | #define BUILD_IU 1 >> >> | | #define STDC_HEADERS 1 >> >> | | #define HAVE_SYS_TYPES_H 1 >> >> | | #define HAVE_SYS_STAT_H 1 >> >> | | #define HAVE_STDLIB_H 1 >> >> | | #define HAVE_STRING_H 1 >> >> | | #define HAVE_MEMORY_H 1 >> >> | | #define HAVE_STRINGS_H 1 >> >> | | #define HAVE_INTTYPES_H 1 >> >> | | #define HAVE_STDINT_H 1 >> >> | | #define HAVE_UNISTD_H 1 >> >> | | #define HAVE_DBI_DBD_H 1 >> >> | | #define HAVE_PCAP_PCAP_H 1 >> >> | | /* end confdefs.h. */ >> >> | | >> >> | | int >> >> | | main () >> >> | | { >> >> | | >> >> | | ; >> >> | | return 0; >> >> | | } >> >> | configure:6769: result: no >> >> | configure:6777: checking whether C compiler accepts >>> -Werror=sizeof-array-argument >> >> | configure:6796: gcc -c -g -O2 -Werror=implicit >>> -Werror=maybe-uninitialized -Werror=memset-transposed-args >>> -Werror=sizeof-array-argument conftest.c >&5 >> >> | configure:6796: $? = 0 >> >> | configure:6804: result: yes >> >> | configure:6812: checking whether C compiler accepts >>> -Werror=sizeof-pointer-memaccess >> >> | configure:6831: gcc -c -g -O2 -Werror=implicit >>> -Werror=maybe-uninitialized -Werror=memset-transposed-args >>> -Werror=sizeof-array-argument -Werror=sizeof-pointer-memaccess conftest.c >>> >&5 >> >> | configure:6831: $? = 0 >> >> | configure:6839: result: yes >> >> | configure:6849: checking whether to enable code coverage support >> >> | configure:6858: result: no >> >> | configure:6870: checking whether struct tm has tm_gmtoff member >> >> | configure:6894: gcc -o conftest -g -O2 -Werror=implicit >>> -Werror=maybe-uninitialized -Werror=memset-transposed-args >>> -Werror=sizeof-array-argument -Werror=sizeof-pointer-memaccess >>> conftest.c >&5 >> >> | configure:6894: $? = 0 >> >> | configure:6904: result: yes >> >> | configure:7176: checking whether to enable VTY/CTRL tests >> >> | configure:7178: result: no >> >> | configure:7302: checking that generated files are newer than configure >> >> | configure:7308: result: done >> >> | configure:7375: creating ./config.status >> >> | >> >> | ## ---------------------- ## >> >> | ## Running config.status. ## >> >> | ## ---------------------- ## >> >> | >> >> | This file was extended by openbsc config.status 0.15.0.776-3824, which >>> was >> >> | generated by GNU Autoconf 2.69. Invocation command line was >> >> | >> >> | CONFIG_FILES = >> >> | CONFIG_HEADERS = >> >> | CONFIG_LINKS = >> >> | CONFIG_COMMANDS = >> >> | $ ./config.status >> >> | >> >> | on ubuntu >> >> | >> >> | config.status:994: creating openbsc.pc >> >> | config.status:994: creating include/openbsc/Makefile >> >> | config.status:994: creating include/Makefile >> >> | config.status:994: creating src/Makefile >> >> | config.status:994: creating src/libtrau/Makefile >> >> | config.status:994: creating src/libbsc/Makefile >> >> | config.status:994: creating src/libmsc/Makefile >> >> | config.status:994: creating src/libvlr/Makefile >> >> | config.status:994: creating src/libmgcp/Makefile >> >> | config.status:994: creating src/libcommon/Makefile >> >> | config.status:994: creating src/libfilter/Makefile >> >> | config.status:994: creating src/libiu/Makefile >> >> | config.status:994: creating src/libcommon-cs/Makefile >> >> | config.status:994: creating src/osmo-msc/Makefile >> >> | config.status:994: creating src/osmo-bsc/Makefile >> >> | config.status:994: creating src/osmo-bsc_nat/Makefile >> >> | config.status:994: creating src/osmo-bsc_mgcp/Makefile >> >> | config.status:994: creating src/ipaccess/Makefile >> >> | config.status:994: creating src/utils/Makefile >> >> | config.status:994: creating src/gprs/Makefile >> >> | config.status:994: creating tests/Makefile >> >> | config.status:994: creating tests/atlocal >> >> | config.status:994: creating tests/libiudummy/Makefile >> >> | config.status:994: creating tests/gsm0408/Makefile >> >> | config.status:994: creating tests/channel/Makefile >> >> | config.status:994: creating tests/bsc/Makefile >> >> | config.status:994: creating tests/bsc-nat/Makefile >> >> | config.status:994: creating tests/bsc-nat-trie/Makefile >> >> | config.status:994: creating tests/mgcp/Makefile >> >> | config.status:994: creating tests/gprs/Makefile >> >> | config.status:994: creating tests/gbproxy/Makefile >> >> | config.status:994: creating tests/abis/Makefile >> >> | config.status:994: creating tests/smpp/Makefile >> >> | config.status:994: creating tests/trau/Makefile >> >> | config.status:994: creating tests/sgsn/Makefile >> >> | config.status:994: creating tests/subscr/Makefile >> >> | config.status:994: creating tests/oap/Makefile >> >> | config.status:994: creating tests/gtphub/Makefile >> >> | config.status:994: creating tests/mm_auth/Makefile >> >> | config.status:994: creating tests/xid/Makefile >> >> | config.status:994: creating tests/sndcp_xid/Makefile >> >> | config.status:994: creating tests/slhc/Makefile >> >> | config.status:994: creating tests/v42bis/Makefile >> >> | config.status:994: creating tests/nanobts_omlattr/Makefile >> >> | config.status:994: creating tests/vlr/Makefile >> >> | config.status:994: creating tests/sms_queue/Makefile >> >> | config.status:994: creating tests/msc_vlr/Makefile >> >> | config.status:994: creating doc/Makefile >> >> | config.status:994: creating doc/examples/Makefile >> >> | config.status:994: creating Makefile >> >> | config.status:994: creating bscconfig.h >> >> | config.status:1223: executing tests/atconfig commands >> >> | config.status:1223: executing depfiles commands >> >> | >> >> | ## ---------------- ## >> >> | ## Cache variables. ## >> >> | ## ---------------- ## >> >> | >> >> | ac_cv_c_compiler_gnu=yes >> >> | ac_cv_env_CC_set= >> >> | ac_cv_env_CC_value= >> >> | ac_cv_env_CFLAGS_set= >> >> | ac_cv_env_CFLAGS_value= >> >> | ac_cv_env_CPPFLAGS_set= >> >> | ac_cv_env_CPPFLAGS_value= >> >> | ac_cv_env_CPP_set= >> >> | ac_cv_env_CPP_value= >> >> | ac_cv_env_LDFLAGS_set= >> >> | ac_cv_env_LDFLAGS_value= >> >> | ac_cv_env_LIBASN1C_CFLAGS_set= >> >> | ac_cv_env_LIBASN1C_CFLAGS_value= >> >> | ac_cv_env_LIBASN1C_LIBS_set= >> >> | ac_cv_env_LIBASN1C_LIBS_value= >> >> | ac_cv_env_LIBBCG729_CFLAGS_set= >> >> | ac_cv_env_LIBBCG729_CFLAGS_value= >> >> | ac_cv_env_LIBBCG729_LIBS_set= >> >> | ac_cv_env_LIBBCG729_LIBS_value= >> >> | ac_cv_env_LIBCARES_CFLAGS_set= >> >> | ac_cv_env_LIBCARES_CFLAGS_value= >> >> | ac_cv_env_LIBCARES_LIBS_set= >> >> | ac_cv_env_LIBCARES_LIBS_value= >> >> | ac_cv_env_LIBCRYPTO_CFLAGS_set= >> >> | ac_cv_env_LIBCRYPTO_CFLAGS_value= >> >> | ac_cv_env_LIBCRYPTO_LIBS_set= >> >> | ac_cv_env_LIBCRYPTO_LIBS_value= >> >> | ac_cv_env_LIBGTP_CFLAGS_set= >> >> | ac_cv_env_LIBGTP_CFLAGS_value= >> >> | ac_cv_env_LIBGTP_LIBS_set= >> >> | ac_cv_env_LIBGTP_LIBS_value= >> >> | ac_cv_env_LIBOSMOABIS_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOABIS_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOABIS_LIBS_set= >> >> | ac_cv_env_LIBOSMOABIS_LIBS_value= >> >> | ac_cv_env_LIBOSMOCORE_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOCORE_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOCORE_LIBS_set= >> >> | ac_cv_env_LIBOSMOCORE_LIBS_value= >> >> | ac_cv_env_LIBOSMOCTRL_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOCTRL_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOCTRL_LIBS_set= >> >> | ac_cv_env_LIBOSMOCTRL_LIBS_value= >> >> | ac_cv_env_LIBOSMOGB_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOGB_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOGB_LIBS_set= >> >> | ac_cv_env_LIBOSMOGB_LIBS_value= >> >> | ac_cv_env_LIBOSMOGSM_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOGSM_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOGSM_LIBS_set= >> >> | ac_cv_env_LIBOSMOGSM_LIBS_value= >> >> | ac_cv_env_LIBOSMONETIF_CFLAGS_set= >> >> | ac_cv_env_LIBOSMONETIF_CFLAGS_value= >> >> | ac_cv_env_LIBOSMONETIF_LIBS_set= >> >> | ac_cv_env_LIBOSMONETIF_LIBS_value= >> >> | ac_cv_env_LIBOSMORANAP_CFLAGS_set= >> >> | ac_cv_env_LIBOSMORANAP_CFLAGS_value= >> >> | ac_cv_env_LIBOSMORANAP_LIBS_set= >> >> | ac_cv_env_LIBOSMORANAP_LIBS_value= >> >> | ac_cv_env_LIBOSMOSCCP_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOSCCP_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOSCCP_LIBS_set= >> >> | ac_cv_env_LIBOSMOSCCP_LIBS_value= >> >> | ac_cv_env_LIBOSMOSIGTRAN_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOSIGTRAN_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOSIGTRAN_LIBS_set= >> >> | ac_cv_env_LIBOSMOSIGTRAN_LIBS_value= >> >> | ac_cv_env_LIBOSMOVTY_CFLAGS_set= >> >> | ac_cv_env_LIBOSMOVTY_CFLAGS_value= >> >> | ac_cv_env_LIBOSMOVTY_LIBS_set= >> >> | ac_cv_env_LIBOSMOVTY_LIBS_value= >> >> | ac_cv_env_LIBSMPP34_CFLAGS_set= >> >> | ac_cv_env_LIBSMPP34_CFLAGS_value= >> >> | ac_cv_env_LIBSMPP34_LIBS_set= >> >> | ac_cv_env_LIBSMPP34_LIBS_value= >> >> | ac_cv_env_LIBS_set= >> >> | ac_cv_env_LIBS_value= >> >> | ac_cv_env_PKG_CONFIG_LIBDIR_set= >> >> | ac_cv_env_PKG_CONFIG_LIBDIR_value= >> >> | ac_cv_env_PKG_CONFIG_PATH_set= >> >> | ac_cv_env_PKG_CONFIG_PATH_value= >> >> | ac_cv_env_PKG_CONFIG_set= >> >> | ac_cv_env_PKG_CONFIG_value= >> >> | ac_cv_env_PYTHON_set= >> >> | ac_cv_env_PYTHON_value= >> >> | ac_cv_env_SQLITE3_CFLAGS_set= >> >> | ac_cv_env_SQLITE3_CFLAGS_value= >> >> | ac_cv_env_SQLITE3_LIBS_set= >> >> | ac_cv_env_SQLITE3_LIBS_value= >> >> | ac_cv_env_build_alias_set= >> >> | ac_cv_env_build_alias_value= >> >> | ac_cv_env_host_alias_set= >> >> | ac_cv_env_host_alias_value= >> >> | ac_cv_env_target_alias_set= >> >> | ac_cv_env_target_alias_value= >> >> | ac_cv_header_cdk_cdk_h=no >> >> | ac_cv_header_dbi_dbd_h=yes >> >> | ac_cv_header_inttypes_h=yes >> >> | ac_cv_header_memory_h=yes >> >> | ac_cv_header_pcap_pcap_h=yes >> >> | ac_cv_header_stdc=yes >> >> | ac_cv_header_stdint_h=yes >> >> | ac_cv_header_stdlib_h=yes >> >> | ac_cv_header_string_h=yes >> >> | ac_cv_header_strings_h=yes >> >> | ac_cv_header_sys_stat_h=yes >> >> | ac_cv_header_sys_types_h=yes >> >> | ac_cv_header_unistd_h=yes >> >> | ac_cv_objext=o >> >> | ac_cv_path_EGREP='/bin/grep -E' >> >> | ac_cv_path_GREP=/bin/grep >> >> | ac_cv_path_PKG_CONFIG_INSTALLED=/usr/bin/pkg-config >> >> | ac_cv_path_ac_pt_PKG_CONFIG=/usr/bin/pkg-config >> >> | ac_cv_path_install='/usr/bin/install -c' >> >> | ac_cv_path_mkdir=/bin/mkdir >> >> | ac_cv_prog_AWK=mawk >> >> | ac_cv_prog_CPP='gcc -E' >> >> | ac_cv_prog_ac_ct_CC=gcc >> >> | ac_cv_prog_ac_ct_RANLIB=ranlib >> >> | ac_cv_prog_cc_c89= >> >> | ac_cv_prog_cc_g=yes >> >> | ac_cv_prog_make_make_set=yes >> >> | ac_cv_search_dlopen=-ldl >> >> | am_cv_CC_dependencies_compiler_type=gcc3 >> >> | am_cv_make_support_nested_variables=yes >> >> | am_cv_prog_cc_c_o=yes >> >> | ax_cv_check_cflags___Werror_implicit=yes >> >> | ax_cv_check_cflags___Werror_maybe_uninitialized=yes >> >> | ax_cv_check_cflags___Werror_memset_transposed_args=yes >> >> | ax_cv_check_cflags___Werror_null_dereference=no >> >> | ax_cv_check_cflags___Werror_sizeof_array_argument=yes >> >> | ax_cv_check_cflags___Werror_sizeof_pointer_memaccess=yes >> >> | osmo_cv_tm_includes_tm_gmtoff=yes >> >> | pkg_cv_LIBASN1C_CFLAGS='-I/usr/local/include/ >>> -I/usr/local/include/asn1c' >> >> | pkg_cv_LIBASN1C_LIBS='-L/usr/local/lib -ltalloc -lasn1c' >> >> | pkg_cv_LIBCARES_CFLAGS= >> >> | pkg_cv_LIBCARES_LIBS=-lcares >> >> | pkg_cv_LIBCRYPTO_CFLAGS= >> >> | pkg_cv_LIBCRYPTO_LIBS=-lcrypto >> >> | pkg_cv_LIBGTP_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBGTP_LIBS='-L/usr/local/lib -lgtp' >> >> | pkg_cv_LIBOSMOABIS_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMOABIS_LIBS='-L/usr/local/lib -losmoabis' >> >> | pkg_cv_LIBOSMOCORE_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMOCORE_LIBS='-L/usr/local/lib -ltalloc -losmocore' >> >> | pkg_cv_LIBOSMOCTRL_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMOCTRL_LIBS='-L/usr/local/lib -ltalloc -losmoctrl -losmogsm >>> -losmocore' >> >> | pkg_cv_LIBOSMOGB_CFLAGS='-fno-strict-aliasing -I/usr/local/include/' >> >> | pkg_cv_LIBOSMOGB_LIBS='-L/usr/local/lib -ltalloc -losmogb -losmovty >>> -losmocore' >> >> | pkg_cv_LIBOSMOGSM_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMOGSM_LIBS='-L/usr/local/lib -ltalloc -losmogsm -losmocore' >> >> | pkg_cv_LIBOSMONETIF_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMONETIF_LIBS='-L/usr/local/lib -losmonetif' >> >> | pkg_cv_LIBOSMORANAP_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMORANAP_LIBS='-L/usr/local/lib -losmo-ranap' >> >> | pkg_cv_LIBOSMOSCCP_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMOSCCP_LIBS='-L/usr/local/lib -lsccp' >> >> | pkg_cv_LIBOSMOSIGTRAN_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMOSIGTRAN_LIBS='-L/usr/local/lib -losmo-sigtran' >> >> | pkg_cv_LIBOSMOVTY_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBOSMOVTY_LIBS='-L/usr/local/lib -ltalloc -losmovty -losmocore' >> >> | pkg_cv_LIBSMPP34_CFLAGS=-I/usr/local/include/ >> >> | pkg_cv_LIBSMPP34_LIBS='-L/usr/local/lib -lsmpp34' >> >> | pkg_cv_SQLITE3_CFLAGS= >> >> | pkg_cv_SQLITE3_LIBS=-lsqlite3 >> >> | >> >> | ## ----------------- ## >> >> | ## Output variables. ## >> >> | ## ----------------- ## >> >> | >> >> | ACLOCAL='${SHELL} >>> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing >>> aclocal-1.15' >> >> | AMDEPBACKSLASH='\' >> >> | AMDEP_FALSE='#' >> >> | AMDEP_TRUE='' >> >> | AMTAR='$${TAR-tar}' >> >> | AM_BACKSLASH='\' >> >> | AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)' >> >> | AM_DEFAULT_VERBOSITY='0' >> >> | AM_V='$(V)' >> >> | AUTOCONF='${SHELL} >>> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing autoconf' >> >> | AUTOHEADER='${SHELL} >>> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing >>> autoheader' >> >> | AUTOMAKE='${SHELL} >>> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing >>> automake-1.15' >> >> | AWK='mawk' >> >> | BUILD_BSC_FALSE='#' >> >> | BUILD_BSC_TRUE='' >> >> | BUILD_IU_FALSE='#' >> >> | BUILD_IU_TRUE='' >> >> | BUILD_MGCP_TRANSCODING_FALSE='' >> >> | BUILD_MGCP_TRANSCODING_TRUE='#' >> >> | BUILD_NAT_FALSE='#' >> >> | BUILD_NAT_TRUE='' >> >> | BUILD_SMPP_FALSE='#' >> >> | BUILD_SMPP_TRUE='' >> >> | CC='gcc' >> >> | CCDEPMODE='depmode=gcc3' >> >> | CFLAGS='-g -O2 -Werror=implicit -Werror=maybe-uninitialized >>> -Werror=memset-transposed-args -Werror=sizeof-array-argument >>> -Werror=sizeof-pointer-memaccess' >> >> | COVERAGE_CFLAGS='' >> >> | COVERAGE_LDFLAGS='' >> >> | CPP='gcc -E' >> >> | CPPFLAGS='' >> >> | CYGPATH_W='echo' >> >> | DEFS='-DHAVE_CONFIG_H' >> >> | DEPDIR='.deps' >> >> | ECHO_C='' >> >> | ECHO_N='-n' >> >> | ECHO_T='' >> >> | EGREP='/bin/grep -E' >> >> | ENABLE_EXT_TESTS_FALSE='' >> >> | ENABLE_EXT_TESTS_TRUE='#' >> >> | EXEEXT='' >> >> | GREP='/bin/grep' >> >> | HAVE_LIBCARES_FALSE='#' >> >> | HAVE_LIBCARES_TRUE='' >> >> | HAVE_LIBCDK_FALSE='' >> >> | HAVE_LIBCDK_TRUE='#' >> >> | HAVE_LIBGTP_FALSE='#' >> >> | HAVE_LIBGTP_TRUE='' >> >> | HAVE_PCAP_FALSE='#' >> >> | HAVE_PCAP_TRUE='' >> >> | HAVE_SQLITE3_FALSE='#' >> >> | HAVE_SQLITE3_TRUE='' >> >> | INSTALL_DATA='${INSTALL} -m 644' >> >> | INSTALL_PROGRAM='${INSTALL}' >> >> | INSTALL_SCRIPT='${INSTALL}' >> >> | INSTALL_STRIP_PROGRAM='$(install_sh) -c -s' >> >> | LDFLAGS='' >> >> | LIBASN1C_CFLAGS='-I/usr/local/include/ -I/usr/local/include/asn1c' >> >> | LIBASN1C_LIBS='-L/usr/local/lib -ltalloc -lasn1c' >> >> | LIBBCG729_CFLAGS='' >> >> | LIBBCG729_LIBS='' >> >> | LIBCARES_CFLAGS='' >> >> | LIBCARES_LIBS='-lcares' >> >> | LIBCRYPTO_CFLAGS='' >> >> | LIBCRYPTO_LIBS='-lcrypto' >> >> | LIBGTP_CFLAGS='-I/usr/local/include/' >> >> | LIBGTP_LIBS='-L/usr/local/lib -lgtp' >> >> | LIBOBJS='' >> >> | LIBOSMOABIS_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMOABIS_LIBS='-L/usr/local/lib -losmoabis' >> >> | LIBOSMOCORE_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMOCORE_LIBS='-L/usr/local/lib -ltalloc -losmocore' >> >> | LIBOSMOCTRL_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMOCTRL_LIBS='-L/usr/local/lib -ltalloc -losmoctrl -losmogsm >>> -losmocore' >> >> | LIBOSMOGB_CFLAGS='-fno-strict-aliasing -I/usr/local/include/' >> >> | LIBOSMOGB_LIBS='-L/usr/local/lib -ltalloc -losmogb -losmovty -losmocore' >> >> | LIBOSMOGSM_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMOGSM_LIBS='-L/usr/local/lib -ltalloc -losmogsm -losmocore' >> >> | LIBOSMONETIF_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMONETIF_LIBS='-L/usr/local/lib -losmonetif' >> >> | LIBOSMORANAP_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMORANAP_LIBS='-L/usr/local/lib -losmo-ranap' >> >> | LIBOSMOSCCP_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMOSCCP_LIBS='-L/usr/local/lib -lsccp' >> >> | LIBOSMOSIGTRAN_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMOSIGTRAN_LIBS='-L/usr/local/lib -losmo-sigtran' >> >> | LIBOSMOVTY_CFLAGS='-I/usr/local/include/' >> >> | LIBOSMOVTY_LIBS='-L/usr/local/lib -ltalloc -losmovty -losmocore' >> >> | LIBRARY_DL='-ldl ' >> >> | LIBRARY_GSM='' >> >> | LIBS='' >> >> | LIBSMPP34_CFLAGS='-I/usr/local/include/' >> >> | LIBSMPP34_LIBS='-L/usr/local/lib -lsmpp34' >> >> | LTLIBOBJS='' >> >> | MAKEINFO='${SHELL} >>> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/missing makeinfo' >> >> | MKDIR_P='/bin/mkdir -p' >> >> | OBJEXT='o' >> >> | OSMOTESTEXT_CHECK='' >> >> | PACKAGE='openbsc' >> >> | PACKAGE_BUGREPORT='openbsc at lists.osmocom.org' >> >> | PACKAGE_NAME='openbsc' >> >> | PACKAGE_STRING='openbsc 0.15.0.776-3824' >> >> | PACKAGE_TARNAME='openbsc' >> >> | PACKAGE_URL='' >> >> | PACKAGE_VERSION='0.15.0.776-3824' >> >> | PATH_SEPARATOR=':' >> >> | PKG_CONFIG='/usr/bin/pkg-config' >> >> | PKG_CONFIG_INSTALLED='/usr/bin/pkg-config' >> >> | PKG_CONFIG_LIBDIR='' >> >> | PKG_CONFIG_PATH='' >> >> | PYTHON='' >> >> | PYTHON_EXEC_PREFIX='' >> >> | PYTHON_PLATFORM='' >> >> | PYTHON_PREFIX='' >> >> | PYTHON_VERSION='' >> >> | RANLIB='ranlib' >> >> | SET_MAKE='' >> >> | SHELL='/bin/bash' >> >> | SQLITE3_CFLAGS='' >> >> | SQLITE3_LIBS='-lsqlite3' >> >> | STRIP='' >> >> | SYMBOL_VISIBILITY='-fvisibility=hidden' >> >> | VERSION='0.15.0.776-3824' >> >> | ac_ct_CC='gcc' >> >> | am__EXEEXT_FALSE='' >> >> | am__EXEEXT_TRUE='#' >> >> | am__fastdepCC_FALSE='#' >> >> | am__fastdepCC_TRUE='' >> >> | am__include='include' >> >> | am__isrc='' >> >> | am__leading_dot='.' >> >> | am__nodep='_no' >> >> | am__quote='' >> >> | am__tar='$${TAR-tar} chof - "$$tardir"' >> >> | am__untar='$${TAR-tar} xf -' >> >> | bindir='${exec_prefix}/bin' >> >> | build_alias='' >> >> | datadir='${datarootdir}' >> >> | datarootdir='${prefix}/share' >> >> | docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' >> >> | dvidir='${docdir}' >> >> | exec_prefix='${prefix}' >> >> | found_libcares='yes' >> >> | found_libgtp='yes' >> >> | found_libgtp_and_libcares='yes' >> >> | found_sqlite3='yes' >> >> | host_alias='' >> >> | htmldir='${docdir}' >> >> | includedir='${prefix}/include' >> >> | infodir='${datarootdir}/info' >> >> | install_sh='${SHELL} >>> /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/install-sh' >> >> | libdir='${exec_prefix}/lib' >> >> | libexecdir='${exec_prefix}/libexec' >> >> | localedir='${datarootdir}/locale' >> >> | localstatedir='${prefix}/var' >> >> | mandir='${datarootdir}/man' >> >> | mkdir_p='$(MKDIR_P)' >> >> | oldincludedir='/usr/include' >> >> | osmo_ac_build_bsc='yes' >> >> | osmo_ac_build_nat='yes' >> >> | osmo_ac_build_smpp='yes' >> >> | osmo_ac_iu='yes' >> >> | osmo_ac_mgcp_transcoding='no' >> >> | pdfdir='${docdir}' >> >> | pkgpyexecdir='' >> >> ## ----------------------------------- ## >> >> ## openbsc 0.15.0.776-3824 test suite. ## >> >> ## ----------------------------------- ## >> >> >>> testsuite: command line was: >> >> $ ./testsuite >> >> >>> ## --------- ## >> >> ## Platform. ## >> >> ## --------- ## >> >> >>> hostname = ubuntu >> >> uname -m = x86_64 >> >> uname -r = 4.15.0-36-generic >> >> uname -s = Linux >> >> uname -v = #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC 2018 >> >> >>> /usr/bin/uname -p = unknown >> >> /bin/uname -X = unknown >> >> >>> /bin/arch = unknown >> >> /usr/bin/arch -k = unknown >> >> /usr/convex/getsysinfo = unknown >> >> /usr/bin/hostinfo = unknown >> >> /bin/machine = unknown >> >> /usr/bin/oslevel = unknown >> >> /bin/universe = unknown >> >> >>> PATH: /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests >> >> PATH: /usr/local/sbin >> >> PATH: /usr/local/bin >> >> PATH: /usr/sbin >> >> PATH: /usr/bin >> >> PATH: /sbin >> >> PATH: /bin >> >> PATH: /usr/games >> >> PATH: /usr/local/games >> >> >>> testsuite: atconfig: >> >> | # Configurable variable values for building test suites. >> >> | # Generated by ./config.status. >> >> | # Copyright (C) 2012 Free Software Foundation, Inc. >> >> | >> >> | # The test suite will define top_srcdir=/../.. etc. >> >> | at_testdir='tests' >> >> | >>> abs_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' >> >> "tests/testsuite.log" 11793L, 778307C >>> 1,1 ?? >> >> | osmo_ac_mgcp_transcoding='no' >> >> | pdfdir='${docdir}' >> >> | pkgpyexecdir='' >> >> | pkgpythondir='' >> >> | prefix='/usr/local' >> >> | program_transform_name='s,x,x,' >> >> | psdir='${docdir}' >> >> | pyexecdir='' >> >> | pythondir='' >> >> | runstatedir='${localstatedir}/run' >> >> | sbindir='${exec_prefix}/sbin' >> >> | sharedstatedir='${prefix}/com' >> >> | sysconfdir='${prefix}/etc' >> >> | target_alias='' >> >> | >> >> | ## ----------- ## >> >> | ## confdefs.h. ## >> >> | ## ----------- ## >> >> | >> >> | /* confdefs.h */ >> >> | #define PACKAGE_NAME "openbsc" >> >> | #define PACKAGE_TARNAME "openbsc" >> >> | #define PACKAGE_VERSION "0.15.0.776-3824" >> >> | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" >> >> | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" >> >> | #define PACKAGE_URL "" >> >> | #define PACKAGE "openbsc" >> >> | #define VERSION "0.15.0.776-3824" >> >> | #define BUILD_SMPP 1 >> >> | #define BUILD_IU 1 >> >> | #define STDC_HEADERS 1 >> >> | #define HAVE_SYS_TYPES_H 1 >> >> | #define HAVE_SYS_STAT_H 1 >> >> | #define HAVE_STDLIB_H 1 >> >> | #define HAVE_STRING_H 1 >> >> | #define HAVE_MEMORY_H 1 >> >> | #define HAVE_STRINGS_H 1 >> >> | #define HAVE_INTTYPES_H 1 >> >> | #define HAVE_STDINT_H 1 >> >> | #define HAVE_UNISTD_H 1 >> >> | #define HAVE_DBI_DBD_H 1 >> >> | #define HAVE_PCAP_PCAP_H 1 >> >> | #define HAVE_TM_GMTOFF_IN_TM 1 >> >> | >> >> | configure: exit 0 >> >> >>> >>> 11754,1 ?? >> >> | pkgpythondir='' >> >> | prefix='/usr/local' >> >> | program_transform_name='s,x,x,' >> >> | psdir='${docdir}' >> >> | pyexecdir='' >> >> | pythondir='' >> >> | runstatedir='${localstatedir}/run' >> >> | sbindir='${exec_prefix}/sbin' >> >> | sharedstatedir='${prefix}/com' >> >> | sysconfdir='${prefix}/etc' >> >> | target_alias='' >> >> | >> >> | ## ----------- ## >> >> | ## confdefs.h. ## >> >> | ## ----------- ## >> >> | >> >> | /* confdefs.h */ >> >> | #define PACKAGE_NAME "openbsc" >> >> | #define PACKAGE_TARNAME "openbsc" >> >> | #define PACKAGE_VERSION "0.15.0.776-3824" >> >> | #define PACKAGE_STRING "openbsc 0.15.0.776-3824" >> >> | #define PACKAGE_BUGREPORT "openbsc at lists.osmocom.org" >> >> | #define PACKAGE_URL "" >> >> | #define PACKAGE "openbsc" >> >> | #define VERSION "0.15.0.776-3824" >> >> | #define BUILD_SMPP 1 >> >> | #define BUILD_IU 1 >> >> | #define STDC_HEADERS 1 >> >> | #define HAVE_SYS_TYPES_H 1 >> >> | #define HAVE_SYS_STAT_H 1 >> >> | #define HAVE_STDLIB_H 1 >> >> | #define HAVE_STRING_H 1 >> >> | #define HAVE_MEMORY_H 1 >> >> | #define HAVE_STRINGS_H 1 >> >> | #define HAVE_INTTYPES_H 1 >> >> | #define HAVE_STDINT_H 1 >> >> | #define HAVE_UNISTD_H 1 >> >> | #define HAVE_DBI_DBD_H 1 >> >> | #define HAVE_PCAP_PCAP_H 1 >> >> | #define HAVE_TM_GMTOFF_IN_TM 1 >> >> | >> >> | configure: exit 0 >> >> >>> root at ubuntu:/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc# >>> ls -la tests/testsuite.log >> >> -rw-r--r-- 1 root root 778307 10? 25 23:53 tests/testsuite.log >> >> root at ubuntu:/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc# >>> vim tests/testsuite.log >> >> root at ubuntu:/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc# >>> cat tests/testsuite.log |more >> >> ## ----------------------------------- ## >> >> ## openbsc 0.15.0.776-3824 test suite. ## >> >> ## ----------------------------------- ## >> >> >>> testsuite: command line was: >> >> $ ./testsuite >> >> >>> ## --------- ## >> >> ## Platform. ## >> >> ## --------- ## >> >> >>> hostname = ubuntu >> >> uname -m = x86_64 >> >> uname -r = 4.15.0-36-generic >> >> uname -s = Linux >> >> uname -v = #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC 2018 >> >> >>> /usr/bin/uname -p = unknown >> >> /bin/uname -X = unknown >> >> >>> /bin/arch = unknown >> >> /usr/bin/arch -k = unknown >> >> /usr/convex/getsysinfo = unknown >> >> /usr/bin/hostinfo = unknown >> >> /bin/machine = unknown >> >> /usr/bin/oslevel = unknown >> >> /bin/universe = unknown >> >> >>> PATH: /home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests >> >> PATH: /usr/local/sbin >> >> PATH: /usr/local/bin >> >> PATH: /usr/sbin >> >> PATH: /usr/bin >> >> PATH: /sbin >> >> PATH: /bin >> >> PATH: /usr/games >> >> PATH: /usr/local/games >> >> >>> testsuite: atconfig: >> >> | # Configurable variable values for building test suites. >> >> | # Generated by ./config.status. >> >> | # Copyright (C) 2012 Free Software Foundation, Inc. >> >> | >> >> | # The test suite will define top_srcdir=/../.. etc. >> >> | at_testdir='tests' >> >> | >>> abs_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' >> >> | at_srcdir='.' >> >> | >>> abs_srcdir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc/tests' >> >> | at_top_srcdir='..' >> >> | >>> abs_top_srcdir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc' >> >> | at_top_build_prefix='../' >> >> | >>> abs_top_builddir='/home/hacksmith/3G/3G-config-example/build/openbsc/openbsc' >> >> | >> >> | # Backward compatibility with Autotest <= 2.59b: >> >> | at_top_builddir=$at_top_build_prefix >> >> | >> >> | AUTOTEST_PATH='tests' >> >> | >> >> | SHELL=${CONFIG_SHELL-'/bin/bash'} >> >> >>> testsuite: atlocal: >> >> | enable_nat_test='yes' >> >> | enable_smpp_test='yes' >> >> | enable_bsc_test='yes' >> >> | enable_mgcp_transcoding_test='no' >> >> | enable_sgsn_test='yes' >> >> | enable_oap_test='yes' >> >> | enable_gtphub_test='yes' >> >> >>> ## ---------------- ## >> >> ## Tested programs. ## >> >> ## ---------------- ## >> >> >>> ## ------------------ ## >> >> ## Running the tests. ## >> >> ## ------------------ ## >> >> testsuite: starting at: Thu Oct 25 23:53:55 PDT 2018 >> >> 1. gsm0408 (testsuite.at:4): ok (0m0.344s 0m0.000s) >> >> 2. bsc_subscr (testsuite.at:10): ok (0m0.005s 0m0.001s) >> >> 3. channel (testsuite.at:17): ok (0m0.005s 0m0.001s) >> >> 4. mgcp (testsuite.at:23): ok (0m0.002s 0m0.007s) >> >> 5. mgcp-trans (testsuite.at:29): skipped (testsuite.at:31) >> >> 6. mgcpgw_client (testsuite.at:36): ok (0m0.006s 0m0.001s) >> >> 7. gprs (testsuite.at:43): ok (0m0.003s 0m0.000s) >> >> 8. bsc-nat (testsuite.at:49): ok (0m0.009s 0m0.004s) >> >> 9. smpp (testsuite.at:59): ok (0m0.003s 0m0.003s) >> >> 10. bsc-nat-trie (testsuite.at:67): ok (0m0.006s 0m0.001s) >> >> 11. abis (testsuite.at:75): ok (0m0.002s 0m0.003s) >> >> 12. bsc (testsuite.at:81): ok (0m0.006s 0m0.000s) >> >> 14. trau (testsuite.at:94): ok (0m0.005s 0m0.000s) >> >> 16. oap (testsuite.at:107): ok (0m0.003s 0m0.003s) >> >> 17. gtphub (testsuite.at:115): ok (0m0.003s 0m0.006s) >> >> 18. mm_auth (testsuite.at:122): ok (0m0.006s 0m0.000s) >> >> 19. xid (testsuite.at:128): ok (0m0.006s 0m0.001s) >> >> 20. sndcp_xid (testsuite.at:135): ok (0m0.006s 0m0.000s) >> >> 21. slhc (testsuite.at:142): ok (0m0.004s 0m0.001s) >> >> 22. v42bis (testsuite.at:149): ok (0m0.009s 0m0.001s) >> >> 23. nanobts_omlattr (testsuite.at:156): ok (0m0.006s 0m0.000s) >> >> 24. sms_queue_test (testsuite.at:162): ok (0m0.005s 0m0.001s) >> >> testsuite: ending at: Thu Oct 25 23:53:57 PDT 2018 >> >> testsuite: test suite duration: 0h 0m 2s >> >> >>> ## ------------- ## >> >> ## Test results. ## >> >> ## ------------- ## >> >> >>> ERROR: 32 tests were run, >> >> 11 failed unexpectedly. >> >> 1 test was skipped. >> >> >>> ## ------------------------ ## >> >> ## Summary of the failures. ## >> >> ## ------------------------ ## >> >> Failed tests: >> >> openbsc 0.15.0.776-3824 test suite test groups: >> >> >>> NUM: FILE-NAME:LINE TEST-GROUP-NAME >> >> KEYWORDS >> >> >>> 13: testsuite.at:88 gbproxy >> >> gbproxy >> >> 15: testsuite.at:100 sgsn >> >> sgsn >> >> 25: testsuite.at:169 msc_vlr_test_no_authen >> >> msc_vlr_test_no_authen >> >> 26: testsuite.at:176 msc_vlr_test_gsm_authen >> >> msc_vlr_test_gsm_authen >> >> 27: testsuite.at:183 msc_vlr_test_gsm_ciph >> >> msc_vlr_test_gsm_ciph >> >> 28: testsuite.at:190 msc_vlr_test_umts_authen >> >> msc_vlr_test_umts_authen >> >> 29: testsuite.at:197 msc_vlr_test_hlr_reject >> >> msc_vlr_test_hlr_reject >> >> 30: testsuite.at:204 msc_vlr_test_hlr_timeout >> >> msc_vlr_test_hlr_timeout >> >> 31: testsuite.at:211 msc_vlr_test_ms_timeout >> >> msc_vlr_test_ms_timeout >> >> 32: testsuite.at:218 msc_vlr_test_reject_concurrency >> >> msc_vlr_test_reject_concurrency >> >> 33: testsuite.at:225 msc_vlr_test_rest >> >> msc_vlr_test_rest >> >> >>> Skipped tests: >> >> openbsc 0.15.0.776-3824 test suite test groups: >> >> >>> NUM: FILE-NAME:LINE TEST-GROUP-NAME >> >> KEYWORDS >> >> >>> 5: testsuite.at:29 mgcp-trans >> >> mgcp-trans >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Oct 26 10:25:35 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 26 Oct 2018 12:25:35 +0200 Subject: [openbsc 0.15.0.776-3824] testsuite: 13 15 25 26 27 28 29 30 31 32 33 failed In-Reply-To: References: Message-ID: <20181026102535.GA5224@nataraja> Dear 0xroot, thanks for your interest in our product. Please note that the old openbsc.git repository and the OsmoNITB it contains has not been supported for more than a year by now. 3G support has been fully integrated into the new OsmoMSC (and OsmoSGSN) from their respective osmo-msc.git and osmo-sgsn.git repositories. This is why the page you are referring to has the following big bold warning on top: ====================================== NOTE: we have split openbsc.git in smaller parts: osmo-{msc,mgw,sgsn,bsc}, and we have full 3G support in the master branches of those new repositories. This wiki page still refers to an earlier development branch in the old openbsc.git. The main difference is that now 3G uses true M3UA, and you need to operate an OsmoSTP, as seen on the Osmocom Network In The Box wiki page. ====================================== So please kindly follow the instructions at https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Oct 26 13:33:15 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 26 Oct 2018 15:33:15 +0200 Subject: OsmoDevCon 2019 date poll In-Reply-To: <20181024200018.GA27815@nataraja> References: <20181024200018.GA27815@nataraja> Message-ID: <20181026133315.GH5224@nataraja> Hi all, On Wed, Oct 24, 2018 at 10:00:18PM +0200, Harald Welte wrote: > April 05-08, 2019 > April 12-15, 2019 > April 26-29, 2019 so far it seems the last date (26th through 29th) is the only date where all 11 people providing feedback so far would be available. Also, according to steve|m, hotel pricing seems to be lower during that weekend compared to the other two options. I will therefore inquire with IN-Berlin regarding availability of the venue during that weekend and if confirmed by them, start a wiki page about OsmoDevCon2019 stating this date. 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 jenkins at lists.osmocom.org Mon Oct 29 02:24:41 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Mon, 29 Oct 2018 02:24:41 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #280 Message-ID: <1717697111.277.1540779881806.JavaMail.jenkins@jenkins.osmocom.org> See Changes: [laforge] gerrot-osmo-bts: Don't use unsupported '/' in labels of axis/matrix jobs ------------------------------------------ [...truncated 720.95 KB...] CC RANAP_LAI.lo CC RANAP_LastKnownServiceArea.lo CC RANAP_LastVisitedUTRANCell-Item.lo CC RANAP_LHN-ID.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_LA-LIST.h:14, from RANAP_LA-LIST.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ?struct MemberA? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ CC RANAP_Links-to-log.lo CC RANAP_ListOF-SNAs.lo CC RANAP_ListOfInterfacesToTrace.lo CC RANAP_InterfacesToTraceItem.lo CC RANAP_LoadValue.lo CC RANAP_LocationRelatedDataRequestType.lo CC RANAP_LocationRelatedDataRequestTypeSpecificToGERANIuMode.lo CC RANAP_LocationReportingTransferInformation.lo CC RANAP_ReportChangeOfSAI.lo CC RANAP_PeriodicReportingIndicator.lo CC RANAP_DirectReportingIndicator.lo CC RANAP_L3-Information.lo CC RANAP_M1Report.lo CC RANAP_M2Report.lo CC RANAP_M4Report.lo CC RANAP_M4-Collection-Parameters.lo CC RANAP_M4-Period.lo CC RANAP_M4-Threshold.lo CC RANAP_M5Report.lo CC RANAP_M5-Period.lo CC RANAP_M6Report.lo CC RANAP_M7Report.lo CC RANAP_M7-Period.lo CC RANAP_M6-Period.lo CC RANAP_Management-Based-MDT-Allowed.lo CC RANAP_MaxBitrate.lo CC RANAP_MaxSDU-Size.lo CC RANAP_MBMS-PTP-RAB-ID.lo CC RANAP_MBMSBearerServiceType.lo CC RANAP_MBMSCNDe-Registration.lo CC RANAP_MBMSCountingInformation.lo CC RANAP_MBMSHCIndicator.lo CC RANAP_MBMSIPMulticastAddressandAPNRequest.lo CC RANAP_MBMSLinkingInformation.lo CC RANAP_MBMSRegistrationRequestType.lo CC RANAP_MBMSServiceArea.lo CC RANAP_MBMSSessionDuration.lo CC RANAP_MBMSSessionIdentity.lo CC RANAP_MBMSSessionRepetitionNumber.lo CC RANAP_MDT-Activation.lo CC RANAP_MDTAreaScope.lo CC RANAP_MDT-Configuration.lo CC RANAP_MDTMode.lo CC RANAP_MDT-PLMN-List.lo CC RANAP_MDT-Report-Parameters.lo CC RANAP_MeasurementQuantity.lo CC RANAP_MeasurementsToActivate.lo CC RANAP_MSISDN.lo CC RANAP_NAS-PDU.lo CC RANAP_NAS-SequenceNumber.lo CC RANAP_NAS-SynchronisationIndicator.lo CC RANAP_NewBSS-To-OldBSS-Information.lo CC RANAP_NonSearchingIndication.lo CC RANAP_NRTLoadInformationValue.lo CC RANAP_NumberOfIuInstances.lo CC RANAP_NumberOfSteps.lo CC RANAP_Offload-RAB-Parameters.lo CC RANAP_Offload-RAB-Parameters-APN.lo CC RANAP_Offload-RAB-Parameters-ChargingCharacteristics.lo CC RANAP_OldBSS-ToNewBSS-Information.lo CC RANAP_OMC-ID.lo CC RANAP_Out-Of-UTRAN.lo CC RANAP_PagingAreaID.lo CC RANAP_PagingCause.lo CC RANAP_PDP-TypeInformation.lo CC RANAP_PDP-Type.lo CC RANAP_PDP-TypeInformation-extension.lo CC RANAP_PDP-Type-extension.lo CC RANAP_PDUType14FrameSequenceNumber.lo CC RANAP_PeriodicLocationInfo.lo CC RANAP_PermanentNAS-UE-ID.lo CC RANAP_PermittedEncryptionAlgorithms.lo CC RANAP_PermittedIntegrityProtectionAlgorithms.lo CC RANAP_LABased.lo CC RANAP_LAI-List.lo CC RANAP_LoggedMDT.lo CC RANAP_LoggingInterval.lo CC RANAP_LoggingDuration.lo CC RANAP_PLMNidentity.lo CC RANAP_PLMNs-in-shared-network.lo CC RANAP_Port-Number.lo CC RANAP_PositioningDataDiscriminator.lo CC RANAP_PositioningDataSet.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from RANAP_PLMNs-in-shared-network.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ?struct MemberA? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ?struct MemberM? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_PositioningMethodAndUsage.lo CC RANAP_PositioningPriority.lo CC RANAP_PositionData.lo CC RANAP_PositionDataSpecificToGERANIuMode.lo CC RANAP_Pre-emptionCapability.lo CC RANAP_Pre-emptionVulnerability.lo CC RANAP_PriorityLevel.lo CC RANAP_Priority-Class-Indicator.lo CC RANAP_ProvidedData.lo CC RANAP_P-TMSI.lo CC RANAP_QueuingAllowed.lo CC RANAP_RAB-AsymmetryIndicator.lo CC RANAP_RABased.lo CC RANAP_RAI-List.lo CC RANAP_RABDataVolumeReport.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:14, from ../../include/osmocom/ranap/RANAP_Shared-Network-Information.h:14, from ../../include/osmocom/ranap/RANAP_ProvidedData.h:14, from RANAP_ProvidedData.c:7: ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:23: warning: ?struct MemberA? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberA { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_LA-LIST.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberA { ^~~~~~~~~~~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:23: warning: ?struct MemberM? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberM { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_PLMNs-in-shared-network.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberM { ^~~~~~~~~~~~~ CC RANAP_RAB-ID.lo CC RANAP_RAB-Parameter-ExtendedGuaranteedBitrateList.lo CC RANAP_RAB-Parameter-ExtendedMaxBitrateList.lo CC RANAP_RAB-Parameter-GuaranteedBitrateList.lo CC RANAP_RAB-Parameter-MaxBitrateList.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:14, from RANAP_RABDataVolumeReport.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ?struct MemberN? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ CC RANAP_RAB-Parameters.lo CC RANAP_RABParametersList.lo CC RANAP_RAB-SubflowCombinationBitRate.lo CC RANAP_RAB-TrCH-Mapping.lo CC RANAP_RAB-TrCH-MappingItem.lo In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:23: warning: ?struct MemberN? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberN { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABDataVolumeReport.h:27:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberN { ^~~~~~~~~~~~~ In file included from /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SEQUENCE_OF.h:8:0, from ../../include/osmocom/ranap/RANAP_RABParametersList.h:14, from RANAP_RABParametersList.c:7: ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:23: warning: ?struct MemberB? declared inside parameter list will not be visible outside of this definition or declaration A_SEQUENCE_OF(struct MemberB { ^ /home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ?A_SET_OF? void (*free)(type *); \ ^~~~ ../../include/osmocom/ranap/RANAP_RABParametersList.h:29:2: note: in expansion of macro ?A_SEQUENCE_OF? A_SEQUENCE_OF(struct MemberB { ^~~~~~~~~~~~~ CC RANAP_RAC.lo CC RANAP_RAI.lo CC RANAP_RAListofIdleModeUEs.lo CC RANAP_NotEmptyRAListofIdleModeUEs.lo CC RANAP_RAofIdleModeUEs.lo CC RANAP_LAListofIdleModeUEs.lo CC RANAP_RAT-Type.lo CC RANAP_RateControlAllowed.lo CC RANAP_RedirectAttemptFlag.lo CC RANAP_RedirectionCompleted.lo CC RANAP_RejectCauseValue.lo CC RANAP_RelocationRequirement.lo CC RANAP_RelocationType.lo CC RANAP_RepetitionNumber0.lo CC RANAP_RepetitionNumber1.lo CC RANAP_ReportArea.lo CC RANAP_ReportInterval.lo CC RANAP_ReportAmount.lo CC RANAP_RequestedGPSAssistanceData.lo CC RANAP_RequestedGANSSAssistanceData.lo CC RANAP_RequestedLocationRelatedDataType.lo CC RANAP_RequestedMBMSIPMulticastAddressandAPNRequest.lo /bin/bash: line 1: 9675 Segmentation fault /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"osmo-iuh\" -DPACKAGE_TARNAME=\"osmo-iuh\" -DPACKAGE_VERSION=\"0.3.0.10-9aad\" -DPACKAGE_STRING=\"osmo-iuh\ 0.3.0.10-9aad\" -DPACKAGE_BUGREPORT=\"openbsc at lists.osmocom.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"osmo-iuh\" -DVERSION=\"0.3.0.10-9aad\" -DSTDC_HEADERS=1 -I. -Wall -I../../include -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/asn1c -I/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/ -g -O2 -Wall -MT RANAP_RequestedGANSSAssistanceData.lo -MD -MP -MF .deps/RANAP_RequestedGANSSAssistanceData.Tpo -c -o RANAP_RequestedGANSSAssistanceData.lo RANAP_RequestedGANSSAssistanceData.c Makefile:2506: recipe for target 'RANAP_RequestedGANSSAssistanceData.lo' failed make[4]: *** [RANAP_RequestedGANSSAssistanceData.lo] Error 139 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src/ranap' Makefile:642: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:454: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh/src' Makefile:458: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/osmo-iuh' Makefile:382: recipe for target 'all' failed make: *** [all] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 1233 C/C++ compilation units (100%) successfully 1233 C/C++ compilation units (100%) are ready for analysis For more details, please look at: /home/osmocom-build/osmo-ci/coverity/source-Osmocom/cov-int/build-log.txt Build step 'Execute shell' marked build as failure From shingy92 at gmail.com Mon Oct 29 06:56:45 2018 From: shingy92 at gmail.com (Shingirai Simba) Date: Mon, 29 Oct 2018 08:56:45 +0200 Subject: OC-2G merge to osmo-bts In-Reply-To: <20181024110141.GO27815@nataraja> References: <20181024094001.GJ27815@nataraja> <20181024110141.GO27815@nataraja> Message-ID: Hie Does anyone know a good place to get OC-2G hardware manufactured. Regards Shingy On Wed, Oct 24, 2018 at 1:10 PM Harald Welte wrote: > On Wed, Oct 24, 2018 at 12:41:19PM +0200, Pau Espin Pedrol wrote: > > We should add another point into the discussion. Who and how are going to > > test these changes? > > Using actual OC-2G hardware with both osmo-gsm-tester as well as with > BTS_Tests.ttcn, even with an extended version of BTS_Tests.ttcn > addressing its various gaps in coverage so far. > > > If I understand correctly code from Omar is rebased on top of current > > osmo-bts master, and has been tested at least in some general scenarios? > > I don't know anything about that, sorry. I would presume some basic > manual testing with a few phones was performed? > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Oct 29 15:04:01 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 29 Oct 2018 16:04:01 +0100 Subject: STP and SGSN communication In-Reply-To: <72641b2b-5639-309d-3f2b-cf383bfad77f@inet.tu-berlin.de> References: <72641b2b-5639-309d-3f2b-cf383bfad77f@inet.tu-berlin.de> Message-ID: <20181029150401.GF4028@my.box> Sorry to see no response here for a whole week. Have you resolved the issue? On Mon, Oct 22, 2018 at 04:37:27PM +0200, Lars Prehn wrote: > Using the VTY interface I can see that only HNBGW and MSC annouced their > code points towards STP. : > > as-rkm-1???? AS_ACTIVE??? 1????????? 0.23.5 > > as-rkm-2???? AS_ACTIVE??? 2????????? 0.23.1 So, you need to get osmo-sgsn to connect to osmo-stp. My osmo-sgsn.cfg looks like this: ---- sgsn gtp local-ip 192.168.2.3 ggsn 0 remote-ip 192.168.2.4 ggsn 0 gtp-version 1 auth-policy remote gsup remote-ip 127.0.0.1 ns encapsulation udp local-ip 192.168.2.3 encapsulation udp local-port 23000 encapsulation framerelay-gre enabled 0 ---- i.e. the SS7 config is implicit / default. When I vty 'enable; show running-config', this implicit cs7 cfg is shown as ---- cs7 instance 1 point-code 0.23.4 asp asp-clnt-OsmoSGSN 2905 0 m3ua remote-ip 127.0.0.1 as as-clnt-OsmoSGSN m3ua asp asp-clnt-OsmoSGSN routing-key 1 0.23.4 ---- Not sure if this helps, but I can't see any mistake in your config. Is your SGSN running on a different machine / network segment and cannot reach the STP at 127.0.0.1? Then change the remote-ip as shown in the cs7 instace cfg... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From m.ordean at cs.bham.ac.uk Mon Oct 29 16:02:46 2018 From: m.ordean at cs.bham.ac.uk (Mihai Ordean) Date: Mon, 29 Oct 2018 16:02:46 +0000 Subject: ipaccess-proxy not relaying traffic to bsc Message-ID: Hey all, First of all let me thanks Neels for his help with the silent_call problem I've been having, which led me to a successful fix. Secondly I was wandering if I could get a bit more help with regards to ipaccess-proxy this time. Now that silent_call is working I want to start manipulating traffic and do some fuzzing. I understand that the ipaccess-proxy is the right tool to use, but I don't seem to get it working. In my current NON ipaccess-proxy setup (which works) I have an osmo-bts which gets data from a USRP B210 via osmo-trx-uhd. On the same machine I also run the osmo-osc. I have configured the OML remote address in the BTS (bts 0 -> oml remote-ip) to a unique localhost (127.0.127.1) and the BSC to listen on that (e1_input -> ipa bind 127.0.127.1). What I want to do is interleave the ipaccess-proxy on this connection (e.g. receive OML from BTS on 127.0.127.2) and forward to the BSC on 127.0.127.1. I have successfully managed to make ipaccess-proxy bind to the specific address (by changing the default IP binding from 0.0.0.0:3002 and 0.0.0.0:3003 to 127.0.127.2:3002 and 3003), and I am receiving traffic from the BTS. However, traffic is never forwarded to the BSC. There seems to be some issue with unrecognized IPA message types. Would anyone be able to provide me with some insight, or perhaps a setup in which ipaccess-proxy worked successfully? I'm also not clear on what ipaccess-proxy is supposed to do. Is it a sniffer (since it binds on 0.0.0.0 by default) or is it a "MITM" relay type of software. I am attaching the output log I get from ipaccess-proxy. -- Mihai -------------- next part -------------- [root at cca-132016] ~ # ipaccess-proxy -l 127.0.127.2 -b 127.0.127.1 <0004> ipaccess-proxy.c:927 accept()ed new OML link from 127.0.0.1 <0006> ipaccess-proxy.c:805 unknown RX<-BTS: 00 61 fe 05 00 0a 08 36 30 30 31 2f 30 2f 30 00 00 13 07 62 30 3a 36 65 3a 62 66 3a 33 31 3a 63 32 3a 30 39 00 00 02 02 00 00 0a 03 73 79 73 6d 6f 42 54 53 00 00 02 04 00 00 07 05 30 2e 38 2e 31 00 00 1c 01 73 79 73 6d 6f 42 54 53 2d 62 30 2d 36 65 2d 62 66 2d 33 31 2d 63 32 2d 30 39 00 00 02 00 00 <0006> ipaccess-proxy.c:459 ID_RESP Unit_ID='6001/0/0' MAC_Address='b0:6e:bf:31:c2:09' Location_1='' Location_2='sysmoBTS' Equipment_Version='' Software_Version='0.8.1' Unit_Name='sysmoBTS-b0-6e-bf-31-c2-09' Serial_Number='' <0006> ipaccess-proxy.c:463 <0004> ipaccess-proxy.c:330 (6001/0/0) New BTS connection: Created BTS Conn data structure <0004> ipaccess-proxy.c:367 (6001/0/0) OML Connected to BSC <0004> ipaccess-proxy.c:379 (6001/0/0) Created UDP socket for injection towards BTS at port 10100 <0004> ipaccess-proxy.c:391 (6001/0/0) Created UDP socket for injection towards BSC at port 20100 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 01 fe 06 <0006> ipaccess-proxy.c:542 ID_ACK? -> ACK! <0006> input/ipaccess.c:246 RX 3: 04 01 08 01 07 01 02 01 03 01 04 01 05 01 01 01 00 <0004> input/ipaccess.c:212 Unknown IPA message type <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 00 ff ff ff 24 02 07 00 01 ff 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 01 00 ff ff 24 ff 07 00 01 05 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 f0 00 ff ff 24 ff 07 00 01 05 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 f1 00 ff ff 24 ff 07 00 01 05 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 f2 00 00 ff 24 ff 07 00 01 05 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 f2 00 01 ff 24 01 07 00 01 03 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 02 00 00 ff 24 ff 07 00 01 02 04 02 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 04 00 00 ff 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 00 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 01 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 02 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 03 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 04 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 05 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 06 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 11 ff 80 80 00 0d 61 03 00 00 07 24 ff 07 00 01 02 04 00 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 19 ff 80 80 00 15 62 01 00 ff ff 11 02 43 01 29 03 fa ce 03 00 05 30 2e 35 2e 31 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 19 ff 80 80 00 15 62 01 00 ff ff 11 02 43 01 29 03 fa ce 03 00 05 30 2e 35 2e 31 <0006> ipaccess-proxy.c:805 (6001/0/0) RX<-BTS: 00 19 ff 80 80 00 15 62 01 00 ff ff 11 02 43 01 29 03 fa ce 03 00 05 30 2e 35 2e 31 -------------- next part -------------- A non-text attachment was scrubbed... Name: m_ordean.vcf Type: text/x-vcard Size: 4 bytes Desc: not available URL: From laforge at gnumonks.org Mon Oct 29 20:46:37 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 29 Oct 2018 21:46:37 +0100 Subject: OC-2G merge to osmo-bts In-Reply-To: References: <20181024094001.GJ27815@nataraja> <20181024110141.GO27815@nataraja> Message-ID: <20181029204637.GL31654@nataraja> Hi Shingy, this question is a bit off-topic here, but... On Mon, Oct 29, 2018 at 08:56:45AM +0200, Shingirai Simba wrote: > Does anyone know a good place to get OC-2G hardware manufactured. At this point, to the best of my knowledge, OC-2G yet has to deliver on their open hardware promise. The design files like schematics / PCB layouts / mechanical drawings / BOM, etc. are yet to be published. I could only find those of OC-SDR and OC-LTE on the OpenCellular git repository so far. I did inquire with the OpenCellular working group chair (Kashif) and asked for those files to be released. Without those files, it's hard to guess who could be a good match to manufacture the related units. The details of the design determine the complexity and therefore the required capabilities for any contract manufacturer. In any case, even with [hopefully] all the related files released as OSHW, there's the equally important question of validation, production testing, calibration, etc. which needs to be implemented and executed. Which brings me to the question of: How many units do you need? I think unless you have at least a binding quantity of several hundred and a realistic forecast to thousands of units, there's very little point in wasting time thinking about setting up any alternative / custom manufacturing, rather than to buy from the original supplier/vendor (NuRAN). 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 jenkins at lists.osmocom.org Tue Oct 30 02:30:40 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 30 Oct 2018 02:30:40 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #281 In-Reply-To: <1717697111.277.1540779881806.JavaMail.jenkins@jenkins.osmocom.org> References: <1717697111.277.1540779881806.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <1218431531.308.1540866640748.JavaMail.jenkins@jenkins.osmocom.org> See From lprehn at inet.tu-berlin.de Tue Oct 30 15:02:46 2018 From: lprehn at inet.tu-berlin.de (Lars Prehn) Date: Tue, 30 Oct 2018 16:02:46 +0100 Subject: logging of KPI Message-ID: <90b1aa88-c7d5-a829-f555-fb17169f63b7@inet.tu-berlin.de> Hi everyone, is there some wiki entry / detailed description of how to properly set up reporting to statsd for a set of given metrics (e.g. number of active users / bytes sent per user) on a per component granularity? Best regards, Lars From pespin at sysmocom.de Tue Oct 30 15:34:40 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 30 Oct 2018 16:34:40 +0100 Subject: logging of KPI In-Reply-To: <90b1aa88-c7d5-a829-f555-fb17169f63b7@inet.tu-berlin.de> References: <90b1aa88-c7d5-a829-f555-fb17169f63b7@inet.tu-berlin.de> Message-ID: Hi, You can find group counter information in User manuals [1] and in this talk [2] Specifically see https://ftp.osmocom.org/docs/latest/osmosgsn-usermanual.pdf "9.4 CDR configuration" and "14 Counters". [1] https://ftp.osmocom.org/docs/latest [2] https://media.ccc.de/v/SE8HRK -- - 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 laforge at gnumonks.org Tue Oct 30 16:03:42 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 30 Oct 2018 17:03:42 +0100 Subject: logging of KPI In-Reply-To: <90b1aa88-c7d5-a829-f555-fb17169f63b7@inet.tu-berlin.de> References: <90b1aa88-c7d5-a829-f555-fb17169f63b7@inet.tu-berlin.de> Message-ID: <20181030160342.GE8374@nataraja> Hi lars, beyond what Pau described, I think we don't have any additional documentation. However, should you create a related setup, we would much appreciate any of your additions to our documentation: Whether to the wiki (please self-register a user account and reach out privately to me to get write access) or as patches to the user manuals (pushed via git into our gerrit instance). Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Tue Oct 30 22:24:56 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 30 Oct 2018 23:24:56 +0100 Subject: OsmoDevCon 2019 date poll In-Reply-To: <20181026133315.GH5224@nataraja> References: <20181024200018.GA27815@nataraja> <20181026133315.GH5224@nataraja> Message-ID: On October 26, 2018 3:33:15 PM GMT+02:00, Harald Welte wrote: >so far it seems the last date (April 26th through 29th) is the only date [...] >I will therefore inquire with IN-Berlin regarding availability of the >venue during that weekend Date is now confirmed by IN-Berlin. Please save the date in your calendars. -- Sent from a mobile device. Please excuse my brevity. From nhofmeyr at sysmocom.de Wed Oct 31 13:18:57 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 31 Oct 2018 14:18:57 +0100 Subject: osmo-dev Message-ID: <20181031131857.GA4027@my.box> osmo-dev is my personal tooling for building and configuring Osmocom core net components. Since osmith is also using it now and starting to send in patches on gerrit, it is receiving some public attention. Despite cosmetics I might have done differently if I were to rewrite it from scratch, I do (obviously) like the way it works, and would welcome anyone else to give it a spin, too. But I assume you have your own tooling anyway...? So far only I have permission to +2 on gerrit for osmo-dev, I see it as my private setup made available to others, so would retain the last say on it. But it also increasingly becomes osmith's setup, so we can change permissions... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From michael at usehover.com Wed Oct 31 20:02:48 2018 From: michael at usehover.com (Michael Benedict) Date: Wed, 31 Oct 2018 13:02:48 -0700 Subject: EUSE with user input Message-ID: Hi all, The demo EUSE application included with OsmoHLR [1] has been very useful for understanding the flow of information during a USSD session. I would like to extend it to request input from the user and allow > 1 request/response. I have tried changing the session state to `OSMO_GSUP_SESSION_STATE_CONTINUE`, and the gsup_msg_type to `OSMO_GSUP_MSGT_PROC_SS_REQUEST` in `euse_tx_ss`. I see the ?You sent?? response on my phone, but do not get an input field. Can anyone advise if this is the correct general approach or point me in the right direction? Thanks for your patience as I figure these things out. Best, ?Michael [1] https://github.com/osmocom/osmo-hlr/blob/master/src/osmo-euse-demo.c