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
Hi all,
it has been coming up in at least two contexts recently: Select is showing
up a lot in system-level profiles particularly on osmo-bts.
This is hardly surprising, as select() is not particularly known for
efficiency. It was used back in 2008 for the *BSC*, in a context where
we were talking about 1-10 BTS with each no more than 1-2 TRX. Now we
are using the same osmo_fd abstraction on the BTS, where the number of
messages per second is much higher, particularly in osmo-bts-trx with
its TRXD protocol, and particularly with higher number of TRX per BTS.
There is an older feature request to introduce epoll support in https://osmocom.org/issues/1579
but unfortunately nobody has been finding the resources and/or time to
implement it.
Meanwhile, 1.5 years ago, the Linux kernel received a new sub-system
called io_uring, which I would personally love to support. Here are some
pointers for those who are interested:
https://lwn.net/Articles/776703/https://kernel.dk/io_uring.pdfhttps://lwn.net/Kernel/Index/#io_uring
As unfortunately not everyone is using half-way recent kernels, we will
likely have to fall back to epoll or something like that.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
There is an urgent need to migrate our most important public
infrastructure to a new server, and I will be doing that on
*Sunday, July 19 2020*, starting about 9am CEST.
The migration involves redmine (main osmocom.org website), jenkins, gerrit,
git, and cgit.
In theory, the migration should be quick. I would expect (significantly)
less than one hour of downtime. However, we all know Murphys law.
Services not affected are mail (including mailman lists), ftp, dns. So in case
of doubt, we can still use mailing lists to communicate.
In case anyone urgently needs osmocom source code on Sunday morning
during the downtime: There are public mirrors available on github.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
Just wondering what the status of OsmoCBC is?
I started compiling from source, but I couldn't find any docs on
interfacing with it other than that it's via a HTTP REST API,
If there aren't any docs are there packet captures or examples I can work
from that'd be quicker than trying to reverse it from the source code,
Happy to contribute some docs once I work it out,
Cheers,
Nick
Good Afternoon,
I recently acquired a NIB Ericsson RBS 6402. The specific model number
appears to be KRD 901 060/83. I see that the osmocom crew has integrated
this RBS with NextEPC at the 2019 CCC Camp event. I have used other
vendors eNodeB's with NextEPC, and would like to try the RBS with it as
well.
So far, I have booted up the RBS, and set my machine with a 10.1.1.1/24
IP address. The limited documentation I found online said the RBS should
respond to http at 10.1.1.11, at which point an XML site configuration
file can be uploaded. I see arp responses in WireShark from 10.1.1.11,
but cannot ping, or access http @ 10.1.1.11. If I place the RBS on a
network with a DHCP server, it obtains an address, but in the same
state, no response to pings, and no http access. Also tried ssh on the
standard port, with no response.
I see the wiki has information that appears to be output from a
terminal. Is that SSH or serial to the board itself?
I do have a rasbpi available on the network with a GPS/1PPS source for
timing. Is this as simple as setting opt 042 in the DHCP server that the
RBS will use?
Any guidance is appreciated!
v/r,
Caleb
dear Pau,
please fix either osmo-bts or ttcn3-bsc-tests so that running ttcn3-bsc-tests works again.
The failure I get for each and every BSC test:
Verdict: fail reason: "Timeout waiting for BTS0 oml-connection-state ""degraded"
When I downgrade osmo-bts to 580a27e97c3f0e139dfd7b0c10de24463d4b5294 (just
before the shutdown FSM was introduced), the tests work again.
(I didn't bisect, just picked that commit.)
This failure is particularly harmful now because we're currently struggling
with quite a couple of other reasons that cause the ttcn3-bsc-tests to fail. So
when we fix those, jenkins won't show the fix, but yet a different error.
I'm reluctant to revert your patches now, hopefully you can find a fix quickly
to move forward instead.
BTW, I also have introduced another new segfault in osmo-bsc myself, testing
the fix now and merging it directly when successful, so that we don't all go
insane.
~N
Hi Philipp (and lurkers on this list),
I've just pushed an update to the @laforge/trau@ branch of libosmo-abis,
which contains the new code modules for E1 / TRAU usage, and also a small
test program and test data.
The test program takes a raw binary dump created from an E1 timeslot with
TRAU frames captured of a BS-11 and converts that to RTP packets. You can feed
those RTP packets into osmo-gapk to play them back. The audio is clear, there
are just a few seconds of quiet at the beginning before anything is audible.
The patches also add an "I460" mode to e1_input. So from the osmo-mgw side,
I think we need to
* link against libosmo-abis and call e1inp_init + e1inp_vty_init()
* use existing VTY code to configure E1 line numbers / drivers / ports
* call e1inp_ts_config_i460() on every timeslot we want to use (this should *not*
happen on all timeslots, as some of them are used for signalling by the BSC)
* call osmo_i460_subchan_add() / osmo_i460_subchan_del() for each i.460 sub-slot
we want to use
* build the processing chain like in libosmo-abis/contrib/trau2rtp/trau2rtp.c
via i460 -> trau_sync -> osmo_trau_frame_decode_16k/osmo_trau_frame_decode_8k -> osmo_trau2rtp
I believe this should be at a stage where it can be integrated into osmo-mgw. The API
may not be 100% stable yet, but it shouldn't change completely. The main missing
bits are:
* allow selection of sync pattern in trau_sync.c (or auto-detect?)
* handling of T-bits for alignment of air-interface timing with downlink
TRAU frame timing
I will next be hacking on a small tool that will speak the 'osmo-e1d' protocol
but use binary capture files that are looped over and over again. This way
you should be able to use libosmo-abis e1_input without any physical card and
still get TRAU frame data.
At a lower priority, I'd like to look into support for HRv1 and AMR TRAU
frames on 16k sub-slots.
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
