OpenBSC January 2018

openbsc@lists.osmocom.org

29 participants
52 discussions

Re: osmocomBB with osmo-bts stuck need help
by Vadim Yanitskiy 09 Jan '18

09 Jan '18

Let's keep the public conversation, there are no secrets, right? ;) > Here is the pcap attached and here is the osmo-nitb > log https://pastebin.com/NJa0YU08 > > here is the osmo-bts log https://pastebin.com/RZ0au5yA > > hope you know what is wrong. Thanks Have a look at the following log lines: > trx_if.c:217 Enqueuing TRX control command 'CMD NOHANDOVER 0 0' > ... > trx_if.c:371 Response message: 'RSP NOHANDOVER -1' > trx_if.c:403 transceiver (phy0.0) rejected TRX command > with response: 'RSP NOHANDOVER -1' > bts.c:208 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL For some reason, the OsmocomBB transceiver rejects the command. Despite it's implemented and should work as expected. Let's look at the source code (trx.c:400 _trx_ctrl_cmd_(no)handover): > int n, tn, ss = 0; > > n = sscanf(args, "%d %d", &tn, &ss); > > if ((n < 1) || (tn < 0) || (tn > 7) || (ss < 0) || ((ss > 8))) > return _trx_ctrl_send_resp(trx, cmd, "%d %d %d", -1, tn, ss); > > // ... Try to debug this condition on your side. I cannot reproduce your problem... With best regards, Vadim Yanitskiy.

2 5

Re: osmocomBB with osmo-bts stuck need help
by Vadim Yanitskiy 08 Jan '18

08 Jan '18

Hi Sandi, > I can see the network but cannot registering my phone. Try to add the following settings at the end of the OsmoNiTB configuration: > nitb > subscriber-create-on-demand > assign-tmsi And please let me know if this would help. I'll correct the wiki page. With best regards, Vadim Yanitskiy.

2 2

question about 'lai & lac' paging
by Stefan Sperling 08 Jan '18

08 Jan '18

I am trying to fix issue OS#2754 "Paging on LAI not working". There are two tests related to this issue: 1) osmo-bsc/tests/bssap/bssap_test 2) TC_paging_imsi_nochan_lai in osmo-ttcn3-hacks/bss The first test is successful with my patch below. But the second test fails. It looks as if the MSC expects a response which is not delivered. I am unsure if the test has wrong expectations or if osmo-bsc is not sending a required response? The test's verdict is: Test case TC_paging_imsi_nochan_lai finished. Verdict: fail reason: Timeout expecting { msg_disc := { msg_group := RSL_MDISC_CCHAN (6), transparent := false }, msg_type := RSL_MT_PAGING_CMD (21), ies := { { iei := ?, body := { chan_nr := { u := { ch0 := RSL_CHAN_NR_PCH_AGCH (18) }, tn := ? } } }, { iei := ?, body := { paging_group := ? } }, { iei := ?, body := { ms_identity := { len := ?, payload := ? } } }, * } } Note that the existing ttcn3 test for the LAC case, which is already supported, and also covered by the bssap_test, fails in the same way: Test case TC_paging_imsi_nochan_lac finished. Verdict: fail reason: Timeout expecting { msg_disc := { msg_group := RSL_MDISC_CCHAN (6), transparent := false }, msg_type := RSL_MT_PAGING_CMD (21), ies := { { iei := ?, body := { chan_nr := { u := { ch0 := RSL_CHAN_NR_PCH_AGCH (18) }, tn := ? } } }, { iei := ?, body := { paging_group := ? } }, { iei := ?, body := { ms_identity := { len := ?, payload := ? } } }, * } } Any hints how to proceed? Thanks, Stefan >From 01200d452971cd20c8a0304e180c2d11ff399d3f Mon Sep 17 00:00:00 2001 From: Stefan Sperling <ssperling(a)sysmocom.de> Date: Fri, 5 Jan 2018 17:22:11 +0100 Subject: [PATCH] Implement support for paging by LAI. This is very similar to the paging by LAC case. We can simply extract the LAC at a different offset. Change-Id: Ic3c62ff0fccea586794ea4b3c275a0685cc9326e Related: OS#2751 --- src/osmo-bsc/osmo_bsc_bssap.c | 9 +++++++++ tests/bssap/bssap_test.c | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/src/osmo-bsc/osmo_bsc_bssap.c b/src/osmo-bsc/osmo_bsc_bssap.c index 45861ccc..9bc59623 100644 --- a/src/osmo-bsc/osmo_bsc_bssap.c +++ b/src/osmo-bsc/osmo_bsc_bssap.c @@ -288,6 +288,15 @@ static int bssmap_handle_paging(struct bsc_msc_data *msc, lac = GSM_LAC_RESERVED_ALL_BTS; switch (cell_ident) { + case CELL_IDENT_LAI_AND_LAC: + if (data_length != 6) { + LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Cell Identifier List for BSS (0x%x)" + " has invalid length: %u, paging entire BSS anyway (%s)\n", + mi_string, CELL_IDENT_BSS, data_length, osmo_hexdump(data, data_length)); + } + lac = osmo_load16be(&data[4]); + break; + case CELL_IDENT_LAC: if (data_length != 3) { LOGP(DMSC, LOGL_ERROR, "Paging IMSI %s: Cell Identifier List for LAC (0x%x)" diff --git a/tests/bssap/bssap_test.c b/tests/bssap/bssap_test.c index 579cae23..2fa2b1fe 100644 --- a/tests/bssap/bssap_test.c +++ b/tests/bssap/bssap_test.c @@ -71,7 +71,7 @@ struct { { "001952080859512069000743940904010844601a060415f5490065", /* ^^^^^^^^^^^^ Cell Identifier List: LAI */ - GSM_LAC_RESERVED_ALL_BTS, 0 + 0x65, 0 }, }; -- 2.14.1

