OpenBSC March 2017

openbsc@lists.osmocom.org

22 participants
51 discussions

IMSI: Inf ?
by Keith 14 Mar '17

14 Mar '17

This is a bit vague again... I have found across our sites several entries with a value of Inf for IMSI on a create-on-demand subscriber: For example: sqlite> select * from Subscriber where id=284054; 284054|2017-03-08 21:19:40|2017-03-08 21:19:40|Inf||20649|0||0| I also have some Inf values for IMEI in Equipment: sqlite> select id,created,imei from Equipment where id = 95108; 95108|2014-03-13 03:18:06|Inf Not a big deal for operations, just thought I'd mention it as I noticed while restoring backups, (sqlite3 doesn't like to reimport the Inf value it writes itself with .dump)

1 0

BS-11 Serial Interface
by Alexander Huemer 14 Mar '17

14 Mar '17

Hi, I have a Siemens BS-11 with the factory cable for the LMT that has a DSUB-9 plug on the non-BTS end. When I connect a USB<-->RS232 adapter and run either $ cu -l /dev/ttyUSB or bs11_config -p /dev/ttyUSB0 I do not get any output when I switch on the BTS. I tried with nullmodem adapter and without just to be sure since I often mix up the pinouts. I was not able to measure any voltage on any of the DSUB-9 pins when the BTS is powered up, but believe that on either RX or TX there should be the voltage level of the serial line since RS232 is active low. Has somebody seen this behavior? -Alex

2 1

FYI: Build failure of network:osmocom:nightly/osmo-pcu in xUbuntu_16.10/x86_64
by Neels Hofmeyr 13 Mar '17

13 Mar '17

fyi, we're still getting daily failures by the opensuse builds, which should be fixed once https://gerrit.osmocom.org/2007 is merged. ~N On Sat, Mar 11, 2017 at 07:57:26PM +0000, OBS Notification wrote: > Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… > > Package network:osmocom:nightly/osmo-pcu failed to build in xUbuntu_16.10/x86_64 > > Check out the package for editing: > osc checkout network:osmocom:nightly osmo-pcu > > Last lines of build log: > [ 111s] from bts.cpp:21: > [ 111s] /usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128) > [ 111s] abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; } > [ 111s] ^~~ > [ 111s] /usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int) > [ 111s] abs(long long __x) { return __builtin_llabs (__x); } > [ 111s] ^~~ > [ 111s] /usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int) > [ 111s] abs(long __i) { return __builtin_labs(__i); } > [ 111s] ^~~ > [ 111s] Makefile:778: recipe for target 'bts.lo' failed > [ 111s] make[2]: *** [bts.lo] Error 1 > [ 111s] make[2]: Leaving directory '/usr/src/packages/BUILD/src' > [ 111s] Makefile:403: recipe for target 'all-recursive' failed > [ 111s] make[1]: *** [all-recursive] Error 1 > [ 111s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 111s] dh_auto_build: make -j1 returned exit code 2 > [ 111s] debian/rules:12: recipe for target 'build' failed > [ 111s] make: *** [build] Error 2 > [ 111s] dpkg-buildpackage: error: debian/rules build gave error exit status 2 > [ 111s] > [ 111s] lamb16 failed "build osmo-pcu_0.3.20170311.dsc" at Sat Mar 11 19:57:22 UTC 2017. > [ 111s] > [ 111s] ### VM INTERACTION START ### > [ 115s] [ 102.127065] reboot: Power down > [ 115s] ### VM INTERACTION END ### > [ 115s] > [ 115s] lamb16 failed "build osmo-pcu_0.3.20170311.dsc" at Sat Mar 11 19:57:26 UTC 2017. > [ 115s] > > -- > Configure notifications at https://build.opensuse.org/user/notifications > openSUSE Build Service (https://build.opensuse.org/)

1 0

RFC: jenkins pipeline
by Klaus Müller 13 Mar '17

