From ptrkrysik at gmail.com Fri Jun 1 18:14:35 2018 From: ptrkrysik at gmail.com (Piotr Krysik) Date: Fri, 1 Jun 2018 20:14:35 +0200 Subject: nanoBTS constantly restarting In-Reply-To: <415BBE2D-3650-4C0A-8A47-8CBFFB402E55@gmail.com> References: <20180329103001.GW26197@nataraja> <651EDA38-D7AE-4740-9913-23179A8C7FAE@gmail.com> <20180403085720.GI3545@nataraja> <415BBE2D-3650-4C0A-8A47-8CBFFB402E55@gmail.com> Message-ID: W dniu 03.04.2018 o?12:04, Michael Spahn pisze: > Nevermind, it?s working perfectly now, I accidentally disabled all SI types?. > So the only type I disabled is SI2quater and now everything seems to work completely fine. > Doesn?t SI2quater handle 3G-related information? I could see why that would cause problems on a 2G cell. > >> On 3. Apr 2018, at 10:57, Harald Welte wrote: >> >> On Tue, Apr 03, 2018 at 10:30:55AM +0200, Michael Spahn wrote: >>> Hi, >>> >>> so I?ve disabled sending of System Information Types >> >> which of the types did you disable, and which are still sent? >> >>> and now the BTS isn?t rebooting anymore and the log doesn?t seem to show any errors. However, as long as osmo-bsc is running my phone endlessly scans for networks. The scan only ends when I stop osmo-bsc. I guess that?s a configuration issue of some sort? >> >> You will need SI2/3/4 as a minimum. And those of course shouldn't contain any indication that other SI types are present, as otherwise the phone will wait for that SI to appear. Hi all, I think I have the same/similar issue with NanoBTS. Is it possible for you to share what exactly solved your problem? It would make this thread more helpful/finished. -- Best Regards, Piotr Krysik From jovanovskiborjan at gmail.com Sat Jun 2 04:58:21 2018 From: jovanovskiborjan at gmail.com (Borjan Jovanovski) Date: Sat, 2 Jun 2018 06:58:21 +0200 Subject: ABIS over IuB SCTP In-Reply-To: References: Message-ID: Hi everyone, i would like to know if it is possible to connect a bts which uses abis over sctp to OpenBSC and if so i would kindly ask for an explenation on how to do that. Kind thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Jun 2 07:32:54 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 2 Jun 2018 09:32:54 +0200 Subject: ABIS over IuB SCTP In-Reply-To: References: Message-ID: <20180602073254.GK3699@nataraja> Hi Borjan, you seem to be confusing different technologies. A BTS is a 2G devices, which is specified to implement Abis (RSL + OML) to a BSC. Abis, including some vendor-specific dialects are implemented in OsmoNITB (deprecated) and OsmoBSC. Your subject line indicates "IuB". This is the protocol of a 3G NodeB to a RNC, and has nothing to do with Abis. We don't implement it. Please clarify which exact equipment you would want to use, as well as as much information about the protocol as you have. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jovanovskiborjan at gmail.com Sat Jun 2 12:15:38 2018 From: jovanovskiborjan at gmail.com (Borjan Jovanovski) Date: Sat, 2 Jun 2018 14:15:38 +0200 Subject: ABIS over IuB SCTP In-Reply-To: <20180602073254.GK3699@nataraja> References: <20180602073254.GK3699@nataraja> Message-ID: Hi Harald, Thank you for the quick response and also the clarification. Let me try explain again, my device is a multimode device BTS NodeB and eNodeB 2G + 3G + 4G and uses SCTP protocol for BSC RNC and MME connection, i am using different software for all the other entities and all support SCTP, but i couldn't get OpenBSC to work with abis over sctp. So my final question is: How to handle Abis over SCTP with OpenBSC. On Sat, Jun 2, 2018, 09:40 Harald Welte wrote: > Hi Borjan, > > you seem to be confusing different technologies. A BTS is a 2G devices, > which is specified to implement Abis (RSL + OML) to a BSC. Abis, including > some vendor-specific dialects are implemented in OsmoNITB (deprecated) and > OsmoBSC. > > Your subject line indicates "IuB". This is the protocol of a 3G NodeB to > a RNC, and has nothing to do with Abis. We don't implement it. > > Please clarify which exact equipment you would want to use, as well as as > much information about the protocol as you have. > > -- > - 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 laforge at gnumonks.org Sat Jun 2 12:49:53 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 2 Jun 2018 14:49:53 +0200 Subject: ABIS over IuB SCTP In-Reply-To: References: <20180602073254.GK3699@nataraja> Message-ID: <20180602124953.GM3699@nataraja> Hi Borjan, On Sat, Jun 02, 2018 at 02:15:38PM +0200, Borjan Jovanovski wrote: > my device is a multimode device BTS NodeB and eNodeB 2G + 3G + 4G and > uses SCTP protocol for BSC RNC and MME connection Can you tell us more about that device? > ... but i couldn't get OpenBSC to work with abis over sctp. So my final question is: > How to handle Abis over SCTP with OpenBSC. To the best of my knowledge, there is no 3GPP specification for Abis over SCTP. As such, it's not a surprise that we're not implementing it in OsmoBSC :) Maybe I missed something. Can you please point me to relevant specification for this Abis dialect? I would assume it's some vendor-specific dialect. Do you have protocol-level documentation for that available? Do you have protocol traces of this dialect? In any case, even with documentation and/or traces, you would need to develop the respective code to interface this new Abis dialect/encapsulation. The required effort depends on how far that dialect diverges from the existing "known" dialects/formats. If it's just 08.58 RSL and 12.21 OML inside SCTP, then it should be rather little effort. But that's a big "if" :) 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 jovanovskiborjan at gmail.com Sat Jun 2 12:57:30 2018 From: jovanovskiborjan at gmail.com (Borjan Jovanovski) Date: Sat, 2 Jun 2018 14:57:30 +0200 Subject: ABIS over IuB SCTP In-Reply-To: <20180602124953.GM3699@nataraja> References: <20180602073254.GK3699@nataraja> <20180602124953.GM3699@nataraja> Message-ID: Hi Harald, We are talking about a ZTE MacroBTS ZXSDR BS8900A. And about your further questions, your final statement is correct it is standard abis dialect encapsulated in SCTP, i can provide documentation at a later time as i am not home at the moment, but i can tell you now that, the SCTP protocol is terminated in a switch type device before the bsc hardware, and then further communication continues over tcp to the bsc. Regards, Borjan On Sat, Jun 2, 2018, 14:50 Harald Welte wrote: > Hi Borjan, > > On Sat, Jun 02, 2018 at 02:15:38PM +0200, Borjan Jovanovski wrote: > > > my device is a multimode device BTS NodeB and eNodeB 2G + 3G + 4G and > > uses SCTP protocol for BSC RNC and MME connection > > Can you tell us more about that device? > > > ... but i couldn't get OpenBSC to work with abis over sctp. So my final > question is: > > How to handle Abis over SCTP with OpenBSC. > > To the best of my knowledge, there is no 3GPP specification for Abis over > SCTP. > > As such, it's not a surprise that we're not implementing it in OsmoBSC :) > Maybe I missed something. Can you please point me to relevant > specification for this Abis dialect? > > I would assume it's some vendor-specific dialect. Do you have > protocol-level > documentation for that available? Do you have protocol traces of this > dialect? > > In any case, even with documentation and/or traces, you would need to > develop the respective code to interface this new Abis > dialect/encapsulation. The required effort depends on how far that > dialect diverges from the existing "known" dialects/formats. If it's > just 08.58 RSL and 12.21 OML inside SCTP, then it should be rather > little effort. But that's a big "if" :) > > 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 jovanovskiborjan at gmail.com Sat Jun 2 13:08:09 2018 From: jovanovskiborjan at gmail.com (Borjan Jovanovski) Date: Sat, 2 Jun 2018 15:08:09 +0200 Subject: ABIS over IuB SCTP In-Reply-To: References: <20180602073254.GK3699@nataraja> <20180602124953.GM3699@nataraja> Message-ID: Further clarification: Regarding my initial mixup of standard iub / abis, it was because of this, when i first met the problem i googled for a solution and ran into this: https://osqa-ask.wireshark.org/questions/23531/abis-over-iua-decoding it was actually abis over IuA. On Sat, Jun 2, 2018, 14:57 Borjan Jovanovski wrote: > Hi Harald, > > We are talking about a ZTE MacroBTS ZXSDR BS8900A. > > And about your further questions, your final statement is correct it is > standard abis dialect encapsulated in SCTP, i can provide documentation at > a later time as i am not home at the moment, but i can tell you now that, > the SCTP protocol is terminated in a switch type device before the bsc > hardware, and then further communication continues over tcp to the bsc. > Regards, > Borjan > > On Sat, Jun 2, 2018, 14:50 Harald Welte wrote: > >> Hi Borjan, >> >> On Sat, Jun 02, 2018 at 02:15:38PM +0200, Borjan Jovanovski wrote: >> >> > my device is a multimode device BTS NodeB and eNodeB 2G + 3G + 4G and >> > uses SCTP protocol for BSC RNC and MME connection >> >> Can you tell us more about that device? >> >> > ... but i couldn't get OpenBSC to work with abis over sctp. So my final >> question is: >> > How to handle Abis over SCTP with OpenBSC. >> >> To the best of my knowledge, there is no 3GPP specification for Abis over >> SCTP. >> >> As such, it's not a surprise that we're not implementing it in OsmoBSC :) >> Maybe I missed something. Can you please point me to relevant >> specification for this Abis dialect? >> >> I would assume it's some vendor-specific dialect. Do you have >> protocol-level >> documentation for that available? Do you have protocol traces of this >> dialect? >> >> In any case, even with documentation and/or traces, you would need to >> develop the respective code to interface this new Abis >> dialect/encapsulation. The required effort depends on how far that >> dialect diverges from the existing "known" dialects/formats. If it's >> just 08.58 RSL and 12.21 OML inside SCTP, then it should be rather >> little effort. But that's a big "if" :) >> >> 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 rp.labs at gmx.ch Sun Jun 3 08:43:04 2018 From: rp.labs at gmx.ch (Labs) Date: Sun, 3 Jun 2018 10:43:04 +0200 Subject: ABIS over IuB SCTP In-Reply-To: References: <20180602073254.GK3699@nataraja> <20180602124953.GM3699@nataraja> Message-ID: Hello, I found this document on the net: https://www.academia.edu/19659583/Documents_mx_zxsdr-bs8900-gu360v40921-outdoor-gsm-umts-dual-mode-macro-node-b-system-description For Abis when using the ethernet port it is using SCTP for control plane messages and after encapsulated in IP and for user plane it is using RTP and then encapsulated in UDP. There is no clear document for Huawei multi-standard boxes but I know that for Abis over IP you need to define IPPATH which is probably SCTP to provide dual-homing feature. Regards, R. Sent from my Mobile > On 02.06.2018, at 15:08, Borjan Jovanovski wrote: > > Further clarification: Regarding my initial mixup of standard iub / abis, it was because of this, when i first met the problem i googled for a solution and ran into this: > > https://osqa-ask.wireshark.org/questions/23531/abis-over-iua-decoding > > it was actually abis over IuA. > > >> On Sat, Jun 2, 2018, 14:57 Borjan Jovanovski wrote: >> Hi Harald, >> >> We are talking about a ZTE MacroBTS ZXSDR BS8900A. >> >> And about your further questions, your final statement is correct it is standard abis dialect encapsulated in SCTP, i can provide documentation at a later time as i am not home at the moment, but i can tell you now that, the SCTP protocol is terminated in a switch type device before the bsc hardware, and then further communication continues over tcp to the bsc. >> Regards, >> Borjan >> >>> On Sat, Jun 2, 2018, 14:50 Harald Welte wrote: >>> Hi Borjan, >>> >>> On Sat, Jun 02, 2018 at 02:15:38PM +0200, Borjan Jovanovski wrote: >>> >>> > my device is a multimode device BTS NodeB and eNodeB 2G + 3G + 4G and >>> > uses SCTP protocol for BSC RNC and MME connection >>> >>> Can you tell us more about that device? >>> >>> > ... but i couldn't get OpenBSC to work with abis over sctp. So my final question is: >>> > How to handle Abis over SCTP with OpenBSC. >>> >>> To the best of my knowledge, there is no 3GPP specification for Abis over SCTP. >>> >>> As such, it's not a surprise that we're not implementing it in OsmoBSC :) >>> Maybe I missed something. Can you please point me to relevant >>> specification for this Abis dialect? >>> >>> I would assume it's some vendor-specific dialect. Do you have protocol-level >>> documentation for that available? Do you have protocol traces of this dialect? >>> >>> In any case, even with documentation and/or traces, you would need to >>> develop the respective code to interface this new Abis >>> dialect/encapsulation. The required effort depends on how far that >>> dialect diverges from the existing "known" dialects/formats. If it's >>> just 08.58 RSL and 12.21 OML inside SCTP, then it should be rather >>> little effort. But that's a big "if" :) >>> >>> 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 jovanovskiborjan at gmail.com Sun Jun 3 13:03:34 2018 From: jovanovskiborjan at gmail.com (Borjan Jovanovski) Date: Sun, 3 Jun 2018 15:03:34 +0200 Subject: ABIS over IuB SCTP In-Reply-To: References: <20180602073254.GK3699@nataraja> <20180602124953.GM3699@nataraja> Message-ID: Hello, yes i also have this document, it id the exact device i am talking about, and it is that exact same protocol and way of function. Now if only someone could implement this as a feature. On Sun, Jun 3, 2018, 10:43 Labs wrote: > Hello, > > I found this document on the net: > > https://www.academia.edu/19659583/Documents_mx_zxsdr-bs8900-gu360v40921-outdoor-gsm-umts-dual-mode-macro-node-b-system-description > > For Abis when using the ethernet port it is using SCTP for control plane > messages and after encapsulated in IP and for user plane it is using RTP > and then encapsulated in UDP. > > There is no clear document for Huawei multi-standard boxes but I know that > for Abis over IP you need to define IPPATH which is probably SCTP to > provide dual-homing feature. > > Regards, > R. > > Sent from my Mobile > > On 02.06.2018, at 15:08, Borjan Jovanovski > wrote: > > Further clarification: Regarding my initial mixup of standard iub / abis, > it was because of this, when i first met the problem i googled for a > solution and ran into this: > > https://osqa-ask.wireshark.org/questions/23531/abis-over-iua-decoding > > it was actually abis over IuA. > > > On Sat, Jun 2, 2018, 14:57 Borjan Jovanovski > wrote: > >> Hi Harald, >> >> We are talking about a ZTE MacroBTS ZXSDR BS8900A. >> >> And about your further questions, your final statement is correct it is >> standard abis dialect encapsulated in SCTP, i can provide documentation at >> a later time as i am not home at the moment, but i can tell you now that, >> the SCTP protocol is terminated in a switch type device before the bsc >> hardware, and then further communication continues over tcp to the bsc. >> Regards, >> Borjan >> >> On Sat, Jun 2, 2018, 14:50 Harald Welte wrote: >> >>> Hi Borjan, >>> >>> On Sat, Jun 02, 2018 at 02:15:38PM +0200, Borjan Jovanovski wrote: >>> >>> > my device is a multimode device BTS NodeB and eNodeB 2G + 3G + 4G and >>> > uses SCTP protocol for BSC RNC and MME connection >>> >>> Can you tell us more about that device? >>> >>> > ... but i couldn't get OpenBSC to work with abis over sctp. So my >>> final question is: >>> > How to handle Abis over SCTP with OpenBSC. >>> >>> To the best of my knowledge, there is no 3GPP specification for Abis >>> over SCTP. >>> >>> As such, it's not a surprise that we're not implementing it in OsmoBSC :) >>> Maybe I missed something. Can you please point me to relevant >>> specification for this Abis dialect? >>> >>> I would assume it's some vendor-specific dialect. Do you have >>> protocol-level >>> documentation for that available? Do you have protocol traces of this >>> dialect? >>> >>> In any case, even with documentation and/or traces, you would need to >>> develop the respective code to interface this new Abis >>> dialect/encapsulation. The required effort depends on how far that >>> dialect diverges from the existing "known" dialects/formats. If it's >>> just 08.58 RSL and 12.21 OML inside SCTP, then it should be rather >>> little effort. But that's a big "if" :) >>> >>> 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 laforge at gnumonks.org Sun Jun 3 13:24:45 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 3 Jun 2018 15:24:45 +0200 Subject: ABIS over IuB SCTP In-Reply-To: References: <20180602073254.GK3699@nataraja> <20180602124953.GM3699@nataraja> Message-ID: <20180603132445.GQ3699@nataraja> On Sun, Jun 03, 2018 at 03:03:34PM +0200, Borjan Jovanovski wrote: > yes i also have this document, it id the exact device i am talking about, > and it is that exact same protocol and way of function. Now if only someone > could implement this as a feature. Free Software lives by contributions. The support for the currently supported Abis dialects and BTS models was added because some people owning the related devices wrote the related code. We're always happy to merge any related patches! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jovanovskiborjan at gmail.com Sun Jun 3 14:15:27 2018 From: jovanovskiborjan at gmail.com (Borjan Jovanovski) Date: Sun, 3 Jun 2018 16:15:27 +0200 Subject: ABIS over IuB SCTP In-Reply-To: <20180603132445.GQ3699@nataraja> References: <20180602073254.GK3699@nataraja> <20180602124953.GM3699@nataraja> <20180603132445.GQ3699@nataraja> Message-ID: I for one am a firm believer in that, but sadly it is out of my scope for now.. maybe some day in the future i will achieve it and gladly submit it for the good people of the community to find use out of it. On Sun, Jun 3, 2018, 15:30 Harald Welte wrote: > On Sun, Jun 03, 2018 at 03:03:34PM +0200, Borjan Jovanovski wrote: > > yes i also have this document, it id the exact device i am talking about, > > and it is that exact same protocol and way of function. Now if only > someone > > could implement this as a feature. > > Free Software lives by contributions. The support for the currently > supported > Abis dialects and BTS models was added because some people owning the > related > devices wrote the related code. We're always happy to merge any related > patches! > > -- > - 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 antony at funquality.be Tue Jun 5 11:14:13 2018 From: antony at funquality.be (Antony Lemmens) Date: Tue, 5 Jun 2018 13:14:13 +0200 Subject: osmo-trx-lms Message-ID: Hello folks, I had trouble with the osmo-trx-uhd and LimeSDR (like in Bug #2723), so I tried the branch "laforge/lime". The result is that the LimeSDR apparently transmit successfully data (my MS display correctly the MCC/MNC and the spectro shows the correct frequency) but it seems that the LimeSDR/driver/not-sure-what does not receive any signal in return. I know that my complete hardware and software setup (cables, tem cell, spectro) is OK because it works fine with the Fairwaves UmTRX board. The LimeSuiteGUI shows some problems with the RX calibration, but if I do a full reset to default settings from the GUI, it works fine (so I suppose that the problem does not come from the LimeSDR board itself). If I restart osmo-trx-lms, it cause the problem again. Is there some specific settings to do in osmo-trx.cfg to make it work? I know that it is a work in progress, and if you need some feedback or tests, do not hesitate to ask. Have a nice day, Antony -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jun 5 11:54:14 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 5 Jun 2018 13:54:14 +0200 Subject: osmo-trx-lms In-Reply-To: References: Message-ID: <20180605115414.GN10664@nataraja> Hi Antony, On Tue, Jun 05, 2018 at 01:14:13PM +0200, Antony Lemmens wrote: > I had trouble with the osmo-trx-uhd and LimeSDR (like in Bug #2723), so I > tried the branch "laforge/lime". yes, unfortunately we haven't had much success in getting OsmoTRX to run stable with LimeSDR so far. It works like a charm with other hardware, though. > The result is that the LimeSDR apparently transmit successfully data (my MS > display correctly the MCC/MNC and the spectro shows the correct frequency) > but it seems that the LimeSDR/driver/not-sure-what does not receive any > signal in return. This is exactly where the development status is for us. We then got side-tracked with various problems introduced with more recent LimeSuite releases, as well as with problems related to the hardware we received at sysmocom. Transmit didn't work reliable for us with LimeSDR-mini HW v1.0 nor with the large LimeSDR, while it did seem to work fine with LimeSDR-mini HW v1.1. I don't think it makes sense to work on the Rx side until Tx works reliable at least on the regular LimeSDR as well as LimeSDR-mini v1.1, and preferably with latest LimeSuite releases rather than having to pin to some old versions. It all feels like it's Lime* is currently still a very moving target. With LimeSDR-mini v1.1 (where Tx waveform looks great) we even have trouble getting the most basic LMS_Open() to work reliably, see http://osmocom.org/issues/2919#note-11 :( > I know that it is a work in progress, and if you need some feedback or > tests, do not hesitate to ask. Thanks for your offer, it's much appreciated. You could provide any feedback from testing at http://osmocom.org/issues/2919 and describe any "known working" setup of hardware (+version), gateware, limeSuite in all detail. 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 ff1016 at wildcats.unh.edu Tue Jun 12 20:47:20 2018 From: ff1016 at wildcats.unh.edu (Ferdaus, Farah) Date: Tue, 12 Jun 2018 20:47:20 +0000 Subject: Regarding Programming SIM cards Message-ID: Hi there, I have built and installed the requirements for OpenBTS and my USRP (Ettus N210) is responding but now I am stuck at SIM card stage. I am trying to program a Super SIM 16-in-1 using the Insten_USB_SIM_Card_Writer and following the steps mentioned here and here but unable to write the sim card. Every time I run the pcsc_scan command it stops working. Below is the output. "wslopenbts at wslopenbts-desktop:~$ pcsc_scan PC/SC device scanner V 1.4.25 (c) 2001-2011, Ludovic Rousseau Compiled with PC/SC lite version: 1.8.14 Using reader plug'n play mechanism Scanning present readers... Waiting for the first reader...^C" The problem seems that the PC is not getting the SIM card reader. But the SIM card reader was plugged into the PC while running the command and the LED turned red which indicate it was getting the power from the PC. Do you think, buying another new SIM card reader can resolve the issue? I can test by buying another SIM and SIM card reader; Do any of you have any suggestion for the SIM and SIM card reader, particularly which one will be good? Finally, any guideline for me regarding programming the SIM card. I will be very grateful if you help me by giving suggestions to resolve my issue. Can anyone please help me regarding this issue. Thanks in advance Best Regards, Farah -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Wed Jun 13 04:25:47 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 13 Jun 2018 06:25:47 +0200 (CEST) Subject: Regarding Programming SIM cards In-Reply-To: References: Message-ID: Hi Farah, What SIM card reader are you using? What does the command lsusb say? Also check dmesg and syslog for more information. It is almost sure that your reader?s driver is not yet or already included in pcsc, so you will need peobably change pcsc version to an older or newer release. Kind regards, Domi 2018. j?n. 13. d?tummal, 1:22 id?pontban Ferdaus, Farah ?rta: > Hi there, > I have built and installed the requirements for OpenBTS and my USRP (Ettus N210) is responding but now I am stuck at SIM card stage. I am trying to program a Super SIM 16-in-1 using the Insten_USB_SIM_Card_Writer and following the steps mentioned here and here but unable to write the sim card. Every time I run the pcsc_scan command it stops working. Below is the output. > > "wslopenbts at wslopenbts-desktop:~$ pcsc_scan > PC/SC device scanner > V 1.4.25 (c) 2001-2011, Ludovic Rousseau > Compiled with PC/SC lite version: 1.8.14 > Using reader plug'n play mechanism > Scanning present readers... > Waiting for the first reader...^C" > > The problem seems that the PC is not getting the SIM card reader. But the SIM card reader was plugged into the PC while running the command and the LED turned red which indicate it was getting the power from the PC. Do you think, buying another new SIM card reader can resolve the issue? I can test by buying another SIM and SIM card reader; Do any of you have any suggestion for the SIM and SIM card reader, particularly which one will be good? Finally, any guideline for me regarding programming the SIM card. I will be very grateful if you help me by giving suggestions to resolve my issue. > > Can anyone please help me regarding this issue. > > Thanks in advance > Best Regards, > Farah > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmocom at lains.me Wed Jun 13 09:54:35 2018 From: osmocom at lains.me (Filipe =?iso-8859-1?b?TGHtbnM=?=) Date: Wed, 13 Jun 2018 10:54:35 +0100 Subject: Regarding Programming SIM cards In-Reply-To: References: Message-ID: <1528883675.27928.1@smtp.migadu.com> Hey, The reader you are using it's called a Phoenix Reader, they are a bit tricky and there isn't much documentation (at least I wasn't able to find). I haven't had any luck making them work with PCSC. You should try to use a proper reader. If you want a recommendation for a decent brand, I would suggest Gemalto. If you really want to use your current reader, you should check UICCSIM by opencells, afaik it should work. http://open-cells.com/d5138782a8739209ec5760865b1e53b0/uicc-v1.3.tgz https://open-cells.com/index.php/uiccsim-programing/ For more information on using phoenix readers with PCSC, check the following link. http://timesinker.blogspot.com/2016/04/using-cheap-sim-card-readers.html (I haven't had any luck with this) Regards, Filipe La?ns (FFY00) https://github.com/FFY00 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 On Wed, Jun 13, 2018 at 5:25 AM, Tomcs?nyi, Domonkos wrote: > Hi Farah, > > What SIM card reader are you using? What does the command lsusb say? > Also check dmesg and syslog for more information. It is almost sure > that your reader?s driver is not yet or already included in pcsc, > so you will need peobably change pcsc version to an older or newer > release. > > Kind regards, > Domi > > > 2018. j?n. 13. d?tummal, 1:22 id?pontban Ferdaus, Farah > ?rta: > >> Hi there, >> I have built and installed the requirements for OpenBTS and my USRP >> (Ettus N210) is responding but now I am stuck at SIM card stage. I >> am trying to program a Super SIM 16-in-1 using the >> Insten_USB_SIM_Card_Writer and following the steps mentioned here >> and here but unable to write the sim card. Every time I run the >> pcsc_scan command it stops working. Below is the output. >> >> "wslopenbts at wslopenbts-desktop:~$ pcsc_scan >> PC/SC device scanner >> V 1.4.25 (c) 2001-2011, Ludovic Rousseau >> Compiled with PC/SC lite version: 1.8.14 >> Using reader plug'n play mechanism >> Scanning present readers... >> Waiting for the first reader...^C" >> >> The problem seems that the PC is not getting the SIM card reader. >> But the SIM card reader was plugged into the PC while running the >> command and the LED turned red which indicate it was getting the >> power from the PC. Do you think, buying another new SIM card reader >> can resolve the issue? I can test by buying another SIM and SIM card >> reader; Do any of you have any suggestion for the SIM and SIM card >> reader, particularly which one will be good? Finally, any guideline >> for me regarding programming the SIM card. I will be very grateful >> if you help me by giving suggestions to resolve my issue. >> >> Can anyone please help me regarding this issue. >> >> Thanks in advance >> Best Regards, >> Farah >> Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- An HTML attachment was scrubbed... URL: From ff1016 at wildcats.unh.edu Wed Jun 13 16:41:30 2018 From: ff1016 at wildcats.unh.edu (Ferdaus, Farah) Date: Wed, 13 Jun 2018 16:41:30 +0000 Subject: Regarding Programming SIM cards In-Reply-To: References: , Message-ID: Dear Domi, Thank you for your kind reply and suggestions. Now I am using this Insten_USB_SIM_Card_Writer one, but I am pretty sure this SIM card reader is not working. I think it will be good to buy a new card reader; I am taking necessary steps to buy the new SIM card reader. I hope everything will be fine. However, here is the output of lsusb command without the Card reader. wslopenbts at wslopenbts-desktop:~$ lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub and with the Card reader. wslopenbts at wslopenbts-desktop:~$ lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub It seems syslog command is not working in my system. Here is the output. wslopenbts at wslopenbts-desktop:~$ syslog No command 'syslog' found, did you mean: Command 'syslogd' from package 'busybox-syslogd' (universe) Command 'syslogd' from package 'inetutils-syslogd' (universe) Command 'dsyslog' from package 'dsyslog' (universe) syslog: command not found Thank you. Best Regards, Farah ________________________________ From: Tomcs?nyi, Domonkos Sent: Wednesday, June 13, 2018 12:25:47 AM To: Ferdaus, Farah Cc: openbsc at lists.osmocom.org Subject: Re: Regarding Programming SIM cards Hi Farah, What SIM card reader are you using? What does the command lsusb say? Also check dmesg and syslog for more information. It is almost sure that your reader?s driver is not yet or already included in pcsc, so you will need peobably change pcsc version to an older or newer release. Kind regards, Domi 2018. j?n. 13. d?tummal, 1:22 id?pontban Ferdaus, Farah > ?rta: Hi there, I have built and installed the requirements for OpenBTS and my USRP (Ettus N210) is responding but now I am stuck at SIM card stage. I am trying to program a Super SIM 16-in-1 using the Insten_USB_SIM_Card_Writer and following the steps mentioned here and here but unable to write the sim card. Every time I run the pcsc_scan command it stops working. Below is the output. "wslopenbts at wslopenbts-desktop:~$ pcsc_scan PC/SC device scanner V 1.4.25 (c) 2001-2011, Ludovic Rousseau > Compiled with PC/SC lite version: 1.8.14 Using reader plug'n play mechanism Scanning present readers... Waiting for the first reader...^C" The problem seems that the PC is not getting the SIM card reader. But the SIM card reader was plugged into the PC while running the command and the LED turned red which indicate it was getting the power from the PC. Do you think, buying another new SIM card reader can resolve the issue? I can test by buying another SIM and SIM card reader; Do any of you have any suggestion for the SIM and SIM card reader, particularly which one will be good? Finally, any guideline for me regarding programming the SIM card. I will be very grateful if you help me by giving suggestions to resolve my issue. Can anyone please help me regarding this issue. Thanks in advance Best Regards, Farah -------------- next part -------------- An HTML attachment was scrubbed... URL: From cattalina.nicolescu at gmail.com Wed Jun 6 09:11:31 2018 From: cattalina.nicolescu at gmail.com (Cattalina Maria) Date: Wed, 6 Jun 2018 05:11:31 -0400 Subject: question! Message-ID: Hello. I have some problems.I want to create a GSM network for my final diploma project for University.I'm using USRP2 and I haven't find any specific configuration files for this type of USRP.Do you have any configuration files for USRP2? I'm running Kali Linux (amd64). I've attached the config files that I've used from osmocom.org and some printscreens.Sorry for my English.I'm looking forward for your response.Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc44.conf Type: application/octet-stream Size: 4250 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmobsc3.cfg Type: application/octet-stream Size: 1807 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts44.cfg Type: application/octet-stream Size: 568 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-pcu44.cfg Type: application/octet-stream Size: 1060 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapbsc.png Type: image/png Size: 897224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapbsc2.png Type: image/png Size: 596849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snapbts.png Type: image/png Size: 647904 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snappcu.png Type: image/png Size: 567156 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: snaptrx.png Type: image/png Size: 640124 bytes Desc: not available URL: From osmocom at lains.me Thu Jun 14 13:16:31 2018 From: osmocom at lains.me (Filipe =?iso-8859-1?b?TGHtbnM=?=) Date: Thu, 14 Jun 2018 14:16:31 +0100 Subject: question! In-Reply-To: References: Message-ID: <1528982191.1052.0@smtp.migadu.com> Hey Cattalina, As stated in the logs, the openbsc44.conf config has some problem. You should re-write it. If you want, you can use this one as a base. Let me know if you more help :) Thanks, Filipe La?ns (FFY00) https://github.com/FFY00 3DCE 51D6 0930 EBA4 7858 BA41 46F6 33CB B0EB 4BF2 On Wed, Jun 6, 2018 at 10:11 AM, Cattalina Maria wrote: > Hello. I have some problems.I want to create a GSM network for my > final diploma project for University.I'm using USRP2 and I haven't > find any specific configuration files for this type of USRP.Do you > have any configuration files for USRP2? I'm running Kali Linux > (amd64). I've attached the config files that I've used from > osmocom.org and some printscreens.Sorry for my English.I'm looking > forward for your response.Thank you! Sent via Migadu.com, world's easiest email hosting -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Fri Jun 15 14:13:40 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 15 Jun 2018 16:13:40 +0200 Subject: Osmo-bts "shutdown timer expired" In-Reply-To: References: Message-ID: <20180615141340.GA5428@my.box> Hi ???????, your English is fine, but you just sent >2 Mb worth of screenshot images of text. That's *really* bad style. Please do not ever send images to a mailing list. If you have large attachments, link to them online. Just send text. "Shutdown timer expired" is what I see when my BTS is unable to connect to the BSC. Though osmocombb is not about BTS, it is about the baseband. ~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 Fri Jun 15 14:14:36 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 15 Jun 2018 16:14:36 +0200 Subject: question! In-Reply-To: References: Message-ID: <20180615141436.GB5428@my.box> Please do not ever send images to a mailing list! Send text instead. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From andrew at carrierdetect.com Fri Jun 15 16:27:12 2018 From: andrew at carrierdetect.com (Andrew Back) Date: Fri, 15 Jun 2018 17:27:12 +0100 Subject: osmo-bsc with remote osmo-stp. Message-ID: <1c9c3705-531b-94ae-be85-13672543fd4f@carrierdetect.com> Hello, I've had success with running a NITB based on the new architecture fine when everything is on one host. However, I'd now like to split this across multiple hosts. I have one host dedicated to running osmo-stp and this appears to bind to the IP specified. However, the instance of osmo-bsc running on another host always fails to connect and I think, despite configuring to use a remote STP, it's trying localhost. Packages installed from Debian 9.0/latest repo. Configs and osmo-bsc output below. Any pointers as to where I'm going wrong would be much appreciated. Regards, Andrew // **** osmo-bsc output: $ sudo /usr/bin/osmo-bsc -c /etc/osmocom/osmo-bsc.cfg <001d> osmo_ss7.c:1269 0: ASP Restart for server not implemented yet! % GPRS not enabled on this BTS % GPRS not enabled on this BTS % GPRS not enabled on this BTS % GPRS not enabled on this BTS % GPRS not enabled on this BTS % GPRS not enabled on this BTS % Line 0 already exists <0011> telnet_interface.c:104 telnet at 10.1.1.7 4242 <0013> input/ipaccess.c:853 enabling ipaccess BSC mode on 10.1.1.7 with OML 3002 and RSL 3003 TCP ports <0018> control_if.c:863 CTRL at 127.0.0.1 4249 <0008> osmo_bsc_sigtran.c:427 Initializing SCCP connection to MSC msc-0 <0008> osmo_bsc_sigtran.c:437 CS7 Instance identifier, A-Interface: 0 <001e> sccp_user.c:397 msc-0: Using SS7 instance 0, pc:0.0.2 <001e> sccp_user.c:411 msc-0: Creating AS instance <001e> sccp_user.c:421 msc-0: Using AS instance as-clnt-msc-0 <001e> sccp_user.c:426 msc-0: Creating default route <001e> sccp_user.c:446 msc-0: Creating ASP instance <0011> socket.c:266 unable to connect socket: (null):2905: Connection refused <0011> socket.c:279 no suitable remote addr found for: (null):2905 <001d> osmo_ss7.c:1253 0: Unable to open stream client for ASP asp-clnt-msc-0 <001e> sccp_user.c:481 msc-0: Using ASP instance asp-clnt-msc-0 <001e> sccp_user.c:484 msc-0: Creating SCCP instance <0008> osmo_bsc_sigtran.c:480 (msc-0) A-interface: local (BSC) SCCP address: RI=SSN_PC,PC=0.0.2,SSN=BSSAP <0008> osmo_bsc_sigtran.c:482 (msc-0) A-interface: remote (MSC) SCCP address: RI=SSN_PC,PC=0.0.1,SSN=BSSAP <0013> input/ipa.c:265 accept()ed new link from 10.1.1.8 to port 3002 <0005> abis_nm.c:506 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix. <0005> abis_nm.c:506 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:506 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:506 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:506 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:506 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:506 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix. <0005> abis_nm.c:573 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/2]: osmobts is 0.8.1 <0005> abis_nm.c:445 BTS0 reported variant: omso-bts-trx <0005> abis_nm.c:467 BTS0 Attribute Manufacturer Dependent State is unreported <0005> abis_nm.c:573 OC=BTS(01) INST=(00,ff,ff): BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown <0005> abis_nm.c:2809 IPA RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0013> input/ipa.c:265 accept()ed new link from 10.1.1.8 to port 3003 <0004> bsc_init.c:333 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 868 using MCC-MNC 901-70 LAC=23 CID=0 BSIC=63 <0004> abis_rsl.c:2502 (bts=0,trx=0,ts=2,pchan=TCH/F_TCH/H_PDCH as NONE): GPRS mode is 'none': not activating PDCH. <0004> abis_rsl.c:2502 (bts=0,trx=0,ts=3,pchan=TCH/F_TCH/H_PDCH as NONE): GPRS mode is 'none': not activating PDCH. <0004> abis_rsl.c:2502 (bts=0,trx=0,ts=4,pchan=TCH/F_TCH/H_PDCH as NONE): GPRS mode is 'none': not activating PDCH. <0004> abis_rsl.c:2502 (bts=0,trx=0,ts=5,pchan=TCH/F_TCH/H_PDCH as NONE): GPRS mode is 'none': not activating PDCH. <0004> abis_rsl.c:2502 (bts=0,trx=0,ts=6,pchan=TCH/F_TCH/H_PDCH as NONE): GPRS mode is 'none': not activating PDCH. <0008> a_reset.c:92 A-RESET(msc-0)[0x1d6fff0]{DISC}: (re)sending BSSMAP RESET message... <0008> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.0.1,SSN=BSSAP <001d> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1d6f7e8]{AS_DOWN}: Event AS-TRANSFER.req not permitted <0008> a_reset.c:92 A-RESET(msc-0)[0x1d6fff0]{DISC}: (re)sending BSSMAP RESET message... <0008> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.0.1,SSN=BSSAP <001d> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1d6f7e8]{AS_DOWN}: Event AS-TRANSFER.req not permitted <0011> socket.c:266 unable to connect socket: (null):2905: Connection refused <0011> socket.c:279 no suitable remote addr found for: (null):2905 <0008> a_reset.c:92 A-RESET(msc-0)[0x1d6fff0]{DISC}: (re)sending BSSMAP RESET message... <0008> osmo_bsc_sigtran.c:92 Sending RESET to MSC: RI=SSN_PC,PC=0.0.1,SSN=BSSAP <001d> m3ua.c:507 XUA_AS(as-clnt-msc-0)[0x1d6f7e8]{AS_DOWN}: Event AS-TRANSFER.req not permitted ^Csignal 2 received <0005> bsc_init.c:96 shutting down OML for BTS 0 **** osmo-bsc.cfg: e1_input e1_line 0 driver ipa ipa bind 10.1.1.7 cs7 instance 0 point-code 0.0.2 asp circ-OsmoBSC 2905 0 m3ua remote-ip 10.1.1.5 sccp-address msc_remote point-code 0.0.1 line vty bind 10.1.1.7 msc msc-addr msc_remote network network country code 901 mobile network code 70 bts 0 type sysmobts band GSM-1800 location_area_code 23 ip.access unit_id 1800 0 gprs mode none gprs nsvc 0 remote ip 192.168.0.9 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 local udp port 23000 gprs nsvc 0 nsvci 1800 gprs nsei 1800 gprs cell bvci 1800 trx 0 rf_locked 0 arfcn 868 nominal power 23 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config SDCCH8 timeslot 2 phys_chan_config TCH/F_TCH/H_PDCH timeslot 3 phys_chan_config TCH/F_TCH/H_PDCH timeslot 4 phys_chan_config TCH/F_TCH/H_PDCH timeslot 5 phys_chan_config TCH/F_TCH/H_PDCH timeslot 6 phys_chan_config TCH/F_TCH/H_PDCH timeslot 7 phys_chan_config PDCH e1_input e1_line 0 driver ipa msc 0 mgw remote-ip 10.1.1.6 mgw remote-port 2427 allow-emergency deny codec-list hr3 **** osmo-stp.cfg: log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 0 logging level lss7 debug logging level lsccp debug logging level lsua debug logging level lm3ua debug cs7 instance 0 xua rkm routing-key-allocation dynamic-permitted listen m3ua 2905 accept-asp-connections dynamic-permitted local-ip 10.1.1.5 listen sua 14001 local-ip 10.1.1.5 line vty bind 10.1.1.5 From laforge at gnumonks.org Sat Jun 16 14:58:05 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 16 Jun 2018 16:58:05 +0200 Subject: osmo-bsc with remote osmo-stp. In-Reply-To: <1c9c3705-531b-94ae-be85-13672543fd4f@carrierdetect.com> References: <1c9c3705-531b-94ae-be85-13672543fd4f@carrierdetect.com> Message-ID: <20180616145805.GQ20729@nataraja> Hi Andrew, On Fri, Jun 15, 2018 at 05:27:12PM +0100, Andrew Back wrote: > I've had success with running a NITB based on the new architecture fine > when everything is on one host. However, I'd now like to split this > across multiple hosts. that should be no problem whatsoever and is actually what we had originally during development before trying to make it easy for people who run everything on one host. Also, please note that all our automatic integration / functional test suites run each service in a separate docker container, each on its own IP address. See e.g. http://git.osmocom.org/docker-playground/tree/ttcn3-bsc-test/osmo-bsc.cfg for the osmo-bsc.cfg we use in this setup. > I have one host dedicated to running osmo-stp and > this appears to bind to the IP specified. > However, the instance of > osmo-bsc running on another host always fails to connect and I think, > despite configuring to use a remote STP, it's trying localhost. If you open wireshark, it should be possible to see rather quickly who connects to whom, and whether that succeeds or fails, or with what error. If you filter on SCTP, you will [likely] only see the relevant connections of the A interface. Also, you can display the SS7/SIGTRAN configuration by the VTY commands of libosmo-sigtran, such as show cs7 instance 0 asp show cs7 instance 0 as all those commands work on the BSC, the MSC as well as the STP to show the respective state. 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 Mon Jun 18 05:50:56 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 18 Jun 2018 07:50:56 +0200 Subject: osmo-bsc refactoring / inter-BSC handover In-Reply-To: <20180615113908.GM20729@nataraja> References: <20180615113908.GM20729@nataraja> Message-ID: <20180618055056.GA8364@my.box> Good morning, I wanted to get inter-BSC handover complete before today, and worked like a maniac for the last two weeks. I'm looking forward to your comments on the osmo-bsc rework, which started so small and rippled through the entire code base like a flash flood. I hope you will find review of it not too daunting, it fully qualifies as a code bomb. It is refactoring no less than: - dynamic timeslots, - lchan states from allocation through release, - assignment, - handover - handling of MGW endpoints, and - the conn FSM. - gsm_network->T123 timer handling, - the way a BTS's neighbors are configured, - handover and assignment rate counters, - and whatnot. - adding five new FSM implementations to osmo-bsc, - and actually adding inter-BSC Handover, both sides (almost). Of course I couldn't wrap things up completely, but the good news is that the only problem left now is that I can't get a ttcn3 test written for inter-bsc MT handover [1]. Consider the MT side broken yet, though it should be small fixes. So the refactoring is done and all ttcn3-bsc-tests pass. Yes, *all*! I will now submit the patches to gerrit; some though could want to go to libosmocore, and for some other "neat" inventions of mine I'm watching the comment space in curiosity. I did try to separate some changes into individual commits, but the final chunk is too inter-related to pull it apart without spending huge amounts of time to make osmo-bsc work for each intermediate state. I feel both like saying "sorry" and "you're welcome" about this at the same time. Sorry about the size of the single patch; but a lot of code got extremely easier to read and follow, and a lot safer too, into a nicer osmo-bsc future. ~N [1] I have a marginal test added for inter-bsc MO, but the inter-bsc MT gets me. The problem there is that it is the first time a conn is initiated by the MSC side. I can get that to work by using BSSAP on that Test_CT. It goes well up to the point where osmo-bsc sends MGCP CRCX and expects a response. Now I want to use the MSC_ConnHdlr to manage MGCP, but I can't for the life of me figure out how to be able to do both at the same time. I tried for very long to resolve "BSC_Tests.ttcn:2755.13-2756.31: error: Message type `@BSSAP_CodecPort.BSSAP_N_CONNECT_req' is not present on the outgoing list of port type `@BSSMAP_Emulation.BSSAP_Conn_PT'" but it feels like a brick wall... It's the final thing before I can say: I'm done, take a look at inter-BSC HO. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From andrew at carrierdetect.com Mon Jun 18 18:29:09 2018 From: andrew at carrierdetect.com (Andrew Back) Date: Mon, 18 Jun 2018 19:29:09 +0100 Subject: osmo-bsc with remote osmo-stp. In-Reply-To: <20180616145805.GQ20729@nataraja> References: <1c9c3705-531b-94ae-be85-13672543fd4f@carrierdetect.com> <20180616145805.GQ20729@nataraja> Message-ID: Hi Harald, On 16/06/18 15:58, Harald Welte wrote: > Hi Andrew, > > On Fri, Jun 15, 2018 at 05:27:12PM +0100, Andrew Back wrote: >> I've had success with running a NITB based on the new architecture fine >> when everything is on one host. However, I'd now like to split this >> across multiple hosts. > > that should be no problem whatsoever and is actually what we had originally > during development before trying to make it easy for people who run everything > on one host. > > Also, please note that all our automatic integration / functional test suites > run each service in a separate docker container, each on its own IP address. > > See e.g. http://git.osmocom.org/docker-playground/tree/ttcn3-bsc-test/osmo-bsc.cfg > for the osmo-bsc.cfg we use in this setup. Many thanks, the osmo-bsc and osmo-msc configs helped and I now have handsets registered and can send/receive SMS. However, when I make a voice call it fails and on the osmo-mgw for osmo-msc, I see in the logs: Jun 18 16:28:47 cc4 osmo-mgw[507]: #033[0;m<0011> mgcp_msg.c:208 Not able to find a free endpoint Jun 18 16:28:47 cc4 osmo-mgw[507]: #033[0;m<0011> mgcp_msg.c:322 Unable to find Endpoint `rtpbridge/*@mgw' Jun 18 16:28:47 cc4 osmo-mgw[507]: #033[0;m<0011> mgcp_protocol.c:329 CRCX 5: failed to find the endpoint There are two separate instances of osmo-mgw, each running on a dedicated host, with minimal configs as per the NITB instructions, but using standard port numbers for both since there is no conflict. Regards, Andrew From andrew at carrierdetect.com Tue Jun 19 15:35:43 2018 From: andrew at carrierdetect.com (Andrew Back) Date: Tue, 19 Jun 2018 16:35:43 +0100 Subject: osmo-bsc with remote osmo-stp. In-Reply-To: References: <1c9c3705-531b-94ae-be85-13672543fd4f@carrierdetect.com> <20180616145805.GQ20729@nataraja> Message-ID: <6ff89792-fb1e-5789-07e0-8b4ecfe83d3e@carrierdetect.com> On 18/06/18 19:29, Andrew Back wrote: > Hi Harald, > > On 16/06/18 15:58, Harald Welte wrote: >> Hi Andrew, >> >> On Fri, Jun 15, 2018 at 05:27:12PM +0100, Andrew Back wrote: >>> I've had success with running a NITB based on the new architecture fine >>> when everything is on one host. However, I'd now like to split this >>> across multiple hosts. >> >> that should be no problem whatsoever and is actually what we had originally >> during development before trying to make it easy for people who run everything >> on one host. >> >> Also, please note that all our automatic integration / functional test suites >> run each service in a separate docker container, each on its own IP address. >> >> See e.g. http://git.osmocom.org/docker-playground/tree/ttcn3-bsc-test/osmo-bsc.cfg >> for the osmo-bsc.cfg we use in this setup. > > Many thanks, the osmo-bsc and osmo-msc configs helped and I now have > handsets registered and can send/receive SMS. However, when I make a > voice call it fails and on the osmo-mgw for osmo-msc, I see in the logs: > > Jun 18 16:28:47 cc4 osmo-mgw[507]: #033[0;m<0011> mgcp_msg.c:208 Not > able to find a free endpoint > Jun 18 16:28:47 cc4 osmo-mgw[507]: #033[0;m<0011> mgcp_msg.c:322 Unable > to find Endpoint `rtpbridge/*@mgw' > Jun 18 16:28:47 cc4 osmo-mgw[507]: #033[0;m<0011> mgcp_protocol.c:329 > CRCX 5: failed to find the endpoint > > There are two separate instances of osmo-mgw, each running on a > dedicated host, with minimal configs as per the NITB instructions, but > using standard port numbers for both since there is no conflict. Just to note that I now have voice calls working using the osmo-mgw configs that Pau previously shared via the list. Thanks for your help and to all who have contributed to the stack ? it's exciting to be using the new post-NITB architecture for the first time! Regards, Andrew From laforge at gnumonks.org Thu Jun 21 11:11:32 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 21 Jun 2018 13:11:32 +0200 Subject: osmo-bsc with remote osmo-stp. In-Reply-To: <6ff89792-fb1e-5789-07e0-8b4ecfe83d3e@carrierdetect.com> References: <1c9c3705-531b-94ae-be85-13672543fd4f@carrierdetect.com> <20180616145805.GQ20729@nataraja> <6ff89792-fb1e-5789-07e0-8b4ecfe83d3e@carrierdetect.com> Message-ID: <20180621111132.GC3565@nataraja> Hi Andrew, On Tue, Jun 19, 2018 at 04:35:43PM +0100, Andrew Back wrote: > Just to note that I now have voice calls working using the osmo-mgw > configs that Pau previously shared via the list. Thanks for your help > and to all who have contributed to the stack ? it's exciting to be using > the new post-NITB architecture for the first time! Great, I'm happy to hear you could make it work. If there's anything we can improve in terms of examples, mauals, wiki, please don't hesitate to let us know. My guess is if you started with the included config file examples but could only make it work with the config files Pau shared here on the list, then we might want to revisit the example config files? Could you pin-point it to any particular setting? -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From andrew at carrierdetect.com Thu Jun 21 15:34:49 2018 From: andrew at carrierdetect.com (Andrew Back) Date: Thu, 21 Jun 2018 16:34:49 +0100 Subject: osmo-bsc with remote osmo-stp. In-Reply-To: <20180621111132.GC3565@nataraja> References: <1c9c3705-531b-94ae-be85-13672543fd4f@carrierdetect.com> <20180616145805.GQ20729@nataraja> <6ff89792-fb1e-5789-07e0-8b4ecfe83d3e@carrierdetect.com> <20180621111132.GC3565@nataraja> Message-ID: <47ba81f8-edb8-095e-e851-fa50b575444e@carrierdetect.com> Hi Harald, On 21/06/18 12:11, Harald Welte wrote: > Hi Andrew, > > On Tue, Jun 19, 2018 at 04:35:43PM +0100, Andrew Back wrote: >> Just to note that I now have voice calls working using the osmo-mgw >> configs that Pau previously shared via the list. Thanks for your help >> and to all who have contributed to the stack ? it's exciting to be using >> the new post-NITB architecture for the first time! > > Great, I'm happy to hear you could make it work. > > If there's anything we can improve in terms of examples, mauals, wiki, > please don't hesitate to let us know. A user manual for OsmoMGW would be good and sounds like it's in the works. I was thinking I could share my configs once I have GPRS working and, subject to these being reviewed, could update the wiki. Other than this I think it's likely a question of just having a better basic understanding of SS7, configuring STP, and MSC/BSC to use this. > My guess is if you started with the included config file examples but could > only make it work with the config files Pau shared here on the list, then > we might want to revisit the example config files? I started with the wiki configs, but then for a remote STP I had to add cs7 config to the MSC and BSC, as per the test configs you linked to. At this point handsets could register and send/receive SMS. Then to get voice calls working I had to add lines to the configuration of the MGW instances for the BSC and MSC, taken from Pau's config files. I had everything running across 7x hosts: 1 each for TRX+BTS (combined), BSC, BSC MGW, STP, MSC MGW, MSC, HLR. > Could you pin-point it to any particular setting? I didn't add in new config a line at a time and test, I'm afraid. E.g. for the MGW for MSC I added: rtp ip-probing rtp ip-tos 184 rtp port-range 4002 8000 sdp audio payload number 98 sdp audio payload name GSM number endpoints 31 loop 0 force-realloc 1 rtcp-omit rtp-accept-all 1 rtp-patch ssrc rtp-patch timestamp Best, Andrew From laforge at gnumonks.org Mon Jun 25 13:57:54 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 25 Jun 2018 15:57:54 +0200 Subject: osmo-bsc refactoring / inter-BSC handover In-Reply-To: <20180618055056.GA8364@my.box> References: <20180615113908.GM20729@nataraja> <20180618055056.GA8364@my.box> Message-ID: <20180625135754.GW3565@nataraja> Hi Neels, sorry for the slow response, I've been down with fever and minding the bed during most parts of last week. I've only started to review your patchset, but let me provide some answer: On Mon, Jun 18, 2018 at 07:50:56AM +0200, Neels Hofmeyr wrote: > I have a marginal test added for inter-bsc MO, but the inter-bsc MT gets me. > The problem there is that it is the first time a conn is initiated by the MSC > side. > I can get that to work by using BSSAP on that Test_CT. that's not such an elegant choice, as it means we will never be able to run multuple of those in parallel. The point of the various *_Emulation.ttcn layers is to (de)multiplex per subscriber/connection/lchan/... and to be able to handle all parts related to *one* particular subscriber/connection in a component, while at the same time having any number of other components handling other concurrent connections/subscribers. > It goes well up to the point where osmo-bsc sends MGCP CRCX and expects a response. Now I want to > use the MSC_ConnHdlr to manage MGCP, but I can't for the life of me figure out > how to be able to do both at the same time. The only clean solutions is to do everything from within a *_ConnHdlr. The logical flow of events should be: * start BSSMAP_Emulation etc. using "f_init(N, true)" * start a ConnHdlr component, from there ** send a BSSAP_Conn_Req to the BSSMAP_Emulation, which consists of the SCCP called / calling party address and the BSSAP to send in the first message. > I tried for very long to resolve > "BSC_Tests.ttcn:2755.13-2756.31: error: Message type `@BSSAP_CodecPort.BSSAP_N_CONNECT_req' is not present on the outgoing list of port type `@BSSMAP_Emulation.BSSAP_Conn_PT'" > but it feels like a brick wall... This specific error message tells you that the BSSAP_N_CONNECT_req type is not listed in the singature of the BSSAP_Conn_PT. Let's look at its definition: /* port between individual per-connection components and this dispatcher */ type port BSSAP_Conn_PT message { /* BSSAP or direct DTAP messages from/to clients */ inout PDU_BSSAP, PDU_DTAP_MO, PDU_DTAP_MT, /* misc indications / requests between SCCP and client */ BSSAP_Conn_Prim, /* Client requests us to create SCCP Connection */ BSSAP_Conn_Req, /* MGCP, only used for IPA SCCPlite (MGCP in IPA mux) */ MgcpCommand, MgcpResponse; } with { extension "internal" }; and this definition clearly doesn't list the related type in its signature. So you're sending something to the port which it doesn't support. -- - 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 Mon Jun 25 19:20:48 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 25 Jun 2018 21:20:48 +0200 Subject: osmo-bsc refactoring / inter-BSC handover In-Reply-To: <20180625135754.GW3565@nataraja> References: <20180615113908.GM20729@nataraja> <20180618055056.GA8364@my.box> <20180625135754.GW3565@nataraja> Message-ID: <20180625192048.GC4760@nataraja> After completing my initial review, some more follow-up here. I think the general strategy to move ahead here is: * address review comments. Sorry there are so many. A lot of them are surprisingly coding style related, where there are many deviations from existing coding style. * make sure that test results with old and new code are identical. ** for tests that don't pass, figure out if it's a regression or if the test expectation is/was wrong. * do some manual testing [not sure if you "only" relied on test suites or also did manual testing with actual BTS / phones? * run the branch in osmo-gsm-tester, also expect identical behavior between master and the inter-bsc-ho branch *before* we actually do the merge, we should tag a version on the last version before the merge, and do a release. This way we make it easy for people to use the older / more trusted codebase and compare against the new code in master. Thanks again for all your efforts! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)