From nhofmeyr at sysmocom.de Mon Apr 1 19:38:18 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 1 Apr 2019 21:38:18 +0200 Subject: GSUP routing for different kinds of entities In-Reply-To: References: <20190317230004.GA25662@my.box> <20190321013608.GE27744@my.box> <20190328161447.GB7022@my.box> Message-ID: <20190401193818.GB3158@my.box> > What if inter-MSC handover happens during an active USSD session > before the HLR (or any other 'dst_entity') responds to USSD? That's no problem. The MSC-A never changes and always remains in charge, the only difference is that before the DTAP messaging reaches the BSC and MS, it first gets "tunneled" via GSUP and the remote MSC, which merely acts as a proxy for the remote BSC. So it is identical to an intra- or an inter-BSC handover happening in the middle of a USSD session: the DTAP remains transparent between the unchanged MSC-A and the MS, the MS has merely hopped onto a different route for DTAP. > 3. OsmoHLR receives that USSD request, and checks the routing > configuration. By default, *#100# is handled by IUSE called > 'own_msisdn', so the HLR terminates request and responds > back to OsmoMSC. Interesting to note / thanks for pointing out that a USSD request should still be directed at the vlr first. This complicates my idea of "Entity" a bit. To cut a long story short, I wrote a bunch of responses while completely re-thinking my idea while I wrote. The result of this is a long mail and this conclusion: I will add only a GSUP message kind IEI, which indicates the GSUP subsystem and allows demuxing GSUP messages without switch(msg_type)ing, and I will *not* name the source/destination entity at all. enum osmo_gsup_kind { OSMO_GSUP_KIND_SUBSCRIBER_MANAGEMENT, /* VLR <-> HLR, D-interface for accessing HLR/HSS data */ OSMO_GSUP_KIND_SMS, /* MSC <-> SMSC */ OSMO_GSUP_KIND_USSD, /* MSC <-> { VLR <-> HLR } <-> EUSE */ OSMO_GSUP_KIND_INTER_MSC /* MSC-A <--> MSC-{T,I}, E-interface for inter-MSC Handover */ }; With this, I can still figure out whether responses like a GSUP routing error are related to inter-MSC or not, while GSUP->MAP->GSUP conversion remains "trivial", and USSD routing remains implicit without naming each hop. That is the conclusion I reach below, and you don't really need to read the rest of this mail, unless anyone wants to follow my reasoning of how I ended up at that conclusion... Thanks for your valuable input, Vadim! ~N ~ + ~ + ~ (long reasoning for above choice follows...) On Sat, Mar 30, 2019 at 08:20:49PM +0700, Vadim Yanitskiy wrote: > b) a bit more elegant: use entity type of the next > component until the USSD request is terminated; [..] > I prefer this approach. What do you think? I agree. > 1. Some MS / UE initiates USSD request *#100#, and we receive > it at MSC. Since our OsmoMSC doesn't handle USSD requests > itself (commercial ones do), it forwards to the VLR: > > OSMO_GSUP_ENTITY_MSC_USSD -> OSMO_GSUP_ENTITY_VLR, Only, this would not end up being an OSMO_GSUP_ENTITY_VLR, because we're not sending a GSUP message to the VLR. Once it goes out past the VLR we get: > OSMO_GSUP_ENTITY_MSC_USSD -> OSMO_GSUP_ENTITY_HLR I would then actually also introduce OSMO_GSUP_ENTITY_HLR_USSD. My idea there still is to separate the kinds of message to avoid demuxing by message type. But .. see below > 3. OsmoHLR receives that USSD request, and checks the routing > configuration. By default, *#100# is handled by IUSE called > 'own_msisdn', so the HLR terminates request and responds > back to OsmoMSC. > > OSMO_GSUP_ENTITY_MSC_USSD <- OSMO_GSUP_ENTITY_HLR Ok, so, on the return path, we don't do all the hops MSC_USSD<-VLR<-HLR<-EUSE anymore, but the response in all cases goes directly to MSC_USSD, right? Makes sense. But. Maybe my idea of combining the message kind and the source/target entity is a bit clumsy. Now I am thinking it would make more sense to indicate the subsystem separately from the source and target entities: enum osmo_gsup_kind { OSMO_GSUP_KIND_SUBSCRIBER_MANAGEMENT, /* VLR <-> HLR, D-interface for accessing HLR/HSS data */ OSMO_GSUP_KIND_SMS, /* MSC <-> SMSC */ OSMO_GSUP_KIND_USSD, /* MSC <-> { VLR <-> HLR } <-> EUSE */ OSMO_GSUP_KIND_INTER_MSC /* MSC-A <--> MSC-{T,I}, E-interface for inter-MSC Handover */ }; enum osmo_gsup_entity { OSMO_GSUP_ENTITY_HLR, OSMO_GSUP_ENTITY_VLR, OSMO_GSUP_ENTITY_MSC_A, OSMO_GSUP_ENTITY_MSC_I, OSMO_GSUP_ENTITY_MSC_T, OSMO_GSUP_ENTITY_SMSC, OSMO_GSUP_ENTITY_EUSE, }; Next, I am reconsidering whether we really need the source and destination entity for any messages other than the E-interface at all. On the E-interface I want to explicitly distinguish between MSC-I and MSC-T. However, it is also a bit questionable how a MAP-to-GSUP converter would figure that out. Has to switch(message_type)... so maybe it's a bad idea to force this decision into a compatibility conversion. For all kinds other than E-interface it would be implicitly clear what the source/target entities are. The benefit of simpler demuxing into VLR/SMS/USSD code paths comes from the message kind, the entity kind adds no value. So I am considering three proposals: a) add an OSMO_GSUP_KIND_IEI with only the message kind (subscriber-management, SMS, USSD, E). Include the _KIND_IEI in all messages. b) Add a), and also add a separate OSMO_GSUP_ENTITY_IEI for source and dest entity (MSC-A, VLR, HLR, ...). Include the _KIND_IEI in all messages, but include the _ENTITY_IEI only for E-interface messages. c) add one OSMO_GSUP_ROUTING_IEI with all of kind, source and destination entity in a single information element. My first intuition was to go with c), but we would probably ignore the entity information for all but the inter-MSC messages. The second intuition is b), but when I consider that the entity info would be lost in a GSUP -> MAP -> GSUP conversion, I end up realizing that I should rather figure out MSC-T or MSC-I from the inter-MSC message kind and MSC state. So now I end up at a) -- only add a GSUP message kind IEI, which indicates the GSUP subsystem and allows demuxing GSUP messages without switch(msg_type)ing. Then we also don't need to figure out the next hop as in HLR or EUSE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From hwelte at sysmocom.de Wed Apr 3 17:15:39 2019 From: hwelte at sysmocom.de (Harald Welte) Date: Wed, 3 Apr 2019 19:15:39 +0200 Subject: docker build slaves / docker in lxc Message-ID: <20190403171539.GI22137@nataraja> Hi all, we just ran out of storage on one of our build slaves. /var/lib/docker inside the debian9 lxc had grown to 240 GB while actually it should be much smaller. "docker system prune" helped to freee 35GB of build cache, but still the remaining 217 GB was way too much compared to what it should use as per "docker system df -v" - and also much more than other build slaves were using (~ 13GB) It turned out that the files were in /var/lib/docker/vfs, and as I didn't see that yet on other systems, I investigated: * if the physical host hosting the lxc container doesn't have 'overlay.ko' loaded, overlay/overlay2 storage drivers are not available to docker * docker "silently" falls back to using "vfs" which is basically not copy-on-write but copy-everything-all-the-time, and which consumes massive amounts of storage I now made sure build2.osmocom.org loads "overlay.ko" by default and I changed the storage driver on the debian9 lxc. This however means you loos all containers/images, and everything has to be rebuilt from scratch. How to test: $ docker info | grep Storage should render Storage Driver: overlay2 If it shows vfs, something is wrong. I checked our other build slaves and they're set up correctly. Regards, Harald -- - Harald Welte http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From axilirator at gmail.com Sat Apr 6 19:46:50 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 7 Apr 2019 02:46:50 +0700 Subject: pySIM: hard-coded test expectations Message-ID: Hi all, I would like to get https://gerrit.osmocom.org/#/c/pysim/+/11491/ merged. Unfortunately, Jenkins always says no (V-1), because the expected test output is hard-coded somewhere on 'symtester' host. Please see: https://gerrit.osmocom.org/#/c/pysim/+/11491/ https://jenkins.osmocom.org/jenkins/job/gerrit-pysim/71/a1=default,a2=default,a3=default,a4=default,label=simtester/console https://jenkins.osmocom.org/jenkins/computer/simtester/ How can we proceed? As far as I can see, there are some *.ok files. It would (probably) make more sense to make them a part of the public pySym repository... With best regards, Vadim Yanitskiy. From laforge at gnumonks.org Sun Apr 7 08:44:34 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 7 Apr 2019 10:44:34 +0200 Subject: pySIM: hard-coded test expectations In-Reply-To: References: Message-ID: <20190407084434.GI25552@nataraja> hi Vadim, On Sun, Apr 07, 2019 at 02:46:50AM +0700, Vadim Yanitskiy wrote: > I would like to get https://gerrit.osmocom.org/#/c/pysim/+/11491/ > merged. Unfortunately, Jenkins always says no (V-1), because the > expected test output is hard-coded somewhere on 'symtester' host. Philipp would be the person to respond to that. > How can we proceed? As far as I can see, there are some *.ok files. > It would (probably) make more sense to make them a part of > the public pySym repository... If those files are not in the git repository, they should be added. Having test expectations separate from the code makes it impossible to ever merge a change. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Apr 8 06:51:22 2019 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 8 Apr 2019 08:51:22 +0200 Subject: minLatency() in osmo-trx Message-ID: <20190408065122.GP25552@nataraja> Dear all, the following question popped up on IRC: 22:08 < roh> is there some documentation how the minLatency() call in osmo-trx works? 22:10 < roh> it looks to me like the values we use for usrp1 and lms are not correct/cargocult I agree, the values are likely wrong for the non-UHD devices. Interestingly, they are auto-tuned at runtime, see the following piece in Transceiver.cpp: // if underrun hasn't occurred in the last sec (216 frames) drop // transmit latency by a timeslot if (mTransmitLatency > mRadioInterface->minLatency()) { if (radioClock->get() > mLatencyUpdateTime + GSM::Time(216,0)) { mTransmitLatency.decTN(); LOG(INFO) << "reduced latency: " << mTransmitLatency; mLatencyUpdateTime = radioClock->get(); } } However, that block only applies to devices with TX_WINDOW_USRP1 set, that is USRP1, B100 and B2xx devices. In fact, I cannot find any user of the minLatency() method outside the context of TX_WINDOW_USRP1, and hence I think it doesn't matter what kind of magic value the LMS driver supplies? So at least I conclude: * it's only ever used on USRP1, B100 and B2xx, and it is dynamically adjusted at runtime on those platforms Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pespin at sysmocom.de Mon Apr 8 09:01:02 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 8 Apr 2019 11:01:02 +0200 Subject: minLatency() in osmo-trx In-Reply-To: <20190408065122.GP25552@nataraja> References: <20190408065122.GP25552@nataraja> Message-ID: <6a7da06a-07be-616c-d0c3-322b265fdeb7@sysmocom.de> Hi, Agree minLatency is only used for TX_WINDOW_USRP1, and doesn't apply at all for osmo-trx-lms. I think it makes sense to drop the magic value in LMSDevice.cpp and return 0 with a comment stating it is not being used. -- - 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 snehasish.cse at LIVE.COM Mon Apr 8 13:35:43 2019 From: snehasish.cse at LIVE.COM (Snehasish Kar) Date: Mon, 8 Apr 2019 13:35:43 +0000 Subject: Phones not registering on network Message-ID: Hello I am trying to use openbsc with usrp x310. I have configured and executed osmo-trx from( https://github.com/osmocom/osmo-trx) and osmo-bts(https://github.com/osmocom/osmo-bts) and I can see the network on my phone but can't register to it, though I have set auth policy to accept-all. I have attached attached my config files for reference. BR Snehasish -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-trx.cfg Type: application/octet-stream Size: 313 bytes Desc: osmo-trx.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-bts-trx.cfg Type: application/octet-stream Size: 596 bytes Desc: osmo-bts-trx.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openbsc.cfg Type: application/octet-stream Size: 1498 bytes Desc: openbsc.cfg URL: From pespin at sysmocom.de Tue Apr 9 09:20:38 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 9 Apr 2019 11:20:38 +0200 Subject: Phones not registering on network In-Reply-To: References: Message-ID: Hi, which hardware are you using under osmo-trx? -- - 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 Tue Apr 9 09:25:22 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 9 Apr 2019 11:25:22 +0200 Subject: Phones not registering on network In-Reply-To: References: Message-ID: <0039b546-c242-b0cf-bc13-2372670ae169@sysmocom.de> Ah sorry, I read to fast, usrp x310 :) I never used that one personally. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Tue Apr 9 11:35:27 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 9 Apr 2019 13:35:27 +0200 Subject: Phones not registering on network In-Reply-To: References: Message-ID: <20190409113527.GD25552@nataraja> Hi Snehasish, On Mon, Apr 08, 2019 at 01:35:43PM +0000, Snehasish Kar wrote: > I am trying to use openbsc with usrp x310. I have configured and executed osmo-trx from( https://github.com/osmocom/osmo-trx) and osmo-bts(https://github.com/osmocom/osmo-bts) and I can see the network on my phone but can't register to it, though I have set auth policy to accept-all. I have attached attached my config files for reference. it would be quite useful if you could generate pcap files of the relevant interfaces, .e.g. in particular the Abis RSL (tcp port 3003) interface. Please also note you appear to be using openbsc (OsmoNITB) which is no longer supported for about two years now. Nevertheless, at least network registration should for sure work. 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 vvvelichkov at gmail.com Tue Apr 9 12:49:36 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Tue, 9 Apr 2019 15:49:36 +0300 Subject: Code coverage reports in Jenkins In-Reply-To: <5cac3c85.1c69fb81.d240a.b479SMTPIN_ADDED_MISSING@mx.google.com> References: <5cac3c85.1c69fb81.d240a.b479SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <1c6e6f97-4ffa-b5d7-0d63-1caad03b6cb9@gmail.com> Hi Harald, Everyone, On 09/04/2019 09.32, Harald Welte wrote: > could you outline somewhere (mailinglist? maybe a wiki page?) how this > would work together? I've started adding code coverage support in changes 13496 and 13551 for OS#1987. Initially my goal was to generate reports only manually using gcov and lcov tools but after submitting my first change to gerrit I've noticed that Jenkins is used for CI/CD so I thought that it might be useful to generate these reports as part of the CI process. Jenkins has a Cobertura plugin [3] which collects coverage data in XML format [4], visualize them and track coverage metrics over time/builds. I've used lcov_cobertura tool to convert the lcov's coverage format to XML. > This Dockerfile which you're patching is used for build verification > of gerrit patches. Do you want to run coverage reports on every build > of every patch before commit? Yes, that was my idea. Other projects that I've used or contributed to in the past are using a workflow where code coverage data is generated in every CI build, then send to a coverage service, which analyze them and post message back in the PR about the coverage results - whether the coverage has increased, decrease, diff between reports, etc...?? For example see [1], [2], [5], [6] > I would argue it makes more sense to have coverage reports done once > per day? > In my opinion the coverage reports are more useful when they are closely integrated into the code review process and you receive information how coverage has changed together with the build status in the code review system. When reviewing a change the report could gives you more insights but still you should be able to merge it no matter what the coverage report says. If you find these reports not very useful during the code review process or the changes too disruptive to your workflow then we could build them once per day in the Osmocom_OBS_nightly (or another) job or not build them at all in the CI. BTW I just noticed that libosmocore is not built in the docker containers. Regards, Vasil [1] https://coveralls.io/github/neovim/neovim [2] https://codecov.io/gh/scrapy/scrapy [3] https://wiki.jenkins.io/display/JENKINS/Cobertura+Plugin [4] https://docs.openstack.org/infra/jenkins-job-builder/publishers.html#publishers.cobertura [5] https://github.com/vlm/asn1c/pull/295#issuecomment-420464856 [6] https://github.com/mouse07410/asn1c/pull/22#issuecomment-298964785 -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith at rhizomatica.org Tue Apr 9 21:32:49 2019 From: keith at rhizomatica.org (Keith) Date: Tue, 9 Apr 2019 23:32:49 +0200 Subject: Phones not registering on network In-Reply-To: References: Message-ID: <3ed17cac-9a22-1a62-0fad-873c061b6142@rhizomatica.org> On 08/04/2019 15:35, Snehasish Kar wrote: > Hello > > I am trying to use openbsc with usrp x310. I have configured and > executed osmo-trx from( https://github.com/osmocom/osmo-trx > ) and > osmo-bts(https://github.com/osmocom/osmo-bts) and I can see the > network on my phone but can't register to it, this is very typical behaviour with other Ettus SDR that I have used when the clock is not accurate. do you have the optional internal GPSDO with your x310? If you have the GPSDO, make sure it is locked. If you do not, you may not be able to have a very satisfactory experience unless you can find another stable clock source. What models of phone have you tried? I found some did not care so much about the clock. If no GPSDO, then try putting the phone into manual selection mode, then power cycle close to your Ettus x310 so the phone sees a string signal from it. Quickly manually search for networks and select your network. Watch the osmo-bts (telnet to port 4241) log output (can't remember which log level right now, but even log level all debug should be ok) for any sign of comms from your phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcassinga at gmail.com Mon Apr 8 14:46:07 2019 From: pcassinga at gmail.com (Brackley Casinga) Date: Mon, 8 Apr 2019 16:46:07 +0200 Subject: Problem while running NIB on Open Cellular Base sation Message-ID: Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga at gmail.com/ brackley at ensemblepourladifference.org www.kwantechnologies.jimdosite.com | Skype: Brackley cassinga Av Semliki N 43 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes at sipsolutions.net Tue Apr 9 13:50:45 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Tue, 09 Apr 2019 15:50:45 +0200 Subject: gsmtap design/extensions? Message-ID: Hi, As I'm looking into adding a generic cell modem framework to the linux kernel (to create session netdevs etc.), I started looking for a metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ). So obviously, I found gsmtap, but for my use case it doesn't really address most of the interesting data, and it got me wondering. So a few questions, if I may: 1) Why the design with encapsulating it in UDP? Radiotap is just a raw header without IP etc. in front, and you use it with tcpdump, wireshark or similar tools on the local system. What's the value in having something "network transparent"? 2) The format of gsmtap doesn't seem very extensible, but I guess a new version could be made that has a TLV-based format or so. I'd have argued that a new version isn't even needed, but the length field is only 8 bits right now which seems too short. (speaking of versions - the docs say "version, set to 0x01 currently" but "#define GSMTAP_VERSION 0x02") 3) Does the packet data follow the gsmtap header? It's not really clear to me based on reading the wireshark code. In particular, the data I'm thinking of is higher-level things, like the session ID for a frame when it's going through the kernel, or perhaps a flow label on RX, etc. Also, vendor-specific data would be useful, e.g. to encapsulate the device-specific headers like QMI, where such metadata is encapsulated in a vendor- or device-specific way, which you'd want to see for debugging certain things, but for other things the generic "session ID" type information - encoded in a vendor-agnostic way - would be better to show in wireshark. Since it doesn't seem possible to use gsmtap in the current version, would it make sense to define a new gsmtap that (say) has version 3 or something, followed by an overall length and TLVs? I do note that this wouldn't be compatible with the current wireshark code as it doesn't check the version, just shows it... Or would it make more sense to define a new ARPHDR_WWANTAP like ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in IP/UDP, and then have a completely new (extensible) protocol inside of that? I'm not really sure I see the point of UDP encapsulation anyway. Thanks, johannes From snehasish.cse at live.com Tue Apr 9 13:00:33 2019 From: snehasish.cse at live.com (Snehasish Kar) Date: Tue, 9 Apr 2019 13:00:33 +0000 Subject: Phones not registering on network In-Reply-To: <20190409113527.GD25552@nataraja> References: , <20190409113527.GD25552@nataraja> Message-ID: Hello Harald Thanks for your Response!!! Since there was clipping happening on Osmo-trx, I was not able to connect. Changing the gain helped. Regards ________________________________ From: Harald Welte Sent: Tuesday, April 9, 2019 5:05 PM To: Snehasish Kar Cc: openbsc at lists.osmocom.org Subject: Re: Phones not registering on network Hi Snehasish, On Mon, Apr 08, 2019 at 01:35:43PM +0000, Snehasish Kar wrote: > I am trying to use openbsc with usrp x310. I have configured and executed osmo-trx from( https://github.com/osmocom/osmo-trx) and osmo-bts(https://github.com/osmocom/osmo-bts) and I can see the network on my phone but can't register to it, though I have set auth policy to accept-all. I have attached attached my config files for reference. it would be quite useful if you could generate pcap files of the relevant interfaces, .e.g. in particular the Abis RSL (tcp port 3003) interface. Please also note you appear to be using openbsc (OsmoNITB) which is no longer supported for about two years now. Nevertheless, at least network registration should for sure work. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Wed Apr 10 06:35:52 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 10 Apr 2019 13:35:52 +0700 Subject: gsmtap design/extensions? In-Reply-To: References: Message-ID: Hello Johannes, FYI, there already was a discussion about GSMTAPv3: https://www.youtube.com/watch?v=vum9jzavZi0&list=PL07C78AF831FFE8F9&index=10 but unfortunately, nobody has invested time into this (yet?). > 1) Why the design with encapsulating it in UDP? This gives us a possibility to "demux" multiple GSMTAP streams on the receiving side, e.g. if you are running multiple processes. > 2) The format of gsmtap doesn't seem very extensible [...] ACK. I definitely support the idea of using TLVs. With best regards, Vadim Yanitskiy. From johannes at sipsolutions.net Wed Apr 10 07:23:13 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Wed, 10 Apr 2019 09:23:13 +0200 Subject: gsmtap design/extensions? In-Reply-To: (sfid-20190410_083605_324978_F3549EC8) References: (sfid-20190410_083605_324978_F3549EC8) Message-ID: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> On Wed, 2019-04-10 at 13:35 +0700, Vadim Yanitskiy wrote: > Hello Johannes, > > FYI, there already was a discussion about GSMTAPv3: > > https://www.youtube.com/watch?v=vum9jzavZi0&list=PL07C78AF831FFE8F9&index=10 > > but unfortunately, nobody has invested time into this (yet?). 2012! But, umm, I don't really have time for a whole video right now - anyone have the slides? :-) But yeah, the first slides look sensible :-) > > 1) Why the design with encapsulating it in UDP? > > This gives us a possibility to "demux" multiple GSMTAP streams on the > receiving side, e.g. if you are running multiple processes. Not sure I get this, but I also don't really care all that much. It's just a pretty strange design if the kernel were to output this, I'm not even sure how I'd do that properly. I don't want to be generating UDP packets there... Perhaps we can define something (GSMTAPv3) to not really care how it's encapsulated, and for 'native' packet captures like what I want on Linux when integrated with the driver, actually use an ARPHDR_GSMTAP, and encapsulate in UDP when you create it in an application and want to send it elsewhere, rather than just writing it to a pcap file? johannes From marcel at holtmann.org Wed Apr 10 07:57:06 2019 From: marcel at holtmann.org (Marcel Holtmann) Date: Wed, 10 Apr 2019 09:57:06 +0200 Subject: gsmtap design/extensions? In-Reply-To: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> Message-ID: <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org> Hi Johannes, >> FYI, there already was a discussion about GSMTAPv3: >> >> https://www.youtube.com/watch?v=vum9jzavZi0&list=PL07C78AF831FFE8F9&index=10 >> >> but unfortunately, nobody has invested time into this (yet?). > > 2012! But, umm, I don't really have time for a whole video right now - > anyone have the slides? :-) > > But yeah, the first slides look sensible :-) > >>> 1) Why the design with encapsulating it in UDP? >> >> This gives us a possibility to "demux" multiple GSMTAP streams on the >> receiving side, e.g. if you are running multiple processes. > > Not sure I get this, but I also don't really care all that much. It's > just a pretty strange design if the kernel were to output this, I'm not > even sure how I'd do that properly. I don't want to be generating UDP > packets there... > > Perhaps we can define something (GSMTAPv3) to not really care how it's > encapsulated, and for 'native' packet captures like what I want on Linux > when integrated with the driver, actually use an ARPHDR_GSMTAP, and > encapsulate in UDP when you create it in an application and want to send > it elsewhere, rather than just writing it to a pcap file? before you go all out and define this, it would suggest to understand what meta-data for the connection contexts you actually need as well. The data path itself is just a pipe and has not all the information attached with it. That goes via the control path and that is normally in user space and carries the real important information to make useful analysis of how the data path / context is setup. From what I am seeing right now is that unless you have a method to also feed the control path into your GSMTAPv3, then this is rather useless. The majority of the debugging is really done for the control path. For oFono that is OFONO_DEBUG=1 environment variable and while it works it is not the most elegant solution. I would love to feed that into a generic debugging / tap that you can read out later. As a side note, for Bluetooth we created a path where the bluetoothd can feed back its control debugging data back into the Bluetooth monitor in the kernel to allow combined userspace, mgmt and HCI tracing. Some really nasty issues could only be triaged by having all the meta data with a common timestamp. Regards Marcel From laforge at gnumonks.org Wed Apr 10 23:32:13 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Apr 2019 01:32:13 +0200 Subject: gsmtap design/extensions? In-Reply-To: References: Message-ID: <20190410233213.GN25552@nataraja> Hi Johannes, On Tue, Apr 09, 2019 at 03:50:45PM +0200, Johannes Berg wrote: > As I'm looking into adding a generic cell modem framework to the linux > kernel (to create session netdevs etc.), I started looking for a > metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ). Is there any discussion about "session netdevs, etc." anywhere? What exactly do you have in mind for that "generic cell modem framework"? I'm quite curious to learn more about it and happy to provide feedback from the perspective of my cellular protocols/specs/systems knowledge. > So obviously, I found gsmtap, but for my use case it doesn't really > address most of the interesting data, I have no knowledge of your use case, so I don't feel like I can comment on that :/ > 1) Why the design with encapsulating it in UDP? Radiotap is just a raw > header without IP etc. in front, and you use it with tcpdump, > wireshark or similar tools on the local system. What's the value in > having something "network transparent"? GSMTAP was designed as a format to encapsulate protocols normally not spoken over IP (such as classic GSM radio protocols, e.g. the Layer 2 LAPDm over GSM Um) inside an IP transport. The existing implementations of such protocols all live outside of the kernel but in userspace. So you either have a) a pure SDR software implementation of a GSM phy, whether on the MS/UE side or on the BTS/network side, or whether in sniffing mode, running as a userspace process. This could e.g. be airprobe or gr-gsm b) a OsmocomBB phone attached over serial port running the Osmocom Layer1 firmware on the baseband processor, with some userspace program on a Linux PC implementing higher layers c) GSM base station software such as osmo-bts, running in userspace d) Using an old nokia phone attached via serial cable to a Linux PC running dct3-gsmtap. So for any of those, if you want to provide real-time data streams, you have to somehow transmit those over some kind of network technology. One could have done raw ethernet frames or raw IP frames, but using UDP seemed straight-forward as one can create UDP socket from non-privileged processes. We also have a virtual physical layer between OsmocomBB and OsmoBTS called virt_phy where the GSMTAP over multicast IP is used to simulate/virtualize the entire Layer1 / PHY / radio interface between phone and base station. Once again, all related network elements are implemented in userspace, and having an > 2) The format of gsmtap doesn't seem very extensible, but I guess a new > version could be made that has a TLV-based format or so. I'd have > argued that a new version isn't even needed, but the length field is > only 8 bits right now which seems too short. Yes, it's a known problem. The format was originally designed for GSM, that is circuit switched common and dedicated channels on the GSM Um interface. It was later extended for GPRS, TETRA, SIM card protocol traces and many others, but all of that was an afterthought. For sure any future version should be more extensible and e.g. use TLVs > (speaking of versions - the docs say "version, set to 0x01 currently" > but "#define GSMTAP_VERSION 0x02") Sorry, it's the usual "developer changes code but not comment". patches are welcome, we use gerrit.osmocom.org :) > 3) Does the packet data follow the gsmtap header? It's not really clear > to me based on reading the wireshark code. Sure, the packet data follows the GSMTAP header, and the type of data is defined by the GSMTAP type / sub-type as per the specific use case. As you can see, there's 18 TYPE by now (each of which has at least one program/implementation generating the data). I think the best way to learn about GSMTAP is to use any of the many programs that support it by now. I think not only the examples above use it, but meanwhile many others like the independently-developed OpenBTS project that's unrelated to Osmocom, as are other projects implementing LTE. > In particular, the data I'm thinking of is higher-level things, like the > session ID for a frame when it's going through the kernel, or perhaps a > flow label on RX, etc. I'm not quite sure how that relates to GSM? GSMTAP so far was intended to encapsulate ETSI/3GPP messages inside UDP/IP, particularly messages of protocols that don't traditionally are transported over IP baesd transports. Having said, we're open to extending the scope - it just all needs to make sense > Also, vendor-specific data would be useful, e.g. to encapsulate the > device-specific headers like QMI, where such metadata is encapsulated in > a vendor- or device-specific way, which you'd want to see for debugging > certain things, but for other things the generic "session ID" type > information - encoded in a vendor-agnostic way - would be better to show > in wireshark. I'm really not following you here. What's a "session ID"? In terms of vendor-specific encapsulations: We do have a GSMTAP sub-type for Qualcomm DIAG, as well as the osmo-qcdiag program to take DIAG from Qualcomm chips + put it in GSMTAP and I do have plenty of experimental wireshark dissectors for various parts of the DIAG protocl in a branch on git.osmocom.org. This just never went anywhere complete enough that I'd consider merging it. > Since it doesn't seem possible to use gsmtap in the current version, > would it make sense to define a new gsmtap that (say) has version 3 or > something, followed by an overall length and TLVs? By all means. Vadim has once presented some ideas/plans about exactly that at an Osmocom conference, but I don't think any related work ever started. > I do note that this > wouldn't be compatible with the current wireshark code as it doesn't > check the version, just shows it... If that's the case that's sad, and I should have paid more attention to it when originally writing it. We should get a related fix into wireshark ASAP then. But then, the current dissector would just state something like unsupported version instead of showing some garbage it cannot parse. Either way, you will of course need new sources and sink side implemetations. > Or would it make more sense to define a new ARPHDR_WWANTAP like > ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in > IP/UDP, and then have a completely new (extensible) protocol inside of > that? No userspace source would ever be able to generate such data and stream it real-time into wireshark, would it? Sure, I can write pcap file with such ARPHDR_* values, but I could never do this in real-time. For many but not all use cases, that's really what it is: A vehicle to stream real-time non-IP protocol traces into wireshark so it can visualize the protocol traces. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Wed Apr 10 23:45:55 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Apr 2019 01:45:55 +0200 Subject: gsmtap design/extensions? In-Reply-To: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> Message-ID: <20190410234555.GO25552@nataraja> Hi Johannes, On Wed, Apr 10, 2019 at 09:23:13AM +0200, Johannes Berg wrote: > > but unfortunately, nobody has invested time into this (yet?). > > 2012! Well, Osmocom is a very small community, with probably somewhere less than 25 active developers over the last few years (less than 15 full-time), with an *incredibly* large scope: Implement virtually any protocol layer of any protocol stack on any of the 3GPP interfaces and all their related network elements for 2G/3G as well as even other technologies like TETRA, GMR-1, ... And all that in a field of technology that has less free software than the Operating Systems world had in the mid-1990ies. It really feels a bit like the Linux community 20 years ago. So resources are always *extremely* tight, and given those limited resources, I'm actually very happy with the results by now, having automatied CI, build verifications, unit tests, functional test suites, end-to-end testing, and all the code we implemented on git.osmocom.org :) While current GSMTAPv2 is ugly, it works rather solid for all known existing use cases, so there was no urgency to introduce a new version of it. > Not sure I get this, but I also don't really care all that much. Well, with all respect, GSMTAP was created for a variety of use cases, see my other lengthy mail. It's fine if you don't care, but unless you could explain your use cases with a few paragraphs, neither you nor us are able to determine if there is common functionality and if it makes sense to use GSMTAP or not :) So far I have not seen any explanation about what kind of data you want to encapsulate at all. > just a pretty strange design if the kernel were to output this, I'm not > even sure how I'd do that properly. I don't want to be generating UDP > packets there... There are well-established APIs for having sockets in the kernel and for generating + receiving UDP packets from it. NFS has been doing this for decades, as do various kernel-side tunneling helpers including the GTP kernel module. I'm not saying it's the right approach for your problem, I'm just saying kernel-side code can for sure use UDP sockets. > Perhaps we can define something (GSMTAPv3) to not really care how it's > encapsulated, and for 'native' packet captures like what I want on Linux > when integrated with the driver, actually use an ARPHDR_GSMTAP, and > encapsulate in UDP when you create it in an application and want to send > it elsewhere, rather than just writing it to a pcap file? Sure, that works. But the real question is, to me: Are there common GSMTAP payload types that both the existing GSMTAP users carry, as well as what you would want to carry? If yes, then it makes sense to think about a common encapsulation like GSMTAP. If the payload types differ, then it seems rather like there are two distinct use cases that wouldn't benefit from standardizing on one format. 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 Thu Apr 11 01:02:17 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 11 Apr 2019 03:02:17 +0200 Subject: RFC: FSM instance IDs / log context / log filters Message-ID: <20190411010217.GA24482@my.box> This is an idea about logging context, the logging filter and FSM instances. The idea is to make logging context a first-class citizen of osmo_fsm_inst and of LOGP(), in order to get cleaner FSM ids, better configurable logging and a more universal and reliable approach to logging filters. At events like 35c3 I want to, and hence any production operator wants to have useful filters for logging. The attempt with this RFC is to get this in an elegant way that also improves current logging context and saves FSM IDs. == Status quo == - Log filters: Since a long time ago, we have a logging filter mechanism which requires setting a global "context pointer" to some object, for every code path. It is not trivial to use and we mostly neglected using and testing it, so it doesn't work well in practice. See enum log_filter_index, enum log_ctx_index, log_set_context() in libosmocore and the filter_fn() in msc_main.c as an example. - Logging context: For a long time, we added logging context to each and every LOGP() line, like: LOGP(DMSC, LOGL_DEBUG, "(%s %s %d %d) Actual message", subscr->ctx1, osmo_foo_name(subscr->ctx2), trans->ctx3, another->ctx); Since the osmo_fsm_inst showed up, I have more and more used the FSM instance's id as logging context: #define LOG_MY_OBJ(my_obj, loglevel, fmt, args...) \ LOGPFSML(my_obj->fi, loglevel, fmt, ##args) my_obj_update_id(my_obj) { osmo_fsm_inst_update_id_f(my_obj->fi, "%s-%s-%d-%d", my_obj->ctx1, osmo_foo_name(my_obj->ctx2), my_obj->ctx3, my_obj->ctx); } stuff() { LOG_MY_OBJ(my_obj, LOGL_DEBUG, "Actual message"); } The advantages are obvious: - less time spent composing log message context when developing code. - context string is composed only once and re-used, less cpu cycles used to compose. - it is now made hard to forget adding useful log context. But this also has disadvantages: - Long lines Since I want to be able to trace logging output by various items, my logging context has often grown to a size that makes the log uncomfortable to read unless the terminal is really wide. For example, in osmo-msc, the context now often looks like this: DMSC DEBUG msc_a(IMSI-901700000014705:MSISDN-1001:TMSI-0x8D91D71B:GERAN-A-0:LU)[0x61200000b620]{MSC_A_ST_AUTH_CIPH}: Received Event MSC_A_EV_AUTHENTICATED (vlr_lu_fsm.c:741) It includes the IMSI, MSISDN, TMSI, the RAN conn info and the complete-l3 type. An extreme example is DCC DEBUG rtp_stream(IMSI-901700000014705:MSISDN-1001:TMSI-0x8D91D71B:GERAN-A-1:CM_SERVICE_REQ:trans-8:call-2147483649:RTP_TO_RAN:CI-BBBD5102:remote-port-not-sent:codec-not-sent:local-192-168-2-4-42000:remote-192-168-2-3-23004)[0x612000015e20]{ESTABLISHING}: Committing: Tx MDCX to update the MGW: updating remote-RTP-IP-port codec (rtp_stream.c:330) WTF. But of course, for an RTP stream, it is interesting to see what subscriber it is for, but also what callref and CC transaction, also the MGW's endpoint CI, whether it is to RAN or CN, and which RTP address and ports are involved. Now, a log line like this is pretty much guaranteed to be truncated in the display of gsmtap_log in wireshark. Very irritating. We would have to remove select items of logging context from the FSM instance ID to strike a good balance of length and usefulness. Each time we tweak it, all the logging output in test programs changes ... ugh. - Special characters Since an FSM instance can only have a limited set of characters for id, we can't add IP addresses as 1.2.3.4, but need to use 1-2-3-4. And so on and so on. - ID obfuscation If I want to address a specific osmo_fsm_inst on the CTRL interface, I need to pass the entire long id. I don't know of anyone using this in practice, but abusing the id as logging context makes this really hard. I think this is the worst side effect of me adding elaborate logging context to FSM instance ids. - log reading Various lengths of logging context make the log line's actual message show on various "indentation" levels. Instead I would like to be able to configure the log context part of a log message to show in the *end* of a log line instead of at the start, so that the short messages like "New conn" or "Rx Location Updating Request" show lined up one below each other; or alternatively introduce a common chunk of indentation spacing to line things up. That's currently not possible if both the log context and log message are just one arbitrary string fed to LOGP(). == IDEA == Reflecting on this, I formed the idea of moving logging context to a separate array of strings for each object. The most common usage would be to tie this array of context information to an osmo_fsm_inst. I'm not sure how far we could take this before we start producing too much load. It would of course be the aim to find a good balance of effort and usefulness, or think of nifty simplifications or optimizations. It's just a vague idea, but I guess it would look something like this in pseudo code: my_obj_update_id(my_obj) { set_log_context(my_obj->logctx, "IMSI", my_obj->imsi); set_log_context(my_obj->logctx, "MSISDN", my_obj->vlr->msisdn); set_log_context(my_obj->logctx, "RTP-local", osmo_sockaddr_str_name(my_obj->rtp_stream->rtp_local)); ... } set_log_context(ctx, name, val) { slot = log_context_find_or_create_slot(ctx, name); osmo_talloc_replace_str(ctx, &ctx[slot], val); /* or osmo_strlcpy() to a fixed-size char[]? */ } #define LOG_MY_OBJ(my_obj, level, fmt, args...) \ LOGP_CTX(DMSC, my_obj->ctx, level, fmt, ##args) use() { LOG_MY_OBJ(my_obj, LOGL_DEBUG, "Actual message"); /* i.e. most current log macros would be invoked in the same way */ } And then allow logging configuration like % hide all logging context in log output, except MSISDN and RTP-local: > logging print context none > logging print context MSISDN > logging print context RTP-local % show only logging lines where this exact IMSI is part of the context > logging filter-rule IMSI == 901700000014705 In gsmtap_log packets, we could add a listing of key-value items for log context, hopefully allowing to show / hide each individual context by name in a wireshark UI. Instead of repeating context like the IMSI in various FSM instance IDs, the logging context could be made chainable, i.e. internally, we could reference one logging context from another. For example, the rtp_stream FSM instance would only add the RTP address to its logging context, and then "upwards" reference the call_leg FSM's context. That would add the callref, and "upwards" reference the subscriber's context, which adds IMSI, MSISDN and RAN conn info to the rtp_stream logging context. (We might be able to do this implicitly from osmo_fsm_inst parent/child relations that we already have.) It might even be thinkable to allow traversing all across related context info, so that filtering for a given RTP port could cause even high level objects (like the vlr_subscr) to search through all childrens' log ctx information to see whether anyone defines this RTP-local context, thus show all logging for a conn that currently uses this RTP port. Premature optimization... To run each log line through a set of filters would potentially take up a lot of CPU cycles. For that I also have an idea to resolve the decision to log or not to log only once per target object and cache that result. For example, when I change the logging filter to pick a specific MSISDN, an internal token is incremented. If I hit an object's logging, I decide whether it passes the logging filter, and store the outcome as true/false with the current filter's token value in the object. Next time I hit that object and the token is still the same, the filter must also have the same result, and I can just use the stored true/false. If the user changes the filter, the token increments and on next logging, each object notices that the filter needs to be re-run in full. If the object's context info changes, reset the object's stored token to also rerun the filter on next logging. This is quite vague, especially not clear whether each object with logging context would have to store tokens for each and every log target separately... Premature optimization: require the log context names to be compile-time string literals, so that we can just compare name_a == name_b without invoking strcmp(). A general advantage is that we would always see the relevant context for logging, and we would immediately notice bugs in the context, thus we would always ensure reliable logging filters "for free". An easy way out of implementing log filters in osmocom would be to simply not have them, just provide well-defined log context in gsmtap_log, in a way that wireshark can parse. Users can then use wireshark rules to filter the log. The disadvantage here is that we would have to first compose all logging, instead of nicely skipping entire log lines before they are even composed. So, this is so far just an idea I would like to run by you. Even if the solutions might still be unworthy, I think it is worthwhile to be aware of the implications I highlighted above. ~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 Thu Apr 11 10:06:03 2019 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 11 Apr 2019 12:06:03 +0200 Subject: RFC: FSM instance IDs / log context / log filters In-Reply-To: <20190411010217.GA24482@my.box> References: <20190411010217.GA24482@my.box> Message-ID: <20190411100602.GR25552@nataraja> Hi Neels, On Thu, Apr 11, 2019 at 03:02:17AM +0200, Neels Hofmeyr wrote: > Since a long time ago, we have a logging filter mechanism which requires > setting a global "context pointer" to some object, for every code path. It is > not trivial to use and we mostly neglected using and testing it, so it doesn't > work well in practice. This is true as the main developers typically test with networks/confiugrations of rather limited size and hence don't need the feature during their day-by-day work. However, it should be rather simple to add more log filters very quickly, once somebody actually wants to improve there. Also, support differs a lot between programs. I think in osmo-gbproxy it's quite "feature complete" as you rarely would want to filter on anything beyond nsvcs? > An extreme example is > > DCC DEBUG rtp_stream(IMSI-901700000014705:MSISDN-1001:TMSI-0x8D91D71B:GERAN-A-1:CM_SERVICE_REQ:trans-8:call-2147483649:RTP_TO_RAN:CI-BBBD5102:remote-port-not-sent:codec-not-sent:local-192-168-2-4-42000:remote-192-168-2-3-23004)[0x612000015e20]{ESTABLISHING}: Committing: Tx MDCX to update the MGW: updating remote-RTP-IP-port codec (rtp_stream.c:330) ;) see my point below about what the ID is supposed to be. > - Special characters > > Since an FSM instance can only have a limited set of characters for id, we > can't add IP addresses as 1.2.3.4, but need to use 1-2-3-4. And so on and so > on. yes, this restriction is very ugly, I really don't like it. And all of that just because we use the dot as separator in the CTRL interface. > - ID obfuscation > > If I want to address a specific osmo_fsm_inst on the CTRL interface, I need to > pass the entire long id. I don't know of anyone using this in practice, but > abusing the id as logging context makes this really hard. > I think this is the worst side effect of me adding elaborate logging context to > FSM instance ids. Yes, this is a problem. The ID was intended to be *a* unique identifier for the given resource, like the IMSI *or* the TMSI. Something like a "primary lookup key". Not as a concatenation of all posssible identifier or context. The primary use case for the ID was the CTRL interface, not logging. So I'm all for returning to the original model, irrespective of the current proposal discussed here. > == IDEA == > > Reflecting on this, I formed the idea of moving logging context to a separate > array of strings for each object. The most common usage would be to tie this > array of context information to an osmo_fsm_inst. > > I'm not sure how far we could take this before we start producing too much > load. It would of course be the aim to find a good balance of effort and > usefulness, or think of nifty simplifications or optimizations. So why not turn it the other way around? If I understand the proposal, you are pre-emptively preparing all kinds of string representations in your application and providing it to the logging core (whether or not they will be used). I would argue that the other way around makes sense: Register something like a "context generator function" which takes a "raw" data structure like a lchan and which can interpret/extract information from it. This way, you *only* generate the strings on demand which are enabled in the vty config. So the string formatting/printing would only happen *if* we are sure that the given object actually is going to be logged given the current configuration of log levels/targets, and only for those parts of the object that are requested. Basically we're talking about an object-oriented approach, where each object provides some kind of poor man's serialization (for a few fields like MSISDN, IMSI, TMSI, ... in our use cases). This could then be used not only for string based logging but maybe also for something like a "structured vty dump" of the object state, or even for something like structured logging (json, extended GSMTAP, ...) > In gsmtap_log packets, we could add a listing of key-value items for log > context, hopefully allowing to show / hide each individual context by name in a > wireshark UI. I would argue in favor of not including the keys with every log line, but rather send a periodic "GSMTAP log configuration" package which contains something like a string-to-identifier mapping which can then be sent only once every second, or every 10s, rather than include it in every line. But well, that may be an over-optimization. > Instead of repeating context like the IMSI in various FSM instance IDs, the > logging context could be made chainable, i.e. internally, we could reference > one logging context from another. For example, the rtp_stream FSM instance > would only add the RTP address to its logging context, and then "upwards" > reference the call_leg FSM's context. That would add the callref, and > "upwards" reference the subscriber's context, which adds IMSI, MSISDN and RAN > conn info to the rtp_stream logging context. (We might be able to do this > implicitly from osmo_fsm_inst parent/child relations that we already have.) Ok, that's what I think is a completely orthogonal proposal to the key/value pairs. This idea might not be as easy to combine with my proposal of the serialization call-back function above. But of course if every FSM class had a serialization function pointer member, then one can also traverse the chain of the FSM hierarchy and call that function for each FSM instance in that hierarchy. > It might even be thinkable to allow traversing all across related context info, > so that filtering for a given RTP port could cause even high level objects > (like the vlr_subscr) to search through all childrens' log ctx information to > see whether anyone defines this RTP-local context, thus show all logging for a > conn that currently uses this RTP port. I don't like the idea of generating all that string-printed context a priori all the time. It seems like an incredible overhead. For filtering based on certain parameters I think we should rather think of the log filters in existing or some extended form. The point of those log filters is that they operate on the native data type which exists anyway, rather than to operate on stringified versions of everything. > An easy way out of implementing log filters in osmocom would be to simply not > have them, just provide well-defined log context in gsmtap_log, in a way that > wireshark can parse. Users can then use wireshark rules to filter the log. The > disadvantage here is that we would have to first compose all logging, instead > of nicely skipping entire log lines before they are even composed. I really don't like those kind of ideas, sorry :) I'm all for discussing possible improvements in whatever way. But I think they should as far as possible be generic, elegant and efficient, even if it means having to write some more code. Hence my suggestion to * generate related string representations only when actually needed * think of general "serialization" of our data structures / objects that may have use cases in other contexts than logging. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From rafael at riseup.net Thu Apr 11 14:17:07 2019 From: rafael at riseup.net (Rafael Diniz) Date: Thu, 11 Apr 2019 11:17:07 -0300 Subject: LimeNet Micro as GSM BTS Message-ID: <480e0ff5-f05f-c551-d41d-152a7cd7097b@riseup.net> Hi all, Have anyone tried Osmo GSM stack (including the trx) with the LimeNet Micro with the Pi compute module? My question is if it is stable enough for any real deployment or just another toy for the lab. With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, with lots of failure messages... Thanks, Rafael Diniz Rhizomatica -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rafael at rhizomatica.org Thu Apr 11 14:15:56 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Thu, 11 Apr 2019 11:15:56 -0300 Subject: LimeNet Micro for BTS Message-ID: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> Hi all, Have anyone tried Osmo GSM stack (including the trx) with the LimeNet Micro with the Pi compute module? My question is if it is stable enough for any real deployment or just another toy for the lab. With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, with lots of failure messages... Thanks, Rafael Diniz Rhizomatica -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Thu Apr 11 14:56:43 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 11 Apr 2019 16:56:43 +0200 Subject: RFC: FSM instance IDs / log context / log filters In-Reply-To: <20190411100602.GR25552@nataraja> References: <20190411010217.GA24482@my.box> <20190411100602.GR25552@nataraja> Message-ID: <20190411145643.GA25903@my.box> On Thu, Apr 11, 2019 at 12:06:03PM +0200, Harald Welte wrote: > Hi Neels, > > On Thu, Apr 11, 2019 at 03:02:17AM +0200, Neels Hofmeyr wrote: > > Since a long time ago, we have a logging filter mechanism which requires > > setting a global "context pointer" to some object, for every code path. It is > > not trivial to use and we mostly neglected using and testing it, so it doesn't > > work well in practice. > > This is true as the main developers typically test with networks/confiugrations > of rather limited size and hence don't need the feature during their day-by-day > work. However, it should be rather simple to add more log filters very quickly, > once somebody actually wants to improve there. Also, support differs a lot between The problems I had when developing filters for this mechanism: it stores a reference to a pointer. To make sure the filter doesn't cause use-after-free, every talloc_free() of an object eligible for a filter needs to take care to remove a filter. Furthermore, that makes it impossible to filter for a subscriber that is not yet attached, which is a huge drawback. If I want to filter for an IMSI, I would typically write a filter that references a VLR subscriber struct. That means the filter gets invalidated as soon as a VLR subscriber is freed, or can't be put in place arbitrarily. The filter could create a VLR subscriber if missing and keep a use count on it -- but a) that affects the VLR state which we should rather not do, and b) isn't a generally valid solution for everything else besides VLR subscribers in osmo-msc. In summary, I find this approach impractical. The second problem I had with this is that you need to carefully examine each code path and set the log context to the correct object. Forget that or do it too late in the code path, and the filter discards interesting logging. Also take care to remove from the global context pointer if the object goes away. This touches each and every code path and is error prone. Finally, you don't notice bugs until you actually try to filter. That's why my aim is rather towards a purely string based filtering, where you can filter for arbitrary strings regardless of objects existing or not, and where you don't need to take care to clean up context references. > > - Special characters > > > > Since an FSM instance can only have a limited set of characters for id, we > > can't add IP addresses as 1.2.3.4, but need to use 1-2-3-4. And so on and so > > on. > > yes, this restriction is very ugly, I really don't like it. And all of that > just because we use the dot as separator in the CTRL interface. > The primary use case for the ID was the CTRL interface, not logging. > > So I'm all for returning to the original model, irrespective of the > current proposal discussed here. The most trivial solution is to add one more string to the osmo_fsm_inst: a "log_context" string that is separate from the id but also gets printed on each logging line. That's if we don't add more elaborate context features. The osmo_fsm_inst->id could also become a numerical id that is implicity increased for each new FSM instance per FSM kind. That would also implicitly avoid having two FSM instances with the same id. I'm suggesting this because so far fsm.c seems to not enforce a unique FSM instance ID at all, meaning that if we poorly choose IDs then the objects will not be accessible from CTRL. We could techincally search the context string to select an object e.g. by IMSI instead of an arbitrary id... but well, probably a meaningful "primary key" as id is more useful, even if not as safe as an implicit increasing numeric id. > you are pre-emptively preparing all kinds of string representations in > your application > I don't like the idea of generating all that string-printed context a > priori all the time. It seems like an incredible overhead. The overhead is pretty much similar to what I am doing now: composing the long FSM instance IDs, typically only once per created object, and maybe once more after it is connected up. That is minuscule compared to msgb composition. That is also minuscule compared to composing string formats for each log line. > [key-value callback functions] Providing key-value callback functions would mean that we need to fetch fresh values for each and every logging line, because a value may have changed since the last logging line. I'd like to avoid aggravating a situation where almost everything is set to debug logging: completely re-composing the logging context string for each log line might cause considerable load. I think this is more important than saving one context string allocation per object. If we have key-value callbacks, an object should have some "version token" indicating whether any values changed since last queried, and a cache of last composed logging context line, for rapid re-use of the same context. > This could then be used not only for string based logging but maybe also > for something like a "structured vty dump" of the object state, or even > for something like structured logging (json, extended GSMTAP, ...) Logging context that preserves the type for each item... I also considered that, but I think that mostly complicates the API for little benefit to logging. Ultimately all logging is string based, so I'd rather go for strings. Providing typed information actually starts to touch on things the CTRL interface should provide, the whole CTRL/VTY refactoring idea. If we play this nicely there could be a grand unified theory of log context, log filtering *and* object property querying *and* object configuration by CTRL and VTY... like a grand unified String Theory ;) Well, I doubt it. That topic will probably remain Schroedinger for a while. > > In gsmtap_log packets, we could add a listing of key-value items for log > > I would argue in favor of not including the keys with every log line, > but rather send a periodic "GSMTAP log configuration" package which The difficulty is that to show useful output, the dissector (and any custom gsmtap_log client programs) have to wait for a "key frame" and cache information before they can produce useful output... in unordered UDP, too. > * generate related string representations only when actually needed > * think of general "serialization" of our data structures / objects > that may have use cases in other contexts than logging. I see this spectrum of proposals: string based ^ Y 1 | < - - just one string | 4 3 | 2 < - - key-stringvalue pairs | cache ctx ---------+--------> compose for each log line | X | | 6 | 5 < - - key-type-value tuples typed (say, each axis ranging from -10 to 10) 1) Have one fixed string besides the FSM instance id, called "log_context", which gets printed for each LOGPFSM() but doesn't affect the FSM instance ID. 2) Have purely string based key-stringvalue pairs that an object (an FSM instance) stores as it gets allocated. A log line concatenates those readily composed strings. 3) key-stringvalue pairs, but also cache the concatenated string. The object re-creates the concatenated string from individual context strings when it changed something. Individual context items may be disabled by user cfg (per log target?). 4) key-stringvalue pairs with a cached complete log context string, but the logging string is not created until the first logging for a given object occurs. The string is returned by a callback function. A "version token" indicates whether it should be updated on next logging. Individual context items may be disabled by user cfg (per log target?). 5) Per object, provide a set of serialization callback functions that return typed results (string or int or...). Each log line walks all/some of those context functions and composes a log context string, every time. 6) Per-object typed callbacks, but cache the resulting logging context string as soon as the first logging happens on an object. An object has a "version token" that indicates the logging context should be refreshed. I favor the top left. (1) would be quite trivial to achieve "right now". (3) or (4) would be the most trivial key-value variants. As soon as we go to (6), we're opening up the need to keep separate API for each type of context info, type enums, validity checking of user input... On the right-hand side, like (5), composing log output would become a lot more expensive than it is with the current FSM IDs, but of course would be optimal for logging being switched off. There is another "axis" to proposals: Treat context separately in the logging API, or just insert in the log line. #define LOGP_CTX([...], ctx, fmt, args...) LOGP([...], "<%s> " fmt, ctx, ##args) ^ Z / / + / / logp3([...], log_ctx, format, args) Adding the context as argument to a logp3() function allows disabling / enabling or moving-left-right of the context info by VTY config. Considering the time/effort vs benefit tradeoff, if I were alone I would go for (1) with logp3(), in coordinates: X=-10 Y=10 Z=-10 cache, one string, logp3() with separate context arg and implement log filtering as a strstr() on the single-string log_context: - Quickly get back a useful FSM instance ID. - Don't bother with key-value nor types. Cache a single string per fi. - Get filtering trivially available for all cached context strings, in pseudocode: bool log_check_level() { ... if (!strstr("IMSI-123321:", log_context)) return false; } This would be a fairly small patch, trivially backwards compatible, with minimal impact on current osmo_fsm_inst allocation to make use of the new features. I hope gsmtap_log is trivially extendible to add a ctx string. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Fri Apr 12 01:23:41 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 12 Apr 2019 03:23:41 +0200 Subject: osmo_quote_str_c() Message-ID: <20190412012341.GA10236@my.box> I think here is a bug: char *osmo_quote_str_c(const void *ctx, const char *str, int in_len) { char *buf = talloc_size(ctx, OSMO_MAX(in_len+2, 32)); if (!buf) return NULL; return osmo_quote_str_buf2(buf, 32, str, in_len); } We may allocate more than 32 bytes (see OSMO_MAX()) but still allow to write only 32 bytes? Looks like the allocated len should be stored in a local variable to pass to osmo_quote_str_buf2(). And if I'm right, what is the 32 for? At least 32?? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Fri Apr 12 05:18:26 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 12 Apr 2019 07:18:26 +0200 Subject: sccp conn_id weirdness Message-ID: <20190412051826.GB10236@my.box> I noticed some odd behavior in our SCCP stack, let me outline. Should this become a new issue? Because the osmo_scu_prim conn_id patches aren't merged yet, I put a temporary shim in place like we have in osmo-bsc to figure out new outgoing conn_ids. With this shim I noticed that some conn_ids work better than others: struct ran_conn *ran_conn_create_outgoing(struct ran_peer *ran_peer) { /* FIXME use method being developed in gerrit id Ifd55c6b7ed2558ff072042079cf45f5068a971de */ static uint32_t next_outgoing_conn_id = 0x80000000; uint32_t conn_id = 0; int attempts = 1000; bool already_used = true; while (attempts--) { struct ran_conn *conn; conn_id = next_outgoing_conn_id; next_outgoing_conn_id++; already_used = false; llist_for_each_entry(conn, &ran_peer->sri->ran_conns, entry) { if (conn->sccp_conn_id == conn_id) { already_used = true; break; } } if (!already_used) break; } if (already_used) return NULL; LOG_RAN_PEER(ran_peer, LOGL_DEBUG, "Outgoing conn id: %u\n", conn_id); return ran_conn_create_incoming(ran_peer, conn_id); } The weird thing is that the conn_id of 0x80000000 does *NOT* work and gets me a log line of: DLSCCP NOTICE Cannot find connection for local reference 0 (sccp_scoc.c:1636) where the MSC should be sending out the initial N-CONNECT to osmo-bsc. However, if I set the initial value to: next_outgoing_conn_id = 2342; then everything works out fine. I am at a loss to understand why this would happen, and currently don't have the cycles left to investigate. Maybe someone else wants to investigate why this happens... Logging for the failing case with 0x80000000: (the source file numbers might be a bit off current master) 20190412033755322 DBSSAP DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Outgoing conn id: 2147483648 (ran_conn.c:81) [...] 20190412033755327 DBSSAP DEBUG msc_t(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b220]{WAIT_HO_REQUEST_ACK}: NAS encode: BSSMAP: HANDOVER_REQUEST (nas_a.c:1159) 20190412033755328 DRR DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Received Event RAN_PEER_EV_MSG_DOWN_CO_INITIAL (ran_conn.c:119) 20190412033755328 DLSCCP DEBUG Received SCCP User Primitive (N-CONNECT.request) (sccp_scoc.c:1712) 20190412033755328 DLSCCP DEBUG SCCP-SCOC(2147483648)[0x6120000201a0]{IDLE}: Allocated (fsm.c:423) 20190412033755328 DLSCCP DEBUG SCCP-SCOC(2147483648)[0x6120000201a0]{IDLE}: Received Event N-CONNECT.req (sccp_scoc.c:1753) 20190412033755328 DLSS7 DEBUG sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CORE,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Protocol Class,L=4,D=00000002), PART(T=Source Reference,L=4,D=80000000), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe), PART(T=Sequence Control,L=4,D=00000000), PART(T=Source Address,L=20,D=0002000380020008000008b980030008000000fe), PART(T=Data,L=83,D=0051100b07010aa19181a5050a09004ad48954cb991d2912035058a605080062f224002a000005080009f1070046000104010c130a6014042f6500200240422c04080899100700001074507c06c0a80204a418) (sccp_scrc.c:398) 20190412033755328 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 08 b9 80 03 00 08 00 00 00 fe (sua.c:385) 20190412033755328 DLSUA DEBUG SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412033755328 DLSUA DEBUG SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412033755328 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): dpc=2236=1.23.4 not local, message is for routing (osmo_ss7_hmrt.c:278) 20190412033755328 DLSS7 DEBUG Found route for dpc=2236=1.23.4: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A-Iu proto=m3ua (osmo_ss7_hmrt.c:227) 20190412033755328 DLSS7 DEBUG rt->dest.as proto is M3UA for dpc=2236=1.23.4 (osmo_ss7_hmrt.c:233) 20190412033755328 DLSS7 DEBUG XUA_AS(as-clnt-OsmoMSC-A-Iu)[0x61200000a720]{AS_ACTIVE}: Received Event AS-TRANSFER.req (m3ua.c:507) 20190412033755329 DLSCCP DEBUG SCCP-SCOC(2147483648)[0x6120000201a0]{IDLE}: State change to CONN_PEND_OUT (no timeout) (sccp_scoc.c:829) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: rtpbridge/2 at msc CI[0] RTP_TO_RAN CI=88A322A7: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: rtpbridge/2 at msc CI[1] RTP_TO_CN CI=55D5651B: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: rtpbridge/2 at msc CI in use: 2, waiting for response: 0 (mgcp_client_endpoint_fsm.c:669) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{WAIT_MGW_RESPONSE}: State change to IN_USE (no timeout) (mgcp_client_endpoint_fsm.c:680) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{IN_USE}: rtpbridge/2 at msc CI[0] RTP_TO_RAN CI=88A322A7: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2147483648:NONE)[0x61200001b6a0]{IN_USE}: rtpbridge/2 at msc CI[1] RTP_TO_CN CI=55D5651B: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755329 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755332 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412033755332 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412033755332 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) (osmo_ss7.c:1609) 20190412033755333 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412033755333 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412033755333 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412033755333 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412033755333 DLSUA DEBUG IEI 259: Parsed Addr: RI=2,PC=2236,SSN=254 (sccp2sua.c:333) 20190412033755333 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:COAK,V=0,LEN=0), PART(T=Protocol Class,L=4,D=00000002), PART(T=Destination Reference,L=4,D=00000000), PART(T=Source Reference,L=4,D=00000000), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe) (sccp_scrc.c:450) 20190412033755333 DLSCCP NOTICE Cannot find connection for local reference 0 (sccp_scoc.c:1636) 20190412033755333 DLSS7 DEBUG sccp_scrc_rx_scoc_conn_msg: HDR=(CO:COERR,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Destination Reference,L=4,D=00000000), PART(T=Cause,L=4,D=00000500) (sccp_scrc.c:398) 20190412033755333 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): dpc=2236=1.23.4 not local, message is for routing (osmo_ss7_hmrt.c:278) 20190412033755333 DLSS7 DEBUG Found route for dpc=2236=1.23.4: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A-Iu proto=m3ua (osmo_ss7_hmrt.c:227) 20190412033755333 DLSS7 DEBUG rt->dest.as proto is M3UA for dpc=2236=1.23.4 (osmo_ss7_hmrt.c:233) 20190412033755333 DLSS7 DEBUG XUA_AS(as-clnt-OsmoMSC-A-Iu)[0x61200000a720]{AS_ACTIVE}: Received Event AS-TRANSFER.req (m3ua.c:507) 20190412033755333 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755333 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755334 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412033755334 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412033755337 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412033755337 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412033755337 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) (osmo_ss7.c:1609) 20190412033755337 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412033755337 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412033755337 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412033755337 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412033755338 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CODT,V=0,LEN=0), PART(T=Destination Reference,L=4,D=00000000), PART(T=Segmentation,L=4,D=00000000), PART(T=Data,L=6,D=000422040120) (sccp_scrc.c:450) 20190412033755338 DLSCCP NOTICE Cannot find connection for local reference 0 (sccp_scoc.c:1636) The same logging for the exact same code and situation, only with 2342 instead of 0x80000000: 20190412040110445 DBSSAP DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Outgoing conn id: 2342 (ran_conn.c:81) [...] 20190412040110451 DBSSAP DEBUG msc_t(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001a920]{WAIT_HO_REQUEST_ACK}: NAS encode: BSSMAP: HANDOVER_REQUEST (nas_a.c:1159) 20190412040110451 DRR DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Received Event RAN_PEER_EV_MSG_DOWN_CO_INITIAL (ran_conn.c:119) 20190412040110451 DLSCCP DEBUG Received SCCP User Primitive (N-CONNECT.request) (sccp_scoc.c:1712) 20190412040110451 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{IDLE}: Allocated (fsm.c:423) 20190412040110451 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{IDLE}: Received Event N-CONNECT.req (sccp_scoc.c:1753) 20190412040110451 DLSS7 DEBUG sccp_scrc_rx_scoc_conn_msg: HDR=(CO:CORE,V=0,LEN=0), PART(T=Routing Context,L=4,D=00000000), PART(T=Protocol Class,L=4,D=00000002), PART(T=Source Reference,L=4,D=00000926), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe), PART(T=Sequence Control,L=4,D=00000000), PART(T=Source Address,L=20,D=0002000380020008000008b980030008000000fe), PART(T=Data,L=83,D=0051100b07010aa19181a5050a090086dc7f8e3f4115be12035058a605080062f224002a000005080009f1070046000104010c130a6014042f6500200240422c04080899100700001074507c06c0a80204a418) (sccp_scrc.c:398) 20190412040110451 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412040110451 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412040110451 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412040110451 DLSUA DEBUG sua_addr_parse_part(IEI=0x0103) (20) 00 02 00 03 80 02 00 08 00 00 08 bc 80 03 00 08 00 00 00 fe (sua.c:385) 20190412040110451 DLSUA DEBUG SUA IEI 0x0103 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412040110452 DLSUA DEBUG SUA IEI 0x0103 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412040110452 DLSUA DEBUG sua_addr_parse_part(IEI=0x0102) (20) 00 02 00 03 80 02 00 08 00 00 08 b9 80 03 00 08 00 00 00 fe (sua.c:385) 20190412040110452 DLSUA DEBUG SUA IEI 0x0102 pos 4/20: subpart tag 0x8002, len 8 (sua.c:439) 20190412040110452 DLSUA DEBUG SUA IEI 0x0102 pos 12/20: subpart tag 0x8003, len 8 (sua.c:439) 20190412040110452 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): dpc=2236=1.23.4 not local, message is for routing (osmo_ss7_hmrt.c:278) 20190412040110452 DLSS7 DEBUG Found route for dpc=2236=1.23.4: pc=0=0.0.0 mask=0x0=0.0.0 via AS as-clnt-OsmoMSC-A-Iu proto=m3ua (osmo_ss7_hmrt.c:227) 20190412040110452 DLSS7 DEBUG rt->dest.as proto is M3UA for dpc=2236=1.23.4 (osmo_ss7_hmrt.c:233) 20190412040110452 DLSS7 DEBUG XUA_AS(as-clnt-OsmoMSC-A-Iu)[0x61200000a720]{AS_ACTIVE}: Received Event AS-TRANSFER.req (m3ua.c:507) 20190412040110452 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{IDLE}: State change to CONN_PEND_OUT (no timeout) (sccp_scoc.c:829) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: rtpbridge/2 at msc CI[0] RTP_TO_RAN CI=D1035D6D: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: rtpbridge/2 at msc CI[1] RTP_TO_CN CI=A01EF28B: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: rtpbridge/2 at msc CI in use: 2, waiting for response: 0 (mgcp_client_endpoint_fsm.c:669) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{WAIT_MGW_RESPONSE}: State change to IN_USE (no timeout) (mgcp_client_endpoint_fsm.c:680) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{IN_USE}: rtpbridge/2 at msc CI[0] RTP_TO_RAN CI=D1035D6D: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42008) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLMGCP DEBUG mgw-endpoint(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001ada0]{IN_USE}: rtpbridge/2 at msc CI[1] RTP_TO_CN CI=A01EF28B: CRCX: done (rtpbridge/2 at msc:192.168.2.4:42010) (mgcp_client_endpoint_fsm.c:651) 20190412040110452 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412040110453 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412040110453 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected write (stream.c:300) 20190412040110453 DLINP DEBUG [ CONNECTED] osmo_stream_cli_write(): sending data (stream.c:225) 20190412040110457 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412040110457 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412040110457 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 48 (flags=0x80) (osmo_ss7.c:1609) 20190412040110457 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412040110457 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412040110457 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412040110457 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412040110457 DLSUA DEBUG IEI 259: Parsed Addr: RI=2,PC=2236,SSN=254 (sccp2sua.c:333) 20190412040110457 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:COAK,V=0,LEN=0), PART(T=Protocol Class,L=4,D=00000002), PART(T=Destination Reference,L=4,D=00000926), PART(T=Source Reference,L=4,D=00000000), PART(T=Destination Address,L=20,D=0002000380020008000008bc80030008000000fe) (sccp_scrc.c:450) [this is where above, the "Cannot find" error occurs] 20190412040110457 DLSCCP DEBUG Received CO:COAK for local reference 2342 (sccp_scoc.c:1645) 20190412040110457 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{CONN_PEND_OUT}: Received Event RCOC-CONNECT_CONFIRM.ind (sccp_scoc.c:1678) 20190412040110457 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{CONN_PEND_OUT}: State change to ACTIVE (no timeout) (sccp_scoc.c:980) 20190412040110458 DLSCCP DEBUG Delivering N-CONNECT.confirm to SCCP User 'OsmoMSC-A' (sccp_user.c:156) 20190412040110458 DBSSAP DEBUG (GERAN-A) sccp_ran_sap_up(N-CONNECT.confirm) (sccp_ran.c:143) 20190412040110464 DLINP DEBUG [ CONNECTED] osmo_stream_cli_fd_cb(): connected read (stream.c:296) 20190412040110464 DLINP DEBUG [ CONNECTED] osmo_stream_cli_read(): message received (stream.c:210) 20190412040110464 DLSS7 DEBUG asp-asp-clnt-OsmoMSC-A-Iu: xua_cli_read_cb(): sctp_recvmsg() returned 76 (flags=0x80) (osmo_ss7.c:1609) 20190412040110464 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: Received M3UA Message (XFER:DATA) (m3ua.c:722) 20190412040110464 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer (m3ua.c:541) 20190412040110464 DLM3UA DEBUG asp-asp-clnt-OsmoMSC-A-Iu: m3ua_rx_xfer(): M3UA data header: opc=2236=1.23.4 dpc=2233=1.23.1 (m3ua.c:580) 20190412040110464 DLSS7 DEBUG m3ua_hmdc_rx_from_l2(): found dpc=2233=1.23.1 as local (osmo_ss7_hmrt.c:274) 20190412040110464 DLSS7 DEBUG scrc_rx_mtp_xfer_ind_xua: HDR=(CO:CODT,V=0,LEN=0), PART(T=Destination Reference,L=4,D=00000926), PART(T=Segmentation,L=4,D=00000000), PART(T=Data,L=34,D=002012170f062bc1660b2366010763410302280821982c0440217c06c0a8020359e4) (sccp_scrc.c:450) 20190412040110464 DLSCCP DEBUG Received CO:CODT for local reference 2342 (sccp_scoc.c:1645) 20190412040110464 DLSCCP DEBUG SCCP-SCOC(2342)[0x61200001b820]{ACTIVE}: Received Event RCOC-DT1.ind (sccp_scoc.c:1678) 20190412040110464 DLSCCP DEBUG Delivering N-DATA.indication to SCCP User 'OsmoMSC-A' (sccp_user.c:156) 20190412040110464 DBSSAP DEBUG (GERAN-A-2342) sccp_ran_sap_up(N-DATA.indication) (sccp_ran.c:106) 20190412040110464 DRR DEBUG ran_peer(GERAN-A:RI-SSN_PC:PC-1-23-4:SSN-BSSAP)[0x61200000aea0]{READY}: Received Event RAN_PEER_EV_MSG_UP_CO (ran_peer.c:529) 20190412040110464 DMSC DEBUG msc_t(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001a920]{WAIT_HO_REQUEST_ACK}: Received Event MSC_EV_FROM_RAN_UP_L2 (ran_peer.c:346) 20190412040110464 DBSSAP DEBUG msc_t(IMSI-901700000014705:GERAN-A-2342:NONE)[0x61200001a920]{WAIT_HO_REQUEST_ACK}: NAS decode: BSSMAP: Rx BSSMAP DT1 HANDOVER REQ ACK (nas_a.c:779) I can only suspect that somewhere the value range is stripped?? I have pcaps for these two if anyone is interested. It was tested with current libosmo-sccp master, as well as with the last commit reverted ("sccp_scoc: conn_create{,_id}() user arg, not inst"), identical results. ~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 Apr 12 08:02:42 2019 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 12 Apr 2019 10:02:42 +0200 Subject: LimeNet Micro for BTS In-Reply-To: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> References: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> Message-ID: <20190412080242.GC25552@nataraja> Hi Rafael, On Thu, Apr 11, 2019 at 11:15:56AM -0300, Rafael Diniz wrote: > Have anyone tried Osmo GSM stack (including the trx) with the LimeNet > Micro with the Pi compute module? My question is if it is stable enough > for any real deployment or just another toy for the lab. I am not aware of anyone even having experience with (or even access to) that hardware in general. It may be that e.g. sysmocom has received one in the last few days (I'm travelling this week), but it doesn't appear to be something that many people have had a chance to try/test yet. Given that the product is as far as I understand at a very early stage, as far as I can tell, I would not have too high expectations on production deployments just yet. This is irrespective of the name of the product nor of the manufacturer. Especially as it is not a brand-new "base station product" consisting of an integrated solution from one vendor who will provide a tested, approved, working product consisting of hardware and software, but as it is - AFAICT - a SDR hardware only product where the user has to "build his own base station" based on several components - one very important of them of course being the actual hardware board. > With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, > with lots of failure messages... I'm sorry to hear this. We're trying to address various problems related to LimeSDR devices for quite some time, but progress is unfortunately not as quick as one would hope, particularly as LimeSuite also evolves and every major version seems to behave quite differently, at least in the way how OsmoTRX is using the API. In recent weeks, Joachim has been making very good progress with help from Lime to resolve some of the most long-standing issues related to RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...). There should be a patchset pushed to gerrit soon which will address this one class of problems. However, this does not adress any USB stability related problems, which is a separate class of issues. We have to look at them once as a time. One thing I'm a bit missing here is: Where are your comprehensive bug reports about this in the osmocom issue tracker? Particularly with problems that manifest themselves only every few hours and hence are not quick to reproduce, we have to collect those issues and related log files, backtraces, ... in the issue tracker. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From pespin at sysmocom.de Fri Apr 12 13:01:15 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 12 Apr 2019 15:01:15 +0200 Subject: osmo_quote_str_c() In-Reply-To: <20190412012341.GA10236@my.box> References: <20190412012341.GA10236@my.box> Message-ID: <5b6ef380-3490-d7e2-f9e7-c179d6c02535@sysmocom.de> Hi Neels, I don't quite get why is 32 used there. Also documentation and implementation look wrong to me: * doc talks about static buffer. That makes no sense to me, line should be removed. * Case of in_len=-1 is not correctly handled there. I'd change it to: char *osmo_quote_str_c(const void *ctx, const char *str, int in_len) { size_t len = in_len == -1 ? strlen(str) : in_len; len += 2; char *buf = talloc_size(ctx, len); if (!buf) return NULL; return osmo_quote_str_buf2(buf, len, str, in_len); } -- - 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 osmith at sysmocom.de Fri Apr 12 13:26:10 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Fri, 12 Apr 2019 15:26:10 +0200 Subject: sccp conn_id weirdness In-Reply-To: <20190412051826.GB10236@my.box> References: <20190412051826.GB10236@my.box> Message-ID: <5db681af-0ad2-e884-7562-fd031f27fa31@sysmocom.de> Hi Neels, On 4/12/19 7:18 AM, Neels Hofmeyr wrote: > I can only suspect that somewhere the value range is stripped?? I was able to reproduce the issue, and indeed one byte does get stripped off - that's why we end up with 0 as local reference. I've created an issue here: https://osmocom.org/issues/3921 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 rafael at rhizomatica.org Fri Apr 12 14:05:21 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Fri, 12 Apr 2019 11:05:21 -0300 Subject: LimeNet Micro for BTS In-Reply-To: <20190412080242.GC25552@nataraja> References: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> <20190412080242.GC25552@nataraja> Message-ID: Hi Harald, > Given that the product is as far as I understand at a very early stage, > as far as I can tell, I would not have too high expectations on > production deployments just yet. This is irrespective of the name of > the product nor of the manufacturer. Especially as it is not a > brand-new "base station product" consisting of an integrated solution > from one vendor who will provide a tested, approved, working product > consisting of hardware and software, but as it is - AFAICT - a SDR > hardware only product where the user has to "build his own base station" > based on several components - one very important of them of course > being the actual hardware board. It is a SDR hardware, but conceived, as far as I understand, with GSM usage in mind, considering the integrated GPSDO and so on. As soon as I put my hands on it I'd like to evaluate if it's worth invest some time to develop a housing for it and appropriate connections for a very low power and low cost BTS. >> With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, >> with lots of failure messages... > > I'm sorry to hear this. We're trying to address various problems > related to LimeSDR devices for quite some time, but progress is > unfortunately not as quick as one would hope, particularly as LimeSuite > also evolves and every major version seems to behave quite differently, > at least in the way how OsmoTRX is using the API. > > In recent weeks, Joachim has been making very good progress with help > from Lime to resolve some of the most long-standing issues related to > RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...). > There should be a patchset pushed to gerrit soon which will address this > one class of problems. However, this does not adress any USB stability > related problems, which is a separate class of issues. We have to look > at them once as a time This is great, thanks for the report! I hope to have USB problems put aside with the LimeNET Micro, this is one of the reasons of my question. > One thing I'm a bit missing here is: Where are your comprehensive bug > reports about this in the osmocom issue tracker? Particularly with > problems that manifest themselves only every few hours and hence are > not quick to reproduce, we have to collect those issues and related > log files, backtraces, ... in the issue tracker. I'll do this in the next couple of days, sorry for sending the email in advance of the actual bug report. Thanks a lot! 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 jsteiger at sysmocom.de Fri Apr 12 16:02:21 2019 From: jsteiger at sysmocom.de (Joachim Steiger) Date: Fri, 12 Apr 2019 18:02:21 +0200 Subject: LimeNet Micro for BTS In-Reply-To: References: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> <20190412080242.GC25552@nataraja> Message-ID: <57d81340-3781-6df7-a9cb-c18d9903a7e7@sysmocom.de> On 4/12/19 4:05 PM, Rafael Diniz wrote: > It is a SDR hardware, but conceived, as far as I understand, with GSM > usage in mind, considering the integrated GPSDO and so on. As soon as I > put my hands on it I'd like to evaluate if it's worth invest some time > to develop a housing for it and appropriate connections for a very low > power and low cost BTS. i have gotten it to work quite fast with help of the patchset i am working on. it behaves mostly like a limesdr mini with a few addons and proper clock. you currently also need limesuite git master, the tagged 19.01 is too old. >>> With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, >>> with lots of failure messages... i have the same problem. i usually i only use usb2 due to it being much more solid that way. it should not matter anyhow, since we only need low bandwith for gsm. >> I'm sorry to hear this. We're trying to address various problems >> related to LimeSDR devices for quite some time, but progress is >> unfortunately not as quick as one would hope, particularly as LimeSuite >> also evolves and every major version seems to behave quite differently, >> at least in the way how OsmoTRX is using the API. well.. there are a couple of things coming together: limesuite did indeed change its behaviour when it comes to a few things. * it got more streamlined and with it the default settings. e.g. channel0 isnt enabled by default anymore. * some not defined behaviours changed, on which we relied. * i have reordered some of the function calls we do: limesuite doesn't like if you do your filtersetup, frequency, gain, streaming setup and calibration setup in the wrong order. sadly, neither our code nor lms has enough asserts to have anybody notice this soon enough. the good news is: the crew of lime is completely on mission helping us get this sorted. >> In recent weeks, Joachim has been making very good progress with help >> from Lime to resolve some of the most long-standing issues related to >> RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...). >> There should be a patchset pushed to gerrit soon which will address this >> one class of problems. However, this does not adress any USB stability >> related problems, which is a separate class of issues. We have to look >> at them once as a time ack, also see below > This is great, thanks for the report! I hope to have USB problems put > aside with the LimeNET Micro, this is one of the reasons of my question. not really. there IS a spi (or rather 2) connection(s) inbetween the fpga and the rpi according to the documentation, but there is also the ftdi601 bridge like used on the lime mini on the board. this is afaik due to the spi link not achieving high enough bandwidth to satisfy all involved. since the rpi is only usb2, this is also limited.... but i dont see any major issues for using it as a gsm trx. >> One thing I'm a bit missing here is: Where are your comprehensive bug >> reports about this in the osmocom issue tracker? Particularly with >> problems that manifest themselves only every few hours and hence are >> not quick to reproduce, we have to collect those issues and related >> log files, backtraces, ... in the issue tracker. > > I'll do this in the next couple of days, sorry for sending the email in > advance of the actual bug report. ps: what would help me out a lot, would be if every bugreport not only references 'limesdr' but also has detail of: * which model (mini, usb, net-micro?...) and revision? * which gateware and firmware release was installed? * which limesuite release or git version? kind regards -- - Joachim Steiger http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Harald Welte From wyao at corrections.com Thu Apr 11 20:00:08 2019 From: wyao at corrections.com (wyao at corrections.com) Date: Thu, 11 Apr 2019 16:00:08 -0400 Subject: OpenBSC on 3rd party MSC Message-ID: <000d01d4f0a1$2cdb08a0$869119e0$@corrections.com> Hello All, I am working on get OpenBSC connected to a 3rd party MSC, I read from the Osmo document that I can use the bsc only mode and the osm-bsc instead of the osmo-nitb. Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp configured and and running, but I see a lot of below error logs in the osmo-stp console: ``````````````````````````` DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): sctp_recvmsg() returned 56 (flags=0x80) DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA) DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1 dpc=185=0.23.1 DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route! ```````````````````````````` On the BSC console, I am seeing a lot of: ``````````````````````````````` <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP ``````````````````````````````` Can anyone identify what is the issue here? Appreciates! Regards, Weiqi -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes at sipsolutions.net Fri Apr 12 12:12:44 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Fri, 12 Apr 2019 14:12:44 +0200 Subject: gsmtap design/extensions? In-Reply-To: <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org> Message-ID: <1d64c578cd5b254d301cf1cac82f32a062916888.camel@sipsolutions.net> Hi Marcel, > before you go all out and define this, it would suggest to understand > what meta-data for the connection contexts you actually need as well. > The data path itself is just a pipe and has not all the information > attached with it. That goes via the control path and that is normally > in user space and carries the real important information to make > useful analysis of how the data path / context is setup. Yes, that's true, though the control path is actually going through one of the data pipes as well. > From what I am seeing right now is that unless you have a method to > also feed the control path into your GSMTAPv3, then this is rather > useless. So the control path *itself* would be there, I guess, but ... > The majority of the debugging is really done for the control path. For > oFono that is OFONO_DEBUG=1 environment variable and while it works it > is not the most elegant solution. I would love to feed that into a > generic debugging / tap that you can read out later. there's definitely room for more information than _just_ the control path "chat", also application state etc. would be useful, and logging etc. Typically on wifi we feed all of this together into kernel tracing (to record with trace-cmd) rather than trying to encapsulate it some other way. > As a side note, for Bluetooth we created a path where the bluetoothd > can feed back its control debugging data back into the Bluetooth > monitor in the kernel to allow combined userspace, mgmt and HCI > tracing. Some really nasty issues could only be triaged by having all > the meta data with a common timestamp. Right. This is something we'd typically use tracing for in wifi. I don't really know what the right model for WWAN would be, I guess. Right now - and I really should've said this before - really the only problem I was thinking of was how we can mux multiple "chat" sessions with a device into a single data stream. Currently, this is all vendor-specific. If you have a Qualcomm modem, you'd be able to see all the open sessions on the underlying netdev, and the QMI header tells you what session a given 'packet' belongs to, and if you follow along maybe you can figure out if this is a control or IP 'packet' (could be an AT command). cdc_mbim uses VLAN tags instead to achieve this, and decapsulates the VLAN tags to send them down to the hardware in a different way. There are a few reasons why I think that this model of having a single underlying netdev controlled by the modem driver, with additional netdevs layered on top in software will not work right in the future. I think drivers should and will need to migrate to creating "real" netdevs for the sessions instead of pure software ones. But if you do this, you lose the ability to listen to all the session streams at the same time, you can only do it for each netdev. Adding this ability back seems worthwhile, but then we probably shouldn't do it in a vendor-specific way, but rather in a generic way. So basically right now that's all I'm trying to solve. In WiFi we don't have the problem of "sessions" because we just use the addresses in the frames to disambiguate - on such 'monitor' netdevs we see the frames including full 802.11 headers. Now, here's maybe where I'm getting off the right path - in wifi we mostly couple that with PHY information as well, and so we have PHY information + full 802.11 headers + data for capturing what's going on. I figured that theoretically at least that would be possible/useful for the modem as well (obviously control packets have no PHY data), but there doesn't seem to be any hardware that would actually expose data in this way. Everyone I've spoken to says these things are only available as modem trace data. What I haven't figured out though is if that's by some other design trade-off, or just because no such infrastructure is/was available. It may well be that doing kernel-tracing instead of doing it via some kind of monitor netdev is perfectly sufficient, but I have a feeling that the relative simplicity of starting tcpdump/wireshark might be preferable. johannes From johannes at sipsolutions.net Fri Apr 12 12:24:25 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Fri, 12 Apr 2019 14:24:25 +0200 Subject: gsmtap design/extensions? In-Reply-To: <20190410233213.GN25552@nataraja> References: <20190410233213.GN25552@nataraja> Message-ID: <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> On Thu, 2019-04-11 at 01:32 +0200, Harald Welte wrote: > Hi Johannes, > > On Tue, Apr 09, 2019 at 03:50:45PM +0200, Johannes Berg wrote: > > As I'm looking into adding a generic cell modem framework to the linux > > kernel (to create session netdevs etc.), I started looking for a > > metadata encapsulation, a la Radiotap (I'm a wifi guy :-) ). > > Is there any discussion about "session netdevs, etc." anywhere? What exactly > do you have in mind for that "generic cell modem framework"? I'm quite > curious to learn more about it and happy to provide feedback from the > perspective of my cellular protocols/specs/systems knowledge. Yeah. I was too much in my little bubble when I wrote this. I just wrote a lengthy reply to Marcel that explains a little more, but basically to summarize: Kernel drivers need to transport multiple data streams, like VoLTE (IP) data, IP data, and control data. Currently, they do this in various ways (cdc_mbim uses VLAN tags, rmnet/qmi_wwan uses Qualcomm QMI headers), when you capture data you have to understand what you're dealing with and maybe extend wireshark to even understand these headers. I'm looking for a general vendor-agnostic encapsulation that would solve this part of the problem. At the same time, I come from WiFi, where - while we don't have these sessions as such but can have different virtual interfaces as well, e.g. for connections to different APs - it's often very useful to also understand the PHY parameters that were used for TX/seen on RX. Now, I realize this isn't something that modems will do right now - they just don't seem to tell you any lower-level information on RX of a packet, but it seemed like it might be worthwhile to not *exclude* this possibility either. > > 1) Why the design with encapsulating it in UDP? Radiotap is just a raw > > header without IP etc. in front, and you use it with tcpdump, > > wireshark or similar tools on the local system. What's the value in > > having something "network transparent"? > > GSMTAP was designed as a format to encapsulate protocols normally not spoken over IP > (such as classic GSM radio protocols, e.g. the Layer 2 LAPDm over GSM Um) > inside an IP transport. Sure, but wifi is also not spoken over IP, yet we don't encapsulate our 802.11 frames into IP to show them in wireshark :-) > The existing implementations of such protocols all live outside of the > kernel but in userspace. So you either have > > a) a pure SDR software implementation of a GSM phy, whether on the MS/UE > side or on the BTS/network side, or whether in sniffing mode, running > as a userspace process. This could e.g. be airprobe or gr-gsm > > b) a OsmocomBB phone attached over serial port running the Osmocom Layer1 > firmware on the baseband processor, with some userspace program on a Linux > PC implementing higher layers > > c) GSM base station software such as osmo-bts, running in userspace > > d) Using an old nokia phone attached via serial cable to a Linux PC running > dct3-gsmtap. Sure. > So for any of those, if you want to provide real-time data streams, you have to > somehow transmit those over some kind of network technology. One could have > done raw ethernet frames or raw IP frames, but using UDP seemed straight-forward > as one can create UDP socket from non-privileged processes. This is the part I guess I don't understand. I haven't really tried, but it seems you should be able to encapsulate arbitrary protocols into 802.3 OUI-based ethertype or so? But I guess if your primary use case is actually to transport them over the network, this makes more sense. Our primary use case with wifi is much more local - capture what's going on - but do the capturing on the local system and write it to a file there. > We also have a virtual physical layer between OsmocomBB and OsmoBTS called > virt_phy where the GSMTAP over multicast IP is used to simulate/virtualize > the entire Layer1 / PHY / radio interface between phone and base station. > > Once again, all related network elements are implemented in userspace, > and having an ...? > > (speaking of versions - the docs say "version, set to 0x01 currently" > > but "#define GSMTAP_VERSION 0x02") > > Sorry, it's the usual "developer changes code but not comment". patches > are welcome, we use gerrit.osmocom.org :) Ok :-) > > 3) Does the packet data follow the gsmtap header? It's not really clear > > to me based on reading the wireshark code. > > Sure, the packet data follows the GSMTAP header, and the type of data > is defined by the GSMTAP type / sub-type as per the specific use case. As > you can see, there's 18 TYPE by now (each of which has at least one > program/implementation generating the data). Right. > I think the best way to learn about GSMTAP is to use any of the many > programs that support it by now. I think not only the examples above > use it, but meanwhile many others like the independently-developed OpenBTS > project that's unrelated to Osmocom, as are other projects implementing LTE. OK. > > In particular, the data I'm thinking of is higher-level things, like the > > session ID for a frame when it's going through the kernel, or perhaps a > > flow label on RX, etc. > > I'm not quite sure how that relates to GSM? GSMTAP so far was intended > to encapsulate ETSI/3GPP messages inside UDP/IP, particularly messages of > protocols that don't traditionally are transported over IP baesd transports. Yeah, I think here's where I got confused or just don't know enough about GSM. Basically, I was looking at it as if it was like WiFi in a sense - you have an IP frame, you're going to transport it over some physical link, so it gets PHY information in the sense of modulation etc. That doesn't seem to be the case for GSM, I guess? Does the IP frame get encapsulated in some kind of 3GPP message first, and then transported over the physical link, and the physical link info isn't even there in GSMTAP? > Having said, we're open to extending the scope - it just all needs to make > sense See above for a bit better description of what I'm trying to solve. > > I do note that this > > wouldn't be compatible with the current wireshark code as it doesn't > > check the version, just shows it... > > If that's the case that's sad, and I should have paid more attention to > it when originally writing it. We should get a related fix into > wireshark ASAP then. But then, the current dissector would just state > something like unsupported version instead of showing some garbage it > cannot parse. Either way, you will of course need new sources and > sink side implemetations. Sure. Just a note in passing. > > Or would it make more sense to define a new ARPHDR_WWANTAP like > > ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in > > IP/UDP, and then have a completely new (extensible) protocol inside of > > that? > > No userspace source would ever be able to generate such data and stream > it real-time into wireshark, would it? Sure, I can write pcap file with > such ARPHDR_* values, but I could never do this in real-time. For many > but not all use cases, that's really what it is: A vehicle to stream > real-time non-IP protocol traces into wireshark so it can visualize > the protocol traces. I think you can pipe a stream into wireshark? To me it feels like the wrong thing to actually make wireshark listen on "lo" or "eth0" or something to get data from the cellular that's (locally) generated by another application, but I guess that's only about how you think about it - and if it's not generated locally then that's an easy transport. I'm not sure it makes *sense* because then you need permissions to capture on the wired network etc. where you don't *really* need that for this stream, but it's convenient for sure. johannes From johannes at sipsolutions.net Fri Apr 12 17:15:56 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Fri, 12 Apr 2019 19:15:56 +0200 Subject: gsmtap design/extensions? In-Reply-To: <20190410234555.GO25552@nataraja> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <20190410234555.GO25552@nataraja> Message-ID: On Thu, 2019-04-11 at 01:45 +0200, Harald Welte wrote: > Hi Johannes, > > On Wed, Apr 10, 2019 at 09:23:13AM +0200, Johannes Berg wrote: > > > but unfortunately, nobody has invested time into this (yet?). > > > > 2012! > > Well, Osmocom is a very small community, with probably somewhere less than > 25 active developers over the last few years (less than 15 full-time), > with an *incredibly* large scope: Implement virtually any protocol > layer of any protocol stack on any of the 3GPP interfaces and all their > related network elements for 2G/3G as well as even other technologies > like TETRA, GMR-1, ... > > And all that in a field of technology that has less free software than > the Operating Systems world had in the mid-1990ies. It really feels a > bit like the Linux community 20 years ago. > > So resources are always *extremely* tight, and given those limited > resources, I'm actually very happy with the results by now, having > automatied CI, build verifications, unit tests, functional test suites, > end-to-end testing, and all the code we implemented on git.osmocom.org :) :-) Sure, I get it. Just a bit surprised I guess. > While current GSMTAPv2 is ugly, it works rather solid for all known > existing use cases, so there was no urgency to introduce a new version > of it. OK. > > Not sure I get this, but I also don't really care all that much. > > Well, with all respect, GSMTAP was created for a variety of use cases, > see my other lengthy mail. It's fine if you don't care, but unless you > could explain your use cases with a few paragraphs, neither you nor us > are able to determine if there is common functionality and if it makes > sense to use GSMTAP or not :) Agree. Sorry about that. No disrespect was intended, but I'm still not sure I understand the need for UDP encapsulation *as part of the protocol*. I guess saying "GSMTAP can optionally be encapsulated in UDP with the well-known port xyz" would be something else, and it'd make more sense to me than saying it has to be. > So far I have not seen any explanation about what kind of data you want > to encapsulate at all. Right, see my other mail(s) from today as well. Basically the IP frame that we're actually sending, and then attaching to that the "session" or "mux id" that it's being sent on. Sorry, I probably also don't know the right term - those show up in the drivers now. > > just a pretty strange design if the kernel were to output this, I'm not > > even sure how I'd do that properly. I don't want to be generating UDP > > packets there... > > There are well-established APIs for having sockets in the kernel and for > generating + receiving UDP packets from it. NFS has been doing this for > decades, as do various kernel-side tunneling helpers including the GTP > kernel module. > > I'm not saying it's the right approach for your problem, I'm just saying > kernel-side code can for sure use UDP sockets. Of course it *can*. But I don't think it makes *sense*. The key feature here isn't communicating with somebody else (unlike NFS, GTP, GENEVE and whatever other protocol they have). In fact, you shouldn't really care about the communication part per se at all, I'd think. > Sure, that works. But the real question is, to me: Are there common > GSMTAP payload types that both the existing GSMTAP users carry, as well > as what you would want to carry? If yes, then it makes sense to think > about a common encapsulation like GSMTAP. If the payload types differ, > then it seems rather like there are two distinct use cases that > wouldn't benefit from standardizing on one format. Agree, and I don't really know. Maybe I should start differently. Do you have an example GSMTAP capture file that I could look at in wireshark? Yes, I see you've pointed out how I can get all the software running, but if you have a file already that's almost certainly faster :-) And then the question I'd want answer is this: If there's an IP frame that I send to the modem from the application using a regular UDP or TCP socket, what would the corresponding GSMTAP capture look like? Surely it includes the IP frame in some way?! If the answer to that question is yes, then I think there is some overlap, because you can always imagine the modem receiving an IP frame and telling you more about how it was encapsulated over the air, no? Mind, most if not all modems probably don't actually do that today, but I wonder how much of that is because of lack of infrastructure to do it, vs. it just not being necessary - since I've been told that the modems do in fact often output tracing that contains information about this. Just not directly combined with the IP frame. johannes From marcel at holtmann.org Fri Apr 12 19:49:42 2019 From: marcel at holtmann.org (Marcel Holtmann) Date: Fri, 12 Apr 2019 21:49:42 +0200 Subject: gsmtap design/extensions? In-Reply-To: <1d64c578cd5b254d301cf1cac82f32a062916888.camel@sipsolutions.net> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org> <1d64c578cd5b254d301cf1cac82f32a062916888.camel@sipsolutions.net> Message-ID: Hi Johannes, >> before you go all out and define this, it would suggest to understand >> what meta-data for the connection contexts you actually need as well. >> The data path itself is just a pipe and has not all the information >> attached with it. That goes via the control path and that is normally >> in user space and carries the real important information to make >> useful analysis of how the data path / context is setup. > > Yes, that's true, though the control path is actually going through one > of the data pipes as well. I think that viewpoint is too simplistic. And for sure we have no such system where the control path is done as IP packets for Ethernet packets. >> From what I am seeing right now is that unless you have a method to >> also feed the control path into your GSMTAPv3, then this is rather >> useless. > > So the control path *itself* would be there, I guess, but ... > >> The majority of the debugging is really done for the control path. For >> oFono that is OFONO_DEBUG=1 environment variable and while it works it >> is not the most elegant solution. I would love to feed that into a >> generic debugging / tap that you can read out later. > > there's definitely room for more information than _just_ the control > path "chat", also application state etc. would be useful, and logging > etc. > > Typically on wifi we feed all of this together into kernel tracing (to > record with trace-cmd) rather than trying to encapsulate it some other > way. > >> As a side note, for Bluetooth we created a path where the bluetoothd >> can feed back its control debugging data back into the Bluetooth >> monitor in the kernel to allow combined userspace, mgmt and HCI >> tracing. Some really nasty issues could only be triaged by having all >> the meta data with a common timestamp. > > Right. This is something we'd typically use tracing for in wifi. Same thing, but different way of doing it. Mind you that Bluetooth support is older than tracing. > I don't really know what the right model for WWAN would be, I guess. > > > Right now - and I really should've said this before - really the only > problem I was thinking of was how we can mux multiple "chat" sessions > with a device into a single data stream. > > Currently, this is all vendor-specific. If you have a Qualcomm modem, > you'd be able to see all the open sessions on the underlying netdev, and > the QMI header tells you what session a given 'packet' belongs to, and > if you follow along maybe you can figure out if this is a control or IP > 'packet' (could be an AT command). > > cdc_mbim uses VLAN tags instead to achieve this, and decapsulates the > VLAN tags to send them down to the hardware in a different way. > > There are a few reasons why I think that this model of having a single > underlying netdev controlled by the modem driver, with additional > netdevs layered on top in software will not work right in the future. I > think drivers should and will need to migrate to creating "real" netdevs > for the sessions instead of pure software ones. I do not follow on why is that. Why would I care if wwan0 is self-sustained of just a VLAN device. Or for that matter any other kind of slave/child device. 3GPP and 3GPP2 are not Ethernet frame based. We only have raw IPv4 and IPv6 packets for the data path. > But if you do this, you lose the ability to listen to all the session > streams at the same time, you can only do it for each netdev. Adding > this ability back seems worthwhile, but then we probably shouldn't do it > in a vendor-specific way, but rather in a generic way. > > So basically right now that's all I'm trying to solve. In WiFi we don't > have the problem of "sessions" because we just use the addresses in the > frames to disambiguate - on such 'monitor' netdevs we see the frames > including full 802.11 headers. And for 3GPP you have context identifiers that at least within the context of the control path make logical sense of the data streams and what they are assigned to. This goes back to my original point. You need to capture the control path to see what APN context is set up and how. Mind you that you also have the fun between primary context and secondary context (primarily for quality of service in VoLTE cases). > Now, here's maybe where I'm getting off the right path - in wifi we > mostly couple that with PHY information as well, and so we have PHY > information + full 802.11 headers + data for capturing what's going on. > I figured that theoretically at least that would be possible/useful for > the modem as well (obviously control packets have no PHY data), but > there doesn't seem to be any hardware that would actually expose data in > this way. Everyone I've spoken to says these things are only available > as modem trace data. What I haven't figured out though is if that's by > some other design trade-off, or just because no such infrastructure > is/was available. > > It may well be that doing kernel-tracing instead of doing it via some > kind of monitor netdev is perfectly sufficient, but I have a feeling > that the relative simplicity of starting tcpdump/wireshark might be > preferable. As I said, as long as you do not get the QMI, AT command, MBIM etc. control path session recorded as well, you have nothing to really analyze. Regards Marcel From guy at alum.mit.edu Fri Apr 12 19:54:47 2019 From: guy at alum.mit.edu (Guy Harris) Date: Fri, 12 Apr 2019 12:54:47 -0700 Subject: gsmtap design/extensions? In-Reply-To: References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <20190410234555.GO25552@nataraja> Message-ID: <196E881D-AB4A-4569-9C1F-5BCB41FE832F@alum.mit.edu> On Apr 12, 2019, at 10:15 AM, Johannes Berg wrote: > Agree. Sorry about that. No disrespect was intended, but I'm still not > sure I understand the need for UDP encapsulation *as part of the > protocol*. I guess saying "GSMTAP can optionally be encapsulated in UDP > with the well-known port xyz" would be something else, and it'd make > more sense to me than saying it has to be. I see nothing about a struct gsmtap_hdr: http://osmocom.org/projects/baseband/wiki/GSMTAP that 1) requires that it plus the payload be encapsulated in a UDP datagram or 2) would prevent it from being at the beginning of a LINKTYPE_GSMTAP/DLT_GSMTAP packet in a pcap or pcapng file. From guy at alum.mit.edu Fri Apr 12 19:48:54 2019 From: guy at alum.mit.edu (Guy Harris) Date: Fri, 12 Apr 2019 12:48:54 -0700 Subject: gsmtap design/extensions? In-Reply-To: <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> References: <20190410233213.GN25552@nataraja> <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> Message-ID: <1089142F-2966-4C41-921B-465FBA721E79@alum.mit.edu> On Apr 12, 2019, at 5:24 AM, Johannes Berg wrote: > On Thu, 2019-04-11 at 01:32 +0200, Harald Welte wrote: > >> GSMTAP was designed as a format to encapsulate protocols normally not spoken over IP >> (such as classic GSM radio protocols, e.g. the Layer 2 LAPDm over GSM Um) >> inside an IP transport. > > Sure, but wifi is also not spoken over IP, yet we don't encapsulate our > 802.11 frames into IP to show them in wireshark :-) That's just because the rpcap protocol hasn't been revved yet to handle the new create/set options/activate mechanism in libpcap to allow monitor-mode capturing, so you only get to see fake Ethernet frames. :-) I.e., there's a split there between "capture" and "getting the packets from a capture delivered to you over an IP network". Perhaps there should be a GSMTAP link-layer header type, so you can have a GSMTAP pcap file or GSMTAP interface in a pcapng file, combined with a more general "remote capture" mechanism in libpcap so that you could capture on gsmtap://host:port and capture from a host using the GSMTAP-over-UDP encapsulation - or capture using rpcap. >> No userspace source would ever be able to generate such data and stream >> it real-time into wireshark, would it? Sure, I can write pcap file with >> such ARPHDR_* values, but I could never do this in real-time. For many >> but not all use cases, that's really what it is: A vehicle to stream >> real-time non-IP protocol traces into wireshark so it can visualize >> the protocol traces. > > I think you can pipe a stream into wireshark? 1) You could pipe into libpcap or otherwise have a way for a libpcap module to connect to a user space source and get packets from it. 2) You could pipe a pcap file into tcpdump/Wireshark/etc.. 3) You could have an extcap program: https://www.wireshark.org/docs/wsdg_html_chunked/ChCaptureExtcap.html provide packets to Wireshark. > To me it feels like the wrong thing to actually make wireshark listen on > "lo" or "eth0" or something to get data from the cellular that's > (locally) generated by another application, but I guess that's only > about how you think about it - and if it's not generated locally then > that's an easy transport. I'm not sure it makes *sense* because then you > need permissions to capture on the wired network etc. Depending on how your system is set up: $ ls -l /dev/bpf* crw-rw---- 1 root access_bpf 23, 0 Apr 10 22:57 /dev/bpf0 crw-rw---- 1 root access_bpf 23, 1 Apr 10 22:56 /dev/bpf1 ... and it could just be rw-rw-rw-. Perhaps other systems make it harder to grant capture privileges. > where you don't *really* need that for this stream If there's a need for that, whatever provides the packets could impose that (by finding out the UID/GID of the other process if this is going over a UNIX-domain socket, at least on some UN*Xes, or by requiring a login if this is going over a network). From guy at alum.mit.edu Fri Apr 12 22:47:26 2019 From: guy at alum.mit.edu (Guy Harris) Date: Fri, 12 Apr 2019 15:47:26 -0700 Subject: gsmtap design/extensions? In-Reply-To: <196E881D-AB4A-4569-9C1F-5BCB41FE832F@alum.mit.edu> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <20190410234555.GO25552@nataraja> <196E881D-AB4A-4569-9C1F-5BCB41FE832F@alum.mit.edu> Message-ID: <1D6FE33B-DC15-47D8-A1AD-E95608300FDC@alum.mit.edu> On Apr 12, 2019, at 12:54 PM, Guy Harris wrote: > I see nothing about a struct gsmtap_hdr: > > http://osmocom.org/projects/baseband/wiki/GSMTAP > > that... > > 2) would prevent it from being at the beginning of a LINKTYPE_GSMTAP/DLT_GSMTAP packet in a pcap or pcapng file. With a specification based on http://cgit.osmocom.org/libosmocore/plain/include/osmocom/core/gsmtap.h From laforge at gnumonks.org Sat Apr 13 06:41:52 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 13 Apr 2019 08:41:52 +0200 Subject: gsmtap design/extensions? In-Reply-To: <1D6FE33B-DC15-47D8-A1AD-E95608300FDC@alum.mit.edu> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <20190410234555.GO25552@nataraja> <196E881D-AB4A-4569-9C1F-5BCB41FE832F@alum.mit.edu> <1D6FE33B-DC15-47D8-A1AD-E95608300FDC@alum.mit.edu> Message-ID: <20190413064152.GB24451@nataraja> Dear Guy and others, On Fri, Apr 12, 2019 at 03:47:26PM -0700, Guy Harris wrote: > On Apr 12, 2019, at 12:54 PM, Guy Harris wrote: > > > I see nothing about a struct gsmtap_hdr: > > http://osmocom.org/projects/baseband/wiki/GSMTAP > > that... > > 2) would prevent it from being at the beginning of a LINKTYPE_GSMTAP/DLT_GSMTAP packet in a pcap or pcapng file. > With a specification based on > http://cgit.osmocom.org/libosmocore/plain/include/osmocom/core/gsmtap.h I completely agree that there is no technical reason why one couldn't put GSMTAP headers in current (v2) or future formats inside an ETHERTYPE / DLT and have them natively appearing in a pcap file of the given DLT. There would be no objections from my side to do so. One could then simply call the same dissector in wireshark from that DLT or from the existing UDP port number based dispatch via the IANA-registered GSMTAP port number. However, among the existing users of GSMTAP in the last decade or so, there would be no advantage, as the related sources of GSMTAP frames all exist in userspace and are feeding data, particularly from potentially multiple sources, which can very well run on different hosts. But that of course doesn't prevent new users from using different transport mechanisms of getting GSMTAP from e.g. the kernel into userspace. 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 Sat Apr 13 07:12:27 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 13 Apr 2019 09:12:27 +0200 Subject: gsmtap design/extensions? In-Reply-To: References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <20190410234555.GO25552@nataraja> Message-ID: <20190413071227.GC24451@nataraja> Hi Johannes, On Fri, Apr 12, 2019 at 07:15:56PM +0200, Johannes Berg wrote: > Agree. Sorry about that. No disrespect was intended, but I'm still not > sure I understand the need for UDP encapsulation *as part of the > protocol*. I guess saying "GSMTAP can optionally be encapsulated in UDP > with the well-known port xyz" would be something else, and it'd make > more sense to me than saying it has to be. Sure, like with most protocols you can wrap them in anything you want. Let me put it like this: You don't have to run RTP inside UDP, you could equally put the RTP frames in to SCTP or DCTP. It's just not what the original users of the protocol/spec had envisioned, but it can for sure be done, and has no side-effect other than not being interoperable with existing implementations. > Right, see my other mail(s) from today as well. Basically the IP frame > that we're actually sending, and then attaching to that the "session" or > "mux id" that it's being sent on. Sorry, I probably also don't know the > right term - those show up in the drivers now. So it's basically the information whch PDP/PDN context your user IP packet belongs to. A single integer "tag". that resembles the identifier that was used by the control plane when activating that context (which is basically a tunnel). > > Sure, that works. But the real question is, to me: Are there common > > GSMTAP payload types that both the existing GSMTAP users carry, as well > > as what you would want to carry? If yes, then it makes sense to think > > about a common encapsulation like GSMTAP. If the payload types differ, > > then it seems rather like there are two distinct use cases that > > wouldn't benefit from standardizing on one format. > > Agree, and I don't really know. >From what I can tell after the burst of e-mails in this thread so far, I don't think there's much commonality here. A modem will "never" give you access to the actual cellular protocol layers that we care about in the Osmocom/srsLTE/YateBTS/OpenBTS/airprobe/gr-gsm/... world, for which GSMTAP was designed (see more below). I'm not saying it cannot be done. If you want to use GSMTAP, I'm happy to help. But at least so far, I don't see why it would make any sense. > Maybe I should start differently. Do you have an example GSMTAP capture > file that I could look at in wireshark? Yes, I see you've pointed out > how I can get all the software running, but if you have a file already > that's almost certainly faster :-) There are a couple of files attached at https://osmocom.org/projects/baseband/wiki/WiresharkIntegration > And then the question I'd want answer is this: If there's an IP frame > that I send to the modem from the application using a regular UDP or TCP > socket, what would the corresponding GSMTAP capture look like? Surely it > includes the IP frame in some way?! GSMTAP was generated initially for GSM. GSM is a circuit-switched digital wireless telephony system that has no inherent/native way of transporting IP payload. As such, the GSMTAP Um captures linked above will not contain IP user data but will contain the signaling plane data of the Um air interface protocol stack, consisting of the LAPDm potocol on Layer2 and the TS 04.08 RR (Radio Resource), MM (Mobility Management) and CC (Call Control) data. Of course one can also use GSMTAP for GPRS, which is packet oriented. In this case, you have the following layering stack inside a GSMTAP Um frame: TCP IP SNDCP (TS 04.65) LLC (TS 04.64) RLC/MAC PHY There is segmentation/reassembly potentially at least at the LLC and at the RLC/MAC layer. There can be encryption at the LLC layer so the IP payload is already invisible at that point. You cab also have both header and payload compression at the SNDCP layer. In the end, you can have start/middle/end segments of LLC frames inside a single RLC/MAC block, belonging to either one or multiple LLC frames, and then the LLC frames contain [segments of] IP packets. GSMTAP can be used on various other interfaces of the cellular network, which are *not* the radio interface between modem/phone and base station (such as e.g. between the Phone and the SIM card), so they're not of interest to your use case and I'll not cover them here. GSMTAP can also be used to encapsulate later cellular technologies such as UMTS aka WCDMA aka 3G, or LTE aka 4G. In all those cases you always have a different (sometimes deeper and sometimes not so deep) protocol stack between the user IP payload and the actual radio interface (PHY). You can think of it a bit if you are not thinking about a User IP packet but you assume for the sake of an argument that you want to see "HTML". Then underneath HTML you either have, depending on the technoolgy, HTTP 1.0, 1.1 or 2.0. And under that you can have any number of additional protocol stacking whether it's TCP based, with or without SSL or TLS, with IPv3 or IPv6, with or without IPsec, inside a VLAN or not, ... - and most importantly, next to all of that you have important "control information" like let's say DHCP or neighbor discovery. So, in other words, the user IP plan is *very* far away from the PHY on the radio interface, and the really interesting things are those that are happening beneath or next to the user IP. However, commercially available cellular modems will go to the utmost extent to make sure you never have access to any of this, and they invent various different ways to make the user (whether that's ofono, the ModemManager, ...) as far away from that as possible. The interfaces between the cellular protocol stacks and the user (whether QMI, MBIM, AT commands, ...) are so abstract that virtually any useful resemblance to what happens on the actual radio interface is lost. You can get a glimpse to some of what's happening with Qualcomm DIAG protocol, but even that doesn't really [always] expose full protocol traces to you, particularly not on the user plane. > If the answer to that question is yes, then I think there is some > overlap, because you can always imagine the modem receiving an IP frame > and telling you more about how it was encapsulated over the air, no? Not really. The modem implements the entire protocol stacks for the various cellular technologies and in the end provides you as the user something like a tunnel endpoint. > Mind, most if not all modems probably don't actually do that today, but > I wonder how much of that is because of lack of infrastructure to do it, > vs. it just not being necessary - since I've been told that the modems > do in fact often output tracing that contains information about this. > Just not directly combined with the IP frame. The most widespread technology to obtain tracing/debugging information is the Qualcomm DIAG protocol, which is a collection of dozens of sub-systems each of whcih has up to hundreds of individual flags/settings of categories that can be enabled and/or disabled. We once did a bit of development in that area, see osmo-qcdiag to enable this (http://git.osmocom.org/osmo-qcdiag/) as well as *extremely minimal* wireshark dissectors at http://git.osmocom.org/wireshark/log/?h=laforge/qcdiag However, this is a proprietary mechanism available only to Qualcomm stack based devices, will only work on those devices where one has figured out how to enable an access it. And the information it provides is completely asynchronous to the user IP plane. There is a similar project for (now very old) Infineon XGold based phones, see https://github.com/2b-as/xgoldmon. It also generates GSMTAP. But AFAIR only for the control plane data and not the user plane data. To be honest, I don't even think there's a lot of context that one could theoretically provide "attached" to the user IP packet, as the interesting bits are happening at lower protocol layers, and due to segmentation/reassembly/compression/... etc. there is no 1:1 mapping between the user IP packet and what's happening on the radio interface. 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 guy at alum.mit.edu Sat Apr 13 07:36:39 2019 From: guy at alum.mit.edu (Guy Harris) Date: Sat, 13 Apr 2019 00:36:39 -0700 Subject: gsmtap design/extensions? In-Reply-To: <20190413064152.GB24451@nataraja> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <20190410234555.GO25552@nataraja> <196E881D-AB4A-4569-9C1F-5BCB41FE832F@alum.mit.edu> <1D6FE33B-DC15-47D8-A1AD-E95608300FDC@alum.mit.edu> <20190413064152.GB24451@nataraja> Message-ID: On Apr 12, 2019, at 11:41 PM, Harald Welte wrote: > But that of course doesn't prevent new users from using different > transport mechanisms of getting GSMTAP from e.g. the kernel into > userspace. Nor does it prevent libpcap (once I generalize the remote-capture mechanism) from supporting gsmtap://{host}[:port] (port optional) URLs that cause it to set up a UDP ({PF_INET or PF_INET6}, SOCK_DGRAM, IPPROTO_UDP) socket on which to receive UDP packets from the specified host (at the specified port or, if no port is specified, the default GSMTAP socket) and supplying packets that begin with a GSMTAP header, with a new linktype of LINKTYPE_GSMTAP/DLT_GSMTAP. From laforge at gnumonks.org Sat Apr 13 07:35:05 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 13 Apr 2019 09:35:05 +0200 Subject: gsmtap design/extensions? In-Reply-To: <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> References: <20190410233213.GN25552@nataraja> <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> Message-ID: <20190413073505.GD24451@nataraja> Hi Johannes, I'll only adress some of the points that haven't been clarified in other mails in this thread alreasdy: On Fri, Apr 12, 2019 at 02:24:25PM +0200, Johannes Berg wrote: > Kernel drivers need to transport multiple data streams, like VoLTE (IP) > data, IP data, and control data. Currently, they do this in various ways > (cdc_mbim uses VLAN tags, rmnet/qmi_wwan uses Qualcomm QMI headers), > when you capture data you have to understand what you're dealing with > and maybe extend wireshark to even understand these headers. > > I'm looking for a general vendor-agnostic encapsulation that would solve > this part of the problem. understood. > At the same time, I come from WiFi, where - while we don't have these > sessions as such but can have different virtual interfaces as well, e.g. > for connections to different APs - it's often very useful to also > understand the PHY parameters that were used for TX/seen on RX. Now, I > realize this isn't something that modems will do right now - they just > don't seem to tell you any lower-level information on RX of a packet, > but it seemed like it might be worthwhile to not *exclude* this > possibility either. Agreed. However, the protocol stacks on WiFi and cellular technologies are very different, to say the least. There is no easy mapping of PHY related parameters to a given IP packet, and the related quality metrics of the radio channels don't work that way. But yes, I agree, that whatever transport mechanism you wan to use between the modem and the user/Linux side should allow for additional, extensible metadata beyond the identifier of the PDP/PDN context. > > GSMTAP was designed as a format to encapsulate protocols normally not spoken over IP > > (such as classic GSM radio protocols, e.g. the Layer 2 LAPDm over GSM Um) > > inside an IP transport. > > Sure, but wifi is also not spoken over IP, yet we don't encapsulate our > 802.11 frames into IP to show them in wireshark :-) This is because your 802.11 implementations are in hardware, while the open source GSM/UMTS/LTE implementations using GSMTAP are implemented in userspace - or at the very least the higher-level parts of the protocol stacks, or the tracing frameworks that are used to generate the GSMTAP data from some hardware. > This is the part I guess I don't understand. I haven't really tried, but > it seems you should be able to encapsulate arbitrary protocols into > 802.3 OUI-based ethertype or so? But why? I'm in an userspace program, and I want to send data to one or more other userspace programs. Why would I not simply open a UDP socket to do so? I would have to have CAP_NET_RAW and open a packet socket, and then generate ethernet frames from that? I admit that the use case with wireshark is a bit odd, but there are other receivers out there. Also, for debugging cellular network elements, it's very useful if you can look at the RAN or core network interfaces (Abis, Gb, Gp, A, Iu, S1, ...) in the same protocol trace in which you also get traces from the radio interface in GSMTAP. Then you can see what happens at each and every interface / network element in one time-line. And as the Osmcoom programs also allow generating log output wrapped in GSMTAP, you get not only protocol traces of all the interfaces, but even textual log information (with machine-readable log level + sub-system) information all in one capture/timeline. > But I guess if your primary use case is actually to transport them over > the network, this makes more sense. The use cases differ, but having UDP encapsulation enables a lot of flexibility and has been proven very useful so far. > Our primary use case with wifi is much more local - capture what's going > on - but do the capturing on the local system and write it to a file > there. Yes, you're looking only at a single interface (the radio interface between one BSS and one STA). You're not looking at five different interfaces at five different levels of network hierarchy/topology in the "wifi controller" and want to mix in a radio interface trace in the same timeline. > > We also have a virtual physical layer between OsmocomBB and OsmoBTS called > > virt_phy where the GSMTAP over multicast IP is used to simulate/virtualize > > the entire Layer1 / PHY / radio interface between phone and base station. > > > > Once again, all related network elements are implemented in userspace, > > and having an > > ...? sorry. '... UDP based transport is ahat enables theis use case' > Basically, I was looking at it as if it was like WiFi in a sense - you > have an IP frame, you're going to transport it over some physical link, > so it gets PHY information in the sense of modulation etc. As stated elsewhere, there's an M:N mapping between user (IP) payload and actual radio interface "MAC blocks", so I'm not aware of anyone mapping radio interface performance to user plane IP. > That doesn't seem to be the case for GSM, I guess? Does the IP frame get > encapsulated in some kind of 3GPP message first, and then transported > over the physical link, and the physical link info isn't even there in > GSMTAP? the "physical link info" is present in GSMTAP, but the granularity of GSMTAP frames is not user-IP frames, but "MAC blocks". So your user IP frame might not be visible as it's still compressed, encrypted, fragmented, etc. > > > Or would it make more sense to define a new ARPHDR_WWANTAP like > > > ARPHDR_IEEE80211_RADIOTAP and just use that instead of encapsulating in > > > IP/UDP, and then have a completely new (extensible) protocol inside of > > > that? > > > > No userspace source would ever be able to generate such data and stream > > it real-time into wireshark, would it? Sure, I can write pcap file with > > such ARPHDR_* values, but I could never do this in real-time. For many > > but not all use cases, that's really what it is: A vehicle to stream > > real-time non-IP protocol traces into wireshark so it can visualize > > the protocol traces. > > I think you can pipe a stream into wireshark? > > To me it feels like the wrong thing to actually make wireshark listen on > "lo" or "eth0" or something to get data from the cellular that's > (locally) generated by another application, I admit it's a bit odd. But has been very useful, particularly in more distributed setups with creating a shared timeline of various GSMTAP sources that may or may not run on the same machine. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From guy at alum.mit.edu Sat Apr 13 07:49:59 2019 From: guy at alum.mit.edu (Guy Harris) Date: Sat, 13 Apr 2019 00:49:59 -0700 Subject: gsmtap design/extensions? In-Reply-To: <20190413071227.GC24451@nataraja> References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <20190410234555.GO25552@nataraja> <20190413071227.GC24451@nataraja> Message-ID: <7C48A51C-852F-480B-9F6D-C5BFEBB1A389@alum.mit.edu> On Apr 13, 2019, at 12:12 AM, Harald Welte wrote: > On Fri, Apr 12, 2019 at 07:15:56PM +0200, Johannes Berg wrote: > >> Agree. Sorry about that. No disrespect was intended, but I'm still not >> sure I understand the need for UDP encapsulation *as part of the >> protocol*. I guess saying "GSMTAP can optionally be encapsulated in UDP >> with the well-known port xyz" would be something else, and it'd make >> more sense to me than saying it has to be. > > Sure, like with most protocols you can wrap them in anything you want. > > Let me put it like this: > You don't have to run RTP inside UDP, you could equally put the RTP > frames in to SCTP or DCTP. It's just not what the original users of > the protocol/spec had envisioned, but it can for sure be done, and has > no side-effect other than not being interoperable with existing > implementations. Or you can just have LINKTYPE_RTP/DLT_RTP and supply them inside nothing. However, unlike RTP, there is no reason *not* to do that for GSMTAP - it's not as if the IP or UDP headers in a packet from a host supplying GSMTAP-encapsulated packets provide any information necessary or even useful for dissecting the encapsulated packets. Whether it's useful, or possible, to have any interfaces on a *host* with cellular modem connectivity supply the cellular-network traffic as packets with GSMTAP headers - which appears to be what Johannes is thinking of - is another matter (but even if the answer is no, there is, as per my other message, a use for a LINKTYPE_GSMTAP/DLT_GSMTAP header type). That might not be possible, as cellular modems, as you note, tend to hide a lot of lower-layer details from the host. From guy at alum.mit.edu Sat Apr 13 07:55:29 2019 From: guy at alum.mit.edu (Guy Harris) Date: Sat, 13 Apr 2019 00:55:29 -0700 Subject: gsmtap design/extensions? In-Reply-To: <20190413073505.GD24451@nataraja> References: <20190410233213.GN25552@nataraja> <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> <20190413073505.GD24451@nataraja> Message-ID: <3658DF8E-535E-43C6-95FD-CE61E3A7164F@alum.mit.edu> On Apr 13, 2019, at 12:35 AM, Harald Welte wrote: > the "physical link info" is present in GSMTAP, but the granularity of > GSMTAP frames is not user-IP frames, but "MAC blocks". So your user IP > frame might not be visible as it's still compressed, encrypted, > fragmented, etc. The granularity of Ethernet frames is not user IP frames, but Ethernet datagrams, so you user IP frame might not be visible as it's fragmented (the fragments might still be IP datagrams, but they would have to be reassembled - which Wireshark, for example, does, for those people still doing NFS-over-UDP :-)). "Encrypted" may not apply there, but it *does* apply for 802.11 frames on a protected network (which Wireshark can decrypt, if you have 1) the network password for WEP or WPA-Personal and 2) the EAPOL handshake for WPA-Personal). From laforge at gnumonks.org Sat Apr 13 09:50:56 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 13 Apr 2019 11:50:56 +0200 Subject: OpenBSC on 3rd party MSC In-Reply-To: <000d01d4f0a1$2cdb08a0$869119e0$@corrections.com> References: <000d01d4f0a1$2cdb08a0$869119e0$@corrections.com> Message-ID: <20190413095056.GI24451@nataraja> Hi Weiqi, On Thu, Apr 11, 2019 at 04:00:08PM -0400, wyao at corrections.com wrote: > I am working on get OpenBSC connected to a 3rd party MSC, I read from the > Osmo document that I can use the bsc only mode and the osm-bsc instead of > the osmo-nitb. This is correct. However, the terminology is a bit messed-up. So it's best to not use OpenBSC anymore but alsways call it OsmoBSC. > Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp > configured and and running, sidenote: You will have to add osmo-mgw for handling voice calls later on, but that is irrelevant until you get the signalling plane up and running. > but I see a lot of below error logs in the osmo-stp console: > > DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): sctp_recvmsg() returned 56 (flags=0x80) > DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA) > DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer > DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1 dpc=185=0.23.1 > DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing > DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route! Your SS7 routing seems to be misconfigured. The STP receives SCCP from OsmoBSC, but there's no (currently active/working) route for the MSC. Hence the message cannot be routed and is discarded. > <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP RESET message... > <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP The BSC is trying to send a BSSMAP RESET to the MSC, but there's no response. > Can anyone identify what is the issue here? It's a SS7 routing / SIGTRAN configuration issue. You need to make sure the osmo-stp and osmo-bsc SS7 related configuration exactly matches the configuration on the MSC side. Also, depending on your SIGTRAN network setup, you may not even need osmo-stp. That would be the case e.g. if the MSC or an existing STP in your core network would already provide a M3UA SGW functionality to which the AS/ASP of OsmoBSC can connect to. It's really not possible to give you an easy answer without fully understanding your core networks SS7/SIGTRAN configuration, routing, addresses, point codes, etc. SIGTRAN and SS7 are rather complex protocol stacks themselves. There's little we can do on the Osmocom side to avoid that. We can just provide all the possible settings/options so you can configure it to match your network topology. 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 johannes at sipsolutions.net Mon Apr 15 09:11:54 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Mon, 15 Apr 2019 11:11:54 +0200 Subject: gsmtap design/extensions? In-Reply-To: References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org> <1d64c578cd5b254d301cf1cac82f32a062916888.camel@sipsolutions.net> Message-ID: <92e8e142b6d441c1c995abc57d64ad7b7747a688.camel@sipsolutions.net> On Fri, 2019-04-12 at 21:49 +0200, Marcel Holtmann wrote: > > > Yes, that's true, though the control path is actually going through one > > of the data pipes as well. > > I think that viewpoint is too simplistic. And for sure we have no such > system where the control path is done as IP packets for Ethernet > packets. That's true, but as far as I can tell in a lot of cases the pipe is actually still a virtual netdev (session, encoded in whatever way) using some sort of serial line format on top? But I agree that typically this will not be sufficient anyway. > > Right. This is something we'd typically use tracing for in wifi. > > Same thing, but different way of doing it. Mind you that Bluetooth > support is older than tracing. Sure. Looking forward though, perhaps tracing *would* indeed be the simplest thing to do. > > There are a few reasons why I think that this model of having a single > > underlying netdev controlled by the modem driver, with additional > > netdevs layered on top in software will not work right in the future. I > > think drivers should and will need to migrate to creating "real" netdevs > > for the sessions instead of pure software ones. > > I do not follow on why is that. Why would I care if wwan0 is self- > sustained of just a VLAN device. Or for that matter any other kind of > slave/child device. >From a driver perspective I think it makes a difference. For example, if you just have a single netdev from the driver, it gets harder to do multiple TX/RX queues properly. > 3GPP and 3GPP2 are not Ethernet frame based. We only have raw IPv4 and > IPv6 packets for the data path. Sure. Though some drivers/devices fake them anyway. > And for 3GPP you have context identifiers that at least within the > context of the control path make logical sense of the data streams and > what they are assigned to. This goes back to my original point. You > need to capture the control path to see what APN context is set up and > how. Mind you that you also have the fun between primary context and > secondary context (primarily for quality of service in VoLTE cases). Right. > > It may well be that doing kernel-tracing instead of doing it via some > > kind of monitor netdev is perfectly sufficient, but I have a feeling > > that the relative simplicity of starting tcpdump/wireshark might be > > preferable. > > As I said, as long as you do not get the QMI, AT command, MBIM etc. > control path session recorded as well, you have nothing to really > analyze. But you do - afaict there are no ways other than the netdevs to communicate with the device, and people do things like "socat" to set up PTYs and pretend to have serial channels there, on top of the netdevs? johannes From johannes at sipsolutions.net Mon Apr 15 09:26:22 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Mon, 15 Apr 2019 11:26:22 +0200 Subject: gsmtap design/extensions? In-Reply-To: <20190413073505.GD24451@nataraja> References: <20190410233213.GN25552@nataraja> <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> <20190413073505.GD24451@nataraja> Message-ID: <77ac708e198c8b04f45e47f53f63bd2f4ed006df.camel@sipsolutions.net> Hi Harald, > Agreed. However, the protocol stacks on WiFi and cellular technologies > are very different, to say the least. There is no easy mapping of PHY > related parameters to a given IP packet, and the related quality metrics > of the radio channels don't work that way. Sure. I'm (vaguely) aware of that. > But yes, I agree, that whatever transport mechanism you wan to use between the modem > and the user/Linux side should allow for additional, extensible metadata beyond > the identifier of the PDP/PDN context. Really the question it goes down to is whether there's possible overlap here with GSMTAP or not. If yes - we can define a GSMTAPv3, with TLVs or so, and add a "PDP/PDN context" or "session" field or something like that, and maybe a tag that says "IP packet is here", or some kind of "content type" field. I expect there would be some such "sessions" that actually just transport the local AT command chat. If no, I guess we'll just define something else for this use case? Or, perhaps, even get rid of it entirely and just rely on trace-cmd recording or so, though then I guess we'd really want to teach libpcap and/or wireshark to understand this in some way. Though it almost sounds like in GSMTAP you're never actually transporting IP data, but other types of packets that in turn transport the (fragmented/compressed/encrypted) IP data. That would kinda mean there's very little potential overlap. > > This is the part I guess I don't understand. I haven't really tried, but > > it seems you should be able to encapsulate arbitrary protocols into > > 802.3 OUI-based ethertype or so? > > But why? I'm in an userspace program, and I want to send data to one or > more other userspace programs. Why would I not simply open a UDP socket > to do so? I would have to have CAP_NET_RAW and open a packet socket, > and then generate ethernet frames from that? > > I admit that the use case with wireshark is a bit odd, but there are > other receivers out there. Yeah, ok. I was thinking kinda the other way around - if all you need is network transparency for wireshark it shouldn't matter, but that's really discussed over in the other subthread with Guy Harris better. Anyway it doesn't matter, and I'm beginning to understand that a (maybe even the primary) use case is getting multiple parts of your stack to talk to each other (over UDP). > Yes, you're looking only at a single interface (the radio interface > between one BSS and one STA). You're not looking at five different > interfaces at five different levels of network hierarchy/topology in the "wifi > controller" and want to mix in a radio interface trace in the same > timeline. Indeed. Well, actually, we often do, but use different mechanics for that (trace-cmd record comes to mind, it records all our driver/fw chat as well as possibly adding in logging from wpa_supplicant etc.) > > Basically, I was looking at it as if it was like WiFi in a sense - you > > have an IP frame, you're going to transport it over some physical link, > > so it gets PHY information in the sense of modulation etc. > > As stated elsewhere, there's an M:N mapping between user (IP) payload > and actual radio interface "MAC blocks", so I'm not aware of anyone > mapping radio interface performance to user plane IP. Right, OK. > the "physical link info" is present in GSMTAP, but the granularity of > GSMTAP frames is not user-IP frames, but "MAC blocks". So your user IP > frame might not be visible as it's still compressed, encrypted, > fragmented, etc. Sure. As Guy Harris pointed out, this is also true for wifi though - we don't have compression, but certainly encryption & fragmentation, wireshark was taught to handle that and recreate the original MSDU (mac service data unit). johannes From johannes at sipsolutions.net Mon Apr 15 09:28:30 2019 From: johannes at sipsolutions.net (Johannes Berg) Date: Mon, 15 Apr 2019 11:28:30 +0200 Subject: gsmtap design/extensions? In-Reply-To: <1089142F-2966-4C41-921B-465FBA721E79@alum.mit.edu> References: <20190410233213.GN25552@nataraja> <1462659018bc40830efbe2348791b8df45b54cff.camel@sipsolutions.net> <1089142F-2966-4C41-921B-465FBA721E79@alum.mit.edu> Message-ID: <446da2afcad3c7bb539027147030649ad08f3f33.camel@sipsolutions.net> On Fri, 2019-04-12 at 12:48 -0700, Guy Harris wrote: > I.e., there's a split there between "capture" and "getting the packets > from a capture delivered to you over an IP network". Right. That's what I was trying to get at, you said it much more succinctly. > Depending on how your system is set up: > > $ ls -l /dev/bpf* > crw-rw---- 1 root access_bpf 23, 0 Apr 10 22:57 /dev/bpf0 > crw-rw---- 1 root access_bpf 23, 1 Apr 10 22:56 /dev/bpf1 > > ... > > and it could just be rw-rw-rw-. Perhaps other systems make it harder > to grant capture privileges. Yeah, generally it's not that *hard*. It still seems *wrong*, and e.g. it would also mean if you do need to do it remotely you'd have to filter out your own remote control (ssh) traffic lest you cause traffic amplification, etc. johannes From bjorn at mork.no Mon Apr 15 10:29:09 2019 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Mon, 15 Apr 2019 12:29:09 +0200 Subject: gsmtap design/extensions? In-Reply-To: <92e8e142b6d441c1c995abc57d64ad7b7747a688.camel@sipsolutions.net> (Johannes Berg's message of "Mon, 15 Apr 2019 11:11:54 +0200") References: <46474c61d7748042cc0a1f23773186786020638e.camel@sipsolutions.net> <6F1998DC-EFD2-4145-BD81-A80F9DC7ED2D@holtmann.org> <1d64c578cd5b254d301cf1cac82f32a062916888.camel@sipsolutions.net> <92e8e142b6d441c1c995abc57d64ad7b7747a688.camel@sipsolutions.net> Message-ID: <87d0ln1s0a.fsf@miraculix.mork.no> Johannes Berg writes: >> As I said, as long as you do not get the QMI, AT command, MBIM etc. >> control path session recorded as well, you have nothing to really >> analyze. > > But you do - afaict there are no ways other than the netdevs to > communicate with the device, I don't understand where you are going here? Neither QMI, AT command nor MBIM management are transported over netdevs. AT is usually transported using simple USB bulk streams, exported to userspace as tty devices by some USB serial driver. Both QMI and MBIM management are transported as USB control messages, and exported to userspace as chardevs. There are no netdevs involved. > and people do things like "socat" to set up > PTYs and pretend to have serial channels there, on top of the netdevs? I assume you are referring to my MBIM DSS examples here. I don't know if anyone is actually using that, so you should probably ignore it... I'll happily admit it was a bad idea. Should have just added the necessary code to map DSS channels to some sort of character device in the driver, like most users requested. But there really isn't anything in the MBIM spec saying how DSS should be used. DSS is a generic data stream. Could easily be connected to a single TCP session for example, in which case you'd probably want to connect it to a TCP session in the other end too. So I wouldn't want to force DSS into character devices on the host end. This doesn't rule out a userspace controlled optional mapping though. We could probably still add that, replacing the VLAN mapping with a chardev for a specific DSS session if requested by userspace. I guess this is something to consider for a generic cellular framework - supporting non-ip data streams between modem and host. Adding to my previous excuses: The DSS implementation in the cdc_mbim driver was added without having seen a single modem firmware with *any* type of DSS support. It was purely based on spec{ification,culation}. The VLAN mapping, along with examples of how to use socat to further map the streams from VLANs into suitable application specific forms, seemed like a simple and flexible enough solution. Bj?rn From rafael at rhizomatica.org Mon Apr 15 12:12:41 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Mon, 15 Apr 2019 09:12:41 -0300 Subject: LimeNet Micro for BTS In-Reply-To: <57d81340-3781-6df7-a9cb-c18d9903a7e7@sysmocom.de> References: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> <20190412080242.GC25552@nataraja> <57d81340-3781-6df7-a9cb-c18d9903a7e7@sysmocom.de> Message-ID: Hi Joachim, This is all very encouraging! I did not even know the Lime could work with USB 2 - thanks! I just realized I have limesuite18.06 (from debian repo) and limesuite18.10 (osmocom repo), but I'll upgrade it to git, re-compile everything and re-run all previous tests I did here. Kind regards, Rafael Diniz On 4/12/19 1:02 PM, Joachim Steiger wrote: > > > On 4/12/19 4:05 PM, Rafael Diniz wrote: > >> It is a SDR hardware, but conceived, as far as I understand, with GSM >> usage in mind, considering the integrated GPSDO and so on. As soon as I >> put my hands on it I'd like to evaluate if it's worth invest some time >> to develop a housing for it and appropriate connections for a very low >> power and low cost BTS. > > i have gotten it to work quite fast with help of the patchset i am > working on. > it behaves mostly like a limesdr mini with a few addons and proper clock. > you currently also need limesuite git master, the tagged 19.01 is too old. > >>>> With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, >>>> with lots of failure messages... > > i have the same problem. > i usually i only use usb2 due to it being much more solid that way. > it should not matter anyhow, since we only need low bandwith for gsm. > >>> I'm sorry to hear this. We're trying to address various problems >>> related to LimeSDR devices for quite some time, but progress is >>> unfortunately not as quick as one would hope, particularly as LimeSuite >>> also evolves and every major version seems to behave quite differently, >>> at least in the way how OsmoTRX is using the API. > > well.. there are a couple of things coming together: > limesuite did indeed change its behaviour when it comes to a few things. > * it got more streamlined and with it the default settings. e.g. > channel0 isnt enabled by default anymore. > * some not defined behaviours changed, on which we relied. > * i have reordered some of the function calls we do: > limesuite doesn't like if you do your filtersetup, frequency, gain, > streaming setup and calibration setup in the wrong order. sadly, neither > our code nor lms has enough asserts to have anybody notice this soon enough. > the good news is: the crew of lime is completely on mission helping us > get this sorted. > >>> In recent weeks, Joachim has been making very good progress with help >>> from Lime to resolve some of the most long-standing issues related to >>> RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...). >>> There should be a patchset pushed to gerrit soon which will address this >>> one class of problems. However, this does not adress any USB stability >>> related problems, which is a separate class of issues. We have to look >>> at them once as a time > > ack, also see below > >> This is great, thanks for the report! I hope to have USB problems put >> aside with the LimeNET Micro, this is one of the reasons of my question. > > not really. there IS a spi (or rather 2) connection(s) inbetween the > fpga and the rpi according to the documentation, but there is also the > ftdi601 bridge like used on the lime mini on the board. > this is afaik due to the spi link not achieving high enough bandwidth to > satisfy all involved. > since the rpi is only usb2, this is also limited.... but i dont see any > major issues for using it as a gsm trx. > >>> One thing I'm a bit missing here is: Where are your comprehensive bug >>> reports about this in the osmocom issue tracker? Particularly with >>> problems that manifest themselves only every few hours and hence are >>> not quick to reproduce, we have to collect those issues and related >>> log files, backtraces, ... in the issue tracker. >> >> I'll do this in the next couple of days, sorry for sending the email in >> advance of the actual bug report. > ps: what would help me out a lot, would be if every bugreport not only > references 'limesdr' but also has detail of: > * which model (mini, usb, net-micro?...) and revision? > * which gateware and firmware release was installed? > * which limesuite release or git version? > > kind regards > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rafael at rhizomatica.org Mon Apr 15 14:14:28 2019 From: rafael at rhizomatica.org (Rafael Diniz) Date: Mon, 15 Apr 2019 11:14:28 -0300 Subject: LimeNet Micro for BTS In-Reply-To: References: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> <20190412080242.GC25552@nataraja> <57d81340-3781-6df7-a9cb-c18d9903a7e7@sysmocom.de> Message-ID: Btw, before any bug report (as I need to upgrade the limesuite and rebuild stuff), after some time running osmo-trx-lms (from osmocom nightly builds), I get: (...) <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19c154 got 3f19e134 (3f19e134) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19cb18 got 3f19eaf8 (3f19eaf8) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19d4dc got 3f19f4bc (3f19f4bc) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19dea0 got 3f19fe80 (3f19fe80) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19e864 got 3f1a0844 (3f1a0844) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19f228 got 3f1a1208 (3f1a1208) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f19fbec got 3f1a1bcc (3f1a1bcc) diff=1fe0 <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len 2500 expect 3f1a05b0 got 3f1a2590 (3f1a2590) diff=1fe0 (...) Rafael Diniz On 4/15/19 9:12 AM, Rafael Diniz wrote: > Hi Joachim, > > This is all very encouraging! I did not even know the Lime could work > with USB 2 - thanks! > > I just realized I have limesuite18.06 (from debian repo) and > limesuite18.10 (osmocom repo), but I'll upgrade it to git, re-compile > everything and re-run all previous tests I did here. > > Kind regards, > Rafael Diniz > > On 4/12/19 1:02 PM, Joachim Steiger wrote: >> >> >> On 4/12/19 4:05 PM, Rafael Diniz wrote: >> >>> It is a SDR hardware, but conceived, as far as I understand, with GSM >>> usage in mind, considering the integrated GPSDO and so on. As soon as I >>> put my hands on it I'd like to evaluate if it's worth invest some time >>> to develop a housing for it and appropriate connections for a very low >>> power and low cost BTS. >> >> i have gotten it to work quite fast with help of the patchset i am >> working on. >> it behaves mostly like a limesdr mini with a few addons and proper clock. >> you currently also need limesuite git master, the tagged 19.01 is too old. >> >>>>> With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, >>>>> with lots of failure messages... >> >> i have the same problem. >> i usually i only use usb2 due to it being much more solid that way. >> it should not matter anyhow, since we only need low bandwith for gsm. >> >>>> I'm sorry to hear this. We're trying to address various problems >>>> related to LimeSDR devices for quite some time, but progress is >>>> unfortunately not as quick as one would hope, particularly as LimeSuite >>>> also evolves and every major version seems to behave quite differently, >>>> at least in the way how OsmoTRX is using the API. >> >> well.. there are a couple of things coming together: >> limesuite did indeed change its behaviour when it comes to a few things. >> * it got more streamlined and with it the default settings. e.g. >> channel0 isnt enabled by default anymore. >> * some not defined behaviours changed, on which we relied. >> * i have reordered some of the function calls we do: >> limesuite doesn't like if you do your filtersetup, frequency, gain, >> streaming setup and calibration setup in the wrong order. sadly, neither >> our code nor lms has enough asserts to have anybody notice this soon enough. >> the good news is: the crew of lime is completely on mission helping us >> get this sorted. >> >>>> In recent weeks, Joachim has been making very good progress with help >>>> from Lime to resolve some of the most long-standing issues related to >>>> RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...). >>>> There should be a patchset pushed to gerrit soon which will address this >>>> one class of problems. However, this does not adress any USB stability >>>> related problems, which is a separate class of issues. We have to look >>>> at them once as a time >> >> ack, also see below >> >>> This is great, thanks for the report! I hope to have USB problems put >>> aside with the LimeNET Micro, this is one of the reasons of my question. >> >> not really. there IS a spi (or rather 2) connection(s) inbetween the >> fpga and the rpi according to the documentation, but there is also the >> ftdi601 bridge like used on the lime mini on the board. >> this is afaik due to the spi link not achieving high enough bandwidth to >> satisfy all involved. >> since the rpi is only usb2, this is also limited.... but i dont see any >> major issues for using it as a gsm trx. >> >>>> One thing I'm a bit missing here is: Where are your comprehensive bug >>>> reports about this in the osmocom issue tracker? Particularly with >>>> problems that manifest themselves only every few hours and hence are >>>> not quick to reproduce, we have to collect those issues and related >>>> log files, backtraces, ... in the issue tracker. >>> >>> I'll do this in the next couple of days, sorry for sending the email in >>> advance of the actual bug report. >> ps: what would help me out a lot, would be if every bugreport not only >> references 'limesdr' but also has detail of: >> * which model (mini, usb, net-micro?...) and revision? >> * which gateware and firmware release was installed? >> * which limesuite release or git version? >> >> kind regards >> > -------------- 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 Mon Apr 15 14:48:19 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 15 Apr 2019 16:48:19 +0200 Subject: LimeNet Micro for BTS In-Reply-To: References: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> <20190412080242.GC25552@nataraja> <57d81340-3781-6df7-a9cb-c18d9903a7e7@sysmocom.de> Message-ID: <52bfbcd6-da53-8fee-44f8-f6fbf1955a48@sysmocom.de> Hi Rafael, that's a known issue, see https://osmocom.org/issues/3339 -- - 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 gullik.webjorn at corevalue.se Mon Apr 15 20:18:57 2019 From: gullik.webjorn at corevalue.se (Gullik Webjorn) Date: Mon, 15 Apr 2019 22:18:57 +0200 Subject: LimeNet Micro for BTS In-Reply-To: References: <3bbeb3a7-0a13-00f4-aff5-35274c5d4256@rhizomatica.org> <20190412080242.GC25552@nataraja> <57d81340-3781-6df7-a9cb-c18d9903a7e7@sysmocom.de> Message-ID: I was getting this error on Orange Pi Zero w. Limesdr Mini. After trying desperately to debug this, my solution was to make sure all cpu was available by keeping the temperature low, since the OPI Z was throttling down from 960 Mhz to 240 Mhz when the temperature want up. The cause was simply not enough CPU during certain conditions, causing an overrun *within* the Limesdr mini. Once triggered, this problem persists until LimeSDR is restarted, whether this is a bug is up for discussion....perhaps debugging error handling ?? Failiure to read correct number of bytes ONCE causes all subsequent reads to fail, until driver AND limesdr are restarted. Once a fan was installed, the problem went away... Gullik On 2019-04-15 16:14, Rafael Diniz wrote: > Btw, before any bug report (as I need to upgrade the limesuite and > rebuild stuff), after some time running osmo-trx-lms (from osmocom > nightly builds), I get: > > (...) > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19c154 got 3f19e134 (3f19e134) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19cb18 got 3f19eaf8 (3f19eaf8) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19d4dc got 3f19f4bc (3f19f4bc) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19dea0 got 3f19fe80 (3f19fe80) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19e864 got 3f1a0844 (3f1a0844) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19f228 got 3f1a1208 (3f1a1208) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19fbec got 3f1a1bcc (3f1a1bcc) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f1a05b0 got 3f1a2590 (3f1a2590) diff=1fe0 > (...) > > Rafael Diniz > > On 4/15/19 9:12 AM, Rafael Diniz wrote: >> Hi Joachim, >> >> This is all very encouraging! I did not even know the Lime could work >> with USB 2 - thanks! >> >> I just realized I have limesuite18.06 (from debian repo) and >> limesuite18.10 (osmocom repo), but I'll upgrade it to git, re-compile >> everything and re-run all previous tests I did here. >> >> Kind regards, >> Rafael Diniz >> >> On 4/12/19 1:02 PM, Joachim Steiger wrote: >>> >>> On 4/12/19 4:05 PM, Rafael Diniz wrote: >>> >>>> It is a SDR hardware, but conceived, as far as I understand, with GSM >>>> usage in mind, considering the integrated GPSDO and so on. As soon as I >>>> put my hands on it I'd like to evaluate if it's worth invest some time >>>> to develop a housing for it and appropriate connections for a very low >>>> power and low cost BTS. >>> i have gotten it to work quite fast with help of the patchset i am >>> working on. >>> it behaves mostly like a limesdr mini with a few addons and proper clock. >>> you currently also need limesuite git master, the tagged 19.01 is too old. >>> >>>>>> With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, >>>>>> with lots of failure messages... >>> i have the same problem. >>> i usually i only use usb2 due to it being much more solid that way. >>> it should not matter anyhow, since we only need low bandwith for gsm. >>> >>>>> I'm sorry to hear this. We're trying to address various problems >>>>> related to LimeSDR devices for quite some time, but progress is >>>>> unfortunately not as quick as one would hope, particularly as LimeSuite >>>>> also evolves and every major version seems to behave quite differently, >>>>> at least in the way how OsmoTRX is using the API. >>> well.. there are a couple of things coming together: >>> limesuite did indeed change its behaviour when it comes to a few things. >>> * it got more streamlined and with it the default settings. e.g. >>> channel0 isnt enabled by default anymore. >>> * some not defined behaviours changed, on which we relied. >>> * i have reordered some of the function calls we do: >>> limesuite doesn't like if you do your filtersetup, frequency, gain, >>> streaming setup and calibration setup in the wrong order. sadly, neither >>> our code nor lms has enough asserts to have anybody notice this soon enough. >>> the good news is: the crew of lime is completely on mission helping us >>> get this sorted. >>> >>>>> In recent weeks, Joachim has been making very good progress with help >>>>> from Lime to resolve some of the most long-standing issues related to >>>>> RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...). >>>>> There should be a patchset pushed to gerrit soon which will address this >>>>> one class of problems. However, this does not adress any USB stability >>>>> related problems, which is a separate class of issues. We have to look >>>>> at them once as a time >>> ack, also see below >>> >>>> This is great, thanks for the report! I hope to have USB problems put >>>> aside with the LimeNET Micro, this is one of the reasons of my question. >>> not really. there IS a spi (or rather 2) connection(s) inbetween the >>> fpga and the rpi according to the documentation, but there is also the >>> ftdi601 bridge like used on the lime mini on the board. >>> this is afaik due to the spi link not achieving high enough bandwidth to >>> satisfy all involved. >>> since the rpi is only usb2, this is also limited.... but i dont see any >>> major issues for using it as a gsm trx. >>> >>>>> One thing I'm a bit missing here is: Where are your comprehensive bug >>>>> reports about this in the osmocom issue tracker? Particularly with >>>>> problems that manifest themselves only every few hours and hence are >>>>> not quick to reproduce, we have to collect those issues and related >>>>> log files, backtraces, ... in the issue tracker. >>>> I'll do this in the next couple of days, sorry for sending the email in >>>> advance of the actual bug report. >>> ps: what would help me out a lot, would be if every bugreport not only >>> references 'limesdr' but also has detail of: >>> * which model (mini, usb, net-micro?...) and revision? >>> * which gateware and firmware release was installed? >>> * which limesuite release or git version? >>> >>> kind regards >>> From wyao at corrections.com Tue Apr 16 16:02:05 2019 From: wyao at corrections.com (wyao at corrections.com) Date: Tue, 16 Apr 2019 12:02:05 -0400 Subject: OpenBSC on 3rd party MSC In-Reply-To: <20190413095056.GI24451@nataraja> References: <000d01d4f0a1$2cdb08a0$869119e0$@corrections.com> <20190413095056.GI24451@nataraja> Message-ID: <001c01d4f46d$bcd909a0$368b1ce0$@corrections.com> Thanks Harald for your reply, Looks like the issue is the connection between OsmoBSC and my MSC. I checked again on my MSC side, looks like it interfaces with softBSC on AoIP, connect to BSC port 2427 and 5000. So basically it just require a softBSC IP address to be able to connect. I found an example cfg called osmo-bsc-mgcp.cfg under the OpenBSC folder, but I have no clue if this is the right one to modify. I will appreciate if you can provide some example BSC configuration like this. Also, Should I still keep the OsmoSTP? Thanks again! Regards, Weiqi -----Original Message----- From: Harald Welte Sent: Saturday, April 13, 2019 5:51 AM To: wyao at corrections.com Cc: OpenBSC at lists.osmocom.org Subject: Re: OpenBSC on 3rd party MSC Hi Weiqi, On Thu, Apr 11, 2019 at 04:00:08PM -0400, wyao at corrections.com wrote: > I am working on get OpenBSC connected to a 3rd party MSC, I read from > the Osmo document that I can use the bsc only mode and the osm-bsc > instead of the osmo-nitb. This is correct. However, the terminology is a bit messed-up. So it's best to not use OpenBSC anymore but alsways call it OsmoBSC. > Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp > configured and and running, sidenote: You will have to add osmo-mgw for handling voice calls later on, but that is irrelevant until you get the signalling plane up and running. > but I see a lot of below error logs in the osmo-stp console: > > DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): > sctp_recvmsg() returned 56 (flags=0x80) DLM3UA <000f> m3ua.c:722 > asp-asp-dyn-0: Received M3UA Message (XFER:DATA) DLM3UA <000f> > m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer DLM3UA <000f> m3ua.c:580 > asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1 > dpc=185=0.23.1 > DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): > dpc=185=0.23.1 not local, message is for routing > DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route! Your SS7 routing seems to be misconfigured. The STP receives SCCP from OsmoBSC, but there's no (currently active/working) route for the MSC. Hence the message cannot be routed and is discarded. > <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP RESET message... > <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: > RI=SSN_PC,PC=0.23.1,SSN=BSSAP The BSC is trying to send a BSSMAP RESET to the MSC, but there's no response. > Can anyone identify what is the issue here? It's a SS7 routing / SIGTRAN configuration issue. You need to make sure the osmo-stp and osmo-bsc SS7 related configuration exactly matches the configuration on the MSC side. Also, depending on your SIGTRAN network setup, you may not even need osmo-stp. That would be the case e.g. if the MSC or an existing STP in your core network would already provide a M3UA SGW functionality to which the AS/ASP of OsmoBSC can connect to. It's really not possible to give you an easy answer without fully understanding your core networks SS7/SIGTRAN configuration, routing, addresses, point codes, etc. SIGTRAN and SS7 are rather complex protocol stacks themselves. There's little we can do on the Osmocom side to avoid that. We can just provide all the possible settings/options so you can configure it to match your network topology. 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 mykola at pentonet.com Tue Apr 23 13:19:42 2019 From: mykola at pentonet.com (Mykola Shchetinin) Date: Tue, 23 Apr 2019 16:19:42 +0300 Subject: Hard-dropping a PDP Context (SGSN) Message-ID: Dear Osmocom community, A question about this part of code - function sgsn_ggsn_ctx_drop_pdp: http://git.osmocom.org/osmo-sgsn/tree/src/gprs/gprs_sgsn.c#n720 The second branch of the condition (hard-dropping) is called even when the phone is registered, and hence no Deactivate PDP Context Request is sent to the phone. Due to that, the phone doesn't know that the PDP Context was deleted on the network side and keeps acting as if it is still active -> the PS isn't working when this happens. Any suggestions/thoughts on how this can be fixed? Thanks Kind regards, Mykola From pespin at sysmocom.de Tue Apr 23 18:58:42 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 23 Apr 2019 20:58:42 +0200 Subject: Hard-dropping a PDP Context (SGSN) In-Reply-To: References: Message-ID: Hi, pleaase open a ticket in redmine with this issue so we can track it. -- - 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 wyao at corrections.com Tue Apr 23 21:00:15 2019 From: wyao at corrections.com (wyao at corrections.com) Date: Tue, 23 Apr 2019 17:00:15 -0400 Subject: FW: OpenBSC on 3rd party MSC In-Reply-To: <001c01d4f46d$bcd909a0$368b1ce0$@corrections.com> References: <000d01d4f0a1$2cdb08a0$869119e0$@corrections.com> <20190413095056.GI24451@nataraja> <001c01d4f46d$bcd909a0$368b1ce0$@corrections.com> Message-ID: <000801d4fa17$8d882a50$a8987ef0$@corrections.com> Hello everyone, I am still not be able to figure out how to configure the A interface on the OsmoBSC side to talk to MSC, I will really appreciated if someone could share a similar configuration. Or if someone could point me to the right document, I looked through the OsmoBSC user manual(http://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf) and could not find the A interfaces config section. Thanks, Weiqi -----Original Message----- From: wyao at corrections.com Sent: Tuesday, April 16, 2019 12:02 PM To: 'Harald Welte' Cc: OpenBSC at lists.osmocom.org Subject: RE: OpenBSC on 3rd party MSC Thanks Harald for your reply, Looks like the issue is the connection between OsmoBSC and my MSC. I checked again on my MSC side, looks like it interfaces with softBSC on AoIP, connect to BSC port 2427 and 5000. So basically it just require a softBSC IP address to be able to connect. I found an example cfg called osmo-bsc-mgcp.cfg under the OpenBSC folder, but I have no clue if this is the right one to modify. I will appreciate if you can provide some example BSC configuration like this. Also, Should I still keep the OsmoSTP? Thanks again! Regards, Weiqi -----Original Message----- From: Harald Welte Sent: Saturday, April 13, 2019 5:51 AM To: wyao at corrections.com Cc: OpenBSC at lists.osmocom.org Subject: Re: OpenBSC on 3rd party MSC Hi Weiqi, On Thu, Apr 11, 2019 at 04:00:08PM -0400, wyao at corrections.com wrote: > I am working on get OpenBSC connected to a 3rd party MSC, I read from > the Osmo document that I can use the bsc only mode and the osm-bsc > instead of the osmo-nitb. This is correct. However, the terminology is a bit messed-up. So it's best to not use OpenBSC anymore but alsways call it OsmoBSC. > Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp > configured and and running, sidenote: You will have to add osmo-mgw for handling voice calls later on, but that is irrelevant until you get the signalling plane up and running. > but I see a lot of below error logs in the osmo-stp console: > > DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): > sctp_recvmsg() returned 56 (flags=0x80) DLM3UA <000f> m3ua.c:722 > asp-asp-dyn-0: Received M3UA Message (XFER:DATA) DLM3UA <000f> > m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer DLM3UA <000f> m3ua.c:580 > asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1 > dpc=185=0.23.1 > DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): > dpc=185=0.23.1 not local, message is for routing > DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route! Your SS7 routing seems to be misconfigured. The STP receives SCCP from OsmoBSC, but there's no (currently active/working) route for the MSC. Hence the message cannot be routed and is discarded. > <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending > BSSMAP RESET message... > <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: > RI=SSN_PC,PC=0.23.1,SSN=BSSAP The BSC is trying to send a BSSMAP RESET to the MSC, but there's no response. > Can anyone identify what is the issue here? It's a SS7 routing / SIGTRAN configuration issue. You need to make sure the osmo-stp and osmo-bsc SS7 related configuration exactly matches the configuration on the MSC side. Also, depending on your SIGTRAN network setup, you may not even need osmo-stp. That would be the case e.g. if the MSC or an existing STP in your core network would already provide a M3UA SGW functionality to which the AS/ASP of OsmoBSC can connect to. It's really not possible to give you an easy answer without fully understanding your core networks SS7/SIGTRAN configuration, routing, addresses, point codes, etc. SIGTRAN and SS7 are rather complex protocol stacks themselves. There's little we can do on the Osmocom side to avoid that. We can just provide all the possible settings/options so you can configure it to match your network topology. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)