13 Mar '17

Hi, >> So, what would be the actual benefits? >>* complete job config in git? (to be confirmed) Just to clarify, the Pipeline plugin on its own doesn't provide a complete config handling in git. This means only the code shown in image [3] lives in git, configurations within the "General" or "Build Triggers" tab will still be handled in the web-ui.*** For the sake of completeness the JobDSL plugin [2][ has to be mention. This plugin allows to put the entire job configuration to git and deploys jobs without previous manual setup in the web-ui. >>* faster because less things have to be rebuilt? (to be confirmed) Somehow I doubt that this improvement dependents on the Pipeline plugin, but I know to few details to have an opinion based on facts. :) >>* faster because easily parallelizable/easier integration with docker? (to be >> confirmed) first point: e.g. Pipeline can trigger "down-stream-projects/stages" after one specific part of a parallel-block/matrix-configurations-project is finished. second point: Pipeline brings a docker wrapper, so one don't have to pass one build script holding the entire build sequence when invoking the container. You can invoke as much scripts as you want within the docker wrapper. (no black-box god-script :) >> If dr.blobb and/or Max could clarify these points that would be great >> (while I guess they will clarify in depth only after actual trials). >> First tests could run on a privately setup Jenkins ... dr.blobb? For sure, let's use this Jenkins instance [1] for trials. Everyone is welcome to sign up and send me a mail to get the necessary permissions. I start migrating the OpenBSC build pipeline to Pipeline and keep you updated. Is this mailing list the appropriate communication channel? Is there already a osmocom ci wiki page, which I overlooked? I'd be happy to contribute! ~André *** Some "web-ui configurations" can be injected from the jenkinsfile, though. [1] https://jenkins.blobb.me/view/osmocom/ [2] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin [2.5] https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.Dsl… [3] http://tinyurl.com/zbavrtp

6 9

Re: BS-11 Serial Interface
by Dieter Spaar 11 Mar '17

11 Mar '17

Hello Alexander, On Sat, 11 Mar 2017 00:42:32 +0100, "Alexander Huemer" <alexander.huemer(a)xx.vu> wrote: > > I was not able to measure any voltage on any of the DSUB-9 pins when the=20 > BTS is powered up, but believe that on either RX or TX there should be=20 > the voltage level of the serial line since RS232 is active low. > Has somebody seen this behavior? Maybe there is something wrong with the cable? This is from my notes about the BS-11 serial interface: The four E1 BNC connectors are here. 5 6 7 8 x x x x x x x x 1 2 3 4 2: LMT Tx (out) 6: LMT Rx (in) 4: +5V 8: GND There are two more 8-pin connectors below, you have to connect the cable to the top one (below the E1 BNC connectors). The same with some pictures is also here: https://osmocom.org/projects/openbsc/wiki/BS11LMT Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: libosmocore build failure cascade
by Vadim Yanitskiy 11 Mar '17

11 Mar '17

Hi Max, > On a related note - are you working on moving OsmoBTS to libosmocoding? Not a whole OsmoBTS :) GSM 05.03 transcoding routines only. Right now, I am testing dynamic TS switching on UmTRX. > Are there some missing pieces before this can be done? Almost done, now we need to switch OsmoBTS to use libosmocore's implementation and remove the old code. With best regards, Vadim Yanitskiy.

1 0

Unknown HFC multiport controller
by Alexander Huemer 11 Mar '17

11 Mar '17

Hi, I have a Siemens BS-11 and a HFC IOB1E1 PCI card. The linux kernel is not very happy with the card, I get Unknown HFC multiport controller (vendor:1397 device:30b1 subvendor:1397 subdevice:b543) Please contact the driver maintainer for support. The same error is mentioned in [1] but with different subdevice id, which I believe does not matter. I am not sure why vendor ID 1397 (PCI_VENDOR_ID_CCD) and device ID 30b1 (PCI_DEVICE_ID_CCD_HFCE1) are not valid. Consulting [2] I was under the impression that this is the expectation of the driver. [1] does not provide an answer as far as I can see. Would anybody know what the problem is here? -Alex [1] http://lists.osmocom.org/pipermail/openbsc/2009-August/001838.html [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/driver…

