Hi.
We have several kind of logs in libosmocore: 'log stderr', 'log file ...', 'log
gsmtap' etc.
Some of them are naturally singleton: you can't have 2 stderrs at the same time. Some
are naturally parallel - it make sense to log different things into different files.
What about "log gsmtap"?
On the one hand sending to different hosts might make sense, on the other hand, the
receiver can do filtering by itself.
The current implementation does not allow multiple "log gsmtap" entries but the code
is kinda unclear - I don't understand if that's intentional.
So, is it a "bug" or "feature"?
Shall we opt for greater flexibility and fix the code to enable multiple gsmtap log
destinations?
Shall we opt for simplicity and fix the code to make it clear that log gsmtap is
singleton?
Do you have any use-case in mind where multiple "log gsmtap" would come in handy?
Do you foresee any problems arising from multiple "log gsmtap"working in parallel?
N. B: this has nothing to do with recording bursts into .pcap, this is about sending
log output using the same facility we use for recording frames sent/received over the
air. The frame recording is used in OsmoBTS/PCU, the logging is used in all Osmo*
projects.
Just in case, the patch enabling multiple 'log gsmtap ...' is available in
https://gerrit.osmocom.org/#/c/5747/ so you can give it a try.
--
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
sorry to bother you, I have a question to ask you:
i install openbsc and osmocombb in a pc.
i want to transfer authentication information (rand) from osmocombb to openbsc,
and transfer sres information from openbsc to osmocombb.
What should I do?
zhanghao
Hi,
In the context of a project GSM-GPRS (not 3G), I recovered the sources of the branch Master (github.com/osmocom).
- osmo-pcu
- openbsc (osmo-nitb, osmo-bsc, osmo-bsc-nat, osmo-bsc-mgcp)
- libosmocore
- libosmo-abis
- libosmo-netif
- liosmo-sccp
- libsmpp34
- libosmo-ggsn
- libosmo-sgsn (it seems not include in the openbsc's directory).
Does the Library osmo-sgsn still need to be generated? because during the compilation only the module "osmo-gbproxy" is compiled.
When I look at the Makefile (osmo-sgsn/src/gprs), the following lines are commented:
#am__append_1 = \
# $(LIBASN1C_CFLAGS) \
# $(LIBOSMOSIGTRAN_CFLAGS) \
# $(LIBOSMORANAP_CFLAGS) \
# $(NULL)
bin_PROGRAMS = osmo-gbproxy$(EXEEXT) $(am__EXEEXT_1)
#am__append_2 = \
# osmo-sgsn \
# osmo-gtphub \
# $(NULL)
#am__append_3 = \
# $(LIBOSMOSIGTRAN_LIBS) \
# $(LIBOSMORANAP_LIBS) \
# $(LIBASN1C_LIBS) \
# $(NULL)
Let me know I you think there are mistakes.
Thanks
Pierre
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.
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.
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
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
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
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
