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
On Tue, Aug 25, 2020 at 02:49:39AM +0000, scan-admin(a)coverity.com wrote:
> *** CID 212862: Error handling issues (CHECKED_RETURN)
> /source-Osmocom/osmo-pcu/src/pdch.cpp: 211 in gprs_rlcmac_pdch::packet_paging_request()()
> 205
> 206 /* loop until message is full */
> 207 while (pag) {
> 208 if (log_check_level(DRLCMAC, LOGL_DEBUG)) {
> 209 struct osmo_mobile_identity omi = {};
> 210 char str[64];
> >>> CID 212862: Error handling issues (CHECKED_RETURN)
> >>> Calling "osmo_mobile_identity_decode" without checking return value (as is done elsewhere 20 out of 22 times).
> 211 osmo_mobile_identity_decode(&omi, pag->identity_lv + 1, pag->identity_lv[0], true);
> 212 osmo_mobile_identity_to_str_buf(str, sizeof(str), &omi);
> 213 LOGP(DRLCMAC, LOGL_DEBUG, "Paging MI - %s\n", str);
> 214 }
I'd like to let you guys know that I intentionally don't check the return value
here. This is only for logging the mobile identity, and if decoding fails, the
logging should just show "NONE".
~N
Hello!
I was able to use the experimental osmo_dia2gsup converter to successfully
enable circuit switched fallback in a test network, but have a couple fixes
for it and osmo_ss7 needed to work with the latest 2G CN components. I
would open a change request in gerrit, but I see that the rebar.conf of
osmo_dia2gsup already depends on a WIP branch from osmo_ss7. How best
should I provide patches for review? Is there ongoing work in
http://git.osmocom.org/erlang/osmo_ss7/log/?h=laforge/wip that needs to be
merged first, and is there a reason it has not been merged already?
Otherwise should I open a change request towards the WIP branch?
Also, do folks have any opinions on how best to package erlang components?
I was going to generate a Debian package for a stand-alone erlang “release”
of osmo_dia2gsup, and am happy to contribute the debian metadata and build
files upstream, but I am not an erlang expert and want to make sure it’s
structured in the correct way if there is a convention I should follow.
>From a random sample it looks like none of the other erlang components are
packaged, so I don’t have a good example to go from. If there is no opinion
I will make an attempt, but I wanted to ask first!
Thanks for your help and patience!
-Matt J.
Hello,
I see that currently openBSC/osmoBSC works with a number of old commercial
BTS such as Ericsson/Nokia/Siemens etc. It works over E1/Abis. My question
is, did somebody try something newer than Nokia UltraSite? I have an
ability to try with FlexiBTS rel.3 with Abis over IP. I'm trying to find
out if maybe it was already tried and had some unresolveable problems?
Please let me know if any.
Thank you
Ivan
Hi all,
What are the plans to expand support for new SDR devices?
When I check the contents of osmo-trx/Transceiver52M/device/ on the git
master I see the supported lms, uhd and usrp1 devices. For example the XTRX
SDR was presented at OsmoDevCon 2018. I expected it to be included in the
master soon. At this point I see its addition in the fairwaves /
libxtrx-wip branch from 2018. That doesn't give me much encouragement for
my next question.
Would it be possible to add support for PCIe SDR from Amarisoft?
Some information about SDR is here
https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288
Based on the
https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drive…
I tried to create support by myself. I've gotten into a state that some MS
with weak requirements for signal quality and timing can connect. My branch
is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle
gr-osmosdr support is here
https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR
This osmo-trx is able to run for a few tens of seconds then it quits and I
have to restart it, so I would need a deeper understanding of the timing
and scheduling of processes within osmo-trx. Who should be a clock master
SW stack or SDR device?
I see a lot of log error messages as
0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst
in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0
<0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending
IND CLOCK 1408899
or
0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver
<0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device
<0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start
<0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR...,
sample rate:1.08333e+06
<0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush
<0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok:
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> radioInterface.cpp:202 [tid=140137328043776] Radio started
<0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task
18522) set name: TxLower
<0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task
18524) set name: RxUpper0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
POWERON 0'
<0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task
18523) set name: RxLower
<0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
<0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested
timestamp is not valid
<0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task
18525) set name: TxUpper0
<0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960,
length = 262144, time_start = 6765960, time_end = 6766960, data_start =
223320, data_end = 224320
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:10976 ts:10960 hwts:6762040
<0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0
<0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in
thread RxLower, requesting stop
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:13476 ts:13460 hwts:6762278
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETRXGAIN 40'
<0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB.
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETRXGAIN 0 40'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETPOWER 0'
<0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60
dB. device:0x1f6e0e0 chan:0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETPOWER 0 0'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 0 5'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 0 5'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 1 7'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 1 7'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 2 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 2 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 3 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 3 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 4 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 4 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 7 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 7 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 13'
<0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver...
<0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver
<0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device
<0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop
<0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped
<0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped
<0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device
Yours XK1Zu
Hi Edgard,
thanks for your interest in the Osmocom project.
On Sat, Aug 08, 2020 at 08:56:08PM +0100, Edgard Ndassimba wrote:
> I have difficulte to implemente osmo-mslookup-client.c
I'm sorry, I don't understand the question...
I looked, and I notice that osmo-mslookup-client is missing from the binary packages.
I opened a bug tracker for it: https://osmocom.org/issues/4706
If you want to use osmo-mslookup-client, you need to build osmo-hlr manually.
For that, please look at
https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source
MSLookup and DGSM are explained in http://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf
chapter "12 Distributed GSM / Multicast MS Lookup"
If you have more questions about this, please write an email to
openbsc(a)lists.osmocom.org
or ask on IRC: FreeNode #osmocom
Please write to the mailing list, and not to me personally.
That way you have more people that can help you, and more people can learn from
your progress. Thanks!
~N
>
> I use ubuntu 16.04 LTS amd64
>
> Could you help me please?
>
> Best Regards
>
> --
> Edgard NDASSIMBA
I recently broke ttcn3-bsc-test-latest for a couple of builds, which is fixed now.
Still it appears like some 'latest' tests remain damaged, but that is actually
not the case. Here a summary of those that look like failures but are expected:
TC_chan_rel_rr_cause:
the test is new and tests a feature not implemented in 'latest' yet.
TC_chan_rqd_emerg_deny:
the test is new and I'm not sure of its 'latest' status.
TC_si2quater_2_earfcns, TC_si2quater_3_earfcns:
osmo-ttcn3-hacks just now merged a patch that also tests EARFCN presence in a
Channel Release message. Since 'latest' still has a bug that causes only the
first EARFCN to appear in that message, these two tests now fail in 'latest'.
TC_cbsp_emerg_write_bts_cgi_cchan:
This used to fail, then during the massive failures it suddenly passed for a
bit, and now fails again. The passes must have been flukes.
~N
Today I noticed that osmo-msc-master was being built several times in a row and
I found there are multiple redundant ricocheting downstream builds of the same
original upstream build timer.
All of:
https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18894/https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18895/https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18896/
show:
Started by upstream project master-libosmocore build number 1624
And then there are:
https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18897/https://jenkins.osmocom.org/jenkins/job/master-osmo-msc/18898/
showing:
Started by upstream project master-libosmo-abis build number 2611
So there are two timers launching master-libosmocore and launching
master-libosmo-abis, and each of these cause multiple downstream build triggers
of osmo-msc. Then there is also the osmo-msc timer, independently launching
more nightly master-osmo-msc builds.
It is not necessary to depend these builds on each other, because none of them
depends on artifacts built in another job, each of them in turn builds the
entire chain of libosmocore up to that build's target project.
Upon a libosmocore *code change*, it makes sense to trigger downstream builds,
but not when caused by a timer or for other jenkins trigger or user reasons.
I vaguely remember discussing this before, but now I realize we could solve
this and have less redundant builds:
Do not configure libosmocore to trigger downstream builds of
master-libosmo-abis (and so on), but instead trigger master-libosmo-abis upon
each libosmocore patch merge. That can be done by adding a "Gerrit trigger" on
the master-libosmo-abis build job config, making a patch-merge to the gerrit
libosmocore.git cause a master-libosmo-abis build. At that point, jenkins
timers no longer cause downstream builds, but merges to master on upstream git
repositories do still cause builds.
(maybe there is also a normal git SCM way that doesn't require
gerrit.osmocom.org?)
For projects like osmo-msc, we would add multiple projects as upstream git
repositories, like libosmocore, libosmo-abis, libosmo-netif, ... , osmo-iuh,
osmo-mgw, ...
Basically all of the projects with more than one dependency get retriggered
redundantly every night, some doing their entire build matrix over several
times for no good reason.
I'm not sure that it's really worth the effort, but I thought I'd mention it
since seeing so many redundant builds on various osmo source trees at night
seems avoidable stupidity. Should someone spend cycles to implement this?
~N
Hi all,
as some of you may know, I am currently working on baseband frequency
hopping implementation for osmo-bts-trx (see OS#4546). I've already
submitted more or less final implementation to Gerrit [1], and in
general it works fine [2].
The idea is quite simple: you have several RF carriers (transceivers)
with fixed frequencies, so on hopping timeslots osmo-bts-trx distributes
bursts between them according to the configured hopping sequence.
However, when it comes to hopping timeslots on C0, the burst
distribution algorithm gets a bit more complicated.
The problem is that on C0 the BTS has to maintain constant power level,
even if there is nothing to transmit, so the phones can detect it
reliably during the power scan. This is achieved by sending dummy
bursts. When frequency hopping is not in use, the scheduler in
osmo-bts-trx sends a dummy burst immediately. When it is in use,
sending dummy bursts needs to be postponed until all transceivers are
processed, because some other transceiver might need to send a normal
burst on the frequency of C0, and there would be no need to send a dummy
burst in that case. So I came up with [3] (any comments regarding
potential optimizations and further improvements are welcome).
While working on this, I stumbled upon the burst filling feature in
osmo-trx [4], that is disabled by default. If enabled, osmo-trx would
be sending dummy bursts itself, so there is no need to send them from
osmo-bts-trx, and thus no need to complicate the burst distribution logic.
I am now wondering why don't we enable this feature by default?
From the VTY reference:
> Send a dummy burst when there is nothing to send on C0 (TRX0) and
> empty burst on other channels. Use for OpenBTS compatibility only,
> don’t use with OsmoBTS as it breaks encryption.
it's unclear how sending dummy bursts would break encryption...
[1] https://gerrit.osmocom.org/c/osmo-bts/+/19030
[2] https://www.youtube.com/watch?v=tGMVNYo9s7E
[3] https://gerrit.osmocom.org/c/osmo-bts/+/19029
[4]
http://ftp.osmocom.org/docs/latest/osmotrx-vty-reference.pdf#subsection.1.9…
Best regards,
Vadim.
--
- Vadim Yanitskiy <vyanitskiy at 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