1 0

MNCC ABI changes
by Holger Freyther 10 Mar '17

10 Mar '17

Hi, as part of looking into early media (and at some point handover handling) I would like to use MNCC_RTP_CONNECT and supply "recvonly", "sendonly" attributes. The gsm_mncc_rtp structure does not carry this information though. struct gsm_mncc_rtp { uint32_t msg_type; uint32_t callref; uint32_t ip; uint16_t port; uint32_t payload_type; uint32_t payload_msg_type; }; The content of payload_msg_type currently holds anything between 0x300 and 0x03ff and I would like to split this field into two uint16_t. The reason is not to change the size of the structure (and maybe not dump the protocol version). It would be a backward compatible change. Is anyone open for such tricks? Otherwise I will bump protocol version and change the ABI (and try to update the various active users of this protocol). holger

2 1

SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts + osmocom-bb/mobile)
by Sebastian Stumpf 10 Mar '17

10 Mar '17

Hi, Some of my sent SMS are not received by my mobile and I try to figure out if this is a problem with my virtual layer 1, configuration or something in the layers 2+. I use: osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919) osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8 MS layer23 app mobile: is the subscriber from osmo-nitb MS layer1 virt-phy: virtual gsmtap layer between bts and mobile I want: Send a sms to subscriber 017519191919. osmo-nitb VTY: OpenBSC# subscriber id 1 sms sender id 1 send Test I have 2 outcomes, first one is the failure. See https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. Do not wonder about the duplicated gsmtap messages from mobile, the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from the gsmtap logging option from mobile. Filter them out via "gsmtap && (ip.dst != 127.0.0.1)". 602-613: RR channel establishment with RA and IA as reaction to paging in 590 627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 656,684,699: I-Data frames on SAPI3 containing the sms 660,688,703: ReceiveReady's from MS (That ACK all I-frames before N(R)-1 as far as I understood) For me, that looks good and I really do not understand why the MS will not answer with the CP-ACK/RP-ACK after receiving the SMS Data in 699. The LAPDM link will stay up for some more time and be used by the network for retransmission of the sms (1149), but MS will never react to it on the SMS layer (CP-ACK, RP-ACK). Here is the console log for the mobile (https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-ni…). The paging is answered in line 378: Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE Second outcome is a successfully sent sms from network to ms. See https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-ni… for the pcap. What is different here? There is no paging, but the sms is sent within the dedicated channel used for the location update initiated by the phone started up. Why there is another outcome, I don't know. 169-181: RR channel establishment with RA and IA as part of mibiles startup routine to make location update 188,416: Location udpdate procedure on SAPI0 230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS) and the ACK from MS 396,444: I-Data frames on SAPI3 containing the sms 400,449: RR's from MS 450: CP-ACK for BTS 482,499: RP-ACK I-Frames for Network (osmo-nitb) Again, the console log of the mobile (https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-ni…). The SABM on SAPI3 on downlink is received in line 206: Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E) received in state LAPD_STATE_IDLE The signaling looks quite similar in both cases, but one time the mobiles sms handler responds to CP-DATA msg containing the SMS, the other time not. Can someone find an error in the signaling I did not see? Is there a known Bug? To be honest, I last merged my branch with master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb and the libraries since then to avoid compatibility problems. Have there been recent changes that could cause that behavior? Thank you and Kind Regards, Sebastian

1 0

about reusing subscriber connections
by Neels Hofmeyr 10 Mar '17

10 Mar '17

