Dear all,
I have switched on logging to file and have set the log level to "debug"
for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot
find any output in the log file related to MGCP if I get an error. Is
there a trick to make the MGCP module more verbose?
Thanks, Kristian
Hello,
I would also ask if the osmo-iuh-3G_2016_09 support the new sfr-femto tha sfr sold now (for 90 euro) or it's not available only for le old sfr femto !?Is it possible also for the new femtocell vodafone signal secure 3 !? (and if it's possible I would like to konw how to find Tx-Rx-GND for this femto)
Thanks for helping
chears,
Dear all,
as osmo-trx has recently introduced a dependency on a super-recent
version of UHD (as opposed to what regular stable distributions ship),
the nightly debian builds are broken for both Debian 8.0 and Ubuntu
14.04:
https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx
I would like to ask the osmo-trx folks to consider
a) adding the uhd version dependencly to the debian rules
b) submitting a suitable uhd package version that can be build in the
osmoco nightly OBS repository
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi osmo-trx folks,
I'd like to draw your attention to https://osmocom.org/issues/1869 --
"osmo-trx binary cannot be moved to similar CPU"
Has anyone seen this before and/or is up to the task of fixing it?
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Hello All,
As reported earlier "CS call is not working using TCH/F_PDCH dynamic channel configuration" in URRP B210 board(osmo-trx) . We further checked the commit version using git bisect to find out the exact version from where this functionality is broken . Below is the commit version of BSC :
c3f72f63afde926dfc46827d6880055597515fb6
dyn TS: fix: ts_subslots() for TCH/F_PDCH in PDCH mode
Thanks and Regards,
Mrinal
Dear all,
when debugging Osmocom programs, one usually looks at either the pcap
trace of one of the many interfaces (Um interface via GSMTAP or
OsmocomBB, Abis, Gb, Gp or A interface via ethernet, ...) or at the log
files of the various osmocom programs.
Sometimes it can be hard to match the two different domains, and it is
useful to see in sequence when a certain message was received and what
kind of actions this triggered inside e.g. OsmoPCU or OSmoSGSN.
One could have used the libosmocore 'syslog' log target for this and
then configure the local syslog daemon to log to a remote syslog server
via the network. However, as there is another local process and context
switches involved, the messages were re-ordered. Also, syslog only
receives the fully-formatted log string, and not the meta-data like the
log level or sub-system.
Hence, the idae of having a GSMTAP based log target was floating around
the project for many years. I finally implemented this today.
The advantage is that in our single-threaded osmocom programs the GSMTAP
messages will leave in-sequence with the protocol messages received or
transmitted, and there is only the limited chance of re-ordering by the
local network stack and/or intermediate routers. Both shouldn't be much
of a concern during local debugging.
What do you need to use this?
1) The follwoing three libosmcoore commits from gerrit:
https://gerrit.osmocom.org/#/c/1355https://gerrit.osmocom.org/#/c/1356https://gerrit.osmocom.org/#/c/1357
2) a "log gsmtap" configuration in your config file (or via vty),
similar to how syslog logging is configured:
=== SNIP ===
log gsmtap localhost
logging filter all 1
logging color 1
logging print category 0
logging timestamp 0
logging level all everything
logging level rll notice
[...]
=== SNIP ===
3) a wireshark with my Change-ID I0de723445e5b5ce0199a4081808111240a9ed047
(can also be found in the laforge/gsmtap-log branch of
git://git.osmocom.org/wireshark or
http://git.osmocom.org/wireshark/commit/?h=laforge/gsmtap-log&id=3a207894a4…
I will leave this in review for a few days and then plan to merge it
into libosmocore. The wireshark patch will also be submitted at that
time.
A screenshot is attached for your reference.
There is of course no coloring of the lines in wirshark, but you can set
various wireshark filters (e.g. on log level, sub-system) and also use
colorization rules to e.g. map sub-systems again to colors.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Heads up, the current openbsc build is broken, as verified by
https://jenkins.osmocom.org/jenkins/job/OpenBSC/
This is due to below libosmocore commit, which adds two items to enum
chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking
the static assert for gsm_network->ctype_by_chreq's size:
../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ‘dummyassert_size’ is negative
osmo_static_assert(sizeof(ctype_by_chreq) ==
^
What this patch lacks is
* adjustment of ctype_by_chreq[] according to the new additions in
libbsc/gsm_04_08_utils.c
* same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c
* enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h.
I could try to guess what the ctype_by_chreq[] and reason_by_chreq[] items
should be, but to not get distracted from my current task, and since the values
don't seem to be used by the current master branches yet, I decided to simply
revert the libosmocore commit and leave it up to the original authors to follow
up. (No need to mention that those should be merged to libosmocore and openbsc
"at the same time" to avoid builds failing.)
Thanks and apologies for any inconvenience...
~Neels
commit c3c28528de78fd5d50c3a141c2176c0da5dd7075
Refs: 0.9.0-299-gc3c2852
Author: Alexander Couzens <lynxis(a)fe80.eu>
AuthorDate: Tue Nov 29 12:42:05 2016 +0100
Commit: Harald Welte <laforge(a)gnumonks.org>
CommitDate: Thu Dec 1 15:26:29 2016 +0000
gsm0408: add chreq_type for CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE
For BSC-located pcu the BSC must understand the PDCH chan request.
Change-Id: Ice44dcaaf798f93af3652a96c567f8e16a6cf784
---
include/osmocom/gsm/protocol/gsm_04_08.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/osmocom/gsm/protocol/gsm_04_08.h b/include/osmocom/gsm/protocol/gsm_04_08.h
index 767aa3d..c05b62e 100644
--- a/include/osmocom/gsm/protocol/gsm_04_08.h
+++ b/include/osmocom/gsm/protocol/gsm_04_08.h
@@ -1456,6 +1456,8 @@ enum chreq_type {
CHREQ_T_PAG_R_TCH_F,
CHREQ_T_PAG_R_TCH_FH,
CHREQ_T_LMU,
+ CHREQ_T_PDCH_ONE_PHASE,
+ CHREQ_T_PDCH_TWO_PHASE,
CHREQ_T_RESERVED_SDCCH,
CHREQ_T_RESERVED_IGNORE,
};
--
- Neels Hofmeyr <nhofmeyr(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
* Geschäftsführer / Managing Directors: Harald Welte
Good Evening,
With the recent commits for the OM2000 protocol, I figured it was time
to dust off the RBS2308 and see what would happen. I am using the latest
version of DAHDI, with a TE122P T1 card. All osmocom software was pulled
yesterday and installed successfully on a machine running Debian Stable.
When OpenBSC starts, all appears normal with regards to bringing the BTS
up until the timeslots for the first TRX are being configured. When the
timeslots are configured, a protocol error is given for each. If I
change trx0/ts0 from the default of CCCH+SDCCH4 to CCCH, that timeslot
is successfully brought up, and the BTS transmits. Other configurations
(TCH/F, TCH/F, PDCH, SDCCH8, TCH/F_TCH/H_PDCH) on timeslots 1-7 give the
same protocol error.
I have attached my openbsc.cfg, the output from the OpenBSC console, a
pcap of the failed startup, and my DAHDI configuration. If they do not
come through the list server, they are also available at:
http://cleb.org/RBS/
Thanks,
Caleb