3 5

osmocomBB with osmo-bts stuck need help
by Sandi Suhendro 08 Jan '18

08 Jan '18

Hello list, can someone look at my problem for osmocomBB for what is wrong on my setup? maybe I miss the configuration or something else? I can see the network but cannot registering my phone. my motorolla C117 attached with PL2303. here are the pcap and everything else : this is my osmo-bts config https://pastebin.com/QHE9cTiZ this is my openbsc config https://pastebin.com/efVhWs91 <https://pastebin.com/efVhWs91> this is the pcap https://wsi.li/tayFOx1GakxK/746634 osmo-bts stuck on this level and cannot going more verbose. https://pastebin.com/2GPtNVw9 -- best regards, DUO

1 0

osmo-python-tests py3 fail
by Neels Hofmeyr 08 Jan '18

08 Jan '18

Hi Max, in osmo-python-tests master, I did python2 setup.py install rm -rf build/ dist/ osmopython.egg-info python3 setup.py install which results in osmotestvty.py installed as py3, causing an encoding problem which I mentioned; py3 is a lot more than print() with braces, see the error log below. So in principle I still don't understand why the py2 scripts need to be made py3 compatible, and why I need to add 'from future' imports to py3 scripts now. There has to be a better way. About the need to rm the installation artifacts, there is no mention of it in the README. And even when I remove those, I still get py2 scripts installed as py3. So anyone is bound to get this error: " osmotestvty.py -p /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc -w /n/s/osmo-dev/make/osmo-msc -v confpath /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc, workdir /n/s/osmo-dev/make/osmo-msc Running tests for specific VTY commands test_history (__main__.TestVTY) ... Launch: ./src/osmo-msc/osmo-msc -c /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg from /n/s/osmo-dev/make/osmo-msc Opening /dev/null Launching: PWD=/n/s/osmo-dev/make/osmo-msc './src/osmo-msc/osmo-msc' '-c' '/n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg' Terminating took 2.679s ERROR test_terminal_length (__main__.TestVTY) ... Launch: ./src/osmo-msc/osmo-msc -c /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg from /n/s/osmo-dev/make/osmo-msc Launching: PWD=/n/s/osmo-dev/make/osmo-msc './src/osmo-msc/osmo-msc' '-c' '/n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg' Terminating took 2.679s ERROR test_unknown_command (__main__.TestVTY) ... Launch: ./src/osmo-msc/osmo-msc -c /n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg from /n/s/osmo-dev/make/osmo-msc Launching: PWD=/n/s/osmo-dev/make/osmo-msc './src/osmo-msc/osmo-msc' '-c' '/n/s/osmo-dev/make/osmo-msc/../../src/osmo-msc/doc/examples/osmo-msc/osmo-msc.cfg' Terminating took 2.679s ERROR ====================================================================== ERROR: test_history (__main__.TestVTY) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.6-py3.6.egg/EGG-INFO/scripts/osmotestvty.py", line 56, in test_history File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.6-py3.6.egg/osmopy/obscvty.py", line 223, in command return self._common_command(request, close) File "/usr/local/lib/python3.6/dist-packages/osmopython-0.0.6-py3.6.egg/osmopy/obscvty.py", line 179, in _common_command self.socket.send("%s\r" % request) TypeError: a bytes-like object is required, not 'str' " With your recent set of changes, you have not only hung all the build slaves' osmo-python-tests updates for 3 weeks, but also dismantled the installation. I wonder how it was possible for this to get past your testing. I will try to get the scripts working for me now. ~N

2 4

Re: build slaves
by Neels Hofmeyr 08 Jan '18

08 Jan '18