Testing with the nano3G, e.g. when sending a large SMS, I see that multiple CM Service Requests may come in on the same IuCS connection. The code so far assumed that a CM Service Request would always come in on a fresh, unauthenticated connection (after iuRelease): the ProcessAccessReQuest FSM always starts out with establishing identities, authentication, ciphering. Now I've added code to accept a CM Service Request on an already accepted connection, by sending back an immediate CM Service Accept without even invoking the PARQ FSM. But that might not be such a good idea: I face the same for a Location Updating. A phone may choose to send a periodic LU on an already open and accepted connection (I guess). So we should allow that by sending back a LU Accept right away, without another authentication dance. But we also want to tell the HLR about the LU. The VLR FSMs may also have other actions in mind that the MSC doesn't know or care about. So: To not re-invent the wheel outside of libvlr, I would go on and add a flag to the LU and PARQ FSMs to indicate that the request is coming in on an already accepted connection, to jump directly to the post-ciphering FSM state. But I'd like to hear whether you guys have some thoughts or experience on this. For the case of the large multi-part SMS, we usually are fast enough in releasing the conn after each SMS fragment. For the next fragment, another initialUE message with a CM Service Request starts the PARQ FSM, auth+ciph is re-established, and the next part goes through. But sometimes the UE has already started to send another CM Service Request to initiate the next SMS fragment before it acked the previous one -- meaning that before we get as far as being done and issuing an iuRelease from the CN, the UE already sends another fresh CM Service Request on the same conn. That means we don't have to re-establish auth, quite nice actually. To allow cascades like these, we might also decide to iuRelease slightly later, giving the UE another second to re-use the open connection, so that we have less message overhead and use less auth tuples -- I wouldn't actually give it much more than a second; after about five seconds, the UE usually does an iuRelease itself. That sounds sane, but actually https://osmocom.org/issues/1816 holds against that: when I send USSD requests *from the phone* rapidly without leaving time to iuRelease, only the first USSD goes through from the UE to the CN. The second one is never received on the IuCS wire. That would indicate that the phone expects a conn to close right away from the CN, always. When I wait for iuRelease before sending another USSD, the MO USSD gets its own conn established and all is well. This behaves identically for both the femto cell kinds I have for testing. But, today, seeing multiple CM Service Requests on the same conn for SMS makes me think that #1816 might be a bug in the USSD dispatch of my phone. If MO SMS can do CM Service Requests on an already open conn, why should MO USSD not be able to do the same? I think in the old, pre-VLR code, we would accept multiple CM Service Requests on the same conn without problems, because the semantics were "re-entrant", calling secure_connection() in multiple places, which was skipped when some flag that we're already authenticated was set. The VLR paradigm is different: it "locks down" a new conn until that is accepted (authenticated and ciphered, according to config). Once a conn is accepted, the rest of the code does not need to bother with asking for securing a connection. So far receiving a CM Service Request is semantically identical with starting a new conn. That's why I would explicitly add a parameter to FSM invocation to skip over auth+ciph in case the conn is already accepted, but still do any HLR actions as needed. What still bugs me is: when the phone knows that a conn is open, why should it bother with a CM Service Request, it could just start sending the real meat right away. Re-using from the CN side: In https://osmocom.org/issues/1712#note-7 I noted that the code should not page when a connection is already open. https://osmocom.org/issues/1862 asks for not attempting to send USSD from the CN to the UE when a conn is there but not authenticated/ciphered yet. When the conn is accepted, we can immediately send the MT messages -- however, if the conn is there but still busy authenticating, we must neither page nor can we send messages right away. We should then add an item to the queue of actions to carry out after a paging response, without dispatching a paging request; and ensure that the queue is also worked off in case we receive a CM Service Request or LU Request instead of a Paging Response ... actually, this might already work, but I should test for it. P.S.: Also wondering, could it happen that we receive a Paging Response on an already accepted connection? Wouldn't make much sense, but might be possible to provoke ;) Any facts/thoughts on this stuff are welcome. ~N

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2017