Hi Folks,
I am busy with implementing XID / SNDCP-XID parameter negotiation to use
data and header compression with GPRS. It would be very helpful to have
an example at hand that shows me how an SNDCP-XID is performed in real life.
If someone of you has a GB-Interface trace at hand it would be very
helpful for me.
regards.
Philipp
Hello everyone,
i am noob to this field and currently trying to establishing a GSM network
with EDGE support
using this page as guide
http://openbsc.osmocom.org/trac/wiki/Ettus_USRP_B2xx_family#no1
i am stuck at this command
sudo osmo-nitb -C -c openbsc.conf -T -P -m
its giving me following error
There is no such command.
Error occurred during reading below line:
extension-prefix 0
% 'dtx-used' is now deprecated: use dtx * configuration options of BTS instead
Fri Jul 15 05:35:26 2016 <0005> bsc_init.c:492 Failed to parse the
config file: '/home/ryker/openbsc.conf'
any help would be highly appreciated
thanks
I have this problem:
DCC <0001> gsm_04_08.c:1649 Cannot patch through call with different channel types: local = TCH_F, remote = TCH_H
(At first I thought it was a bug in dynamic TCH_F/TCH_H/PDCH, but it's actually
about any situation where both TCH/H and TCH/F are available. Tested with master:)
If I configure the BSC to have both TCH_H and TCH_F slots, my two test phones
try to call each other with mismatching TCH types. The CHANNEL REQUIRED
messages send TCH/H and TCH/F, respectively.
phones: Samsung S4 vs. Sony Ericsson SE K800i.
If the CN is configured with only TCH/H or only TCH/F, the two phones talk to
each other fine.
So is this a missing feature in openbsc? In this sense: If one side started off
in TCH/H, the other side should be urged towards TCH/H as well.
This breaks the dynamic TS feature #1776: with fully dynamic TS, we're
implicitly allowing both TCH/H and TCH/F, so if an MS asks for a TCH/F, it will
get one before even considering a TCH/H, even if that mismatches the MS peer.
So we should fix openbsc to "clamp" the callee to the caller's pchan type.
We could also offer a limited TCH/H_PDCH type (or some other config to disable
TCH/F on dyn TS, for example).
~Neels
--
- 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
Hi Neels,
[posting to the openbsc mailing list, as this discussion is not GPRS
related]
On Thu, Jul 21, 2016 at 12:25:25PM +0200, Neels Hofmeyr wrote:
> On Wed, Jul 20, 2016 at 06:50:24PM +0200, Max wrote:
> > It's called from lchan_act_compl_cb() via sapi_queue_send() which is
> > also in mph_send_activate_req() - I have hard time understanding how
> > this works at all. Do we have this documented somewhere?
>
> Both the TCH/F_TCH/H_PDCH timeslot feature and the TCH/F_PDCH on osmo-trx
> are stuck on some post-lchan_act_compl SAPI stuff.
can you be more specific about what "stuff"? It's hard to be of
assistance without details.
Also, SAPIs exist completely separately on every SAP, such as the (M)PH-SAP
of the physical layer and the (M)DL-SAP of LAPDm, wich is implemented
via RSL. So it is useful to explicitly state which SAP we are talking
about when mentioning "SAPI stuff".
> So, I would also benefit from better understanding the actions after
> lchan_act.
I actually think the L1 SAPI activation/deactivation is rather simple.
You have the tables that list the SAPI+Direction combinations needed for
every lchan type (what I just quoted for PDCH in my recent mail), and
then the code iterates over the list of SAPI+Direction at time of lchan
activation or deactivation.
> Apparently related: libosmocore/gsm/lapd*.c
How are the SAPIs of the data link layer should be related to SAPIs of
the physical layer?
LAPDm is establishing reliable channels over the already established
physical layer, and LAPDm is not by iself activating/deactivating any
channels, i.e. not talking to the MPH-SAP.
--
- 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)
Yesterday I came across gsm_ts2chan_nr() in openbsc gsm_data_shared.c
(which is used both in openbsc and osmo-bts).
IIUC this case would expect lchan_nr to be in the range 0..3:
case GSM_PCHAN_CCCH_SDCCH4:
case GSM_PCHAN_CCCH_SDCCH4_CBCH:
cbits = 0x04;
cbits += lchan_nr;
break;
Because if we'd add 4 or more, we would be walking into this cbits space:
case GSM_PCHAN_SDCCH8_SACCH8C:
case GSM_PCHAN_SDCCH8_SACCH8C_CBCH:
cbits = 0x08;
cbits += lchan_nr;
break;
The thing is, I added an assert for lchan_nr < 4, and it hits. We're
actually passing lchan_nr == 4 and thus use cbits = 0x08 for a
GSM_PCHAN_CCCH_SDCCH4: wrong.
This code in osmo-bts-*/oml.c:opstart_compl() activates lchan[4] of a
CCCH+SDCCH4 ts:
/* ugly hack to auto-activate all SAPIs for the BCCH/CCCH on TS0 */
if (mo->obj_class == NM_OC_CHANNEL && mo->obj_inst.trx_nr == 0 &&
mo->obj_inst.ts_nr == 0) {
struct gsm_lchan *cbch = gsm_bts_get_cbch(mo->bts);
DEBUGP(DL1C, "====> trying to activate lchans of BCCH\n");
mo->bts->c0->ts[0].lchan[4].rel_act_kind = LCHAN_REL_ACT_OML;
lchan_activate(&mo->bts->c0->ts[0].lchan[4]);
if (cbch) {
cbch->rel_act_kind = LCHAN_REL_ACT_OML;
lchan_activate(cbch);
}
}
This [4] the first SDCCH4, because this has CCCH in the first [0..3], right?
But then we should use lchan->nr - 4 to add to the cbits, right?
It seems pretty much everyone, our code and various BTS models, are ignoring
the erratic cbits, but would be good to fix.
My SysmoBTS GSM cell still works if I pass cbits = 0x04 instead of 0x08, like
this:
case GSM_PCHAN_CCCH_SDCCH4:
case GSM_PCHAN_CCCH_SDCCH4_CBCH:
/* SDCCH4 is in lchan_nr 4..7, so subtract 4 before adding to
* the cbits. */
if (lchan_nr >= 4)
lchan_nr -= 4;
OSMO_ASSERT(lchan_nr < 4);
cbits = 0x04;
cbits += lchan_nr;
However, I guess passing 0x04 cbits for a CCCH lchan is wrong as well (0x04 is
RSL_CHAN_SDCCH4_ACCH). Instead, we should pass RSL_CHAN_RACH (Uplink CCCH) or
RSL_CHAN_PCH_AGCH (Downlink CCCH), right? How to decide which of the two?
Thanks for any hints,
~Neels
[[[
[...]
<0001> oml.c:830 OC=CHANNEL(03) INST=(00,00,00) Rx OPSTART
<0006> oml.c:500 (bts=0,trx=0,ts=0,ss=0) pchan=CCCH+SDCCH4 ts_connect_as(CCCH+SDCCH4) logChComb=4
^ SDCCH4
<0007> l1_if.c:164 Tx L1 prim MPH-CONNECT.req
<0001> oml.c:249 OC=CHANNEL INST=(00,00,00) AVAIL STATE Dependency -> OK
<0001> oml.c:256 OC=CHANNEL INST=(00,00,00) OPER STATE Disabled -> Enabled
<0001> oml.c:217 OC=CHANNEL INST=(00,00,00) Tx STATE CHG REP
<0006> oml.c:285 ====> trying to activate lchans of BCCH
<0006> lchan.c:31 (bts=0,trx=0,ts=0,ss=4) state NONE -> ACTIVATION REQUESTED
^ ss=4 means lchan->nr=4
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, FCCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (FCCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI FCCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, SCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (SCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI SCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, BCCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (BCCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI BCCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, AGCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (AGCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI AGCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, PCH TxDL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (PCH TxDL)
<0006> oml.c:783 Successful activation of L1 SAPI PCH on TS 0
<0006> oml.c:1040 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.req (hL2=0x000004bb, RACH RxUL)
<0007> l1_if.c:164 Tx L1 prim MPH-ACTIVATE.req
<0006> oml.c:777 (bts=0,trx=0,ts=0,ss=4) MPH-ACTIVATE.conf (RACH RxUL)
<0006> oml.c:783 Successful activation of L1 SAPI RACH on TS 0
<0006> lchan.c:31 (bts=0,trx=0,ts=0,ss=4) state ACTIVATION REQUESTED -> ACTIVE
Assert failed lchan_nr < 4 gsm_data_shared.c:518
^ from mph_info_chan_confirm(), lchan_nr == 4
(gdb) bt
#0 0x47d47208 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x47d4ad8c in __GI_abort () at abort.c:89
#2 0x000186e4 in gsm_ts2chan_nr (ts=<optimized out>, lchan_nr=<optimized out>) at ../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:518
#3 0x00018710 in gsm_lchan2chan_nr (lchan=lchan@entry=0xb6d5b000) at ../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:540
#4 0x0000eb0c in mph_info_chan_confirm (lchan=0xb6d5b000, lchan@entry=0xb6d283c8, type=type@entry=PRIM_INFO_ACTIVATE, cause=cause@entry=0 '\000') at oml.c:56
#5 0x00010730 in sapi_activate_cb (lchan=0xb6d283c8, status=0) at oml.c:1080
#6 0x000108d4 in sapi_queue_dispatch (lchan=0x1, lchan@entry=0xb6d283c8, status=<optimized out>) at oml.c:729
#7 0x00010c2c in lchan_act_compl_cb (trx=<optimized out>, l1_msg=l1_msg@entry=0x4f850, data=<optimized out>) at oml.c:814
#8 0x0000da2c in l1if_handle_l1prim (wq=<optimized out>, fl1h=0xafdc0, msg=msg@entry=0x4f850) at l1_if.c:1037
]]]
--
- 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
Hi list,
I've got a jenkins job ready that adds --enable-iu to the openbsc build matrix.
I'd like to verify with you guys: so far we had a build matrix of 2 x 2, so
openbsc and all its dependencies are built four times over (~22 min).
Adding --enable-iu doubles this matrix to eight times.
This means that any new commit would take about 55 min to verify with jenkins,
even if it is just a comment tweak.
I assume we want to bring this time down a bit?
I'd have these suggestions:
(1)
Just add --enable-iu, let jenkins build for hours and proliferate global
warming, and care about this once it actually bugs us.
(2)
Limit the build matrix: Only build --enable-iu once, e.g. with --enable-smpp
and --enable-mgcp-transcoding, not with all of the other combinations. (Would
--disable-mgcp make more sense?)
(3)
Don't build all of the dependencies over and over. In pseudo sort of:
dep_hashes = ""
for dep in libosmo*:
dep_hashes += "," + dep.get_current_git_hash()
if dep.last_hashes == dep_hashes:
dep."make install"
continue
dep.wipe_out()
dep."autoreconf; configure; make check; make install"
cat dep_hashes > "${dep.dir}/last_hashes"
That would shorten the build time substantially, and we could keep the build
matrix fully featured without taking too much time.
I've so far spent 5 minutes on implementing something like this and could
polish that up, maybe using a global dependencies workspace somewhere else on
the build slave so the separate matrix items benefit from each other.
But do we like that? I would consider re-using previous builds safe enough for
our jenkins verifier, since all deps would be rebuilt even if only one dep's
git hash changes; assuming that it *works*, of course. Do you guys agree?
http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit-test/
openbsc.git branches osmocom/jenkins-test and neels/speed_up_matrix_builds
Thanks for your opinions!
~Neels
--
- 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,
I am playing around with osmocom now for more then 2 years.
i pretty much seen every possible error's when compiling and building stuff but i always used OpenBTS for running my network, but now a couple months back i wanted to try and do the same thing using openbsc
I got most off the tools working on a Debian 8.5, but when i try to run
osmo-nitb -c ~/.osmocom/open-bsc.cfg
i get the an error Aborted
since there is no more information about the error i can't seem to figure out what is wrong maybe something to do with ipaccess?Did anyone else also came up to this problem ?I tried many many times with a fresh installOn Ubuntu 12.04Debian 8.5Kali linux 2016.1also with kali in a docker container i got pretty far with doing it in docker, and osmo-nitb worked, until i installed all the rest and then when i needed to run osmo-nitb i also got back the error Aborted when trying to run it
Please help me out
Thanks in advance
Develectron
Hi Max,
in e.g. e6052c4cc756f7d3a5023a0ba57fe8d80783967c you have added #include
<stdbool.h> in various files.
I'd like to nitpick about the place where you put it:
index 3cba5d1..3d7c244 100644
--- a/openbsc/include/openbsc/gsm_subscriber.h
+++ b/openbsc/include/openbsc/gsm_subscriber.h
@@ -5,6 +5,8 @@
#include <osmocom/core/linuxlist.h>
#include <osmocom/gsm/protocol/gsm_23_003.h>
+#include <stdbool.h>
+
(there are also some more instances)
I'd prefer if we keep system headers grouped on top.
Thanks :)
~Neels
About http://osmocom.org/issues/1757#note-4
With the current naming scheme, the logical name for a fully dynamic
TCH/F-TCH/H-PDCH channel would be
GSM_PCHAN_TCH_F_TCH_H_PDCH
timeslot 2
phys_chan_config TCH/F_TCH/H_PDCH
Is it asking for trouble to just name it DYN instead?
GSM_PCHAN_DYN
timeslot 2
phys_chan_config DYN
I'm in (at least) two minds about it, opinions welcome...
~Neels
