> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote:
> [translated from german]
> is it certain that we switch a channel to PDCH only when
> gprs mode != none?
A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we
send a PDCH ACT message.
We send a PDCH ACT message
- during init (CHANNEL OML's state changed to enabled -> send PDCH ACT),
- and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH.
So the question is, when we receive a channel release ack, could that be
the PDCH release and we switch PDCH right back on by accident? No, because
we only receive a chan rel ack when the *TCH/F* is being released.
That is because the PDCH release is initiated "internally" from the PDCH
DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches
on, which existed before dyn PDCH:
if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) {
LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n",
gsm_lchan_name(lchan));
return 0;
}
In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but
not in the rsl_rx_dyn_pdch().
This is analogous to the ip.access way -- the ip.access nanobts replies to
a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel
release ack.
Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH
for clarity? (But we shouldn't actually send a release ack, to stay
compatible.)
Even though it works as-is, we should indeed add another flag check:
- We do check the flags that no ACT/DEACT is already pending;
- And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE;
- But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE.
This should never happen, but it would make sense to ensure that.
~Neels
Hi,
My name is Brackley Cassinga Form DRC, we run a community network called
pamoja net where we offer gsm services using osmocom open source software
and OC Base station.
Recently I have tried to install another base station as the same installed
but I could not find any resource guiding through all the steps to take to
run NIB on a base station.
I'm currently running Ubuntu and I will appreciate if you could guide me on
the installation of BSC,hlr,MSC , in order to run a basic gsm network.
Thank you. Regards
--
*Ir Brackley heshima Casinga **Pacifique*
*CEO and Founder of kwanzatechnologie*
KwanzaTechnologies ,GlobalElectronics
+243977265291 | +243977265291 | Pcassinga(a)gmail.com/
brackley(a)ensemblepourladifference.org
www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> |
Skype: Brackley cassinga <https://webapp.wisestamp.com/#>
Av Semliki N 43
Hi all,
DW-TV has just released a video report on the community owned and operated
cellular networks within TIC, the Mexican partner of Rhizomatica.
You can find the (Spanish only) video at
https://www.dw.com/es/telefon%C3%ADa-ind%C3%ADgena-en-defensa-del-derecho-a…
I recommend to watch the full video to catch some glimpses into the
life of people in one of the communities operating their own Osmocom
based cellular network.
If you don't have the time to follow the full video, some pointers
below:
* from 4:35 you can see how the taxi service (the only form of public
transport!) can pick up people anywhere in the region after they
make a mobile phone call
* from 12:50 onwards, the BTS is introduced, and its role (and that of
the BSC) are explained in a nice animation.
* from 18:49 you can see the part covering the role Osmocom
and sysmocom are playing in the development of the underlying
technology. You can also catch a glimpse of the sysmocom office
Especially for somebody who's never been there in person, it is very
enlightening to see more about how people use it. And the technology
geek in me of course enjoys the work related to power supply, including
the home-made inverter for solar charging (from 16:12)
Let me conclude with the statement that I'm extremely happy about
(and proud of) the amazing work that Rhizomatica, TIC and friends are
doing. It's great to see Osmocom code being put to use in such a
meaningful way, and for what it was crated: To enable people (literally
anyone) to operate their own cellular networks in whatever way,
independent of large multi-national corporations. There are just very
few places where people have actually managed to do this, given all the
legal, political, economic constraints, including spectrum licensing.
Thanks to Peter, Keith and his colleagues for dedicating many years to
this cause.
Thanks to DW-TV and Eva Usi (the reporter behind this piece).
Further links (in case you weren't aware of those projects/entities):
https://www.rhizomatica.org/https://www.tic-ac.org/
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)
In case this wasn't noticed yet, libosmo-netif doesn't build (pass "make check") on debian 8 anymore. This clearly looks like a regression. It happens both on x86_64 and on armv7l.
Thanks in advance for anyone finding time to investigate.
Cheers (from holidays),
Harald
-------- Original Message --------
From: OBS Notification <admin(a)opensuse.org>
Sent: September 19, 2019 3:44:40 AM GMT+02:00
To: Alexander Couzens <lynxis(a)fe80.eu>, Harald Welte <laforge(a)gnumonks.org>, OpenBSC gerrit-log Mailing List <gerrit-log(a)lists.osmocom.org>
Subject: Build failure of network:osmocom:nightly/libosmo-netif in Debian_8.0/x86_64
Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l…
Package network:osmocom:nightly/libosmo-netif failed to build in Debian_8.0/x86_64
Check out the package for editing:
osc checkout network:osmocom:nightly libosmo-netif
Last lines of build log:
[ 124s] autoreconnecting test step 3 [client OK, server OK], FD reg 1
[ 124s]
[ 124s] autoreconnecting test step 2 [client OK, server OK], FD reg 0
[ 124s] +
[ 124s] +autoreconnecting test step 1 [client OK, server OK], FD reg 0
[ 124s] connection closed with srv
[ 124s]
[ 124s] -autoreconnecting test step 1 [client OK, server NA], FD reg 0
[ 124s] +autoreconnecting test step 0 [client OK, server NA], FD reg 0
[ 124s]
[ 124s] non-reconnecting test step 7 [client NA, server OK], FD reg 1
[ 124s]
[ 124s] 1. testsuite.at:4: 1. stream_test (testsuite.at:4): FAILED (testsuite.at:8)
[ 124s] debian/rules:27: recipe for target 'override_dh_auto_test' failed
[ 124s] make[1]: *** [override_dh_auto_test] Error 1
[ 124s] make[1]: Leaving directory '/usr/src/packages/BUILD'
[ 124s] debian/rules:13: recipe for target 'build' failed
[ 124s] make: *** [build] Error 2
[ 124s] dpkg-buildpackage: error: debian/rules build gave error exit status 2
[ 124s]
[ 124s] build30 failed "build libosmo-netif_0.6.0.2.a1e9.dsc" at Thu Sep 19 01:44:36 UTC 2019.
[ 124s]
[ 124s] ### VM INTERACTION START ###
[ 125s] Powering off.
[ 125s] [ 106.236806] reboot: Power down
[ 125s] ### VM INTERACTION END ###
[ 125s]
[ 125s] build30 failed "build libosmo-netif_0.6.0.2.a1e9.dsc" at Thu Sep 19 01:44:38 UTC 2019.
[ 125s]
--
Configure notifications at https://build.opensuse.org/user/notifications
openSUSE Build Service (https://build.opensuse.org/)
--
Sent from a mobile device. Please excuse my brevity.
Hello Osmocom community,
how about we set the C and C++ dialect defaults in for each Osmocom
program? Then we would not run into the kind of errors, where code
compiled without errors in the gerrit verification jenkins job, but
failed to compile elsewhere because a different GCC uses different
default dialects. We ran into this already with differences in gerrit
verification and master builds [1], and it can easily happen when
building the binary packages for the various Debian versions and
derivatives in OBS.
In [2] is an example patch for OsmoPCU, hardcoding the following
dialects (gnu89 is the same as the linux kernel uses [3]).
CXXFLAGS="$CXXFLAGS -std=gnu++03"
CFLAGS="$CFLAGS -std=gnu89"
(Note that we can't use the non-gnu dialects, libosmocore won't build
with those.)
Is anybody against doing this, or has other recommendations for dialects
we should use?
Regards,
Oliver
[1] https://osmocom.org/issues/3598
[2] https://gerrit.osmocom.org/c/osmo-pcu/+/15565
[3]
https://github.com/torvalds/linux/commit/51b97e354ba9fce1890cf38ecc754aa496…
--
- Oliver Smith <osmith(a)sysmocom.de> https://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
Dear osmocom-cni contributors,
I would like to retrieve (i.e. read or get) some data from a running
osmo-msc from the CONTROL interface...
but sorry, currently I cannot find either from the manuals or the source
code the name of variables I can query.
Is there a mean to list all the variables that can be “GET” from the
osmo-msc CONTROL interface?
And… the list that can be “SET” through the osmo-msc CONTROL interface?
I am also interested in other osmo-cni nodes.
Thanks a lot in advance.
BR,
Igor.
Dear Osmocom community and friends,
Next week on September 10, I will be presenting a talk about cellular base
station technology as part of the "Datengarten" series of talks at Chaos
Computer Club Berlin (CCCB).
The talk will focus on actual base station hardware as it evolved during the
last 20 years or so. It will not assume much in terms of protocol stacks or
cellular architecture, but more focus on the hardware building blocks.
More information can be found at https://berlin.ccc.de/datengarten/102/
The event is public, so feel free to invite anyone along whom you think
might be interested.
Regards,
Harald
--- Abstract
In today’s hyper-connected society, everyone constantly uses their
smartphone, which in turn uses the commercial cellular networks (from
2G/GSM to 4G/LTE) in order to achieve connectivity. However, contrary to
WiFi technology, even most technology-minded people don’t have much of
an idea how the infrastructure behind those cellular networks looks
like.
This talk does not cover the architecture and protocols of underlying
cellular systems, but focuses on the physical side of things:
* what are the typical components of cellular base stations?
* what are their key functionalities?
* how did cellular base station technology evolve during the past 20 years?
* how do we expect cellular base stations to change in the [near] future?
We will not cover DIY or hobbyist projects here, but the actual
technology deployed in the field by real-world commercial operators.
---
--
- 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 everyone!
I have a BTS that is trying to connect to openbsc via SCTP, but as i see it
is not supported.
I have attached a capture file between the core network equipment and BTS
10.0.0.7 is the IP Address of the ABIS link and port is 14597 the rest is
for UMTS and LTE so please ignore it.
I would be really gratefull if someone could look into this
Kind thanks to everyone!
Hi,
i've pushed all modificatons from the chaos communication camp 2019 to
the osmocom repositories as cccamp2019. Except for libosmo-abis which I
directly pushed to gerrit.
I would like to go next over the 35c3 branches, take a short overlook
and remove them if them aren't useful.
best,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604