From ron.menez at entropysolution.com Tue Sep 4 09:06:37 2018 From: ron.menez at entropysolution.com (Ron) Date: Tue, 4 Sep 2018 09:06:37 +0000 Subject: Call Detail Log - OSMO Elements Message-ID: Hi Community, Is there a documentation regarding the Call Detail Logs in any of the OSMO Elements such as Call Information (call started, duration and end/caller and callee information,etc...) and SMS Information (sent/received time/sender and receiver,etc...)? And may we know what log level configuration do we need to configure for us to see those information? Thanks in advance. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Sep 5 10:09:01 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 5 Sep 2018 12:09:01 +0200 Subject: Call Detail Log - OSMO Elements In-Reply-To: References: Message-ID: <20180905100901.GC20470@my.box> On Tue, Sep 04, 2018 at 09:06:37AM +0000, Ron wrote: > Is there a documentation regarding the Call Detail Logs in any of the OSMO Elements such as Call Information (call started, duration and end/caller and callee information,etc...) and SMS Information (sent/received time/sender and receiver,etc...)? The component that knows most about caller identities and duration is the MSC, but it doesn't (yet) conveniently summarize call details anywhere. More suited would be the use of an external call router via MNCC, I guess. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From shingy92 at gmail.com Wed Sep 5 14:15:26 2018 From: shingy92 at gmail.com (Shingirai Simba) Date: Wed, 5 Sep 2018 16:15:26 +0200 Subject: Multi-Tenancy / Multi-Operator Support Message-ID: Hie We are contemplating on a Multi-Operator / shared radio for 3 communitiy operators in Zimbabwe, Africa. Does OsmoBSC/OsmoMSC n support this using SDR front ends. Regards Shingirai Simba -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo.cavallini at gmail.com Wed Sep 5 15:04:01 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Wed, 5 Sep 2018 17:04:01 +0200 Subject: CBCH support for osmo-bts-trx Message-ID: Hello everyone, I was going to add support for CBCH to osmo-bts-trx for a project, then just by chance I looked at this ticket: https://osmocom.org/issues/1617 and I've seen that the issue was reopened 13 days ago. Any chance on getting some pre-pre-pre-alpha patch? I would gladly test and work on it in whatever state the code is now, still better than starting from scratch. Thanks for the awesome work anyway! Best regards, Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Sep 5 16:39:29 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 5 Sep 2018 18:39:29 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: References: Message-ID: <20180905163929.GT23553@nataraja> Hi Lorenzo, On Wed, Sep 05, 2018 at 05:04:01PM +0200, Lorenzo Cavallini wrote: > I was going to add support for CBCH to osmo-bts-trx for a project, then > just by chance I looked at this ticket: https://osmocom.org/issues/1617 and > I've seen that the issue was reopened 13 days ago. this is currently undergoing development. > Any chance on getting some pre-pre-pre-alpha patch? I would gladly test and > work on it in whatever state the code is now, still better than starting > from scratch. It's available in the laforge/cbch-trx branch of osmo-bts.git -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From matt9j at cs.washington.edu Wed Sep 5 17:24:16 2018 From: matt9j at cs.washington.edu (Matthew Johnson) Date: Wed, 5 Sep 2018 10:24:16 -0700 Subject: Call Detail Log - OSMO Elements In-Reply-To: References: Message-ID: Hello Ron, It's been a few months since I've worked with the osmocom CDR's, but from memory I think what you're looking for is the cdr configuration option. In osmocom, "log" refers to the logs of the actual programs (think what you would see in syslog). I've only ever used cdr's in the SGSN to track data usage for billing, but I believe you can get the same information on the circuit switched side of the world too. In the SGSN, the relevant config line is detailed in the latest SGSN manual http://ftp.osmocom.org/docs/latest/osmosgsn-usermanual.pdf , although suspiciously the cdr config options are not listed under the SGSN vty reference anymore. Regards, -Matt J. On Tue, Sep 4, 2018 at 2:06 AM Ron wrote: > Hi Community, > > Is there a documentation regarding the Call Detail Logs in any of the OSMO > Elements such as Call Information (call started, duration and end/caller > and callee information,etc...) and SMS Information (sent/received > time/sender and receiver,etc...)? > > And may we know what log level configuration do we need to configure for > us to see those information? > > Thanks in advance. > > Best Regard, > > Ron Menez > ron.menez at entropysolution.com > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.menez at entropysolution.com Thu Sep 6 02:23:15 2018 From: ron.menez at entropysolution.com (Ron) Date: Thu, 6 Sep 2018 02:23:15 +0000 Subject: Call Detail Log - OSMO Elements In-Reply-To: References: Message-ID: <7CAA0213-8AA1-42AF-B998-B856AC12F77F@entropysolution.com> Thanks for the input Matthew. We?ll explore the CDR from other OSMO elements if it is still available. Best Regard, Ron Menez ron.menez at entropysolution.com On Sep 6, 2018, at 1:24 AM, Matthew Johnson > wrote: Hello Ron, It's been a few months since I've worked with the osmocom CDR's, but from memory I think what you're looking for is the cdr configuration option. In osmocom, "log" refers to the logs of the actual programs (think what you would see in syslog). I've only ever used cdr's in the SGSN to track data usage for billing, but I believe you can get the same information on the circuit switched side of the world too. In the SGSN, the relevant config line is detailed in the latest SGSN manual http://ftp.osmocom.org/docs/latest/osmosgsn-usermanual.pdf , although suspiciously the cdr config options are not listed under the SGSN vty reference anymore. Regards, -Matt J. On Tue, Sep 4, 2018 at 2:06 AM Ron > wrote: Hi Community, Is there a documentation regarding the Call Detail Logs in any of the OSMO Elements such as Call Information (call started, duration and end/caller and callee information,etc...) and SMS Information (sent/received time/sender and receiver,etc...)? And may we know what log level configuration do we need to configure for us to see those information? Thanks in advance. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.menez at entropysolution.com Thu Sep 6 02:23:48 2018 From: ron.menez at entropysolution.com (Ron) Date: Thu, 6 Sep 2018 02:23:48 +0000 Subject: Call Detail Log - OSMO Elements In-Reply-To: <20180905100901.GC20470@my.box> References: <20180905100901.GC20470@my.box> Message-ID: Thanks for info Neels. Best Regard, Ron Menez ron.menez at entropysolution.com On Sep 5, 2018, at 6:09 PM, Neels Hofmeyr > wrote: On Tue, Sep 04, 2018 at 09:06:37AM +0000, Ron wrote: Is there a documentation regarding the Call Detail Logs in any of the OSMO Elements such as Call Information (call started, duration and end/caller and callee information,etc...) and SMS Information (sent/received time/sender and receiver,etc...)? The component that knows most about caller identities and duration is the MSC, but it doesn't (yet) conveniently summarize call details anywhere. More suited would be the use of an external call router via MNCC, I guess. ~N -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Sep 6 05:48:47 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Sep 2018 07:48:47 +0200 Subject: Call Detail Log - OSMO Elements In-Reply-To: References: Message-ID: <20180906054847.GX23553@nataraja> Hi Matthew, thanks for sharing your experience! On Wed, Sep 05, 2018 at 10:24:16AM -0700, Matthew Johnson wrote: > It's been a few months since I've worked with the osmocom CDR's, but from > memory I think what you're looking for is the cdr configuration option. > In osmocom, "log" refers to the logs of the actual programs (think > what you would see in syslog). this is correct. > I've only ever used cdr's in the SGSN to track data > usage for billing, but I believe you can get the same information on the > circuit switched side of the world too. Unfortunately we don't have any CDR generation in OsmoMSC. This reasons are twofold: a) this is an "enterprise" feature, i.e. nothing that you'd need for research/lab type use, and hence nothing that anyone would likely volunteer to do in their spare time. The SGSN CDR was developed under funding from a specific enterprise user who had a related requirement. b) most networks don't end at the MSC but they actually have some kind of other (soft)switch infrastructure behind the MSC, and hence the voice call related logs can be obtained there. This doesn't apply to the same degree for SMS, though. > although suspiciously the cdr config options are not listed under the > SGSN vty reference anymore. This is definitely not how it's supposed to be. Would you mind opening a new issue about this in the OsmoSGSN issue tracker at https://osmocom.org/projects/osmosgsn/issues ? 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 Thu Sep 6 05:54:18 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Sep 2018 07:54:18 +0200 Subject: Multi-Tenancy / Multi-Operator Support In-Reply-To: References: Message-ID: <20180906055418.GY23553@nataraja> Hi Shingirai Simba, On Wed, Sep 05, 2018 at 04:15:26PM +0200, Shingirai Simba wrote: > We are contemplating on a Multi-Operator / shared radio for 3 communitiy > operators in Zimbabwe, Africa. The question is: How exactly does the above high-level goal translate into concrete technical architecture? Would the goal be to run your complete own PLMN with the other operators just roaming into that network (i.e. using TCAP/MAP roaming interface), or are you referring to a 3GPP MOCN / GWCN as per TS 23.251? Or something else entirely? > Does OsmoBSC/OsmoMSC n support this using SDR front ends. In either of the two cases, the current implementation doesn't provide everything you'd need for such a setup. But let's continue this discussion once it's more clear what kind of technical architecture you're looking for. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lorenzo.cavallini at gmail.com Thu Sep 6 08:43:56 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Thu, 6 Sep 2018 10:43:56 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: <20180905163929.GT23553@nataraja> References: <20180905163929.GT23553@nataraja> Message-ID: hey, thanks for the quick reply! I think the branch is not upstream yet, on osmo-bts.git I can see only these ones: laforge/avoid_ramp_spike laforge/bands-eeprom laforge/ciph-fix fix laforge/fsm-name laforge/gprs-suspend laforge/late_l1ifreset laforge/meas256 laforge/oml-router laforge/omldummy laforge/power_control laforge/sob-bts-pa-ctrl laforge/virt-new am I missing something? thanks! On Wed, 5 Sep 2018, 18:40 Harald Welte, wrote: > Hi Lorenzo, > > On Wed, Sep 05, 2018 at 05:04:01PM +0200, Lorenzo Cavallini wrote: > > I was going to add support for CBCH to osmo-bts-trx for a project, then > > just by chance I looked at this ticket: https://osmocom.org/issues/1617 > and > > I've seen that the issue was reopened 13 days ago. > > this is currently undergoing development. > > > Any chance on getting some pre-pre-pre-alpha patch? I would gladly test > and > > work on it in whatever state the code is now, still better than starting > > from scratch. > > It's available in the laforge/cbch-trx branch of osmo-bts.git > > -- > - 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 Thu Sep 6 09:06:26 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Sep 2018 11:06:26 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: References: <20180905163929.GT23553@nataraja> Message-ID: <20180906090626.GD23553@nataraja> Hi Lorenzo, On Thu, Sep 06, 2018 at 10:43:56AM +0200, Lorenzo Cavallini wrote: > I think the branch is not upstream yet, on osmo-bts.git I can see only > these ones: this is very odd. the branch had been pushed to gerrit, and I can verify exists on gerrit when cloning using git clone https://gerrit.osmocom.org/osmo-bts Still, gerrit doesn't seem to be replicating this to git.osmocom.org. Odd. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lorenzo.cavallini at gmail.com Thu Sep 6 09:12:29 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Thu, 6 Sep 2018 11:12:29 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: <20180906090626.GD23553@nataraja> References: <20180905163929.GT23553@nataraja> <20180906090626.GD23553@nataraja> Message-ID: yes I cloned it now from gerrit and the branch is definitely there.. that's fine for me anyway, thanks! On Thu, Sep 6, 2018 at 11:10 AM Harald Welte wrote: > Hi Lorenzo, > > On Thu, Sep 06, 2018 at 10:43:56AM +0200, Lorenzo Cavallini wrote: > > I think the branch is not upstream yet, on osmo-bts.git I can see only > > these ones: > > this is very odd. the branch had been pushed to gerrit, and I can verify > exists > on gerrit when cloning using > git clone https://gerrit.osmocom.org/osmo-bts > > Still, gerrit doesn't seem to be replicating this to git.osmocom.org. Odd. > > -- > - 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 Thu Sep 6 09:17:42 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Sep 2018 11:17:42 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: References: <20180905163929.GT23553@nataraja> <20180906090626.GD23553@nataraja> Message-ID: <20180906091742.GE23553@nataraja> On Thu, Sep 06, 2018 at 11:12:29AM +0200, Lorenzo Cavallini wrote: > yes I cloned it now from gerrit and the branch is definitely there.. > that's fine for me anyway, thanks! After restarting gerrit, it appears to have replicated to git.osmocom.org now, too: http://git.osmocom.org/osmo-bts/log/?h=laforge/cbch-trx -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lorenzo.cavallini at gmail.com Thu Sep 6 09:23:45 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Thu, 6 Sep 2018 11:23:45 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: <20180906091742.GE23553@nataraja> References: <20180905163929.GT23553@nataraja> <20180906090626.GD23553@nataraja> <20180906091742.GE23553@nataraja> Message-ID: so after all, restart is always the solution to every problem... :) thanks for looking into this anyway! On Thu, Sep 6, 2018 at 11:20 AM Harald Welte wrote: > On Thu, Sep 06, 2018 at 11:12:29AM +0200, Lorenzo Cavallini wrote: > > yes I cloned it now from gerrit and the branch is definitely there.. > > that's fine for me anyway, thanks! > > After restarting gerrit, it appears to have replicated to git.osmocom.org > now, too: > http://git.osmocom.org/osmo-bts/log/?h=laforge/cbch-trx > -- > - 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 shingy92 at gmail.com Thu Sep 6 10:31:44 2018 From: shingy92 at gmail.com (Shingirai Simba) Date: Thu, 6 Sep 2018 12:31:44 +0200 Subject: Fwd: Multi-Tenancy / Multi-Operator Support In-Reply-To: <20180906102811.GG23553@nataraja> References: <20180906055418.GY23553@nataraja> <20180906102811.GG23553@nataraja> Message-ID: ---------- Forwarded message --------- From: Harald Welte Date: Thu, Sep 6, 2018 at 12:30 PM Subject: Re: Multi-Tenancy / Multi-Operator Support To: Shingirai Simba Hi! I would appreciate if you could send your response to the mailing list, so I can further follow-up to it. This way, our conversation is to the benefit of the wider Osmocom community. Regards, Harald On Thu, Sep 06, 2018 at 11:57:48AM +0200, Shingirai Simba wrote: > Hie Harald > > Indeed i am referring to 3GPP MOCN / GWCN as per TS 23.251, but any viable > work around is most welcomed even if it does not met specifications. I am > contemplating the idea of just running this kind of configuration as 3 > different LXD instances, but will i able to share the same physical SDR > radio instance with the 3 separate core networks.' > > Regards > > Shingirai A. Simba > > On Thu, Sep 6, 2018 at 7:54 AM Harald Welte wrote: > > > Hi Shingirai Simba, > > > > On Wed, Sep 05, 2018 at 04:15:26PM +0200, Shingirai Simba wrote: > > > We are contemplating on a Multi-Operator / shared radio for 3 communitiy > > > operators in Zimbabwe, Africa. > > > > The question is: How exactly does the above high-level goal translate into > > concrete technical architecture? Would the goal be to run your complete > > own > > PLMN with the other operators just roaming into that network (i.e. using > > TCAP/MAP > > roaming interface), or are you referring to a 3GPP MOCN / GWCN as per TS > > 23.251? > > > > Or something else entirely? > > > > > Does OsmoBSC/OsmoMSC n support this using SDR front ends. > > > > In either of the two cases, the current implementation doesn't provide > > everything > > you'd need for such a setup. But let's continue this discussion once it's > > more > > clear what kind of technical architecture you're looking for. > > > > -- > > - Harald Welte > > http://laforge.gnumonks.org/ > > > > ============================================================================ > > "Privacy in residential applications is a desirable marketing option." > > (ETSI EN 300 175-7 Ch. > > A6) > > -- - 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 Thu Sep 6 11:32:33 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 6 Sep 2018 13:32:33 +0200 Subject: Fwd: Multi-Tenancy / Multi-Operator Support In-Reply-To: References: <20180906055418.GY23553@nataraja> <20180906102811.GG23553@nataraja> Message-ID: <20180906113233.GL23553@nataraja> Hi! > On Thu, Sep 06, 2018 at 11:57:48AM +0200, Shingirai Simba wrote: > > Indeed i am referring to 3GPP MOCN / GWCN as per TS 23.251, but any viable > > work around is most welcomed even if it does not met specifications. I am > > contemplating the idea of just running this kind of configuration as 3 > > different LXD instances, but will i able to share the same physical SDR > > radio instance with the 3 separate core networks.' 3GPP MOCN for GERAN is a rather modern feature in terms of GSM/GERAN. So far nobody has yet contributed related code to Osmocom. We would of course more than welcome anyone contributing related patches/code, or funding related development efforts. I believe it should be possible to do entirely inside OsmoBSC without any changes to other parts of the stack. 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 keith at rhizomatica.org Thu Sep 6 13:32:00 2018 From: keith at rhizomatica.org (Keith Whyte) Date: Thu, 6 Sep 2018 15:32:00 +0200 Subject: OsMux + MGW + SIP Message-ID: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> Hi community! I'd like here to set out a few issues that we have identified for going forward with the rhizomatica autonomous networks and the osmocom split stack. Some of this has been very briefly discussed between myself and Pablo, and I bring it to the mailing list so hopefully there will be feedback,? ideas and suggestions :) I am cherry picking from previous emails here, (mostly mine) please excuse any repetition. I hope others will post their previous comments on this thread, either verbatim of edited to be relevant to the current discussion. 1) This is a question that relates to voip traffic in and out of the autonomous communities over satellite. Currently this is what we HAVE to have in the local village to support autonomous operation): * BSC * MSC * HLR * Freeswitch (freeswitch is our call control, call routing, billing etc) We can't have any essential backhaul running over the satellite , like A for example as we would loose all functionality when the sat link is down, and we'd burn expensive bandwidth! One option to use osmux from autonomous community (village) is to teach osmo-mgw to speak osmux, then we have a co-located bsc/msc/mgw in the village, and the media transport is osmux to another mgw in our datacentre that is demuxing and converting to RTP suitable to be forwarded to our upstream VoIP provider. The question here is what is signalling the MGW in the data centre? Maybe another freeswitch could signal the osmoMGW via some kind of SIP<->MGCP translator. Or we teach the MGW to speak SIP? Another option that I want to put on the table and see what people say is to look at implementing osmux as a codec in freeswitch. I don't know what that would mean in terms of effort. I don't know if the osmux code can be abstracted, if that is the right term, into it's own external includible library that could then be used to build a freeswitch codec. I looked some implementations of AMR codec for freeswitch, and really it looks like a boiler plate codec with registration, setup and then it calls the encoding and decoding functions in the opencore amr library. Maybe, we can do the same with osmux? Then we could have two freeswitchs signalling and transcoding to/from osmux? -? then we are not really working on osmo solution and others in the osmo community might prefer to see osmux fully implemented in MGW before anything else? Here are a number of related tickets from Harald on osmux integration: http://osmocom.org/issues/1683 and http://osmocom.org/issues/2832 as well as https://osmocom.org/issues/2909 I think though, that in 1683, we are stalled by https://osmocom.org/issues/2391 for the split setup. 2) Another question relates to this proposal of a media gateway less mode: ?https://osmocom.org/issues/3142 I think this suits us, because really our call signalling is all happening in freeswitch and we would prefer I think not to have the media gateway at all most of the time. and in fact for local Mobile to Mobile calls on the same BTS, we would in fact prefer the RTP be local on the sysmobts, or indeed BTS<->BTS! Freeswitch has a "bypass media" parameter, in fact you can even activate this at call processing time before bridging the call, depending on whether it makes sense in terms of direct connection being possible and the lack of transcoding. There's also a "bypass media after bridge" parameter that is automatically using SIP (re)-INVITES to switch the RTP stream from passing through freeswitch or going directly from end point to end point.? Using "bypass media" in our profile works nicely; of course, as all it is doing is using the IP address(es) of the osmo-bts in the SDP, so the rtp stream loops on lo in the sysmobts. It would help with something that I mentioned at Osmodevcon, Harald, which was that in some cases we might like to avoid having our RTP go over the (sometimes variable quality) Wifi links between the BTS and the BSC. A problem is that if you use "bypass media" you have no early media and no audible ringing signal, you don't get any audio stream until the B leg picks up. This is what "bypass media after bridge" is for. Unfortunately, osmo-nitb (at least, and I don't believe anything has been done in osmo-bsc related) plus LCR or osmo-sip-connector combinations do not react correctly to the SIP reINVITES, you end up with multiple calls. So all that needs to be fixed / implemented. I noticed mention of implementation of MNCC_RTP_MODIFY on fairwaves branches of OpenBSC and LCR. I've compiled and tested this, but as far as I can see it is still not working, as issuing a SIP reINVITE from freeswitch is still setting up new calls, not just changing the RTP streams. Maybe I also need a fairwaves osmo-bts. So this is something I think I would like to see: * Full support for SIP reinvite in osmo-sip-connector which would then send a MNCC_RTP_MODIFY which ends up sending (I think it's called a IPAC_CRCX?) to osmo-bts which will then switch the stream endpoints. This I believe is also necessary for handover to function with an MNCC socket setup and we don't currently have it, not even in the osmo-nitb. * Implement a no media gateway mode in osmo-msc and have the MSC control the media stream using SIP via MNCC/osmo-sip-connector instead of controlling the MGW using MGCP. K/ ? From matt9j at cs.washington.edu Thu Sep 6 21:29:50 2018 From: matt9j at cs.washington.edu (Matthew Johnson) Date: Thu, 6 Sep 2018 14:29:50 -0700 Subject: Call Detail Log - OSMO Elements In-Reply-To: <20180906054847.GX23553@nataraja> References: <20180906054847.GX23553@nataraja> Message-ID: Hello Harald, I went to go file the bug, and realized that I had made an error! I was looking quickly through several manuals at the same time, and was searching the GGSN VTY reference by accident. Ron, The details on the CDR configuration options for the SGSN are available as expected in the SGSN's VTY reference manual http://ftp.osmocom.org/docs/latest/osmosgsn-vty-reference.pdf Cheers, -Matt J. On Wed, Sep 5, 2018 at 10:50 PM Harald Welte wrote: > Hi Matthew, > > thanks for sharing your experience! > > On Wed, Sep 05, 2018 at 10:24:16AM -0700, Matthew Johnson wrote: > > It's been a few months since I've worked with the osmocom CDR's, but from > > memory I think what you're looking for is the cdr configuration option. > > > In osmocom, "log" refers to the logs of the actual programs (think > > what you would see in syslog). > > this is correct. > > > I've only ever used cdr's in the SGSN to track data > > usage for billing, but I believe you can get the same information on the > > circuit switched side of the world too. > > Unfortunately we don't have any CDR generation in OsmoMSC. This reasons > are twofold: > > a) this is an "enterprise" feature, i.e. nothing that you'd need for > research/lab type use, and hence nothing that anyone would likely > volunteer to do in their spare time. The SGSN CDR was developed > under funding from a specific enterprise user who had a related > requirement. > > b) most networks don't end at the MSC but they actually have some kind > of other (soft)switch infrastructure behind the MSC, and hence the > voice call related logs can be obtained there. This doesn't apply > to the same degree for SMS, though. > > > although suspiciously the cdr config options are not listed under the > > SGSN vty reference anymore. > > This is definitely not how it's supposed to be. Would you mind opening a > new issue about this in the OsmoSGSN issue tracker at > https://osmocom.org/projects/osmosgsn/issues ? Thanks! > > -- > - 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 Sep 7 00:27:27 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 7 Sep 2018 02:27:27 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> Message-ID: <20180907002727.GA10626@my.box> On Thu, Sep 06, 2018 at 03:32:00PM +0200, Keith Whyte wrote: > was that in some cases we might like to avoid having our RTP go > over the (sometimes variable quality) Wifi links between the BTS and the > BSC. Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. I think the idea of LCLS is to take out the MSC's MGW, and instructing the BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step from there to switching BTS directly back to BTS. osmo-bsc has full control over that. > A problem is that if you use "bypass media" you have no early media and > no audible ringing signal IIUC LCLS happens after bridge. IIUC we instruct the MS to generate a ringing signal anyway? > * Full support for SIP reinvite in osmo-sip-connector which would then > send a MNCC_RTP_MODIFY which ends up sending (I think it's called a > IPAC_CRCX?) to osmo-bts which will then switch the stream endpoints. IPAC_CRCX is a CReate ConneXion, I think you mean IPAC_MDCX, a MoDify. In the MDCX you can tell the BTS where to send its RTP stream. Feels wrong to me to let osmo-sip-connector mess around with the BTS' IPAC_MDCX, I think that's firmly osmo-bsc's realm. And sounds like LCLS is the thing. As so often LaF0rge will know a lot more about it... > * Implement a no media gateway mode in osmo-msc and have the MSC control > the media stream using SIP via MNCC/osmo-sip-connector instead of > controlling > the MGW using MGCP. Currently we need an MGW both from MSC and from BSC. Again it seems to me LCLS is the answer to take out the MSC's MGW, and osmo-bsc's LCLS decision might then end up bypassing the BSC's MGW, if it doesn't do that yet? I think osmo-msc doesn't support LCLS though, only osmo-bsc? And also I think the MSC doesn't need to do much for LCLS anyway. But before I ramble on about things I'm not sure about, I'm shutting up now. ~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 Fri Sep 7 08:15:18 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 7 Sep 2018 10:15:18 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> Message-ID: <20180907081518.GW23553@nataraja> Hi Keith, the "big" problem is not adding Osmux media handling here or there (whether fixing it in the new osmo-mgw, or adding it to freeswitch, or to whatever else). That's I think the comparatively the easy part. The bigger problem is how to *signal/* osmux between the various elements. The protocols that are used for signaling the media plane typically assume that each media flow * uses RTP/UDP * operates on its own port number for this flow whereas in osmux you now have multiple flows (unidirectional calls) sharing one UDP 5-tuple (src-ip/src-port/dst-ip/dst-port/l4). Instead, you have some internal ID to distinguish which of the media flows inside the osmux flow you are referring-to. So the non-trivial problem to solve is how to make the media-related signaling understand those differences, or what kind of mechanism to invent to map it to the existing presumptions that said implementations have on how media flows work. Implementing some kind of proxy (e.g. osmo-bsc_nat for old SCCPlite based A) is one option, as long as that proxy will handle translation of both the actual media (RTP/Osmux) as well as the signaling that is associated for those media flows (e.g. MGCP in old SCCPlite, or 3GPP AoIP in proper A interface). At that time, said proxy knows all the related state and can perform whatever mapping/translation. However, proxies work only good in 1:1 relationships. This means, you will be in trouble if you're looking for redundant systems (proxies would have to replicate state), or if you want to have a more "peer to peer" architecture between your villages/deployments, where any village would establish calls directly to any other village, and hence we're not just talking about a strict client-server model anymore. > 1) This is a question that relates to voip traffic in and out of the > autonomous communities over satellite. > > Currently this is what we HAVE to have in the local village to support > autonomous operation): > * BSC > * MSC > * HLR > * Freeswitch (freeswitch is our call control, call routing, billing etc) > > We can't have any essential backhaul running over the satellite , like A > for example as we would loose all functionality when the sat link is > down, and we'd burn expensive bandwidth! I'm not sure about the "burning of expensive bandwidth" in an "A backhaul" scenario. Sure, you'd have some location update traffic, but the actual media plane of local calls could stay local by means of LCLS, as Neels has pointed out. > Maybe another freeswitch could signal the osmoMGW via some kind of > SIP<->MGCP > translator. Or we teach the MGW to speak SIP? a media gateway is (as the name implies) not a signaling gateway. As MGCP is an interoperable protocol to control media gateways, you could use any switch that speaks MGCP to control it. yate offers some level of MGCP support, for example - as do many of the large/proprietary soft switches. This of course doesn't solve the question of how to represent OSMUX on MGCP/SDP side in the first place. > Another option that I want to put on the table and see what people say > is to look at implementing osmux as a codec in freeswitch. I don't know anything about freeswitch internals. I would expect that the proper way to go about this is to actually have Freeswitch talk MGCP and use it to control OsmoMGW. That's how the concept of media gateways was intended to work, and it fits the architectural model. > I don't know what that would mean in terms of effort. > I don't know if the osmux code can be abstracted, if that is the right > term, into it's > own external includible library that could then be used to build a > freeswitch codec. I don't know either, but I would be surprised if it wasn't possible. The biggest question I'd look into is the concurrency model. Osmocom code uses single-thread/single-process event-driven select() abstraction, which doesn't work well with heavily-multithreaded environments/applications. > I looked some implementations of AMR codec for > freeswitch, and really it looks like a boiler plate codec with > registration, setup and then it calls the encoding and decoding > functions in the opencore amr library. The question is: How can you represent a "trunk" of multiple calls between two systems sharing one UDP IP/port tuple, and how do you express that in SDP. Once that problem has been solved, you can signal OSMUX either via SIP or via MGCP. And once that signaling on the wire is clear, you have to think how you can fit that into the data model of whatever program you want to teach it > Here are a number of related tickets from Harald on osmux integration: > http://osmocom.org/issues/1683 and http://osmocom.org/issues/2832 > as well as https://osmocom.org/issues/2909 > I think though, that in 1683, we are stalled by > https://osmocom.org/issues/2391 for the split setup. I don't agree, sorry. In fact, I fail to see the connection. #2391 is only for annotating logs with more context, not about any functional changes. > 2) Another question relates to this proposal of a media gateway less mode: > > ?https://osmocom.org/issues/3142 > > I think this suits us, because really our call signalling is all > happening in freeswitch and we would prefer I think not to have the > media gateway at all most of the time. and in fact for local Mobile to > Mobile calls on the same BTS, > we would in fact prefer the RTP be local on the sysmobts, or indeed > BTS<->BTS! > Freeswitch has a "bypass media" parameter, in fact you can even activate > this at > call processing time before bridging the call, depending on whether it > makes sense in terms of direct connection being possible and the lack of > transcoding. > There's also a "bypass media after bridge" parameter that is > automatically using SIP (re)-INVITES to switch the RTP stream from > passing through freeswitch or going directly from end point to end point.? > > Using "bypass media" in our profile works nicely; of course, as all it > is doing is using the IP address(es) of the > osmo-bts in the SDP, so the rtp stream loops on lo in the sysmobts. It > would help with something that I mentioned at Osmodevcon, Harald, which > was that in some cases we might like to avoid having our RTP go > over the (sometimes variable quality) Wifi links between the BTS and the > BSC. As Neels already hinted, the "proper" method of doing this is actually to extend the current LCLS implementation to go that way. So far, it only avoids media back-haul from BSC to MSC over the A interface. But with some extra logic, we could make RTP go directly between BTSs. Doing this with LCLS means that it's not a binary "bypass", but that you can actually change it at any point during the call. So you could start with media going all the way back to the core (for ringtone play-out, etc.) and then go to local switching during the call, only to later on going back through the core to play some "your balance is about to exceed" playback from a media playout server in the core, etc. So it's not an "either-or", but a very flexible system. Also, with LCLS enabled, the system will automatically figure out if local switching is possible, i.e. if both legs are going through the same BSC or not. > So this is something I think I would like to see: > > * Full support for SIP reinvite in osmo-sip-connector which would then > send a MNCC_RTP_MODIFY which ends up sending (I think it's called a > IPAC_CRCX?) to osmo-bts which will then switch the stream endpoints. > This I believe is also necessary for handover to function with an MNCC > socket setup and we don't currently have it, not even in the osmo-nitb. I don't know off my head how complex that would be. My general preference is to modify MNCC in a way to either a) include SDP for media plane parameters in MNCC. This overcomes various restrictions in MNCC today, such as being only able to configure one codec, rather than a list of codecs permitted, or b) simply only handle the RAN/A side MGCP connection from OsmoMSC, and leave the CN side MGCP connection to the external MNCC entity. This way MNCC doesn't have to be "encumbered" with SDP etc. The problem with the external (SIP) world fiddling with too many low-level details of RTP media plans is that they don't have all of the information that is owned by the GSM side of things. What kind of codecs are supported and/or permitted by BTS/BSC/MSC/etc? What exactly was negotiated between the various elements? What if after a hand-over between different BTSs, the channel type and/or codec/rate are changing? A proper MGW (ours is lacking re-introduction of transcoding) exists to resolve all those bits by separating the GSM-network internals from the external side. > * Implement a no media gateway mode in osmo-msc and have the MSC control > the media stream using SIP via MNCC/osmo-sip-connector instead of > controlling the MGW using MGCP. Possible, but I don't think this is advisable. It's violating layering / network architecture all over the place. It assumes that your entiren network from CN to the BTS exist in a transparently routed network without any firewalls or NATs. And it would introduce special-purpose code which is not relevant to "normal" GSM network operation. That code needs to be maintained, and we'd need an entire different set of tests for all of this "non-standard" code. I would much rather want to see a system which is as closely aligned with the "normal" GSM network use case, which would mean going down the LCLS route for keeping media flows local. Currently within BSC-MGW, but with some easy patches you can get direct BTS-to-BTS. The hard problem to solve, as indicated, is how to express osmux in SDP, and then how to use SIP+OSMUX on the connections between OsmoMSCs of different vilalges and/or your central "public network gateway". 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 Fri Sep 7 08:27:15 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 7 Sep 2018 10:27:15 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <20180907002727.GA10626@my.box> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907002727.GA10626@my.box> Message-ID: <20180907082715.GX23553@nataraja> Hi Neels, On Fri, Sep 07, 2018 at 02:27:27AM +0200, Neels Hofmeyr wrote: > > Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. > I think the idea of LCLS is to take out the MSC's MGW, and instructing the > BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step > from there to switching BTS directly back to BTS. osmo-bsc has full control > over that. LCLS actually doesn't specify how far you go inside the RAN. We chose to simply keep the stream local to the BSC's MGW as this was simple and matched the requirements at the time. As stated before, it's just some additional logic inside osmo-bsc to take the BSC-MGW out of the local loop entirely. > IIUC LCLS happens after bridge. ack. > IIUC we instruct the MS to generate a ringing signal anyway? Yes, but it's known that not all phones really like to do that, in violation of the GSM specs. > Feels wrong to me to let osmo-sip-connector mess around with the BTS' > IPAC_MDCX, I think that's firmly osmo-bsc's realm. And sounds like LCLS is the > thing. Agreed. > Currently we need an MGW both from MSC and from BSC. Again it seems to me LCLS > is the answer to take out the MSC's MGW, and osmo-bsc's LCLS decision might > then end up bypassing the BSC's MGW, if it doesn't do that yet? It doesn't do that last step, but it's just some additional logic inside the BSC to do that. > I think osmo-msc doesn't support LCLS though, only osmo-bsc? And also I think > the MSC doesn't need to do much for LCLS anyway. It's correct that osmo-bsc implements LCLS, but osmo-msc doesn't enable LCLS yet. See https://osmocom.org/issues/2487 But indeed, all that's needed in osmo-msc is: * generate a global call reference for each call, include it in the BSSMAP signaling * permit the BSC to use LCLS (expressed in BSSMAP signaling) >From that point onwards, the work entirely focuses around the logic if and when you would like to permit LCLS, or break LCLS again, etc. - and that depends on your use cases. The basic use case "switch locally whenever possible" is very easy to achieve. Also, a simple use case "switch locally only after the CC CONNECT" is equally easy to achieve, and that way you get your ringtone from the core network. If you want to switch it on and of conditionally at whatever other points during a call, more logic is needed. But I think this is not Rhizomatica's use case, is it? There are 3GPP specs how LCLS paramters are signaled via SIP. This is what is used in "real" LCLS-using GSM networks between the MSCs. The specs should be referenced from https://osmocom.org/projects/cellular-infrastructure/wiki/Local_Call_Local_Switch But I don't think we need to go there. The "basic use case" should be sufficient. The hard problem, as stated in my other mail, is how to signal OSMUX, and how to handle this in the existing notion/data model/... of SIP implementations on how the media plane works. -- - 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 Sep 7 09:41:31 2018 From: keith at rhizomatica.org (Keith) Date: Fri, 7 Sep 2018 11:41:31 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <20180907081518.GW23553@nataraja> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907081518.GW23553@nataraja> Message-ID: On 07.09.2018 10:15, Harald Welte wrote: > Hi Keith, > > > The bigger problem is how to *signal/* osmux between the various elements. > > > whereas in osmux you now have multiple flows (unidirectional calls) > sharing one UDP 5-tuple (src-ip/src-port/dst-ip/dst-port/l4). Instead, > you have some internal ID to distinguish which of the media flows inside > the osmux flow you are referring-to. Yes, I had some conversation with Pablo about this and he explained that to me, and I then assumed that there would be some way to extend the SDP with a field that specifies the internal stream ID to use. (as you say below) This might be relevant: https://tools.ietf.org/html/rfc5939 ? > > Implementing some kind of proxy (e.g. osmo-bsc_nat for old SCCPlite > based A) is one option, as long as that proxy will handle translation of > both the actual media (RTP/Osmux) as well as the signaling that is > associated for those media flows (e.g. MGCP in old SCCPlite, or 3GPP > AoIP in proper A interface). At that time, said proxy knows all the > related state and can perform whatever mapping/translation. > > However, proxies work only good in 1:1 relationships. This means, you > will be in trouble if you're looking for redundant systems (proxies > would have to replicate state), I don't really understand all that, to be honest, but not to worry, it is because i'm unfamiliar with these operational concepts. I haven't studied A or SCCP at all. (yet) :-/ > or if you want to have a more "peer to > peer" architecture between your villages/deployments, where any village > would establish calls directly to any other village, and hence we're > not just talking about a strict client-server model anymore. I think it's probably unlikely that we would gain much from osmux for inter-village traffic anyway, and the volume of concurrent calls I observe is quite low. however, this can change, we could do something like carry the media stream for an inter-village call over osmux/vsat to a central switch and redistribute back to the other village either over terrestrial link if it has it, or into the other osmux stream via vSat. > >> 1) This is a question that relates to voip traffic in and out of the >> autonomous communities over satellite. >> >> Currently this is what we HAVE to have in the local village to support >> autonomous operation): >> * BSC >> * MSC >> * HLR >> * Freeswitch (freeswitch is our call control, call routing, billing etc) >> >> We can't have any essential backhaul running over the satellite , like A >> for example as we would loose all functionality when the sat link is >> down, and we'd burn expensive bandwidth! > I'm not sure about the "burning of expensive bandwidth" in an "A > backhaul" scenario. OK. Let's not dwell on it. As I said, I need to study 'A'. I seem to be assuming there is more traffic on it than in reality there is. >> Maybe another freeswitch could signal the osmoMGW via some kind of >> SIP<->MGCP > translator. Or we teach the MGW to speak SIP? > a media gateway is (as the name implies) not a signaling gateway. Understood, I wasn't suggesting that is would signal anything, I said freeswitch would signal the MGW, over SIP, but again, as you say below better to have freeswitch speak MGCP. > As > MGCP is an interoperable protocol to control media gateways, you could > use any switch that speaks MGCP to control it. yate offers some level > of MGCP support, for example - as do many of the large/proprietary soft > switches. This of course doesn't solve the question of how to represent > OSMUX on MGCP/SDP side in the first place. > >> Another option that I want to put on the table and see what people say >> is to look at implementing osmux as a codec in freeswitch. > I don't know anything about freeswitch internals. I would expect that > the proper way to go about this is to actually have Freeswitch talk MGCP > and use it to control OsmoMGW. That's how the concept of media gateways > was intended to work, and it fits the architectural model. Hmm, interestingly, There's seems to be a bounty on offer for implementing freeswitch support for MGCP Given that rhizomatica might also need this for the ultimate vSat/osmux solution, in might make it even more attractive for somebody to implement. https://freeswitch.org/jira/browse/FS-2726 Look like one would have to get their hands on an "Adtran TA600 series IAD" https://portal.adtran.com/web/page/portal/Adtran/group/30 > >> I don't know what that would mean in terms of effort. >> I don't know if the osmux code can be abstracted, if that is the right >> term, into it's >> own external includible library that could then be used to build a >> freeswitch codec. > I don't know either, but I would be surprised if it wasn't possible. > The biggest question I'd look into is the concurrency model. Osmocom > code uses single-thread/single-process event-driven select() > abstraction, which doesn't work well with heavily-multithreaded > environments/applications. Right, I can't really evaluate that, but I suspected something like this would be an issue, and I wondered about how deep one might have to go into freeswitch to have it play well with the one 5-tuple per flow as opposed to the internal stream IDs per flow inside the one 5-tuple. Probably best not to go there. >> I think though, that in 1683, we are stalled by >> https://osmocom.org/issues/2391 for the split setup. > I don't agree, sorry. In fact, I fail to see the connection. #2391 is > only for annotating logs with more context, not about any functional > changes. Um.. So in relation to #1683 where we are talking about bearer cap and knowledge of the lchans, I understand this is currently broken. see: http://osmocom.org/issues/1683#note-11 - "complete MNCC breakage in OsmoMSC" ?? But then.. as you are pointing out below, the /right/ way to do it is to isolate all this knowledge from SIP altogether. > I don't know off my head how complex that would be. My general > preference is to modify MNCC in a way to either > > a) include SDP for media plane parameters in MNCC. This overcomes > various restrictions in MNCC today, such as being only able to > configure one codec, rather than a list of codecs permitted, or > > b) simply only handle the RAN/A side MGCP connection from OsmoMSC, and > leave the CN side MGCP connection to the external MNCC entity. This > way MNCC doesn't have to be "encumbered" with SDP etc. > > The problem with the external (SIP) world fiddling with too many > low-level details of RTP media plans is that they don't have all of the > information that is owned by the GSM side of things. What kind of > codecs are supported and/or permitted by BTS/BSC/MSC/etc? What exactly > was negotiated between the various elements? What if after a hand-over > between different BTSs, the channel type and/or codec/rate are changing? > > A proper MGW (ours is lacking re-introduction of transcoding) exists to > resolve all those bits by separating the GSM-network internals from the > external side. OK, so I understand then that my proposals are trying to implement things in sip-connector/freeswitch that should be done by the MGW. Freeswitch (in our case) should really just handle call control and be told to bypass media. Then the two co-located? MGWs work out the media stream. The MSC co-located MGW doesn't need to care about the channel type/codec used on the radio link. correct? So then we don't need these extension TLVs spoken of in #2391 > >> * Implement a no media gateway mode in osmo-msc and have the MSC control >> the media stream using SIP via MNCC/osmo-sip-connector instead of >> controlling the MGW using MGCP. > Possible, but I don't think this is advisable. It's violating layering > / network architecture all over the place. OK, so in that case, what's your current thoughts on https://osmocom.org/issues/3142 ? Should it be closed as "won't implement"? I ask because even though it does not have to be necessarily related to this discussion, I was considering attempting to implement it as a way to dive into the MSC code. > > The hard problem to solve, as indicated, is how to express osmux in SDP, > and then how to use SIP+OSMUX on the connections between OsmoMSCs of > different vilalges and/or your central "public network gateway". OK, Let's concetrate on that as the central problem to be solved here. Maybe Pablo can pick it up here with thoughts? (also Rafael, if you're listening, I think this response from Harald should clarify some concerns you had about media streams and signaling over vSAT) > > Regards, > Harald :) From keith at rhizomatica.org Fri Sep 7 09:54:53 2018 From: keith at rhizomatica.org (Keith) Date: Fri, 7 Sep 2018 11:54:53 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <20180907082715.GX23553@nataraja> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907002727.GA10626@my.box> <20180907082715.GX23553@nataraja> Message-ID: <486379f5-4433-72d9-8864-5465149d3cbc@rhizomatica.org> On 07.09.2018 10:27, Harald Welte wrote: > Hi Neels, > > On Fri, Sep 07, 2018 at 02:27:27AM +0200, Neels Hofmeyr wrote: >> Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. >> I think the idea of LCLS is to take out the MSC's MGW, and instructing the >> BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step >> from there to switching BTS directly back to BTS. osmo-bsc has full control >> over that. > LCLS actually doesn't specify how far you go inside the RAN. We chose to > simply keep the stream local to the BSC's MGW as this was simple and matched > the requirements at the time. As stated before, it's just some additional logic > inside osmo-bsc to take the BSC-MGW out of the local loop entirely. OK. So we could compare codecs and endpoints and make a switching decision for internal BTS media? > >> IIUC LCLS happens after bridge. > ack. > >> IIUC we instruct the MS to generate a ringing signal anyway? > Yes, but it's known that not all phones really like to do that, in violation of the GSM specs. Yep. I noticed that :-/ > >> Feels wrong to me to let osmo-sip-connector mess around with the BTS' >> IPAC_MDCX, I think that's firmly osmo-bsc's realm. And sounds like LCLS is the >> thing. > Agreed. > >> Currently we need an MGW both from MSC and from BSC. Again it seems to me LCLS >> is the answer to take out the MSC's MGW, and osmo-bsc's LCLS decision might >> then end up bypassing the BSC's MGW, if it doesn't do that yet? > It doesn't do that last step, but it's just some additional logic inside the BSC to do that. > >> I think osmo-msc doesn't support LCLS though, only osmo-bsc? And also I think >> the MSC doesn't need to do much for LCLS anyway. > It's correct that osmo-bsc implements LCLS, but osmo-msc doesn't enable LCLS yet. See > https://osmocom.org/issues/2487 > > But indeed, all that's needed in osmo-msc is: > * generate a global call reference for each call, include it in the BSSMAP signaling In the case of a SIP originated call, you will get a uniq call ref there. Just wondering if there would be any reason to have it passed over the MNCC? > > The basic use case "switch locally whenever possible" is very easy to achieve. > Also, a simple use case "switch locally only after the CC CONNECT" is equally easy to achieve, > and that way you get your ringtone from the core network. > > If you want to switch it on and of conditionally at whatever other > points during a call, more logic is needed. But I think this is not > Rhizomatica's use case, is it? We do play back "You're credit is about to expire" messages. We would have to switch the stream back to do that.? We could just hang up I suppose, but that's not so nice for the user. > > From laforge at gnumonks.org Fri Sep 7 11:29:06 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 7 Sep 2018 13:29:06 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <486379f5-4433-72d9-8864-5465149d3cbc@rhizomatica.org> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907002727.GA10626@my.box> <20180907082715.GX23553@nataraja> <486379f5-4433-72d9-8864-5465149d3cbc@rhizomatica.org> Message-ID: <20180907112906.GB23553@nataraja> On Fri, Sep 07, 2018 at 11:54:53AM +0200, Keith wrote: > On 07.09.2018 10:27, Harald Welte wrote: > > On Fri, Sep 07, 2018 at 02:27:27AM +0200, Neels Hofmeyr wrote: > >> Reminds me of the LCLS feature recently implemented -- Local Call Local Switch. > >> I think the idea of LCLS is to take out the MSC's MGW, and instructing the > >> BSC's MGW to loop directly back to the BTS. But I guess it's only a tiny step > >> from there to switching BTS directly back to BTS. osmo-bsc has full control > >> over that. > > LCLS actually doesn't specify how far you go inside the RAN. We chose to > > simply keep the stream local to the BSC's MGW as this was simple and matched > > the requirements at the time. As stated before, it's just some additional logic > > inside osmo-bsc to take the BSC-MGW out of the local loop entirely. > > OK. So we could compare codecs and endpoints and make a switching > decision for internal BTS media? exactly. At the time the LCLS decision is made in OsmoBSC, you need to check if the codecs are compatible and then send the IPA MDCX to the two BTSs without keeping anythin on the MGW. To be fair, LCLS also contains use cases where the media in either uplink or downlink is bi-casted (for purposes including lawful intercept), but I think we can exclude those for now, and I think OsmoBSC currently doesn't advertise support for those anyway. > > But indeed, all that's needed in osmo-msc is: > > * generate a global call reference for each call, include it in the BSSMAP signaling > > In the case of a SIP originated call, you will get a uniq call ref there. LCLS needs a way to generate unique call references which are a) unique in the sense that the number space is divided between each element that generates GCRs and hence no two elements would ever end up generating identical GCRs b) signaling for *both legs of each call* have to contain that same, globally unique call reference. "elements" is basically anything that could/would ever initiate a call, so basically MSCs or any other switches (SIP or ISUP or whatever). > Just wondering if there would be any reason to have it passed over the MNCC? It's needed if you want to locally switch media for calls whose both legs aren't handled by the same MSC. This includes more complex scenarios such as inbound roaming in classic networks. I strongly suggest to read the 3GPP LCLS specs, they have nice, colorful diagrams of all those use cases. I don't think it's what we're looking at in this discussion for now, but maybe only at a later step. > > The basic use case "switch locally whenever possible" is very easy to achieve. > > Also, a simple use case "switch locally only after the CC CONNECT" is equally easy to achieve, > > and that way you get your ringtone from the core network. > > > > If you want to switch it on and of conditionally at whatever other > > points during a call, more logic is needed. But I think this is not > > Rhizomatica's use case, is it? > > We do play back "You're credit is about to expire" messages. > We would have to switch the stream back to do that.? Who takes those kinds of decisions? the central switch in the datacenter? If yes, then we'd need some SIP based signaling to switch the (downlink) media plane [temporarily] back to the core. LCLS permits for that, it's just that we have to implement those bits in OsmoMSC and osmo-sip-connector. I don't know the details of how 3GPP specified this for SIP, but I saw there are SIP related parts among those LCLS specs. -- - 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 Sep 7 14:25:56 2018 From: keith at rhizomatica.org (Keith) Date: Fri, 7 Sep 2018 16:25:56 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <20180907112906.GB23553@nataraja> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907002727.GA10626@my.box> <20180907082715.GX23553@nataraja> <486379f5-4433-72d9-8864-5465149d3cbc@rhizomatica.org> <20180907112906.GB23553@nataraja> Message-ID: <2ff71b68-ebca-82db-4ac2-8a4a9440f82c@rhizomatica.org> On 07/09/18 13:29, Harald Welte wrote: > On Fri, Sep 07, 2018 at 11:54:53AM +0200, Keith wrote: > >> We do play back "You're credit is about to expire" messages. >> We would have to switch the stream back to do that.? > Who takes those kinds of decisions? the central switch in the > datacenter? The local switch in the village. Each local village is totally autonomous in terms of supporting local calls. So the local freeswitch has to take care of this. (in reality, if there's no IP uplink, then there is no chargable call either, but never mind that, point is we don't have any centralised switch.) ? > If yes, then we'd need some SIP based signaling to switch > the (downlink) media plane [temporarily] back to the core. Yes, that would be the SIP re-INVITE. This is kind of what I was talking about before. in the freeswitch console, one can just type media_uuid + [uuid of the call] to switch the media in and out of bypass mode. FS then send an INVITE and SDP with the updated ip/port currently, osmo-sip-connector (and LCR + nitb and the fairwaves versions that are supposed to work but I could not get it to work), do not respond correctly and you end up with new call setup and chaos. > LCLS permits > for that, it's just that we have to implement those bits in OsmoMSC and > osmo-sip-connector. Right.. I hoped to gain something from the nitb stuff to port, but looks like not, so that would be a good part of this to table for getting done then. > From keith at rhizomatica.org Sat Sep 8 18:10:50 2018 From: keith at rhizomatica.org (Keith) Date: Sat, 8 Sep 2018 20:10:50 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <20180908171132.vkxz2b7e2wghf2je@salvia> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907081518.GW23553@nataraja> <20180907114137.ctmiq3fr3lx3phfv@salvia> <20180907164905.fyvj6w3ivjq56phk@salvia> <63e8255f-a05d-a1bd-6fb8-1d667cc335d8@rhizomatica.org> <20180908171132.vkxz2b7e2wghf2je@salvia> Message-ID: <41949742-55d3-0d27-c012-9c59cb8a1a03@rhizomatica.org> I was browsing a little through the osmux code in openbsc and libosmo-netif, but I did not quite find the answer to this question I have: Pablo maybe you can shed light? When you divide the OSMUX stream again and turn each circuit ID back into individual RTP stream you have an associated port and IP, right? (on the terrestrial side) I'm wondering if we could have: * local bsc and it's colocated mgw * local msc, with two colocated mgws (we decide which one to signal depending on if the call is local or needs the SAT stream) another point here is I undertand we don't _really_ need two MGWs, so maybe just one in the village, shared between bsc/msc and one in the datacentre. so in the case of a call that is using sat/ osmux, the MSC in the village is signalling the MGW in the datacentre, therefore this MSC knows which IP/port combination to tell to osmo-sip-connector and on to freeswitch, which then signals whatever SIP UA in the data centre So, the fact that osmux is used at all is completely transparent to the SIP UAs Does that make sense? k/ From laforge at gnumonks.org Sun Sep 9 14:08:00 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 9 Sep 2018 16:08:00 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <41949742-55d3-0d27-c012-9c59cb8a1a03@rhizomatica.org> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907081518.GW23553@nataraja> <20180907114137.ctmiq3fr3lx3phfv@salvia> <20180907164905.fyvj6w3ivjq56phk@salvia> <63e8255f-a05d-a1bd-6fb8-1d667cc335d8@rhizomatica.org> <20180908171132.vkxz2b7e2wghf2je@salvia> <41949742-55d3-0d27-c012-9c59cb8a1a03@rhizomatica.org> Message-ID: <20180909140800.GA2799@nataraja> Hi Keith, I'm not sure I'm following your lines of thought completely. In any case, a media gateway is always co-located to a signaling element next to it, at the same level of the network. So the BSC controls its (local) MGW, whith the MSC controls its (local) MGW The split into call-agent and MGW was introduced conceptually simply to separate the control from the user plane. From the outside point of view, it's still a "MSC" logical network element, even though internally it has been split into the "MSS" (MSC Server) and the MGW internally. So any process from another domain / hierarchy controlling a media gateway directly sounds immediately like "HACK/UNCLEAN" to me. On Sat, Sep 08, 2018 at 08:10:50PM +0200, Keith wrote: > When you divide the OSMUX stream again and turn each circuit ID back > into individual RTP stream you have an associated port and IP, right? > (on the terrestrial side) osmux doesn't establish that relationship. Whoever decapsulates OSMUX must know where to send it to, and which dynamic payload type was allocated to it, etc. > * local msc, with two colocated mgws (we decide which one to signal > depending on if the call is local or needs the SAT stream) what's the advantage of having two separate MGWs, compared to having one? All the parameters related to this call/connection are signaled in the MGCP CRCX/MDCX commands. So whether or not a given set of endpoints/calls/connections is on one MGW or on different MGW doesn't really make a difference, IMHO. > another point here is I undertand we don't _really_ need two MGWs, so > maybe just one in the village, shared between bsc/msc and one in the > datacentre. OsmoBSC + OsmoMSC can already share a single MGW at this point. > so in the case of a call that is using sat/ osmux, the MSC in the > village is signalling the MGW in the datacentre, therefore this MSC > knows which IP/port combination to tell to osmo-sip-connector and on to > freeswitch, which then signals whatever SIP UA in the data centre again, sounds like "hack" to me. The MSC signals *its* media gateway, and not "somebody elses". Sure, it's possible to design a system architecture that way, but it's not how media gateways are intended to be used, I think - whether in the context of GSM or not. > So, the fact that osmux is used at all is completely transparent to the > SIP UAs I think if that's the goal, then you'd have to implement a proxy solution that proxies both the SIP as well as the RTP flows. At that point the protocol between the two proxies doesn't matter. The proxy would then re-write/re-generate any IP/port/payload-type/etc. information in the SIP/SDP to hide the presence of osmux. To me, that looks like a last resort kind of 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 Sun Sep 9 15:58:08 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 9 Sep 2018 17:58:08 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: References: Message-ID: <20180909155808.GC2799@nataraja> Hi Lorenzo, there were many bugs in the generic CBCH/SMS-CB support of both OsmoBTS and OsmoBSC. It was working once but has bit-rot over time. Due to a lack of related regression tests, this went unnoticed so far. The fixes are now all merged, so if you build current master of osmo-bts and osmo-trx, you should get working CBCH support. I've also put an example at https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast#How-to-testuse-it Please let me know if it works for you. -- - 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 Sun Sep 9 18:33:44 2018 From: keith at rhizomatica.org (Keith) Date: Sun, 9 Sep 2018 20:33:44 +0200 Subject: confused by osmo-bts rsl.c:bts_supports_cm() Message-ID: Hi All. posting to the list here rather than going down the line of a ticket as I'm using the nitb to configure my bts and so this may not be a bug, but rather a missing back port to legacy. (which may not be appreciated here, I'm aware!) Anyway, this is the scenario: I noticed a lack of audio with latest osmo-bts, and this log message: <0000> rsl.c:1503 invalid mode/codec instructed by BSC, check BSC configuration. ?I added some logging in osmo-bts to check what was being passed into this line in rsl.c: if (bts_supports_cm(lchan->ts->trx->bts, lchan->ts->pchan, lchan->tch_mode) != 1) and the values are 0 (zero), GSM_PCHAN_TCH_F_TCH_H_PDCH? and GSM48_CMODE_SPEECH_AMR but bts_supports_cm() only checks against GSM_PCHAN_TCH_F and GSM_PCHAN_TCH_H Is it that osmo-bsc is sending the actual current channel mode now, whereas the osmo-nitb is sending the configured mode, i.e. TCH_F_TCH_H_PDCH ?? in which case, sorry to bother you, but I will ask: should we try to keep basic functionality between BTS and nitb for a little while longer :) Or are we missing checks for all possible modes in rsl.c:bts_supports_cm() Related commit: http://git.osmocom.org/osmo-bts/commit/src?id=a4bca1155 Thanks!! k/ From keith at rhizomatica.org Sun Sep 9 18:58:08 2018 From: keith at rhizomatica.org (Keith) Date: Sun, 9 Sep 2018 20:58:08 +0200 Subject: OsMux + MGW + SIP In-Reply-To: <20180909140800.GA2799@nataraja> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907081518.GW23553@nataraja> <20180907114137.ctmiq3fr3lx3phfv@salvia> <20180907164905.fyvj6w3ivjq56phk@salvia> <63e8255f-a05d-a1bd-6fb8-1d667cc335d8@rhizomatica.org> <20180908171132.vkxz2b7e2wghf2je@salvia> <41949742-55d3-0d27-c012-9c59cb8a1a03@rhizomatica.org> <20180909140800.GA2799@nataraja> Message-ID: On 09/09/18 16:08, Harald Welte wrote: > Hi Keith, > > I'm not sure I'm following your lines of thought completely. Hi Harald, thanks for taking the time to reply to my thoughts! > > So any process from another domain / hierarchy controlling a media gateway directly > sounds immediately like "HACK/UNCLEAN" to me. Yes. What we are doing; GSM with no centralised core network and no reliable backhaul is kind of HACK-ish though, isn't it? > > On Sat, Sep 08, 2018 at 08:10:50PM +0200, Keith wrote: >> When you divide the OSMUX stream again and turn each circuit ID back >> into individual RTP stream you have an associated port and IP, right? >> (on the terrestrial side) > osmux doesn't establish that relationship. Whoever decapsulates OSMUX > must know where to send it to, and which dynamic payload type was allocated > to it, etc. OK, but isn't it going to be a MGW that decapsulates OSMUX? And then, isn't the MGW going to communicate to it's controlling MSC over MGCP which port it is going to send the decapsulated stream for circuit ID (x) to? (and where it expects the other direction stream) SO therefore, isn't it the MSC, via osmo-sip-connector that has to communicate this info to the SIP UA so it can react accordingly? > >> * local msc, with two colocated mgws (we decide which one to signal >> depending on if the call is local or needs the SAT stream) > what's the advantage of having two separate MGWs, compared to having one? One is in the village, one is in the data centre. I /think/ I can be concise here and say that what I am proposing is that to use OSMUX with MSC/MGW, you have two MGW processes, one on either end of the satellite link and the one MSC signals both of them. I get that it's a horrific departure from standards, but so is the use case, no? :) Before we shoot it down for that, can we discuss if it would work? > > All the parameters related to this call/connection are signaled in the MGCP CRCX/MDCX > commands. So whether or not a given set of endpoints/calls/connections is on one > MGW or on different MGW doesn't really make a difference, IMHO. Yeah, I entered confusion into my last email by mentioning the two MGW for BSC and MSC in the same breath as this other hacky thing.. > >> another point here is I undertand we don't _really_ need two MGWs, so >> maybe just one in the village, shared between bsc/msc and one in the >> datacentre. > OsmoBSC + OsmoMSC can already share a single MGW at this point. Right, good. > >> so in the case of a call that is using sat/ osmux, the MSC in the >> village is signalling the MGW in the datacentre, therefore this MSC >> knows which IP/port combination to tell to osmo-sip-connector and on to >> freeswitch, which then signals whatever SIP UA in the data centre > again, sounds like "hack" to me. The MSC signals *its* media gateway, and not > "somebody elses". :) Yep. It's a hack. but it wouldn't be somebody else's media gateway . it'd be an orphan! > > Sure, it's possible to design a system architecture that way, but it's not > how media gateways are intended to be used, I think - whether in the context > of GSM or not. > >> So, the fact that osmux is used at all is completely transparent to the >> SIP UAs > I think if that's the goal, then you'd have to implement a proxy solution that > proxies both the SIP as well as the RTP flows. At that point the protocol between > the two proxies doesn't matter. Ok so i'm can agree and we can argue away this proposal, but if we don't teach freeswitch to understand osmux... > > The proxy would then re-write/re-generate any IP/port/payload-type/etc. information > in the SIP/SDP to hide the presence of osmux. To me, that looks like a last resort > kind of approach. then what? if not write a proxy, then how to communicate from the demuxing MGW to the SIP UA where to read/send the streams?? thanks! k/ From nhofmeyr at sysmocom.de Mon Sep 10 00:50:17 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 10 Sep 2018 02:50:17 +0200 Subject: confused by osmo-bts rsl.c:bts_supports_cm() In-Reply-To: References: Message-ID: <20180910005017.GB3268@my.box> On Sun, Sep 09, 2018 at 08:33:44PM +0200, Keith wrote: > posting to the list here rather than going down the line of a ticket as > I'm using the nitb to configure my bts and so this may not be a bug, but > rather a missing back port to legacy. (which may not be appreciated > here, I'm aware!) Well, it's rather the other way round: "Our" opinion is that it makes little sense to do it, but whoever wants to spend time on osmo-nitb is welcome to do so! "we" I guess being most of the Osmocom core dev team. And I appreciate you finding below Chan Mode Modif bug: > <0000> rsl.c:1503 invalid mode/codec instructed by BSC, check BSC > configuration. > > ?I added some logging in osmo-bts to check what was being passed into > this line in rsl.c: > > if (bts_supports_cm(lchan->ts->trx->bts, lchan->ts->pchan, > lchan->tch_mode) != 1) > > and the values are 0 (zero), GSM_PCHAN_TCH_F_TCH_H_PDCH? and > GSM48_CMODE_SPEECH_AMR but bts_supports_cm() only checks against > GSM_PCHAN_TCH_F and GSM_PCHAN_TCH_H At first glance, there should not be a difference between osmo-nitb and osmo-bsc there. However, looking more closely, your error message happens during an RSL Mode Modif. This occurs if the MS already is on an lchan suitable for the voice call, but just needs a more accurate chan mode. The point being that current osmo-bsc never reaches that: a) we almost never assign a TCH/F for immediate assignment even if a phone asked for it so we usually will not encounter this situation that a phone already has a TCH/F for early signalling to begin with; b) the code path that would trigger the mode modif currently doesn't, and instead we assign a new lchan ( http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/assignment_fsm.c?id=981f8b934771460354163dd148a5ecab46dd4476#n347 ). c) Even though current osmo-bsc never invokes Chan Mode Modif, I kind of expected osmo-bts code to also invoke the same function somewhere for the chan act case. But it doesn't :P osmo-nitb, however, doesn't do late assignment, so commonly reaches the Chan Mode Modif code path. Either way, even though osmo-bsc doesn't currently use this code path, we still want it fixed for the future, not only for osmo-nitb. Solution: bts_supports_cm() should never be fed with dynamic pchan kinds. To test my patch, I'd need to setup an osmo-nitb ... Keith, can you take over the test whether this fixes the problem instead? Placed it on branch neels/dyn_modif in osmo-bts; it's just: - if (bts_supports_cm(lchan->ts->trx->bts, lchan->ts->pchan, lchan->tch_mode) != 1) { + if (bts_supports_cm(lchan->ts->trx->bts, ts_pchan(lchan->ts), lchan->tch_mode) != 1) { If it's any difficulty to build osmo-bts, I do have a compile for sysmoBTS ready to fire up and could also test myself if you ask me back. (My initial implementation of dyn TS made using the right pchan value a bit hard, for hysterical raisins. First there were the TCH/F_PDCH dynamic timeslots; the implementation I took over from jolly used bit flags to indicate the current actual channel mode. Then I added TCH/F_TCH/H_PDCH also with separate state. The better thing to do from the start would have been to keep the currently used pchan state in the central ts->pchan, and only code that needs to know about the dynamic nature of TS should need to be aware of them. So a code refactoring would be good to make it easier to add new code around checking pchan types -- https://osmocom.org/issues/1902. Such a refactoring has already happened in osmo-bsc, but that's unrelated to this issue.) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lorenzo.cavallini at gmail.com Mon Sep 10 06:14:49 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Mon, 10 Sep 2018 08:14:49 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: <20180909155808.GC2799@nataraja> References: <20180909155808.GC2799@nataraja> Message-ID: Hi, thanks for the update! I'll check as soon as I can and I'll let you know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Mon Sep 10 13:36:43 2018 From: keith at rhizomatica.org (Keith) Date: Mon, 10 Sep 2018 15:36:43 +0200 Subject: confused by osmo-bts rsl.c:bts_supports_cm() In-Reply-To: <20180910005017.GB3268@my.box> References: <20180910005017.GB3268@my.box> Message-ID: <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> On 10/09/18 02:50, Neels Hofmeyr wrote: > > b) the code path that would trigger the mode modif currently doesn't, and > instead we assign a new lchan ( > http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/assignment_fsm.c?id=981f8b934771460354163dd148a5ecab46dd4476#n347 > ). Thanks for explaining that! > c) Even though current osmo-bsc never invokes Chan Mode Modif, I kind of > expected osmo-bts code to also invoke the same function somewhere for the chan > act case. But it doesn't :P > > > osmo-nitb, however, doesn't do late assignment, so commonly reaches the Chan > Mode Modif code path. > > Either way, even though osmo-bsc doesn't currently use this code path, we still > want it fixed for the future, not only for osmo-nitb. > > > Solution: bts_supports_cm() should never be fed with dynamic pchan kinds. To > test my patch, I'd need to setup an osmo-nitb ... Keith, can you take over the > test whether this fixes the problem instead? > OK tested, works fine, I have pushed gerrit #10864 > Placed it on branch neels/dyn_modif in osmo-bts; it's just: > > - if (bts_supports_cm(lchan->ts->trx->bts, lchan->ts->pchan, lchan->tch_mode) != 1) { > + if (bts_supports_cm(lchan->ts->trx->bts, ts_pchan(lchan->ts), lchan->tch_mode) != 1) { I pushed before actually looking at your branch, you'ld probably prefer a different commit message. and maybe not include the logging changes.. anyway, please comment on gerrit. > > If it's any difficulty to build osmo-bts, I do have a compile for sysmoBTS > ready to fire up and could also test myself if you ask me back. No problems, I also have a build machine for sysmoBTS ready, but I am getting great value at the moment from the LimeSDR-mini and osmo-trx-lms running on x86!! > > So a code refactoring would be good to make it easier to add new code around > checking pchan types -- https://osmocom.org/issues/1902. Such a refactoring has > already happened in osmo-bsc, but that's unrelated to this issue.) Good to know, it might help me to spot these things in the future. > > ~N 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 nhofmeyr at sysmocom.de Mon Sep 10 21:26:46 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 10 Sep 2018 23:26:46 +0200 Subject: logging level all everything Message-ID: <20180910212646.GA16443@my.box> Hi list, looking at the logging code, I was surprised: turns out the 'logging level all everything', though quite a misnomer, was an important counterpart to 'logging level all (debug|...|fatal)'. It worked like this: Assuming some levels are set... logging level foo fatal logging level bar debug Now 'logging level all' would override all of them forcefully: logging level all error # Now all categories including 'foo' and 'bar' log exactly error,fatal # messages. logging level all debug # Now all categories including 'foo' and 'bar' log all messages from debug # thru fatal. # manipulating individual categories has no effect at all now! logging level foo notice logging level bar error # no change in logging behavior! logging level foo fatal logging level bar debug # the way to get rid of the forced level was: logging level all everything # Now we see above configured behavior of foo == fatal, bar == debug This is *still the case*, only that we're now ignoring the 'everything' keyword. The consequence is that we can force all categories and clamp them to all-the-same level, but we cannot lift that clamp anymore! :/ I think we should never have accepted the removal of 'everything' as such, it should have been replaced with a more accurate command, like 'no logging level all'. I am considering to bring this back now, ... but But now that we haven't had 'everything' for a long time and the outrage about it has been limited, I am also drawn towards completely dropping that feature, or at least renaming it. Damage is done, no need to go back to mad naming. From the logging discussion, we concluded that we want a command to set the log level for all categories at once, one-time; not force-clamping all to one level until the clamp is removed, but as if we set each individual level manually. I've cracked my head on what name other than "all" we could want this command to have, 'logging level (*|each|any|set-all)'? I keep coming back to 'logging level all (debug|...|fatal)' being by far the best name for this. Backwards compatibility: what do users see when we modify 'logging level all' to not be a forceful clamp, but instead setting individual levels once-off? If a user had a config of "all" coming last: logging level foo debug logging level bar fatal logging level all notice then the experience is that all categories are logging at level 'notice', and that is what the user most likely also expects to happen. Changing the 'all' command does not change the logging behavior one bit. If in turn the config has "all" first: logging level all notice logging level foo debug logging level bar fatal Then the experience is still that before changing the command, all categories are logging at level 'notice'. Most likely the user expected though to see foo='debug' and bar='fatal', because they were set after the 'all' -- what other reason could a user have to keep these lines in the config file, which don't have any effect as-is? If we change the 'all' command to not be a forceful clamp but just a one-time set, then the logging behavior changes to what the user likely expected when writing this config. However: if these settings were forgotten in the config file, we would suddenly change the logging behavior and might surprise users ... but I still kinda think we would change it to what the user expected, right? And the user would likely go: "ah, finally it's doing what I wanted all the while!" right? So, I want to make 'logging level all' manipulate each individual category once-off, I want to completely deprecate the 'everything' keyword, and drop the "global clamp" feature entirely. Maybe I'd re-add the clamp as 'logging level force-all (debug|...|fatal)' and 'no logging level force-all' to switch it off. That would be exactly the old clamping feature just with less confusing names. The only thing that makes me write here is that I'm only 90% sure on changing the meaning of an existing command, of 'logging level all'. If there is no negative feedback on this here, that would bring me to 100%. 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 nhofmeyr at sysmocom.de Mon Sep 10 22:07:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Sep 2018 00:07:23 +0200 Subject: confused by osmo-bts rsl.c:bts_supports_cm() In-Reply-To: <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> References: <20180910005017.GB3268@my.box> <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> Message-ID: <20180910220723.GC16443@my.box> On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote: > OK tested, works fine, I have pushed gerrit #10864 Excellent! > but I am getting great value at the moment from the LimeSDR-mini and > osmo-trx-lms running on x86!! Interesting how every other dev is reporting completely different results on lime. For some it seems to give pure satisfaction, while others seem to be but puzzled by the sheer uselessness of it? I also still have that lime mini we got on the OsmoDevCon, still unused. Might give it a spin then? ~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 Tue Sep 11 03:41:38 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 11 Sep 2018 06:41:38 +0300 Subject: logging level all everything In-Reply-To: <20180910212646.GA16443@my.box> References: <20180910212646.GA16443@my.box> Message-ID: <20180911034138.GG11124@nataraja> Hi Neels, On Mon, Sep 10, 2018 at 11:26:46PM +0200, Neels Hofmeyr wrote: > So, I want to make 'logging level all' manipulate each individual category > once-off, I want to completely deprecate the 'everything' keyword, and drop the > "global clamp" feature entirely. > > Maybe I'd re-add the clamp as 'logging level force-all (debug|...|fatal)' and > 'no logging level force-all' to switch it off. That would be exactly the old > clamping feature just with less confusing names. > > > The only thing that makes me write here is that I'm only 90% sure on changing > the meaning of an existing command, of 'logging level all'. If there is no > negative feedback on this here, that would bring me to 100%. In terms of semantics, old notes/documentation, etc. I would suggest to simply deprecate "all" and introduce a new command instead. If the global clamping is removed, then "logging level all debug" could simply become a no-op, so if people type it in because they are used to it, or have it in some old configs, no harm is done. And if they use "logging level all notice" then they should get a non-fatal warning/notice message that this command is no longer supported. So in short: I suggest to not overload existing keywords, but introducing new ones with well-defined/documented meaning. -- - 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 Sep 11 03:49:58 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 11 Sep 2018 06:49:58 +0300 Subject: LimeSDR-mini (was Re: confused by osmo-bts rsl.c:bts_supports_cm()) In-Reply-To: <20180910220723.GC16443@my.box> References: <20180910005017.GB3268@my.box> <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> <20180910220723.GC16443@my.box> Message-ID: <20180911034958.GH11124@nataraja> Hi Neels, On Tue, Sep 11, 2018 at 12:07:23AM +0200, Neels Hofmeyr wrote: > On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote: > > but I am getting great value at the moment from the LimeSDR-mini and > > osmo-trx-lms running on x86!! > > Interesting how every other dev is reporting completely different results on > lime. For some it seems to give pure satisfaction, while others seem to be but > puzzled by the sheer uselessness of it? I think it may be related to a) the exact LimeSuite version you're using. b) like any SDR, the stability/calibration of the clock you use. For the mini, this typically means using an external GPS-DO, which means you need to do a hardware re-work of moving one resistor, as well as using LimeSuite with patch/commit 9977771c4af14731b5c2b32868b98e29ce7a3ce5 Operating any BTS without a very good clock reference (GPS-DO, calibrated OCXO) is like playing lottery. You may get lucky some times, with some phones, but in most cases it will fail one way or another, in very subtle ways. At sysmocom, it seems we have bricked all three LimeSDR-mini we have by doing the usual gateware update using "LimeSuite master" last week or so. And no error at all was reported during the update. The devices simply are completely useless afterwards. > I also still have that lime mini we got on the OsmoDevCon, still unused. Might > give it a spin then? I also bricked my personal LimeSDR-mini by duing a LimeUtil --update to install the "latest" gateware (from June 2018!) like the three above-mentioned at sysmocom. So whatever you do, I would recommend to be extremely careful with updating the firmware aka gateware. -- - 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 Tue Sep 11 07:27:26 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 11 Sep 2018 09:27:26 +0200 Subject: LimeSDR-mini (was Re: confused by osmo-bts rsl.c:bts_supports_cm()) In-Reply-To: <20180911034958.GH11124@nataraja> References: <20180910005017.GB3268@my.box> <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> <20180910220723.GC16443@my.box> <20180911034958.GH11124@nataraja> Message-ID: <93eb4671-7a62-feeb-9d8b-e9c9383a5e43@rhizomatica.org> On 11/09/18 05:49, Harald Welte wrote: > Hi Neels, > > On Tue, Sep 11, 2018 at 12:07:23AM +0200, Neels Hofmeyr wrote: >> On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote: >>> but I am getting great value at the moment from the LimeSDR-mini and >>> osmo-trx-lms running on x86!! >> Interesting how every other dev is reporting completely different results on >> lime. For some it seems to give pure satisfaction, while others seem to be but >> puzzled by the sheer uselessness of it? > I think it may be related to > a) the exact LimeSuite version you're using. I am using this packaged version: root at debian-dev:~# apt-cache policy limesuite limesuite: ? Installed: 18.06.0-1 ? Candidate: 18.06.0-1 ? Version table: ?*** 18.06.0-1 500 ??????? 500 http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0 ./ Packages The about box on LimeSuiteGui says build date 2018-07-14 > > b) like any SDR, the stability/calibration of the clock you use. For the mini, this > typically means using an external GPS-DO, which means you need to do a hardware > re-work of moving one resistor, as well as using LimeSuite with patch/commit > 9977771c4af14731b5c2b32868b98e29ce7a3ce5 > Operating any BTS without a very good clock reference (GPS-DO, > calibrated OCXO) is like playing lottery. You may get lucky some > times, with some phones, but in most cases it will fail one way or > another, in very subtle ways. I have done no hardware mod. I assume that patch is included in the packge on the osmocom/opensuse repo. Oddly enough, ALL of the phones I have are seeing, camping and (mostly) operating correctly with the LimeSDR-Mini. Even the notoriously cranky K3 that often will not connect to the Ettus N210 unless the GPS-DO is locked. I was also using it to do tests of osmo-pcu on x86 and the Lime seemed to be working fine. > > At sysmocom, it seems we have bricked all three LimeSDR-mini we have by > doing the usual gateware update using "LimeSuite master" last week or > so. And no error at all was reported during the update. The devices > simply are completely useless afterwards. As far as I'm aware, I haven't updated the gateware. I certainly didn't do it manually, so unless something was done automatically by part of LimeSuite, it is as it is when I received it at osmodevcon. root at debian-dev:~# LimeUtil --find ? * [LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D3A0B0F4756A6] I don't know what else I can say about it. I did do some calibration things following tutorials on some webpage in the LimeSuiteGui at some point, but I really don't know what I'm doing there, and I believe anyway that none of that is permanent? osmo-trx-lms does it's own calibration on start up, at least according to log output. This might be good to know: root at debian-dev:/etc/osmocom# apt-cache policy osmo-trx-lms osmo-trx-lms: ? Installed: 0.4.0.53.544c ? Candidate: 0.4.0.53.544c ? Version table: ?*** 0.4.0.53.544c 500 ??????? 500 http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0 ./ Packages > >> I also still have that lime mini we got on the OsmoDevCon, still unused. Might >> give it a spin then? Why not? I'd certainly be interested to know how it works for you. giving it a spin as such, well it should be as simple as installing osmo-trx-lms and limesuite from the opensuse repo and go! The only other thing that occurs to me is ambient operating temperature. The temperature here in this top floor (outside walls exposed to direct sun all afternoon) I am working in has been far too hot for the last month, and the Lime has been working fine, although my head has not. I don't have a thermometer here, but I would guess no less than 35 degrees C in here, heading for 40s in the afternoon. I stopped working then, partly because i couldn't even think and partly because even the sysmoBTS 1002 was getting frighteningly hot. as in too hot to hold. Previous to that, I did notice that it appeared to be operating fine, but sometimes "weird" things happened, that "looked" to me like RX was failing when stressed. I mean.. it "looked" like bursts were received, a LUR could be completed for example.. and call setup signalling, but once you got a call going, the audio would fail. pure guesswork, of course. ( Hence my comments at one time on IRC to not use the Lime for debugging audio issues on split setup. It's been cooler last weekend and the Lime is still working although set to get warm again this week. Of course, the lime itself gets quite hot even just plugged in but idle, and extremely hot when running osmo-trx for a few minutes. I tend to try not to run it too long without a break. So really, that's probably all worthless info, all the same, maybe give it two minutes to "warm up"? Of course. maybe somebody who knows more about the hardware can say if that's nonsense. > I also bricked my personal LimeSDR-mini by duing a LimeUtil --update to install > the "latest" gateware (from June 2018!) like the three above-mentioned at sysmocom. > > So whatever you do, I would recommend to be extremely careful with updating the firmware aka gateware. > Good to know! I will avoid it. I hope I have not jinxed mine now with all this praise.! k/ From keith at rhizomatica.org Tue Sep 11 07:45:48 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 11 Sep 2018 09:45:48 +0200 Subject: logging level all everything In-Reply-To: <20180910212646.GA16443@my.box> References: <20180910212646.GA16443@my.box> Message-ID: <979fc876-5066-df30-89d8-fd9c63a7471f@rhizomatica.org> On 10/09/18 23:26, Neels Hofmeyr wrote: > Hi list, > > looking at the logging code, I was surprised: turns out the 'logging level all > everything', though quite a misnomer, was an important counterpart to 'logging > level all (debug|...|fatal)'. It worked like this: Ahem. https://osmocom.org/issues/71#note-17 > > > > # the way to get rid of the forced level was: > logging level all everything > # Now we see above configured behavior of foo == fatal, bar == debug > > This is *still the case*, only that we're now ignoring the 'everything' > keyword. The consequence is that we can force all categories and clamp them to > all-the-same level, but we cannot lift that clamp anymore! :/ > https://gerrit.osmocom.org/#/c/libosmocore/+/4313/ From keith at rhizomatica.org Tue Sep 11 08:48:07 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 11 Sep 2018 10:48:07 +0200 Subject: logging level all everything In-Reply-To: <20180911034138.GG11124@nataraja> References: <20180910212646.GA16443@my.box> <20180911034138.GG11124@nataraja> Message-ID: <1f5cc1ea-b175-2233-3e45-ea2da90ddc5b@rhizomatica.org> On 11/09/18 05:41, Harald Welte wrote: > Hi Neels, > > On Mon, Sep 10, 2018 at 11:26:46PM +0200, Neels Hofmeyr wrote: > >> So, I want to make 'logging level all' manipulate each individual category >> once-off, I want to completely deprecate the 'everything' keyword, and drop the >> "global clamp" feature entirely. >> >> Maybe I'd re-add the clamp as 'logging level force-all (debug|...|fatal)' and >> 'no logging level force-all' to switch it off. That would be exactly the old >> clamping feature just with less confusing names. Well, I was in favour of the "clamp" originally, and I was using it a lot, hence my manual patching for a while of libosmocore to restore "everything" as "clamp-remover". I use it less now, if ever I do do something like logging level all debug, I know I have to exit the vty and start again to remove the clamp. ? >> >> >> The only thing that makes me write here is that I'm only 90% sure on changing >> the meaning of an existing command, of 'logging level all'. If there is no >> negative feedback on this here, that would bring me to 100%. > In terms of semantics, old notes/documentation, etc. I would suggest to simply > deprecate "all" and introduce a new command instead. If the global clamping > is removed, then "logging level all debug" could simply become a no-op, so if people > type it in because they are used to it, or have it in some old configs, no > harm is done. And if they use "logging level all notice" then they should get > a non-fatal warning/notice message that this command is no longer supported. You /could/ just reinstate the "all everything" as clamp remover. Note that doing "write" in the vty still writes a "logging level all everything" line to the config, causing a warning on startup: ?% Ignoring deprecated logging level everything Then leave logging level all notice meaning "clamp to notice" (as it always was). I honestly never found this difficult to understand once I understood how it worked, so I'd suggest documenting "all" as a "clamp" and suggesting prefer the use of "set-all" > > So in short: I suggest to not overload existing keywords, but introducing new ones > with well-defined/documented meaning. > Then add logging level set-all [level]? set-all makes most sense to me out of the suggestions, for a temporary But again... I really don't mind.. I don't want to wreck your head, Neels, in making decisions. Deprecate 'all' if you want. As I said before I just use expect scripts as shell functions to setup different logging scenarios: rhizomatica at rccnII:~$ type nitb_cc nitb_cc is a function nitb_cc () { ??? /usr/bin/expect -c 'spawn telnet localhost 4242;send "enable\r";send "logging enable\r";send "logging print category 1\r";send "logging level smpp fatal\r"; send "logging level mncc debug\r"; send "logging level cc debug\r"; send "logging filter all 1\r"; interact' } I think this is easier that trying to put that functionality into osmocore itself.. which would be something like logging level foo bar.. [..repeat according to preferences..] then logging scenario save mylogging logging scenario load mylogging One has more urgent things to do.. right? k/ From pespin at sysmocom.de Tue Sep 11 08:57:16 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 11 Sep 2018 10:57:16 +0200 Subject: logging level all everything In-Reply-To: <20180910212646.GA16443@my.box> References: <20180910212646.GA16443@my.box> Message-ID: Hi, As I already shared in last discussion about this topic, I agree with keeping and fixing "logging level all" instead of dropping it and creating a new command, because imho most if not all users of "logging level all" in config files expect the fixed behavior (set each category to level X). Dropping and adding a new command is going to add far more breakage than fixing it. Having said that, I don't want to spend more and more hours in discussions regarding this topic, so I'm fine with whatever fix you want to do as long as current misleading behavior disappears. Have a look at the patches I submitted if you are interested in a similar fix. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From nhofmeyr at sysmocom.de Tue Sep 11 12:20:36 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Sep 2018 14:20:36 +0200 Subject: logging level all everything In-Reply-To: <979fc876-5066-df30-89d8-fd9c63a7471f@rhizomatica.org> References: <20180910212646.GA16443@my.box> <979fc876-5066-df30-89d8-fd9c63a7471f@rhizomatica.org> Message-ID: <20180911122036.GA10057@my.box> On Tue, Sep 11, 2018 at 09:45:48AM +0200, Keith wrote: > Ahem. > https://osmocom.org/issues/71#note-17 Yes, that looked like a good explanation, but my huge trouble reading that was that I did not grok which log lines were being logged on which log level, so I completely did not get what you were explaining back then :( Now I do :) > https://gerrit.osmocom.org/#/c/libosmocore/+/4313/ This link is dead!? Does gerrit forget things? ~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 Sep 11 12:26:53 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 11 Sep 2018 14:26:53 +0200 Subject: logging level all everything In-Reply-To: <20180911122036.GA10057@my.box> References: <20180910212646.GA16443@my.box> <979fc876-5066-df30-89d8-fd9c63a7471f@rhizomatica.org> <20180911122036.GA10057@my.box> Message-ID: On 11/09/18 14:20, Neels Hofmeyr wrote: > On Tue, Sep 11, 2018 at 09:45:48AM +0200, Keith wrote: > >> https://gerrit.osmocom.org/#/c/libosmocore/+/4313/ > This link is dead!? Does gerrit forget things? Sorry, it was marked "Private" > > ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From keith at rhizomatica.org Tue Sep 11 12:28:52 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 11 Sep 2018 14:28:52 +0200 Subject: logging level all everything In-Reply-To: <20180911122036.GA10057@my.box> References: <20180910212646.GA16443@my.box> <979fc876-5066-df30-89d8-fd9c63a7471f@rhizomatica.org> <20180911122036.GA10057@my.box> Message-ID: On 11/09/18 14:20, Neels Hofmeyr wrote: > Yes, that looked like a good explanation, but my huge trouble reading that was > that I did not grok which log lines were being logged on which log level, Understood, without colour and logging print category 1, we never know the log level. :) From keith at rhizomatica.org Tue Sep 11 12:32:49 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 11 Sep 2018 14:32:49 +0200 Subject: confused by osmo-bts rsl.c:bts_supports_cm() In-Reply-To: <20180910220723.GC16443@my.box> References: <20180910005017.GB3268@my.box> <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> <20180910220723.GC16443@my.box> Message-ID: <3e9b00cc-6e90-586a-daf7-f6ce2c5d4a22@rhizomatica.org> On 11/09/18 00:07, Neels Hofmeyr wrote: > On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote: >> OK tested, works fine, I have pushed gerrit #10864 > Excellent! Many thanks for fixing up my patch!! I have submitted it + the two follow up logging patches. 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 nhofmeyr at sysmocom.de Tue Sep 11 12:54:36 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Sep 2018 14:54:36 +0200 Subject: logging level all everything In-Reply-To: References: <20180910212646.GA16443@my.box> Message-ID: <20180911125436.GB10057@my.box> On Tue, Sep 11, 2018 at 10:57:16AM +0200, Pau Espin Pedrol wrote: > As I already shared in last discussion about this topic, I agree with > keeping and fixing "logging level all" instead of dropping it and creating a > new command, because imho most if not all users of "logging level all" in > config files expect the fixed behavior (set each category to level X). But "logging level all" does *not* set each category to level X, instead it sets a global forced level over and above the individually set log levels, which stays clamped on forever regardles of individual logging levels set. I almost had re-used it to mean "set each", basically accepting your patch as it is, but after all I do agree with laforge that it is better to not re-use the same name to mean something different. > Dropping and adding a new command is going to add far more breakage than > fixing it. Not dropping, just deprecating. They will remain available, but not be prominently visible in vty online doc / command autocompletion. So ... after all of your input ... In Accordance with my Title of Supreme Grand Master of Logging and Reforestation I Decree that we Shall: - keep 'logging level all', and bring back 'everything', properly documented, but marked as deprecated. That means the old clamping behavior is still there (the code itself is trivial), but the commands do not appear when querying the VTY cmdline doc. Why keep it? So that old config files still work as they did when conceived. Why hide it? because the naming is misleading to most of us, and it's less trouble to just see the new ones with a clear meaning. - add 'logging level set-all' to set each category once-off. - add 'logging level force-all ' and 'no logging level force-all' as aliases for 'all ' and 'all everything' to not write deprecated commands to file. I agree that we want to stop discussing this now. This is both an example of Bikeshedding and of why writing new software can be faster than changing old software. (If you disagree with the above, I don't want to shut you up, everyone is always allowed to talk more, regardless. Just offering to relieve everyone of the burden now.) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rafael at riseup.net Tue Sep 11 13:00:49 2018 From: rafael at riseup.net (Rafael Diniz) Date: Tue, 11 Sep 2018 10:00:49 -0300 Subject: OsMux + MGW + SIP In-Reply-To: References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907081518.GW23553@nataraja> Message-ID: <5cd9584e-75bc-6535-a532-ec1c35fbae75@riseup.net> Hi all, >> The hard problem to solve, as indicated, is how to express osmux in SDP, >> and then how to use SIP+OSMUX on the connections between OsmoMSCs of >> different vilalges and/or your central "public network gateway". > > OK, Let's concetrate on that as the central problem to be solved here. > > Maybe Pablo can pick it up here with thoughts? > > (also Rafael, if you're listening, I think this response from Harald > should clarify some concerns you had about media streams and signaling > over vSAT) Hi there, I'm listening. ; ) So are we trying to use OsMux for calls on different MSCs using SIP, right? So I should concentrate on making osmo-mgw, osmo-msc and osmo-sip-connector play nicelly with OsMux and SIP? Btw, why SIP if we can still use MGCP to control the media plane with OsMux multiplex? Cheers, 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 djks74 at gmail.com Tue Sep 11 13:10:52 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Tue, 11 Sep 2018 20:10:52 +0700 Subject: OsMux + MGW + SIP In-Reply-To: <5cd9584e-75bc-6535-a532-ec1c35fbae75@riseup.net> References: <99305620-ff12-df4b-0376-1f708cbae938@rhizomatica.org> <20180907081518.GW23553@nataraja> <5cd9584e-75bc-6535-a532-ec1c35fbae75@riseup.net> Message-ID: Because SIP is the one manage to voice gateway via osmo-sip-connector, Correct me if im wrong. On Tue, Sep 11, 2018, 20:07 Rafael Diniz wrote: > Hi all, > > >> The hard problem to solve, as indicated, is how to express osmux in SDP, > >> and then how to use SIP+OSMUX on the connections between OsmoMSCs of > >> different vilalges and/or your central "public network gateway". > > > > OK, Let's concetrate on that as the central problem to be solved here. > > > > Maybe Pablo can pick it up here with thoughts? > > > > (also Rafael, if you're listening, I think this response from Harald > > should clarify some concerns you had about media streams and signaling > > over vSAT) > > Hi there, I'm listening. > ; ) > > So are we trying to use OsMux for calls on different MSCs using SIP, > right? So I should concentrate on making osmo-mgw, osmo-msc and > osmo-sip-connector play nicelly with OsMux and SIP? > > Btw, why SIP if we can still use MGCP to control the media plane with > OsMux multiplex? > > Cheers, > Rafael Diniz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Sep 11 13:26:43 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Sep 2018 15:26:43 +0200 Subject: logging level all everything In-Reply-To: References: <20180910212646.GA16443@my.box> <979fc876-5066-df30-89d8-fd9c63a7471f@rhizomatica.org> <20180911122036.GA10057@my.box> Message-ID: <20180911132643.GA11170@my.box> On Tue, Sep 11, 2018 at 02:28:52PM +0200, Keith wrote: > > > On 11/09/18 14:20, Neels Hofmeyr wrote: > > Yes, that looked like a good explanation, but my huge trouble reading that was > > that I did not grok which log lines were being logged on which log level, > > Understood, without colour and logging print category 1, we never know > the log level. :) Rather 'logging print level 1', which I think I added pretty much because I didn't understand that explanation :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rafael at riseup.net Tue Sep 11 14:09:23 2018 From: rafael at riseup.net (Rafael Diniz) Date: Tue, 11 Sep 2018 11:09:23 -0300 Subject: Relevant GSM 3GPP standards Message-ID: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> Hi all, I'm diving into 3GPP standards after all the OsMux discussion. For example, LCLS, 3GPP TS 44.007 standard was mentioned. Trying to figure out where to download it, I reached: http://www.3gpp.org/DynaReport/44-series.htm But it's not there any 44.007. Any hint? Thanks, 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 domi at tomcsanyi.net Tue Sep 11 14:20:03 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Tue, 11 Sep 2018 16:20:03 +0200 (CEST) Subject: Relevant GSM 3GPP standards In-Reply-To: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> References: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> Message-ID: <8D8EE139-F17A-4967-97CB-666CF653AD45@tomcsanyi.net> Hi This might help http://laforge.gnumonks.org/blog/20161216-3gpp-specs-etsi-pdf/ Regards, Domi 2018. szept. 11. d?tummal, 16:09 id?pontban Rafael Diniz ?rta: > Hi all, > I'm diving into 3GPP standards after all the OsMux discussion. For > example, LCLS, 3GPP TS 44.007 standard was mentioned. Trying to figure > out where to download it, I reached: > http://www.3gpp.org/DynaReport/44-series.htm > > But it's not there any 44.007. Any hint? > > Thanks, > Rafael Diniz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Tue Sep 11 17:48:31 2018 From: keith at rhizomatica.org (Keith) Date: Tue, 11 Sep 2018 19:48:31 +0200 Subject: logging level all everything In-Reply-To: <20180911132643.GA11170@my.box> References: <20180910212646.GA16443@my.box> <979fc876-5066-df30-89d8-fd9c63a7471f@rhizomatica.org> <20180911122036.GA10057@my.box> <20180911132643.GA11170@my.box> Message-ID: On 11/09/18 15:26, Neels Hofmeyr wrote: > > Rather 'logging print level 1', which I think I added pretty much because I > didn't understand that explanation :) ah! I never even notice[d] that! > ~N From nhofmeyr at sysmocom.de Tue Sep 11 19:56:51 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 11 Sep 2018 21:56:51 +0200 Subject: Relevant GSM 3GPP standards In-Reply-To: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> References: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> Message-ID: <20180911195651.GC11170@my.box> I usually get my specs from etsi.org directly. Updates get published all the time, sometimes fixing bugs, and it's a bad idea to be stuck on an older version. They also have a search that has more than once helped me to find the relevant spec number for a gem that I had forgotten where to find: https://www.etsi.org/ The catch is that on the top search bar, first click on "Standards", then search. That will get you to a more extensive search filter. Interestingly enough, I can't find 44.007 there at all. Are you sure that number is correct? So far I have found everything else without a problem. For LCLS, I find 23.284 https://www.etsi.org/deliver/etsi_ts/123200_123299/123284/15.00.00_60/ts_123284v150000p.pdf ~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 Tue Sep 11 20:35:39 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 11 Sep 2018 23:35:39 +0300 Subject: Relevant GSM 3GPP standards In-Reply-To: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> References: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> Message-ID: <20180911203539.GR32026@nataraja> Hi Rafael, On Tue, Sep 11, 2018 at 11:09:23AM -0300, Rafael Diniz wrote: > I'm diving into 3GPP standards after all the OsMux discussion. For > example, LCLS, 3GPP TS 44.007 standard was mentioned. might have been a typo or a 'thinko'. Where did you find that reference? The closest I can think of is the old 04.07, and I don't see how that would have any relation to LCLS. 23.284 is the most important spec for LCLS. The so called "stage 2" specs describe a given feature on a relatively high level, without going into detailed message encodings or the like. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vvvelichkov at gmail.com Tue Sep 11 20:54:12 2018 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Tue, 11 Sep 2018 23:54:12 +0300 Subject: Relevant GSM 3GPP standards In-Reply-To: <20180911203539.GR32026@nataraja> References: <01a07bcc-31d7-700d-d9d8-bed9f609bf28@riseup.net> <20180911203539.GR32026@nataraja> Message-ID: <88c92eee-6e10-ebf8-0904-3a813e333c8a@gmail.com> Hi Harald, On 9/11/18 11:35 PM, Harald Welte wrote: > Hi Rafael, > > On Tue, Sep 11, 2018 at 11:09:23AM -0300, Rafael Diniz wrote: >> I'm diving into 3GPP standards after all the OsMux discussion. For >> example, LCLS, 3GPP TS 44.007 standard was mentioned. > might have been a typo or a 'thinko'. Where did you find that reference? There are two references in the redmine https://osmocom.org/search?utf8=%E2%9C%93&q=%22TS+44.007%22 https://osmocom.org/projects/cellular-infrastructure/wiki/MNCC https://osmocom.org/projects/osmo-sip-conector From andrew at carrierdetect.com Wed Sep 12 11:13:56 2018 From: andrew at carrierdetect.com (Andrew Back) Date: Wed, 12 Sep 2018 12:13:56 +0100 Subject: confused by osmo-bts rsl.c:bts_supports_cm() In-Reply-To: <20180910220723.GC16443@my.box> References: <20180910005017.GB3268@my.box> <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> <20180910220723.GC16443@my.box> Message-ID: On 10/09/18 23:07, Neels Hofmeyr wrote: > On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote: >> OK tested, works fine, I have pushed gerrit #10864 > > Excellent! > >> but I am getting great value at the moment from the LimeSDR-mini and >> osmo-trx-lms running on x86!! > > Interesting how every other dev is reporting completely different results on > lime. For some it seems to give pure satisfaction, while others seem to be but > puzzled by the sheer uselessness of it? I would note that there has been varying behaviour reported with OsmoTRX use across Lime Suite (driver) and gateware revisions, which is clearly frustrating and something we're investigating. This likely explains why present experiences may vary, but we're working to address this and plan to use Osmocom CNI as a reference application in release testing. Cheers, Andrew [Wearing my Lime Micro hat, but posting from this account since it's subscribed] From djks74 at gmail.com Wed Sep 12 11:35:52 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Wed, 12 Sep 2018 18:35:52 +0700 Subject: confused by osmo-bts rsl.c:bts_supports_cm() In-Reply-To: References: <20180910005017.GB3268@my.box> <46f8fc90-3740-22fb-0ee1-7013eb2155e1@rhizomatica.org> <20180910220723.GC16443@my.box> Message-ID: As far i can say, the driver that i mention here is the best for LimeSDR-USB. Someone never get voice working and dead connection, but after downgrade to my suggestion, this guys is make it work. http://discourse.myriadrf.org/t/limesdr-gsm-with-omso/2589/86 So who have the LimeSDR-USB. Try the firmware/gateware version I mention. firmware/gateware version: LimeSDR-USB_HW_1.3_r3.0.img and LimeSDR-USB_HW_1.4_r2.9.rbf from LimeSuite V.17.09. It should work. I compare to all version and this one is absolutely perfect with osmo-nitb. Hope someone can get help. On Wed, Sep 12, 2018, 18:19 Andrew Back wrote: > On 10/09/18 23:07, Neels Hofmeyr wrote: > > On Mon, Sep 10, 2018 at 03:36:43PM +0200, Keith wrote: > >> OK tested, works fine, I have pushed gerrit #10864 > > > > Excellent! > > > >> but I am getting great value at the moment from the LimeSDR-mini and > >> osmo-trx-lms running on x86!! > > > > Interesting how every other dev is reporting completely different > results on > > lime. For some it seems to give pure satisfaction, while others seem to > be but > > puzzled by the sheer uselessness of it? > > I would note that there has been varying behaviour reported with OsmoTRX > use across Lime Suite (driver) and gateware revisions, which is clearly > frustrating and something we're investigating. This likely explains why > present experiences may vary, but we're working to address this and plan > to use Osmocom CNI as a reference application in release testing. > > Cheers, > > Andrew > > [Wearing my Lime Micro hat, but posting from this account since it's > subscribed] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mia at mob5g.net Wed Sep 12 17:16:00 2018 From: mia at mob5g.net (Michael Andersen) Date: Wed, 12 Sep 2018 19:16:00 +0200 Subject: Nokia packet Abis experiment Message-ID: <016501d44abc$46de2e20$d49a8a60$@net> Hi OpenBSC, My company is working on integrating some BTS (Nokia Flexi ESMB) with Nokia packet Abis with OsmoBSC. The Nokia packet Abis seems to be Nokia OML/RSL over SCTP/IUA (RFC 3057). To get started, we have built a little stub that takes the incoming SCTP/IUA connection and carries out ASP_UP/ASP_ACTIVE handshake. After this handshake is complete, we see OML coming in from the BTS. It seems that this OML is in a form that would be understood by "bts_nokia_site.c". So now we would like to continue the experiment by feeding the OML/RSL into a BTS configured in OsmoBSC as type "nokia_site". Now the questions: 1. Is it possible to configure a BTS of type "nokia_site" to run Abis over a unix domain socket ? 2. Is there a better way to prototype this integration ? PS: PCAP trace available on request Best Regards, Michael Andersen From djks74 at gmail.com Wed Sep 12 17:56:09 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Thu, 13 Sep 2018 00:56:09 +0700 Subject: LimeSDR-USB experience with New Splits Solved! Message-ID: Osmocom New Splits stacks for voice is SOLVED and stable with LimeSDR! Voice is working actually since back then, my fault is using only C117/118 for test call all the time. Now I just test using newer phone both Caller and Callee and voice is work perfectly! I tested both osmo-trx-lms and osmo-trx legacy. using osmo-trx legacy 0.20 also have better performance using the firmware/gateware version I mention here : firmware/gateware version: LimeSDR-USB_HW_1.3_r3.0.img and LimeSDR-USB_HW_1.4_r2.9.rbf from LimeSuite . There is trace in wireshark when using old phone as C117/118, the BTS always freeze and send Measurement Indication all the time when calling is made and answered, but with newer phone, the Indication is normal. -- Best Regards, DUO -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Sep 12 18:06:25 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 12 Sep 2018 20:06:25 +0200 Subject: Nokia packet Abis experiment In-Reply-To: <016501d44abc$46de2e20$d49a8a60$@net> References: <016501d44abc$46de2e20$d49a8a60$@net> Message-ID: <20180912180625.GA1297@my.box> On Wed, Sep 12, 2018 at 07:16:00PM +0200, Michael Andersen wrote: > Hi OpenBSC, > > My company is working on integrating some BTS (Nokia Flexi ESMB) with Nokia > packet Abis with OsmoBSC. > > The Nokia packet Abis seems to be Nokia OML/RSL over SCTP/IUA (RFC 3057). > > To get started, we have built a little stub that takes the incoming SCTP/IUA > connection and carries out ASP_UP/ASP_ACTIVE handshake. After this handshake > is complete, we see OML coming in from the BTS. Short of teaching osmo-bsc to listen for and handshake SCTP/IUA ... Maybe you could just open Abis/IP connections from your stub to osmo-bsc and feed OML and RSL through those? e.g. using the libosmo-abis client, like osmo-bts does? Let me plug here: In case you would like to have more concrete and timely assistance than a public mailing list can provide in developers' free time, maybe it would help you to book professional support from an Osmocom affiliated company? (My employer comes to mind.) It's not mandatory, of course, but especially for professional use of Osmocom it would be good to support the community ecosystem. Booking support hours (that helps pay developers' wages) is just one possibility, more ways would be to contribute patches / documentation / ... As you see fit. ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Thu Sep 13 07:18:01 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 13 Sep 2018 10:18:01 +0300 Subject: Nokia packet Abis experiment In-Reply-To: <016501d44abc$46de2e20$d49a8a60$@net> References: <016501d44abc$46de2e20$d49a8a60$@net> Message-ID: <20180913071801.GB28879@nataraja> Hi Michael, On Wed, Sep 12, 2018 at 07:16:00PM +0200, Michael Andersen wrote: > My company is working on integrating some BTS (Nokia Flexi ESMB) with Nokia > packet Abis with OsmoBSC. this sounds very exciting! I'm really happy to read that somebody is working on supporting some other BTS models / dialects. > The Nokia packet Abis seems to be Nokia OML/RSL over SCTP/IUA (RFC 3057). Interesting. Do you have protocol traces from a working setup with the Nokia BSC? My usual approach for implementing Abis protocol dialects in all of the Osmocom history has been the following process: * obtain as many protocol traces as possible (sometimes only 1 or 2) from a working setup * try to find vendor documentation on the Abis specifics (often not available) * try to see if there are protocol analyzers that can decode the vendor specific dialects (Nethawk, MA-10, Tektronix, ...) * implement a wireshark dissector at least for those bits of the protocol that are understood/known/standard * try to re-implement the protocol from the Osmocom side > To get started, we have built a little stub that takes the incoming SCTP/IUA > connection and carries out ASP_UP/ASP_ACTIVE handshake. After this handshake > is complete, we see OML coming in from the BTS. Great! I hope you have seen libosmo-sigtran. It already implements SUA and M3UA, and a lot of the infrastructure and the state machines would also workfor M2UA, M2PA, and likely also for IUA. The next step then would be to think about how to use this new Abis within the context of libosmo-abis, which currently only deals with T1/E1 and IPA/Osmo-stylae Abis/IP. > It seems that this OML is in a form that would be understood by > "bts_nokia_site.c". So now we would like to continue the experiment by > feeding the OML/RSL into a BTS configured in OsmoBSC as type "nokia_site". great! > 1. Is it possible to configure a BTS of type "nokia_site" to run Abis over a > unix domain socket ? The unixsocket.c code in libosmoabis should be rather generic. I'm not sure anyone has tried to use it with Nokia BTS model so far, but it *should* work. > 2. Is there a better way to prototype this integration ? See my above thoughts. Whatever comes out of this and however far you get, I strongly suggest that you publish all findings for the benefit of the wider community. Thanks! 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 mychaela.falconia at gmail.com Thu Sep 13 23:53:22 2018 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Thu, 13 Sep 2018 15:53:22 -0800 Subject: LimeSDR-USB experience with New Splits Solved! In-Reply-To: References: Message-ID: Sandi Suhendro wrote: > Voice is working actually since back then, my fault is using only > C117/118 for test call all the time. > Now I just test using newer phone both Caller and Callee and voice is > work perfectly! > [...] > There is trace in wireshark when using old phone as C117/118, the BTS > always freeze and send Measurement Indication all the time when calling > is made and answered, but with newer phone, the Indication is normal. In your tests with C117/118 phones that produced failing results, were those phones running OsmocomBB or Motorola's original firmware? If Motorola phones running their original firmware (which presumably had passed official certification and type approval tests back in the day) don't work with Osmocom networks (be it LimeSDR or other Osmocom- compatible BTS hardware, SDR-based or otherwise) but "newer" (meaning more proprietary and more thoroughly locked down) phones do work, then it is a very grave problem from the perspective of Freedom, and needs to be taken very seriously. Sysmocom has two of my FreeCalypso development boards, only one of which has been calibrated with a CMU200 instrument and fc-rfcal-tools before leaving my shop - the other board did not receive calibration because Harald claimed it early in the bring-up process, before I had climbed the calibration learning curve and developed my calibration programs. Looking at the photo in issue #2704: https://osmocom.org/issues/2704 The board you've got set up there is the one that did get properly calibrated before being sold to Sysmocom. Like all boards from that batch, it was shipped with an official FreeCalypso firmware image in its flash - based on the date it was shipped, it was probably the 20170831 build. Do you still have that firmware image in the flash, or have you erased it? Where is the RF from that board connected to - does it go to a sysmoBTS unit? Would it be possible for someone from Sysmocom (or someone from the community who have been set up with remote access to that board) to test and see if the FCDEV3B can successfully connect to Osmocom network using the official FreeCalypso firmware on the board, driven via AT commands? If Sysmocom folks are philosophically against doing any tests with FreeCalypso firmware, would someone else in the community be more willing? I am hoping to have the next batch of my boards (which will also be at hardware revision V2) made in the next few months (more precisely, as soon as I can afford the ~3kUSD cost of the new PCB fab run for V2), and when I get those boards made, I plan on giving away a limited number of them on a subsidized basis, free of cost to the recipient. If anyone here is interested in pairing the source-enabled (source freely published for all to see and to tinker with) network side GSM implementation from Osmocom with the equally source-enabled mobile side implementation from FreeCalypso (which is much more robust and feature-complete than OsmocomBB), you may very well be eligible to receive a subsidized FCDEV3B V2 board when they become available. Warm regards, Mychaela Falconia, Mother of FreeCalypso P.S. Regarding Sysmocom's other FCDEV3B board which you got before it was calibrated, if you have a CMU200 instrument which is itself in good calibration standing, you can calibrate the board yourself. The needed software is here: https://bitbucket.org/falconian/fc-rfcal-tools Given your level of expertise with GSM RF, I trust that you should have absolutely no difficulty with figuring out how to use my calibration sw if you have the needed RF test equipment. From mia at mob5g.net Fri Sep 14 07:50:50 2018 From: mia at mob5g.net (Michael Andersen) Date: Fri, 14 Sep 2018 09:50:50 +0200 Subject: Nokia packet Abis experiment In-Reply-To: <20180913071801.GB28879@nataraja> References: <016501d44abc$46de2e20$d49a8a60$@net> <20180913071801.GB28879@nataraja> Message-ID: <005801d44bff$a7b2bec0$f7183c40$@net> Hi Harald, >> The Nokia packet Abis seems to be Nokia OML/RSL over SCTP/IUA (RFC 3057). >Interesting. Do you have protocol traces from a working setup with the Nokia >BSC? I have enclosed the trace of the handshake experiment. This is the trace that ends with receiving the OML wrapped in SCTP/IUA. We are working on getting our hands on a trace from a working setup. >> 1. Is it possible to configure a BTS of type "nokia_site" to run Abis over a >> unix domain socket ? >The unixsocket.c code in libosmoabis should be rather generic. I'm not >sure anyone has tried to use it with Nokia BTS model so far, but it *should* work. We will try something like this and see if that brings us to a new milestone. BR, Michael A -------------- next part -------------- A non-text attachment was scrubbed... Name: abis.pcap Type: application/octet-stream Size: 4180 bytes Desc: not available URL: From djks74 at gmail.com Fri Sep 14 08:20:17 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Fri, 14 Sep 2018 15:20:17 +0700 Subject: LimeSDR-USB experience with New Splits Solved! In-Reply-To: References: Message-ID: I tested using original firmware. On Fri, Sep 14, 2018 at 6:53 AM Mychaela Falconia < mychaela.falconia at gmail.com> wrote: > Sandi Suhendro wrote: > > > Voice is working actually since back then, my fault is using only > > C117/118 for test call all the time. > > Now I just test using newer phone both Caller and Callee and voice is > > work perfectly! > > [...] > > There is trace in wireshark when using old phone as C117/118, the BTS > > always freeze and send Measurement Indication all the time when calling > > is made and answered, but with newer phone, the Indication is normal. > > In your tests with C117/118 phones that produced failing results, were > those phones running OsmocomBB or Motorola's original firmware? If > Motorola phones running their original firmware (which presumably had > passed official certification and type approval tests back in the day) > don't work with Osmocom networks (be it LimeSDR or other Osmocom- > compatible BTS hardware, SDR-based or otherwise) but "newer" (meaning > more proprietary and more thoroughly locked down) phones do work, then > it is a very grave problem from the perspective of Freedom, and needs > to be taken very seriously. > > Sysmocom has two of my FreeCalypso development boards, only one of > which has been calibrated with a CMU200 instrument and fc-rfcal-tools > before leaving my shop - the other board did not receive calibration > because Harald claimed it early in the bring-up process, before I had > climbed the calibration learning curve and developed my calibration > programs. Looking at the photo in issue #2704: > > https://osmocom.org/issues/2704 > > The board you've got set up there is the one that did get properly > calibrated before being sold to Sysmocom. Like all boards from that > batch, it was shipped with an official FreeCalypso firmware image in > its flash - based on the date it was shipped, it was probably the > 20170831 build. Do you still have that firmware image in the flash, > or have you erased it? Where is the RF from that board connected to - > does it go to a sysmoBTS unit? Would it be possible for someone from > Sysmocom (or someone from the community who have been set up with > remote access to that board) to test and see if the FCDEV3B can > successfully connect to Osmocom network using the official FreeCalypso > firmware on the board, driven via AT commands? > > If Sysmocom folks are philosophically against doing any tests with > FreeCalypso firmware, would someone else in the community be more > willing? I am hoping to have the next batch of my boards (which will > also be at hardware revision V2) made in the next few months (more > precisely, as soon as I can afford the ~3kUSD cost of the new PCB fab > run for V2), and when I get those boards made, I plan on giving away a > limited number of them on a subsidized basis, free of cost to the > recipient. If anyone here is interested in pairing the source-enabled > (source freely published for all to see and to tinker with) network > side GSM implementation from Osmocom with the equally source-enabled > mobile side implementation from FreeCalypso (which is much more robust > and feature-complete than OsmocomBB), you may very well be eligible to > receive a subsidized FCDEV3B V2 board when they become available. > > Warm regards, > Mychaela Falconia, > Mother of FreeCalypso > > P.S. Regarding Sysmocom's other FCDEV3B board which you got before it > was calibrated, if you have a CMU200 instrument which is itself in good > calibration standing, you can calibrate the board yourself. The needed > software is here: > > https://bitbucket.org/falconian/fc-rfcal-tools > > Given your level of expertise with GSM RF, I trust that you should > have absolutely no difficulty with figuring out how to use my > calibration sw if you have the needed RF test equipment. > -- Best Regards, Sandi -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Fri Sep 14 09:29:10 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 14 Sep 2018 16:29:10 +0700 Subject: LimeSDR-USB experience with New Splits Solved! Message-ID: Hi Mychaela, > If Motorola phones running their original firmware [...] > don't work with Osmocom networks [...] it is a very grave > problem from the perspective of Freedom [...] Actually, they do. You can even find some videos on YouTube, where an original Motorola phone runing FreeCalypso firmware was tested with Osmocom based network (most likely, CalypsoBTS). The problem is that the author of this topic is using LimeSDR, that is still not 100% reliable as a PHY for OsmoTRX, and not reliable itself, because even a regular firmware update can brick the board... Moreover, AFAIK the author is not using any stable clock source, such as GPSDO. > Sysmocom has two of my FreeCalypso development boards [...] > The board you've got set up there is the one that did get > properly calibrated before being sold to Sysmocom. Maybe I am missing something, but how is this related to the original topic? > Do you still have that firmware image in the flash, or have > you erased it? Where is the RF from that board connected to - > does it go to a sysmoBTS unit? Would it be possible for someone > from Sysmocom [...] to test and see if the FCDEV3B can successfully > connect to Osmocom network using the official FreeCalypso > firmware on the board, driven via AT commands? I think you could ask this in context of the mentioned issue. > If Sysmocom folks are philosophically against doing any > tests with FreeCalypso firmware [...] Please don't get me wrong, but I am philosophically against abusing the mailing list in order to PR your production. This is not the first time I see some thread mixed with your advertisements. There are other commercial companies also using this mailing list, and let's imagine everybody would constantly PR their production here? It would just result in a mess. Even Sysmocom is not abusing that much, at least I don't see any offers to buy e.g. sysmoBTS when a general question about some BTS is asked... With best regards, Vadim Yanitskiy. From mychaela.falconia at gmail.com Fri Sep 14 11:48:01 2018 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Fri, 14 Sep 2018 03:48:01 -0800 Subject: LimeSDR-USB experience with New Splits Solved! In-Reply-To: References: Message-ID: Vadim wrote: > Actually, they do. You can even find some videos on YouTube, > where an original Motorola phone runing FreeCalypso firmware > was tested with Osmocom based network (most likely, CalypsoBTS). Videos on YouTube? Are you referring to the ones from 2015 or so with Russian titles? Those are the only ones I am aware of - how do you know that phone was running against an Osmocom network as opposed to the regular commercial GSM operator in Russia or wherever those videos were made? > Maybe I am missing something, but how is this related to > the original topic? The relation is simple: if phones like Mot C1xx running Motorola's original factory fw don't work with Osmocom networks, then there is a high chance that Osmocom GSM networks may be similarly incompatible with the newer FreeCalypso MS implementation, given the genealogical proximity between the two. If Osmocom networks work fine when serving ultra-locked-down Qualcomm and MTK phones but don't work with the world's only published-source GSM MS implementation that is also feature-complete, it would be absolutely terrible news for Freedom- minded folks, hence me raising the concern here in this thread. I was simply asking if *anyone* (doesn't matter who) has ever actually tested the combination of Osmocom on the network side + FreeCalypso on the mobile side. Because of the scarcity of the needed hardware (only a handful of FCDEV3B boards have been made and sent out to people), I asked if Sysmocom could do this test on one of their FCDEV3B boards because they are the only FCDEV3B owner to my knowledge who are also involved in network-side work: all other FCDEV3B owners in the world are just like me, testing against pre-existing major commercial GSM operators (and in my case also against the CMU200) without any BTS of our own. And I hope to rectify this situation when I have more boards by giving some away free of cost, and hopefully getting at least one board into the hands of someone who regularly plays with current Osmocom network-side sw on their own BTS. M~ From axilirator at gmail.com Fri Sep 14 12:27:48 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 14 Sep 2018 19:27:48 +0700 Subject: LimeSDR-USB experience with New Splits Solved! Message-ID: > 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. From rafael at riseup.net Fri Sep 14 13:01:03 2018 From: rafael at riseup.net (Rafael Diniz) Date: Fri, 14 Sep 2018 10:01:03 -0300 Subject: Osmo-pcu error: PCU interface version number of BTS (7) is different (9). Message-ID: <1b1edd40-b4ee-c2d0-0617-d148651d0060@riseup.net> Hi all, I'm trying to test trunk osmo-pcu (using armhf osmo repo) in the NuRan LC 1.5 in the lab, but I get: 20180914124657820 DLGLOBAL <000e> telnet_interface.c:104 telnet at 127.0.0.2 4240 20180914124657821 DL1IF <0001> osmobts_sock.cpp:248 Opening OsmoPCU L1 interface to OsmoBTS 20180914124657821 DL1IF <0001> osmobts_sock.cpp:308 osmo-bts PCU socket /tmp/pcu_bts has been connected 20180914124657821 DL1IF <0001> osmobts_sock.cpp:312 Sending version 0.5.1.3-3e9c to BTS. 20180914124657821 DL1IF <0001> pcu_l1_if.cpp:113 Sending 0.5.1.3-3e9c TXT as PCU_VERSION to BTS PCU interface version number of BTS (7) is different (9). Please re-compile! Any way to make it work without changing BTS software? Thanks, 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 pespin at sysmocom.de Fri Sep 14 13:26:53 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 14 Sep 2018 15:26:53 +0200 Subject: Osmo-pcu error: PCU interface version number of BTS (7) is different (9). In-Reply-To: References: <1b1edd40-b4ee-c2d0-0617-d148651d0060@riseup.net> Message-ID: <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> Sorry forgot to reply-all and didn't send original mail to ML, re-sending now. On 9/14/18 3:25 PM, Pau Espin Pedrol wrote: > Hi Rafael, > > You may want to check at PCU_IF_VERSION in both osmo-pcu.git and > osmo-pcu.git > > It seems that you are running a recent osmo-pcu together with a quite > old osmo-bts (from at least Feb 28 2018, see osmo-bts.git > 4046e3b3dd0cffd53d8d0d1f3e1bf9d0dec83ede), and they are not protocol > compatible. > > So you need to either use a newer osmo-bts (preferred I guess) or switch > to an older osmo-pcu which uses PCU_IF_VERSION 7. > > If you are using NuRan original firmware, you either ask them to update > their stuff or your are pretty much on your own to build new images > (with non-upstream osmocom versions afaik). > > At sysmocom we maintain meta-sysmocom-bsp [1] which together with > system-images [2] and osmocom's meta-telephny [3] allows to build > firmware for both sysmobts and litecell 1.5 machines, together with SDKs > to compile software for them. > > I think generated images are not available publicly, but I guess you can > either attempt building them yourself or perhaps ask sysmocom customer > support to have access to it. > > [1] https://git.sysmocom.de/poky/meta-sysmocom-bsp/ > [2] https://git.sysmocom.de/poky/system-images/ > [3] https://git.osmocom.org/meta-telephony/ > > 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 pespin at sysmocom.de Fri Sep 14 13:28:40 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 14 Sep 2018 15:28:40 +0200 Subject: Osmo-pcu error: PCU interface version number of BTS (7) is different (9). In-Reply-To: <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> References: <1b1edd40-b4ee-c2d0-0617-d148651d0060@riseup.net> <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> Message-ID: <8825d0eb-3685-7d71-67de-29485d73579c@sysmocom.de> Hi again, I forgot to say, if you look at those repositories, you need to check either branch "201705" (pointing to latest releases, similar to "latest" debian osmocom repo), or branch laforge/nightly, which points to osmocom master (similar o "nightly" from osmocom debian repos). -- - 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 rafael at riseup.net Fri Sep 14 13:41:41 2018 From: rafael at riseup.net (Rafael Diniz) Date: Fri, 14 Sep 2018 10:41:41 -0300 Subject: Osmo-pcu error: PCU interface version number of BTS (7) is different (9). In-Reply-To: <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> References: <1b1edd40-b4ee-c2d0-0617-d148651d0060@riseup.net> <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> Message-ID: Thanks Pau! I'll ask NuRan to check if they can provide me a newer BTS software. If not, I understand I can compile stuff for the LC 1.5, but how about the closed source firmware / software, how can I create an image for the board without these proprietary pieces? Rafael Diniz On 09/14/2018 10:26 AM, Pau Espin Pedrol wrote: > Sorry forgot to reply-all and didn't send original mail to ML, > re-sending now. > > On 9/14/18 3:25 PM, Pau Espin Pedrol wrote: >> Hi Rafael, >> >> You may want to check at PCU_IF_VERSION in both osmo-pcu.git and >> osmo-pcu.git >> >> It seems that you are running a recent osmo-pcu together with a quite >> old osmo-bts (from at least Feb 28 2018, see osmo-bts.git >> 4046e3b3dd0cffd53d8d0d1f3e1bf9d0dec83ede), and they are not protocol >> compatible. >> >> So you need to either use a newer osmo-bts (preferred I guess) or >> switch to an older osmo-pcu which uses PCU_IF_VERSION 7. >> >> If you are using NuRan original firmware, you either ask them to >> update their stuff or your are pretty much on your own to build new >> images (with non-upstream osmocom versions afaik). >> >> At sysmocom we maintain meta-sysmocom-bsp [1] which together with >> system-images [2] and osmocom's meta-telephny [3] allows to build >> firmware for both sysmobts and litecell 1.5 machines, together with >> SDKs to compile software for them. >> >> I think generated images are not available publicly, but I guess you >> can either attempt building them yourself or perhaps ask sysmocom >> customer support to have access to it. >> >> [1] https://git.sysmocom.de/poky/meta-sysmocom-bsp/ >> [2] https://git.sysmocom.de/poky/system-images/ >> [3] https://git.osmocom.org/meta-telephony/ >> >> Regards, >> Pau >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From pespin at sysmocom.de Fri Sep 14 14:00:39 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 14 Sep 2018 16:00:39 +0200 Subject: Osmo-pcu error: PCU interface version number of BTS (7) is different (9). In-Reply-To: References: <1b1edd40-b4ee-c2d0-0617-d148651d0060@riseup.net> <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> Message-ID: <1f27cdf6-a38b-9f11-7ad0-66d5c182fcaa@sysmocom.de> And again, forgot to include the list, sorry ;) On 9/14/18 3:59 PM, Pau Espin Pedrol wrote: > Hi Rafael, > > I'm not sure right now about the details of the binary firmware > installation and the exact rights you have as customer/user regarding > it, but I guess you can ask NuRan to provide them, or take them from > your current LC 1.5 image you are using if they are available there. I > think the headers are at least provided publicly in gitlab: > https://gitlab.com/nrw_noa > > 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 matt9j at cs.washington.edu Fri Sep 14 17:37:57 2018 From: matt9j at cs.washington.edu (Matthew Johnson) Date: Fri, 14 Sep 2018 10:37:57 -0700 Subject: Osmo-pcu error: PCU interface version number of BTS (7) is different (9). In-Reply-To: <1f27cdf6-a38b-9f11-7ad0-66d5c182fcaa@sysmocom.de> References: <1b1edd40-b4ee-c2d0-0617-d148651d0060@riseup.net> <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> <1f27cdf6-a38b-9f11-7ad0-66d5c182fcaa@sysmocom.de> Message-ID: Pau, I've been able to build a complete LiteCell BTS firmware image from the h ttps://gitlab.com/nrw_noa repo with Yocto and load and run it successfully on my LC1.5. I believe going this path may void your warranty, but I am not sure. I had better luck with the BTS version than the nitb or bsc versions, although I was rushed for time and didn't take much effort to attempt to debug those builds. There are good instructions for generating the bts binary here: https://gitlab.com/nrw_noa/lc15-bts-release-manifest/wikis/home On Fri, Sep 14, 2018 at 7:01 AM Pau Espin Pedrol wrote: > And again, forgot to include the list, sorry ;) > > On 9/14/18 3:59 PM, Pau Espin Pedrol wrote: > > Hi Rafael, > > > > I'm not sure right now about the details of the binary firmware > > installation and the exact rights you have as customer/user regarding > > it, but I guess you can ask NuRan to provide them, or take them from > > your current LC 1.5 image you are using if they are available there. I > > think the headers are at least provided publicly in gitlab: > > https://gitlab.com/nrw_noa > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Fri Sep 14 19:30:51 2018 From: keith at rhizomatica.org (Keith) Date: Fri, 14 Sep 2018 21:30:51 +0200 Subject: radisys / NRW_NOA PCU (was Re: Osmo-pcu error..) In-Reply-To: References: <1b1edd40-b4ee-c2d0-0617-d148651d0060@riseup.net> <9c7139f4-048e-2df5-14f2-ba6fffc18484@sysmocom.de> Message-ID: I want to add that I asked Rafael to take a quick look at the performance of the Nuran supplied osmo-pcu on the LC 1.5, given that he has one to hand and I don't. :) This is partly in relation to this ticket: http://osmocom.org/issues/2603 titled "Review the various incomplete and never merged changes in radisys branch" Having taken a look at those branches, I noted that the most recent commit there (in the egprs_features branch) is quite old, from December 2016, and that this same commit appears in the nuran open access lc15 branch https://gitlab.com/nrw_noa/osmo-pcu/commit/f9bc46bf13028cc21763e56a0be41d85eab1c1f1 although this particular commit is not is osmo master branch. Si, it seems some of the radisys work made it back into osmo master (via nrw_noa) at some point, but then the two diverged again. I did ask Nuran about this last year and I was told the "there's not always time/resources to pursue code review" answer. There is currently quite a large set of differences between https://gitlab.com/nrw_noa/osmo-pcu/commits/nrw/litecell15 and osmo master. A small amount of it is LC15 specific, but most is not. As Rafaels feedback about the quick functionality test of EGPRS was good, I want to take a closer look at this. My prime motivation is the somewhat broken unknown TA handling in current osmo-pcu master that Max worked on: http://osmocom.org/issues/1526 It seems from a few quick glances that a lot of what is in the radisys branches is in the noa repo and also in osmo-pcu master. I wonder if it's worth assuming that anything useful there made it's way into the noa branch and it would be better to work from there? I'd appreciate some guidance on how to go about that. If I find things that look useful, cherry pick them into osmo master and test and all looks good, should I propose them verbatim on gerrit for review? Should I keep the orginal commit messages and author, even if I were to make small changes, in the case i should spot something that I know would help with passing code review? Thanks! K. From holger at freyther.de Sat Sep 15 07:35:48 2018 From: holger at freyther.de (Holger Freyther) Date: Sat, 15 Sep 2018 08:35:48 +0100 Subject: shellcheck for our shell scripts? Message-ID: <2919399E-5587-421C-B513-111000B8F100@freyther.de> Hey, I recently stumbled across shellcheck[1] and think we should make it a goal that our shell scripts don't produce errors/warnings with it. Some of the examples in the GSM tester: In jenkins-build-common.sh line 76: cd "$base" ^-- SC2164: Use 'cd ... || exit' or 'cd ... || return' in case cd fails. In jenkins-build-common.sh line 93: rm -rf * ^-- SC2035: Use ./*glob* or -- *glob* so names with dashes won't become options. What do you think? My approach would be: * Install shellcheck into our build containers * Run them and provide warnings * Fix them over time and on new code * Make CI fail with failures cheers holger [1] https://www.shellcheck.net/ From laforge at gnumonks.org Sat Sep 15 09:19:02 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 15 Sep 2018 12:19:02 +0300 Subject: FreeCalypso / Osmocom testing (Re: LimeSDR-USB experience with New Splits Solved!) In-Reply-To: References: Message-ID: <20180915091902.GF2015@nataraja> Hi Mychaela, On Thu, Sep 13, 2018 at 03:53:22PM -0800, Mychaela Falconia wrote: > Sysmocom has two of my FreeCalypso development boards, To clarify: sysmocom != Harald. I personally have bought one, which I have at home, and sysmocom has another one (at the sysmocom office/lab). > The board you've got set up there is the one that did get properly > calibrated before being sold to Sysmocom. Like all boards from that > batch, it was shipped with an official FreeCalypso firmware image in > its flash - based on the date it was shipped, it was probably the > 20170831 build. Do you still have that firmware image in the flash, > or have you erased it? > Where is the RF from that board connected to - does it go to a sysmoBTS unit? the way it looks, it has been connected to our osmo-gsm-tester setup, which basically is a coaxial RF distribution network to which a variety of BTSs (nanoBTS, sysmoBTS, USRP B2xx, UmTRX, ...) are connected, and where we run automatic continous tests with a set of modems against our latest "master" of the Osmocom stack. > Would it be possible for someone from > Sysmocom (or someone from the community who have been set up with > remote access to that board) to test and see if the FCDEV3B can > successfully connect to Osmocom network using the official FreeCalypso > firmware on the board, driven via AT commands? This should all be possible. I doubt anyone has removed/erased the firmware on it. In fact, I think that connecting the FCDEV to the osmo-gsm-tester setup might not be the best idea. It might be better to have a dedicated test setup with a single BTS and the FCDEV, to which we can then provide remote access. But let's have that discussion at https://osmocom.org/issues/2704 > If Sysmocom folks are philosophically against doing any tests with > FreeCalypso firmware, I'm not sure where you would get such an idea from. We're happy to test whatever makes sense technically, and if there are any [suspected] interoperability problems with the Osmocom network-side stack, then we want to resolve those, no matter what the MS side implementation. -- - 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 Sep 15 09:21:00 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 15 Sep 2018 12:21:00 +0300 Subject: shellcheck for our shell scripts? In-Reply-To: <2919399E-5587-421C-B513-111000B8F100@freyther.de> References: <2919399E-5587-421C-B513-111000B8F100@freyther.de> Message-ID: <20180915092100.GG2015@nataraja> Hi Holger, On Sat, Sep 15, 2018 at 08:35:48AM +0100, Holger Freyther wrote: > I recently stumbled across shellcheck[1] and think we should make it a goal that our shell scripts don't > produce errors/warnings with it. definitely a good idea! > What do you think? My approach would be: > > * Install shellcheck into our build containers > * Run them and provide warnings > * Fix them over time and on new code > * Make CI fail with failures sounds like a good plan. I suppose any changes to the build slaves would be performed via our ansible playbooks to ensure we can replicate the setup at any point in the future, as needed. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Sat Sep 15 11:56:41 2018 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Sat, 15 Sep 2018 03:56:41 -0800 Subject: FreeCalypso / Osmocom testing (Re: LimeSDR-USB experience with New Splits Solved!) In-Reply-To: <20180915091902.GF2015@nataraja> References: <20180915091902.GF2015@nataraja> Message-ID: Hi Harald! > > If Sysmocom folks are philosophically against doing any tests with > > FreeCalypso firmware, > > I'm not sure where you would get such an idea from. We're happy to test > whatever makes sense technically, and if there are any [suspected] > interoperability > problems with the Osmocom network-side stack, then we want to resolve those, > no matter what the MS side implementation. Good to hear. I was afraid that you would see my firmware as being untouchable for you because you are located in a country that deems it as being in violation of copyright. Now if you *are* willing to test FC firmware against Osmocom network-side gear, does that willingness extend only to the dated fw version already in the flash, or would you also be willing to test newer FC fw versions which you would need to download from ftp.freecalypso.org and flash yourself? Or would the latter be unacceptable to you because your country deems all of these FC firmwares to be in violation of copyright? Just wondering what your stance is. M~ From pespin at sysmocom.de Sat Sep 15 20:07:55 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sat, 15 Sep 2018 22:07:55 +0200 Subject: shellcheck for our shell scripts? In-Reply-To: <2919399E-5587-421C-B513-111000B8F100@freyther.de> References: <2919399E-5587-421C-B513-111000B8F100@freyther.de> Message-ID: <442c73c5-648a-eb7e-9e6e-970d525a08dc@sysmocom.de> Hi Holger, I personally have shellcheck plugin in my editor (atom) which performs checks in real time when I write shell scripts, I really recommend using it if your editor supports it. Regarding checking stuff with shellcheck, it can be fine but it may be dangerous requiring fix of all warnings/errors, since some of them are sometimes really hard to fix. For instance doing some stuff in posix shell bs doing it for bash or whatever. A related topic could be discussing about using "uncrustify" to force correct code format to be applied to code during gerrit jenkins job. 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 Sun Sep 16 19:51:56 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 16 Sep 2018 21:51:56 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: References: <20180909155808.GC2799@nataraja> Message-ID: <20180916195156.GR6125@nataraja> Hi Lorenzo, On Mon, Sep 10, 2018 at 08:14:49AM +0200, Lorenzo Cavallini wrote: > thanks for the update! > I'll check as soon as I can and I'll let you know. Any news yet? I've meanwhile developed a related test suite for osmo-bts (see http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=laforge/cbch&id=7048dc207acc94b0fca0ed82d4bc46b071e678e5) as well as discovered + fixed a wireshark RSL dissector bug related to RSL CBCH (https://code.wireshark.org/review/29683). -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lorenzo.cavallini at gmail.com Mon Sep 17 08:41:16 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Mon, 17 Sep 2018 10:41:16 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: <20180916195156.GR6125@nataraja> References: <20180909155808.GC2799@nataraja> <20180916195156.GR6125@nataraja> Message-ID: Hi, yes I have some updates. I tested with two different timeslot configurations: CCCH+SDCCH4+CBCH on ts0 and SDCCH8+CBCH on ts1. In both cases I'm using an iPhone8 to test. With the first ts configuration, the iphone could not perform the location update procedure, so basically I had no connectivity to the basestation. With the second, the location update procedure goes through, I'm connected, I can send/receive sms and phonecalls, but smscb are not being delivered, at least that's what I think. I can definitely see the smscb messages on the gsmtap interface and I can see the smscb request coming from RSL link. However, I don't get any broadcasts on the phone itself. But this last part is till not very clear, I need to investigate a bit more on what's going on. As a side note, when using CCCH+SDCCH4+CBCH ts0 configuration, both my iPhone8 and my Huawei Honor9 cannot perform the location update procedure. Apparently they can only get the BCCH channel but the location update procedure never starts. I tested as outlined here: https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast#How-to-testuse-it . Let me know if this helps and what kind of debug I can provide you, as you may guess getting debug out of mainstream smartphones is not really easy, so what I can do is limited on that side. Thanks! Lorenzo On Sun, Sep 16, 2018 at 10:00 PM Harald Welte wrote: > Hi Lorenzo, > > On Mon, Sep 10, 2018 at 08:14:49AM +0200, Lorenzo Cavallini wrote: > > thanks for the update! > > I'll check as soon as I can and I'll let you know. > > Any news yet? > > I've meanwhile developed a related test suite for osmo-bts (see > http://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=laforge/cbch&id=7048dc207acc94b0fca0ed82d4bc46b071e678e5 > ) > as well as discovered + fixed a wireshark RSL dissector bug related to RSL > CBCH > (https://code.wireshark.org/review/29683). > > -- > - 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 osmith at sysmocom.de Mon Sep 17 08:54:41 2018 From: osmith at sysmocom.de (Oliver Smith) Date: Mon, 17 Sep 2018 10:54:41 +0200 Subject: shellcheck for our shell scripts? In-Reply-To: <442c73c5-648a-eb7e-9e6e-970d525a08dc@sysmocom.de> References: <2919399E-5587-421C-B513-111000B8F100@freyther.de> <442c73c5-648a-eb7e-9e6e-970d525a08dc@sysmocom.de> Message-ID: <8b7c61b7-ca92-56fd-7111-0791328748fb@sysmocom.de> Hi Pau, On 9/15/18 10:07 PM, Pau Espin Pedrol wrote:> Regarding checking stuff with shellcheck, it can be fine but it may be > dangerous requiring fix of all warnings/errors, since some of them are > sometimes really hard to fix. For instance doing some stuff in posix > shell bs doing it for bash or whatever. I've been using shellcheck a lot myself, and in my experience it is actually feasible to require scripts having no warnings and errors. We even have that set up as a CI test in a project. It detects the shell from the shebang, so if one specifies #!/bin/bash, it allows using the bash features. For warnings that are not helpful, it's possible to add a line like the following above: # shellcheck disable=SC2086 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 Sep 17 09:30:21 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 17 Sep 2018 11:30:21 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: References: <20180909155808.GC2799@nataraja> <20180916195156.GR6125@nataraja> Message-ID: <20180917093021.GH6125@nataraja> Hi Lorenzo, On Mon, Sep 17, 2018 at 10:41:16AM +0200, Lorenzo Cavallini wrote: > yes I have some updates. I tested with two different timeslot > configurations: CCCH+SDCCH4+CBCH on ts0 and SDCCH8+CBCH on ts1. > In both cases I'm using an iPhone8 to test. iPhones are generally known to have (together with at leats older Blackberries) the most "critical" protocol stacks out there, i.e. they will bail out the first time they see any single bit that is not like they expect it. So in general, it might be worth to also test with other phones and compare. > With the first ts configuration, the iphone could not perform the > location update procedure, so basically I had no connectivity to the > basestation. the qeustion is which particular commit you were using at the time. There is one fix that might be related to this: commit 526b4a5f350725d312c6739cf6abdcef040b698c Author: Neels Hofmeyr Date: Tue Sep 11 00:47:29 2018 +0200 ts,lchan_fsm: do not attempt to allocate CBCH subslots Also, please noe that as per GSM spec, if you use the CBCH on SDCCH/4, you *must* advertise BS_AG_BLKS_RES >= 1 to achieve a valid configuration. > Let me know if this helps and what kind of debug I can provide you, as you > may guess getting debug out of mainstream smartphones is not really easy, > so what I can do is limited on that side. I think particularly the big trouble in the SDCCH/4 case should be possible to debug with traces only from the network side. If you can provide pcap files with * GSMTAP (containing at least BCCH,CCCH,SDCCH,CBCH SAPI) * Abis OML and RSL (tcp port 3003 + 3002) during the time where you tried to register the phone unsuccessfully, it would help. Also, please double-check if the commit above by Neels makes a difference. I'll also try to reproduce this here today using a LimeSDR-USB and current osmo-bts / osmo-bsc master and a couple of phones. 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 Sep 17 12:50:29 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 17 Sep 2018 14:50:29 +0200 Subject: "codec_pref: fix typo in comment" Message-ID: <20180917125029.GA6700@my.box> BTW, "iff" is not a typo, it means "If and only if". https://www.merriam-webster.com/dictionary/iff re https://gerrit.osmocom.org/10962 ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From lorenzo.cavallini at gmail.com Tue Sep 18 09:30:58 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Tue, 18 Sep 2018 11:30:58 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: <20180917093021.GH6125@nataraja> References: <20180909155808.GC2799@nataraja> <20180916195156.GR6125@nataraja> <20180917093021.GH6125@nataraja> Message-ID: Hi, I've seen the latest commits and tested them. I can confirm that now SMSCBs are working in the CCCH+SDCCH4+CBCH configuration, however the funny part is they're working on my extremely old, pre-iPhone era Samsung mobile phone, where I can receive the smscb message. On my iPhone8 and Honor9 I still can't get anything, but that's not an issue, I just wanted to be sure that SMSCBs are being delivered. Anyway, the location update procedure is successfully completed in all three phones I've tested. I'll do other tests meanwhile and try to understand why they're not being displayed by "modern" phones, most likely they're being blocked in the baseband before reaching Android/iOS, but again this is not a problem. I can see some garbage text on my old Samsung, so it might be some issues with encoding. Anyway, thanks for the support! Regards, Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenkins at lists.osmocom.org Tue Sep 18 12:30:43 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 18 Sep 2018 12:30:43 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #233 In-Reply-To: <1456559717.151.1537237022566.JavaMail.jenkins@jenkins.osmocom.org> References: <1456559717.151.1537237022566.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <1797347401.163.1537273843828.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 533.22 KB...] Generating docs for compound osmo_scu_unitdata_param... Generating docs for compound osmo_ss7_as... Generating docs for compound osmo_ss7_asp... Generating docs for compound osmo_ss7_asp_peer... Generating docs for compound osmo_ss7_instance... Generating docs for compound osmo_ss7_link... Generating docs for compound osmo_ss7_linkset... Generating docs for compound osmo_ss7_pc_fmt... Generating docs for compound osmo_ss7_route... Generating docs for compound osmo_ss7_route_table... Generating docs for compound osmo_ss7_routing_key... Generating docs for compound osmo_ss7_user... Generating docs for compound osmo_xlm_prim... Generating docs for compound osmo_xlm_prim_error... Generating docs for compound osmo_xlm_prim_notify... Generating docs for compound osmo_xlm_prim_rk_dereg... Generating docs for compound osmo_xlm_prim_rk_reg... Generating docs for compound osmo_xua_layer_manager... Generating docs for compound osmo_xua_server... Generating docs for compound pcap_hdr... Generating docs for compound pcaprec_hdr... Generating docs for compound sccp_connection... Generating docs for compound sccp_data_callback... Generating docs for compound sccp_system... Generating docs for compound xua_as_fsm_priv... Generating docs for compound xua_asp_fsm_priv... Generating docs for compound xua_common_hdr... Generating docs for compound xua_dialect... Generating docs for compound xua_msg... Generating docs for compound xua_msg_class... Generating docs for compound xua_msg_event_map... Generating docs for compound xua_msg_part... Generating docs for compound xua_parameter_hdr... Generating namespace index... Generating graph info page... Generating directory documentation... Generating index page... Generating page index... Generating module index... Generating namespace index... Generating namespace member index... Generating annotated compound index... Generating alphabetical compound index... Generating hierarchical class index... Generating member index... Generating file index... Generating file member index... Generating example index... finalizing index lists... writing tag file... lookup cache used 2511/65536 hits=19828 misses=2595 finished... cd ./doc && tar cf html.tar */html make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' + make install make install-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' Making install in include make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' Making install in sccp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sccp' /usr/bin/install -c -m 644 sccp_types.h sccp.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sccp' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' Making install in mtp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mtp' /usr/bin/install -c -m 644 mtp_level3.h mtp_pcap.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mtp' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' Making install in osmocom make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' Making install in sigtran make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[5]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[5]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran' /usr/bin/install -c -m 644 xua_types.h xua_msg.h m2ua_types.h sccp_sap.h sigtran_sap.h sccp_helpers.h mtp_sap.h osmo_ss7.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran/protocol' /usr/bin/install -c -m 644 protocol/sua.h protocol/m3ua.h protocol/mtp.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran/protocol' make[5]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[5]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[5]: Nothing to be done for 'install-exec-am'. make[5]: Nothing to be done for 'install-data-am'. make[5]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' Making install in src make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' /bin/bash ../libtool --mode=install /usr/bin/install -c libosmo-sigtran.la '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' libtool: install: /usr/bin/install -c .libs/libosmo-sigtran.so.0.2.0 /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.so.0.2.0 libtool: install: (cd /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib && { ln -s -f libosmo-sigtran.so.0.2.0 libosmo-sigtran.so.0 || { rm -f libosmo-sigtran.so.0 && ln -s libosmo-sigtran.so.0.2.0 libosmo-sigtran.so.0; }; }) libtool: install: (cd /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib && { ln -s -f libosmo-sigtran.so.0.2.0 libosmo-sigtran.so || { rm -f libosmo-sigtran.so && ln -s libosmo-sigtran.so.0.2.0 libosmo-sigtran.so; }; }) libtool: install: /usr/bin/install -c .libs/libosmo-sigtran.lai /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.la libtool: install: /usr/bin/install -c .libs/libosmo-sigtran.a /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.a libtool: install: chmod 644 /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.a libtool: install: ranlib /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.a libtool: finish: PATH="/home/osmocom-build/osmo-ci/coverity/cov-analysis-linux64-8.5.0/bin/:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/osmocom-build/bin:/opt/coverity/current/bin:/sbin" ldconfig -n /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib ---------------------------------------------------------------------- Libraries have been installed in: /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the '-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the 'LD_RUN_PATH' environment variable during linking - use the '-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to '/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' /usr/bin/install -c -m 644 libsccp.a libmtp.a libxua.a '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' ( cd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' && ranlib libsccp.a ) ( cd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' && ranlib libmtp.a ) ( cd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' && ranlib libxua.a ) make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' Making install in tests make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' Making install in xua make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' Making install in sccp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' Making install in mtp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' Making install in m2ua make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' Making install in ss7 make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' Making install in examples make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' Making install in stp make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-stp '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c .libs/osmo-stp /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-stp make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' Making install in doc make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' Making install in examples make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/doc/libosmo-sccp/examples/osmo-stp' /usr/bin/install -c -m 644 osmo-stp.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/doc/libosmo-sccp/examples/osmo-stp' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' /usr/bin/install -c -m 644 osmo-stp.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' Making install in contrib make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib' Making install in systemd make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/lib/systemd/system' /usr/bin/install -c -m 644 osmo-stp.service '/lib/systemd/system' /usr/bin/install: cannot create regular file '/lib/systemd/system/osmo-stp.service': Permission denied Makefile:328: recipe for target 'install-systemdsystemunitDATA' failed make[4]: *** [install-systemdsystemunitDATA] Error 1 make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' Makefile:398: recipe for target 'install-am' failed make[3]: *** [install-am] Error 2 make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' Makefile:362: recipe for target 'install-recursive' failed make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib' Makefile:489: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' Makefile:788: recipe for target 'install' failed make: *** [install] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 431 C/C++ compilation units (100%) successfully 431 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 jenkins at lists.osmocom.org Tue Sep 18 13:03:16 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 18 Sep 2018 13:03:16 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #234 In-Reply-To: <1797347401.163.1537273843828.JavaMail.jenkins@jenkins.osmocom.org> References: <1797347401.163.1537273843828.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <737381497.164.1537275796105.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 533.22 KB...] Generating docs for compound osmo_scu_unitdata_param... Generating docs for compound osmo_ss7_as... Generating docs for compound osmo_ss7_asp... Generating docs for compound osmo_ss7_asp_peer... Generating docs for compound osmo_ss7_instance... Generating docs for compound osmo_ss7_link... Generating docs for compound osmo_ss7_linkset... Generating docs for compound osmo_ss7_pc_fmt... Generating docs for compound osmo_ss7_route... Generating docs for compound osmo_ss7_route_table... Generating docs for compound osmo_ss7_routing_key... Generating docs for compound osmo_ss7_user... Generating docs for compound osmo_xlm_prim... Generating docs for compound osmo_xlm_prim_error... Generating docs for compound osmo_xlm_prim_notify... Generating docs for compound osmo_xlm_prim_rk_dereg... Generating docs for compound osmo_xlm_prim_rk_reg... Generating docs for compound osmo_xua_layer_manager... Generating docs for compound osmo_xua_server... Generating docs for compound pcap_hdr... Generating docs for compound pcaprec_hdr... Generating docs for compound sccp_connection... Generating docs for compound sccp_data_callback... Generating docs for compound sccp_system... Generating docs for compound xua_as_fsm_priv... Generating docs for compound xua_asp_fsm_priv... Generating docs for compound xua_common_hdr... Generating docs for compound xua_dialect... Generating docs for compound xua_msg... Generating docs for compound xua_msg_class... Generating docs for compound xua_msg_event_map... Generating docs for compound xua_msg_part... Generating docs for compound xua_parameter_hdr... Generating namespace index... Generating graph info page... Generating directory documentation... Generating index page... Generating page index... Generating module index... Generating namespace index... Generating namespace member index... Generating annotated compound index... Generating alphabetical compound index... Generating hierarchical class index... Generating member index... Generating file index... Generating file member index... Generating example index... finalizing index lists... writing tag file... lookup cache used 2511/65536 hits=19828 misses=2595 finished... cd ./doc && tar cf html.tar */html make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' + make install make install-recursive make[1]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' Making install in include make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' Making install in sccp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sccp' /usr/bin/install -c -m 644 sccp_types.h sccp.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sccp' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/sccp' Making install in mtp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mtp' /usr/bin/install -c -m 644 mtp_level3.h mtp_pcap.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/mtp' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/mtp' Making install in osmocom make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' Making install in sigtran make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[5]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[5]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran' /usr/bin/install -c -m 644 xua_types.h xua_msg.h m2ua_types.h sccp_sap.h sigtran_sap.h sccp_helpers.h mtp_sap.h osmo_ss7.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran/protocol' /usr/bin/install -c -m 644 protocol/sua.h protocol/m3ua.h protocol/mtp.h '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/include/osmocom/sigtran/protocol' make[5]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom/sigtran' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[5]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[5]: Nothing to be done for 'install-exec-am'. make[5]: Nothing to be done for 'install-data-am'. make[5]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include/osmocom' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/include' Making install in src make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' /bin/bash ../libtool --mode=install /usr/bin/install -c libosmo-sigtran.la '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' libtool: install: /usr/bin/install -c .libs/libosmo-sigtran.so.0.2.0 /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.so.0.2.0 libtool: install: (cd /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib && { ln -s -f libosmo-sigtran.so.0.2.0 libosmo-sigtran.so.0 || { rm -f libosmo-sigtran.so.0 && ln -s libosmo-sigtran.so.0.2.0 libosmo-sigtran.so.0; }; }) libtool: install: (cd /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib && { ln -s -f libosmo-sigtran.so.0.2.0 libosmo-sigtran.so || { rm -f libosmo-sigtran.so && ln -s libosmo-sigtran.so.0.2.0 libosmo-sigtran.so; }; }) libtool: install: /usr/bin/install -c .libs/libosmo-sigtran.lai /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.la libtool: install: /usr/bin/install -c .libs/libosmo-sigtran.a /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.a libtool: install: chmod 644 /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.a libtool: install: ranlib /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib/libosmo-sigtran.a libtool: finish: PATH="/home/osmocom-build/osmo-ci/coverity/cov-analysis-linux64-8.5.0/bin/:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/osmocom-build/bin:/opt/coverity/current/bin:/sbin" ldconfig -n /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib ---------------------------------------------------------------------- Libraries have been installed in: /home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the '-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the 'LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the 'LD_RUN_PATH' environment variable during linking - use the '-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to '/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' /usr/bin/install -c -m 644 libsccp.a libmtp.a libxua.a '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' ( cd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' && ranlib libsccp.a ) ( cd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' && ranlib libmtp.a ) ( cd '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/lib' && ranlib libxua.a ) make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/src' Making install in tests make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' Making install in xua make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/xua' Making install in sccp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/sccp' Making install in mtp make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/mtp' Making install in m2ua make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/m2ua' Making install in ss7 make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests/ss7' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/tests' Making install in examples make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/examples' Making install in stp make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-stp '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin' libtool: install: /usr/bin/install -c .libs/osmo-stp /home/osmocom-build/osmo-ci/coverity/install-Osmocom/bin/osmo-stp make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/stp' Making install in doc make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' Making install in examples make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/doc/libosmo-sccp/examples/osmo-stp' /usr/bin/install -c -m 644 osmo-stp.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/share/doc/libosmo-sccp/examples/osmo-stp' /bin/mkdir -p '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' /usr/bin/install -c -m 644 osmo-stp.cfg '/home/osmocom-build/osmo-ci/coverity/install-Osmocom/etc/osmocom' make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc/examples' make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/doc' Making install in contrib make[2]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib' Making install in systemd make[3]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' make[4]: Entering directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' make[4]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/lib/systemd/system' /usr/bin/install -c -m 644 osmo-stp.service '/lib/systemd/system' /usr/bin/install: cannot create regular file '/lib/systemd/system/osmo-stp.service': Permission denied Makefile:328: recipe for target 'install-systemdsystemunitDATA' failed make[4]: *** [install-systemdsystemunitDATA] Error 1 make[4]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' Makefile:398: recipe for target 'install-am' failed make[3]: *** [install-am] Error 2 make[3]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib/systemd' Makefile:362: recipe for target 'install-recursive' failed make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp/contrib' Makefile:489: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/home/osmocom-build/osmo-ci/coverity/source-Osmocom/libosmo-sccp' Makefile:788: recipe for target 'install' failed make: *** [install] Error 2 [WARNING] Build command ./build_Osmocom.sh exited with code 2. Please verify that the build completed successfully. Emitted 431 C/C++ compilation units (100%) successfully 431 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 jenkins at lists.osmocom.org Tue Sep 18 15:23:29 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Tue, 18 Sep 2018 15:23:29 +0000 (UTC) Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #235 In-Reply-To: <737381497.164.1537275796105.JavaMail.jenkins@jenkins.osmocom.org> References: <737381497.164.1537275796105.JavaMail.jenkins@jenkins.osmocom.org> Message-ID: <89362461.167.1537284209450.JavaMail.jenkins@jenkins.osmocom.org> See ------------------------------------------ [...truncated 1.29 MB...] make[4]: Leaving directory ' Making all in x86 make[4]: Entering directory ' CC convert.lo CC convolve.lo CC libarch_sse_3_la-convert_sse_3.lo CC libarch_sse_3_la-convolve_sse_3.lo CC libarch_sse_4_1_la-convert_sse_4_1.lo CCLD libarch_sse_4_1.la ar: `u' modifier ignored since `D' is the default (see `U') CCLD libarch_sse_3.la ar: `u' modifier ignored since `D' is the default (see `U') CCLD libarch.la ar: `u' modifier ignored since `D' is the default (see `U') make[4]: Leaving directory ' make[4]: Entering directory ' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory ' make[3]: Leaving directory ' Making all in device make[3]: Entering directory ' Making all in uhd make[4]: Entering directory ' CXX UHDDevice.lo CXXLD libdevice.la ar: `u' modifier ignored since `D' is the default (see `U') make[4]: Leaving directory ' make[4]: Entering directory ' make[4]: Nothing to be done for 'all-am'. make[4]: Leaving directory ' make[3]: Leaving directory ' make[3]: Entering directory ' CXX radioInterface.lo CXX sigProcLib.lo CXX signalVector.lo CXX radioClock.lo CXX radioVector.lo CXX radioBuffer.lo CXX ChannelizerBase.lo CXX Transceiver.lo CXX Channelizer.lo CXX Synthesis.lo CXX Resampler.lo CXX radioInterfaceResamp.lo CXX radioInterfaceMulti.lo CXX osmo_trx_uhd-osmo-trx.o CXXLD libtransceiver_common.la ar: `u' modifier ignored since `D' is the default (see `U') CXXLD osmo-trx-uhd make[3]: Leaving directory ' make[2]: Leaving directory ' Making all in contrib make[2]: Entering directory ' Making all in systemd make[3]: Entering directory ' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory ' make[2]: Leaving directory ' Making all in tests make[2]: Entering directory ' Making all in CommonLibs make[3]: Entering directory ' CXX SocketsTest.o CXX InterthreadTest.o CXX TimevalTest.o CXX PRBSTest.o CXX BitVectorTest.o CXX VectorTest.o CXX LogTest.o CXXLD VectorTest CXXLD LogTest CXXLD SocketsTest CXXLD PRBSTest CXXLD TimevalTest CXXLD BitVectorTest CXXLD InterthreadTest make[3]: Leaving directory ' Making all in Transceiver52M make[3]: Entering directory ' CC convolve_test-convolve_test.o CCLD convolve_test make[3]: Leaving directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'all-am'. make[3]: Leaving directory ' make[2]: Leaving directory ' make[2]: Entering directory ' make[2]: Leaving directory ' make[1]: Leaving directory ' + make install Making install in doc make[1]: Entering directory ' Making install in examples make[2]: Entering directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p ' /usr/bin/install -c -m 644 osmo-trx-uhd/osmo-trx-uhd.cfg ' make install-data-hook make[4]: Entering directory ' for f in $(find . -type f -name '*.cfg*' | sed -e 's,^.,,'); do \ j=" && \ mkdir -p "$(dirname $j)" && \ /usr/bin/install -c -m 644 ./$f $j; \ done make[4]: Leaving directory ' make[3]: Leaving directory ' make[2]: Leaving directory ' make[2]: Entering directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory ' make[2]: Leaving directory ' make[1]: Leaving directory ' Making install in CommonLibs make[1]: Entering directory ' make[2]: Entering directory ' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory ' make[1]: Leaving directory ' Making install in GSM make[1]: Entering directory ' make[2]: Entering directory ' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory ' make[1]: Leaving directory ' Making install in Transceiver52M make[1]: Entering directory ' Making install in arch make[2]: Entering directory ' Making install in common make[3]: Entering directory ' make[4]: Entering directory ' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory ' make[3]: Leaving directory ' Making install in x86 make[3]: Entering directory ' make[4]: Entering directory ' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory ' make[3]: Leaving directory ' make[3]: Entering directory ' make[4]: Entering directory ' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory ' make[3]: Leaving directory ' make[2]: Leaving directory ' Making install in device make[2]: Entering directory ' Making install in uhd make[3]: Entering directory ' make[4]: Entering directory ' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory ' make[3]: Leaving directory ' make[3]: Entering directory ' make[4]: Entering directory ' make[4]: Nothing to be done for 'install-exec-am'. make[4]: Nothing to be done for 'install-data-am'. make[4]: Leaving directory ' make[3]: Leaving directory ' make[2]: Leaving directory ' make[2]: Entering directory ' make[3]: Entering directory ' /bin/mkdir -p ' /bin/bash ../libtool --mode=install /usr/bin/install -c osmo-trx-uhd ' libtool: install: /usr/bin/install -c osmo-trx-uhd /bin/mkdir -p ' /usr/bin/install -c -m 644 std_inband.rbf ' /bin/mkdir -p ' /usr/bin/install -c -m 644 std_inband.rbf ' make[3]: Leaving directory ' make[2]: Leaving directory ' make[1]: Leaving directory ' Making install in contrib make[1]: Entering directory ' Making install in systemd make[2]: Entering directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'install-exec-am'. /bin/mkdir -p '/tmp/' /usr/bin/install -c -m 644 osmo-trx-uhd.service '/tmp/' make[3]: Leaving directory ' make[2]: Leaving directory ' make[2]: Entering directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory ' make[2]: Leaving directory ' make[1]: Leaving directory ' Making install in tests make[1]: Entering directory ' Making install in CommonLibs make[2]: Entering directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory ' make[2]: Leaving directory ' Making install in Transceiver52M make[2]: Entering directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory ' make[2]: Leaving directory ' make[2]: Entering directory ' make[3]: Entering directory ' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory ' make[2]: Leaving directory ' make[1]: Leaving directory ' make[1]: Entering directory ' make[2]: Entering directory ' make[2]: Nothing to be done for 'install-exec-am'. make[2]: Nothing to be done for 'install-data-am'. make[2]: Leaving directory ' make[1]: Leaving directory ' + popd ~/jenkins/workspace/osmocom-coverity/coverity/source-Osmocom Emitted 2317 C/C++ compilation units (100%) successfully 2317 C/C++ compilation units (100%) are ready for analysis The cov-build utility completed successfully. + cd + rm -f Osmocom.tgz + tar czf Osmocom.tgz cov-int + set +x curl \ --form token="$token" \ --form email=holger at freyther.de --form file=@Osmocom.tgz \ --form version=Version --form description=AutoUpload \ https://scan.coverity.com/builds?project=Osmocom grep: : No such file or directory TOKEN IS EMPTY Build step 'Execute shell' marked build as failure From laforge at gnumonks.org Tue Sep 18 20:03:07 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 18 Sep 2018 22:03:07 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: References: <20180909155808.GC2799@nataraja> <20180916195156.GR6125@nataraja> <20180917093021.GH6125@nataraja> Message-ID: <20180918200307.GH30506@nataraja> Hi Lorenzo, On Tue, Sep 18, 2018 at 11:30:58AM +0200, Lorenzo Cavallini wrote: > I've seen the latest commits and tested them. I can confirm that now SMSCBs > are working in the CCCH+SDCCH4+CBCH configuration, great! > however the funny part is they're working on my extremely old, pre-iPhone era Samsung mobile > phone, where I can receive the smscb message. FYI, even the (to me hyper-modern) Samsung Galaxy S5 decodes the messages here. I mostly work with >= 10 year old feature phones during development, as their UI is inside the baseband processor and closer to what happens on the GSM protocol side than all the smartphones that go via AT-commands or QMI. > Anyway, the location update procedure is > successfully completed in all three phones I've tested. that's great and confirms the related bug is fixed. > I'll do other tests meanwhile and try to understand why they're not being > displayed by "modern" phones, most likely they're being blocked in the > baseband before reaching Android/iOS. I'm not sure why that is. One thing to try is to use CBCH on SDCCH/8, and also to ensure that those very same phones with their firmware/software and configuration will show SMSCB on other/production GSM networks (in 2G-only mode!!). The OsmoBTS implementation of CBCH is very conservative. * it doesn't use the optional DRX cycle * it doesn't use the optional extended CBCH * it definitely sends the blocks at the right time in the multiplex as per TS 05.02, I verified this several times The only things that I can imagine to still go wrong is message encoding, including padding (see below) > I can see some garbage text on my old Samsung, so it might be some issues > with encoding. The padding is IMHO not really fully specified. I read all relevant specs several times, and I understand there is some 7-bit-GSM-alphabet-CR used. However, the padding is specified primarily for SMS (point-to-point), and then slightly adjusted for USSD, only to then be referred that SMSCB/CBCH should also use that padding. The difference is that SMS-PP and USSD work inside LAPDm, so you do have a "length" field in a L2 header which tells you how many bytes L3 payload there are. Inside that L3 payload you need to pad using the "CR" rules, but outside the L2/LAPDm will pad with the usua 0x2B pattern. In CBCH however, you have no L2/LAPDm, but always a fixed-length frame of 88 bytes, split into four chunks of 22 bytes (each with a one-byte header as per TS 04.12). If somebody has references or sample traces that show how SMSCB is padded in the real world out there, we can try to mimic that. -- - 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 Wed Sep 19 10:28:59 2018 From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org) Date: Wed, 19 Sep 2018 10:28:59 +0000 (UTC) Subject: Jenkins build is back to normal : Coverity-Upload (jenkins-job-builder) #240 Message-ID: <1087865496.175.1537352939382.JavaMail.jenkins@jenkins.osmocom.org> See From lorenzo.cavallini at gmail.com Wed Sep 19 11:40:21 2018 From: lorenzo.cavallini at gmail.com (Lorenzo Cavallini) Date: Wed, 19 Sep 2018 13:40:21 +0200 Subject: CBCH support for osmo-bts-trx In-Reply-To: <20180918200307.GH30506@nataraja> References: <20180909155808.GC2799@nataraja> <20180916195156.GR6125@nataraja> <20180917093021.GH6125@nataraja> <20180918200307.GH30506@nataraja> Message-ID: Hi, On Tue, Sep 18, 2018 at 10:10 PM Harald Welte wrote: > Hi Lorenzo, > > FYI, even the (to me hyper-modern) Samsung Galaxy S5 decodes the messages > here. > I mostly work with >= 10 year old feature phones during development, as > their UI > is inside the baseband processor and closer to what happens on the GSM > protocol side > than all the smartphones that go via AT-commands or QMI. > I think the main issue is that Samsung switched baseband after the S5. I tested just now on the S7 and it's not working. > > Anyway, the location update procedure is > > successfully completed in all three phones I've tested. > > that's great and confirms the related bug is fixed. > You can add iPhone7 and Galaxy S7 to the list of phones that can successfully complete the location update procedure, with the SDCCH4+CBCH configuration. On the other hand, on a very old Huawei LUA-L21 I'm not even able to receive the BCCH, my cell is not present in the list. I'm not 100% sure that's related to osmocom stack here, this phone is in a really bad shape overall, but it works without CBCH. > I'm not sure why that is. One thing to try is to use CBCH on SDCCH/8, and > also > to ensure that those very same phones with their firmware/software and > configuration > will show SMSCB on other/production GSM networks (in 2G-only mode!!). > I'm pretty much sure that my iPhone8, Honor 9 and Galaxy S7 can receive broadcast notifications, because I get them during network tests for floods and other calamities in my country. However, I never checked if they're delivered through Paging Type 1 rest octets or through SMSCB, so this might make a difference. And to be honest I don't remember if I was in 2G only mode or not, but they test them once per month, so in about 2 weeks I can check this :) The OsmoBTS implementation of CBCH is very conservative. > * it doesn't use the optional DRX cycle > * it doesn't use the optional extended CBCH > * it definitely sends the blocks at the right time in the multiplex as per > TS 05.02, > I verified this several times > I'm going to retest all my mobile phones with the SDCCH8+CBCH configuration and see if this makes a difference. I will let you know. Unfortunately I don't have any pre-iPhone era phones that still work beside my Samsung, so I cannot test anything else for a "positive" result. Thanks! Regards, Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From domi at tomcsanyi.net Wed Sep 19 16:54:16 2018 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Wed, 19 Sep 2018 18:54:16 +0200 (CEST) Subject: CBCH support for osmo-bts-trx In-Reply-To: References: <20180909155808.GC2799@nataraja> <20180916195156.GR6125@nataraja> <20180917093021.GH6125@nataraja> <20180918200307.GH30506@nataraja> Message-ID: Hi Lorenzo, Try, if possible, to put a Qualcomm chipset based phone with some kind of tracing (e.g. Snoopsnitch) under testing. It might yield some results looking into the PCAP file. Wireshark dissectors can help sometimes catching wrongly coded messages - at least they helped me in the past. Good luck! Cheers, Domi 2018. szept. 19. d?tummal, 13:40 id?pontban Lorenzo Cavallini ?rta: > Hi, > >> On Tue, Sep 18, 2018 at 10:10 PM Harald Welte wrote: >> Hi Lorenzo, >> >> FYI, even the (to me hyper-modern) Samsung Galaxy S5 decodes the messages here. >> I mostly work with >= 10 year old feature phones during development, as their UI >> is inside the baseband processor and closer to what happens on the GSM protocol side >> than all the smartphones that go via AT-commands or QMI. > I think the main issue is that Samsung switched baseband after the S5. I tested just now on the S7 and it's not working. > >> > Anyway, the location update procedure is >> > successfully completed in all three phones I've tested. >> >> that's great and confirms the related bug is fixed. > You can add iPhone7 and Galaxy S7 to the list of phones that can successfully complete the location update procedure, with the SDCCH4+CBCH configuration. On the other hand, on a very old Huawei LUA-L21 I'm not even able to receive the BCCH, my cell is not present in the list. I'm not 100% sure that's related to osmocom stack here, this phone is in a really bad shape overall, but it works without CBCH. > >> I'm not sure why that is. One thing to try is to use CBCH on SDCCH/8, and also >> to ensure that those very same phones with their firmware/software and configuration >> will show SMSCB on other/production GSM networks (in 2G-only mode!!). > I'm pretty much sure that my iPhone8, Honor 9 and Galaxy S7 can receive broadcast notifications, because I get them during network tests for floods and other calamities in my country. However, I never checked if they're delivered through Paging Type 1 rest octets or through SMSCB, so this might make a difference. And to be honest I don't remember if I was in 2G only mode or not, but they test them once per month, so in about 2 weeks I can check this :) > >> The OsmoBTS implementation of CBCH is very conservative. >> * it doesn't use the optional DRX cycle >> * it doesn't use the optional extended CBCH >> * it definitely sends the blocks at the right time in the multiplex as per TS 05.02, >> I verified this several times > I'm going to retest all my mobile phones with the SDCCH8+CBCH configuration and see if this makes a difference. I will let you know. > Unfortunately I don't have any pre-iPhone era phones that still work beside my Samsung, so I cannot test anything else for a "positive" result. > Thanks! > > Regards, > > Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Wed Sep 19 21:35:08 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 19 Sep 2018 23:35:08 +0200 Subject: CBSP protocol traces wanted / wireshark dissector Message-ID: <20180919213508.GO30506@nataraja> Hi! I recently wrote a wireshark dissector for the CBSP protocol, which is a 3GPP standard for the interface between the Cell Broadcast Centre and the BSC. It's specified in 3GPP TS 48.049 in case you're curious. The dissector can be found at https://code.wireshark.org/review/#/c/29745/ However, I couldn't find any protocol traces to verify the dissector against. So if you happen to have done any work on cell broadcast in 2G network and have a CBSP trace around (or can generate one): Please send it to me, thanks! If I ever find the time, I'd love to add CBSP support to OsmoBSC, and even to go one step further and write a minimal CBC itself. Contributions are of course always welcome, in case there are other interested folks. 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 Sun Sep 23 14:12:11 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 23 Sep 2018 16:12:11 +0200 Subject: Build failure of network:osmocom:nightly/simtrace2 in xUbuntu_18.04/x86_64 In-Reply-To: <5ba69fb165c31_3a78fa468c542482@build.opensuse.org> References: <5ba69fb165c31_3a78fa468c542482@build.opensuse.org> Message-ID: <20180923141211.GA9186@my.box> These build failures are continuously piling up in my inbox. Would it make sense to either fix or disable it? ~N On Sat, Sep 22, 2018 at 08:01:31PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/simtrace2/xUbuntu_18.04/x86_64 > > Package network:osmocom:nightly/simtrace2 failed to build in xUbuntu_18.04/x86_64 > > Check out the package for editing: > osc checkout network:osmocom:nightly simtrace2 -------------- 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 Sun Sep 23 15:01:04 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 23 Sep 2018 17:01:04 +0200 Subject: Build failure of network:osmocom:nightly/simtrace2 in xUbuntu_18.04/x86_64 In-Reply-To: <20180923141211.GA9186@my.box> References: <5ba69fb165c31_3a78fa468c542482@build.opensuse.org> <20180923141211.GA9186@my.box> Message-ID: <20180923150104.GJ7756@nataraja> Hi Neels, On Sun, Sep 23, 2018 at 04:12:11PM +0200, Neels Hofmeyr wrote: > These build failures are continuously piling up in my inbox. Welcome to the club. > Would it make sense to either fix or disable it? The problem is that the person (likely) responsible for the commit breaking the build has been on holidays for two weeks and hence (understandably) not responding my related e-mail. commit faf1e88e48c216456bdea6060a623b7c31f07c70 is likely the cause of this, as it introduced the use of pkg-config for libpcsc-lite. [ 131s] Package libpcsclite was not found in the pkg-config search path. I guess the only solution to this kind of problem is to ensure nobody pushes/submits any patches immediately before any [scheduled] period of absence. It can happen to any of us. -- - 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 Sep 24 14:43:32 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 24 Sep 2018 16:43:32 +0200 Subject: Build failure of network:osmocom:nightly/simtrace2 in xUbuntu_18.04/x86_64 In-Reply-To: <20180923150104.GJ7756@nataraja> References: <5ba69fb165c31_3a78fa468c542482@build.opensuse.org> <20180923141211.GA9186@my.box> <20180923150104.GJ7756@nataraja> Message-ID: <20180924144332.qjshjxob224hsb4l@ass40.sysmocom.de> On Sun, Sep 23, 2018 at 05:01:04PM +0200, Harald Welte wrote: > I guess the only solution to this kind of problem is to ensure nobody pushes/submits > any patches immediately before any [scheduled] period of absence. You mean like me merging the refactoring code bomb of osmo-bsc the day before going on three weeks of summer vacation? ;) (I'm quite proud/surprised that the fallout from that was so limited.) ~N -------------- 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 Sep 25 09:28:40 2018 From: pmaier at sysmocom.de (Philipp Maier) Date: Tue, 25 Sep 2018 11:28:40 +0200 Subject: Trace needed: AMR voice call signalling on SCCP in AoIP network Message-ID: <3ff2229d-122e-c106-fd9c-7d97d5182e6c@sysmocom.de> Hello Folks, I am trying to resolve some open questions about the encoding of the AMR codec configuration bits S0-S15. (see also 3GPP TS 48.008, 3.2.2.103, "The coding of Speech Codec Element for FR_AMR, HR_AMR and OHR_AMR:" and 3GPP TS 28.062, Table 7.11.3.1.3-2) Since I do not have any AoIP network that I could trace against to verify that all my assumptions about the coding of those bits are correct I would love to see a trace from some other network. It would be kind if anyone of you could help me out with that. All I need is a trace from a call. It is important that AMR is negotiated in the Assignment request. best regards, Philipp Maier -- 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