On Sun, Jan 07, 2018 at 05:58:40PM +0100, Max wrote: > Hi. > > Seems like jobs which update osmo-ci and osmo-python-tests on build slaves are > failing for 20+ days. This only happens for some of the slaves but not the others. > > I'd like to understand why this is happening and, ideally, fix it. However, there're > few obstacles: It's because of "ImportError: No module named setuptools" since your commit, where you obviously never checked whether setuptools is available on the build slaves: Author: Max <msuraev(a)sysmocom.de> AuthorDate: Fri Dec 15 12:12:01 2017 +0100 Commit: Max <msuraev(a)sysmocom.de> CommitDate: Fri Dec 15 20:40:41 2017 +0100 Use setuptools for packaging According to https://docs.python.org/3/library/distutils.html the setuptools are used in place of distutils anyway. Using it directly allows us to make packaging more flexible: specify dependencies, automatically find package name etc. Change-Id: I39ee53f352001e47c6df055cbec52d638480253d I see console logs fine. https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=O… https://jenkins.osmocom.org/jenkins/job/update-osmo-ci-on-slaves/63/label=b… So do we really need this setuptools thing or can we just revert the change? ~N

2 2

stricter rate counter group allocation breaks applications
by Neels Hofmeyr 07 Jan '18

07 Jan '18

A recent patch to libosmocore refuses to allocate a rate counter group with an index that already exists. Per se that's a good thing, but it needs fixes in a whole range of callers. Numerous callers wrongly just pass 0 as rate counter group, so as soon as a second <thing> shows up, the application may deny service; that's unacceptable. For example, OsmoSGSN now crashes with the second subscriber showing up! causing patch: https://gerrit.osmocom.org/5418 my proposed change: https://gerrit.osmocom.org/5516 I'd like to request everyone to refrain from submitting patches that are insufficiently tested, in general of course, but in particular until after congress, please ;) ~N

2 2

build slaves
by Max 07 Jan '18

07 Jan '18

Hi. Seems like jobs which update osmo-ci and osmo-python-tests on build slaves are failing for 20+ days. This only happens for some of the slaves but not the others. I'd like to understand why this is happening and, ideally, fix it. However, there're few obstacles: - there seems to be no "console output" or logs available for those jobs - am I looking at the wrong place? - we don't seems to have any docs on the wiki about the build slaves On a related note, do we have a ticket tracking progress on automated build slave creation? -- Max Suraev <msuraev(a)sysmocom.de> 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

1 0

Handover log
by Alexander Chemeris 07 Jan '18

07 Jan '18

Hello, all, I wonder if anyone has thought about introducing a handover log (to a file or a DB) to OsmoBSC/OsmoNITB? For small deployments <6 BTS you can just add every BTS to neighbor lists of each other and don't worry, but once you get above that, you face a handover optimization issue. I.e. which BTS should be neighbors of which other ones. Initial assigning of the neighbors can be done by simply looking at coverage maps of each BTS. But once the network is actually used there is a lot of useful information about the network performance which can be extracted from the handover history - which cells have issues handing over to each other, etc. -- Regards, Alexander Chemeris. CTO/Founder, Fairwaves, Inc. https://fairwaves.co

2 1

Unable to make calls
by Anindya Sankar Roy 03 Jan '18

03 Jan '18

Hello, I have built osmo-bsc, osmo-msc, osmo-hlr, osmo-stp, osmo-mgcp and connected them successfuly in the same computer. When I try to make calls it gives the folowing error in MGCP osmo-mgw -c newmgw.cfg <0001> telnet_interface.c:104 telnet at 127.0.0.1 4243 <0011> mgw_main.c:336 Configured for MGCP. <0011> mgcp_protocol.c:827 DLCX: endpoint:0x1 deleting connection ... <0011> mgcp_protocol.c:832 DLCX: endpoint:0x1 endpoint is not holding a connection. <0011> mgcp_protocol.c:827 DLCX: endpoint:0x2 deleting connection ... <0011> mgcp_protocol.c:832 DLCX: endpoint:0x2 endpoint is not holding a connection. <0011> mgcp_protocol.c:453 CRCX: creating new connection ... <0011> mgcp_protocol.c:79 endpoint:1 RTP-setup: Endpoint is in loopback mode, stopping here! <0000> mgcp_network.c:188 endpoint:0x1 Failed to send dummy RTP packet. <0011> mgcp_protocol.c:650 CRCX: endpoint:0x1 connection successfully created <0011> mgcp_protocol.c:827 DLCX: endpoint:0x1 deleting connection ... <0011> mgcp_protocol.c:895 DLCX: endpoint:0x1 missing ci (connectionIdentifier), will remove all connections at once <0011> mgcp_protocol.c:453 CRCX: creating new connection ... <0011> mgcp_protocol.c:79 endpoint:1 RTP-setup: Endpoint is in loopback mode, stopping here! <0000> mgcp_network.c:188 endpoint:0x1 Failed to send dummy RTP packet. PFA configuration files for all the blocks that I have been using to run the system and also the pcap trace. Please tell me what am I doing wrong due to which I am unable to make calls. Thanks Anindya calltrace.pcap <https://drive.google.com/a/toshniwalcontrols.com/file/d/1vmDuNJuePVDB9XCHtw…>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2018