This is most probably related to / fixed by https://gerrit.osmocom.org/5516 :
[ 142s] [0;m<001e> rate_ctr.c:195 counter group 'msc' already exists for index 0
[ 142s] [0;m/usr/src/packages/BUILD/openbsc/tests/testsuite.dir/at-groups/1/test-source: line 25: 20213 Segmentation fault $abs_top_builddir/tests/gsm0408/gsm0408_test
On Tue, Dec 19, 2017 at 08:14:06PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o…
I recently saw this video / post in which Osmocom had be used to create a GSM Base Station with a LimeSDR mini and a Raspberry PI.
https://www.crowdsupply.com/lime-micro/limesdr-mini/updates/gsm-base-statio…
I was very interested in this, because I need to be able to test cellular broadcast messages, and this seemed to provide a way to do this.. CB seems to be supported in Osmocom.
I am a bit overwhelmed about what I need to install, to get a minimal, but functioning ‘system’ running, so I can test some features.. I ordered a LimeSDR and it hopefully will arrive sometime after the new year
But I wanted to get a jump start on it now. Is there some instructions in the wiki, I just did’tn know which ones to follow.
Kind Regards
Hi,
I want to setup a BTS where only a few subscribers (about 10) are allowed to connect but I do not want any other IMSI/IMEI to be stored in the DB as I have noticed that when the number of subscribers in the database reaches a few thousands the network starts to crash more frequently. Is there an option to prevent all undesired subscribers from being stored in the DB or should I modify the code.
best regards,
Robert
Hi!
As some other developers are starting to work with (and on) the test suites
in the osmo-ttcn3-hacks repository, I migrated it to gerrit today for future
code / patch reviews. I also worked on building the codebase without
having to rely on some out-of-tree clones of upstream titan
repositories. Rather, the makefiles now ensure that all dependencies
are cloned + linked from within the osmo-ttcn3-hacks repository.
I also added jenkins build testing, i.e. we will not get any future
patches into the repository which would break TTCN-3 compiletion. So
far, it validates only on Debian9 with TITAN 6.1.0. As I've already
seen a lot of code that compiles on 9.3.0 (my developent system) but not
on 6.1.0, we will likely add build validation for 6.3.0 soon.
The first patch that has succesfully passed compilation is at
https://gerrit.osmocom.org/#/c/5302/6
Please note that right now we only test the TTCN3->C++ compilation, and
not the compilation of the resulting C++ code for performance reasons.
It would be easy to add if we're willing to wait for the compile time,
but I think it's not really needed. I so far have not yet managed to
make ttcn3_compiler generate any C++ which would then later not pass the
g++ compilation - at least not on a clean build environment.
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)
enum osmo_auth_algo features OSMO_AUTH_ALG_XOR, but now that I'm trying to use
it, I notice that we have no code actually implementing OSMO_AUTH_ALG_XOR.
We have xor as algorithm exposed as a VTY option in the osmo-hlr DB, but when I
choose it, I must notice that libosmocore doesn't osmo_auth_register() any xor
implementation.
Another detail is that I happen to remember that XOR is set as algorithm on the
SIM cards we have in the osmo-gsm-tester, at least in the RnD unit.
How should we deal with it? Implement xor, or remove it from osmo-hlr?
Or am I missing something?
~N
Hi all developers,
I'd like to briefly review the decision for 120 chars line width we've
taken some time ago. To make this clear, I don't want us to re-raise this
issue on a weekly basis. But let's recap on what 120 has brought us?
I know of three developers not finding 120 chars appropriate.
One of them is me, I still think more than 80 would help a lot and remove
the cumbersome need for wrapping lines in many places, but I would prefer
100 chars to 120. I end up getting wrapped lines and have to enlarge
terminals such that only one fits on the screen at my preferred font size.
I used to easily have two.
One objective argument against 120 is the gerrit website: scrolling
left/right there is annoying, because for once there is the overall page
scroll left/right if the window doesn't have enough space (on smaller
screens), and then there's the side-scroll in the individual columns in
the side-by-side view. So UI wise it is beneficial to minimize the need to
scroll on the gerrit website.
For some time I have actually set my local line wrap to 105 and submitted
a number of patches like that, but recently decided it's stupid if each of
us chooses their own favorite, and set it to 120; hence the mail.
My guess is that I'm not the only one who picked his own local favorite,
and if that is so we might as well re-assess the common average favorite,
so that we can all use & enforce the same width.
In case we change this again: about the lines already merged in 120 width,
I wouldn't want us to edit them and just live with a few 120 wide lines
here and there.
What do you guys think?
Would it make sense to have a "pick your favorite <= 120" rule?
Rather re-negotiate one common width? Keep it at 120?
~N
Hello,
we are trying to setup a splitted gsm 2g network, all services are on
different vm's,
e.g. one machine for bsc ,one for bts ...!
At all we have 6 different vm's on a local subnet 192.168.192.X:
osmo-bts-trx (IP = .12) with osmo-trx to support N210 (192.168.10.6) with
TRX IP 127.0.0.1
osmo-bsc - IP = .41
osmo-msc - IP = .42
osmo-hlr IP= .43
osmo-stp IP = .44
and also osmo-mgw (IP=.45) with 2 instances, one for osmo-bsc and the other
for osmo-msc.
If I'm try to call from mobile a to mobile b, I able to see that the call
is incoming but a connection won't establish, the other mobile is ringing,
if I pick up the call on mobile b, mobile a is still trying to connect.
On osmo-bts-trx I get some errors:
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 320 vs 160
(1937437->1937446)
<000e> l1sap.c:96 RTP clock out of sync with lower layer: 0 vs 160
(1937446->1937446)
On osmo-mgw at bsc-side the output looks like:
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:15 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x15 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x15 connection successfully
created
<0011> mgcp_protocol.c:676 MDCX: modifying existing connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 26360, payload 255
(unknown), duration 20, addr 192.168.192.12
<0011> mgcp_protocol.c:805 MDCX: endpoint:0x15 connection successfully
modified
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 4002, payload 255
(unknown), duration 20, addr 192.168.192.45
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x15 connection successfully
created
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:16 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x16 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x16 connection successfully
created
<0011> mgcp_protocol.c:676 MDCX: modifying existing connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 64810, payload 255
(unknown), duration 20, addr 192.168.192.12
<0011> mgcp_protocol.c:805 MDCX: endpoint:0x16 connection successfully
modified
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_sdp.c:333 Got media info via SDP: port 4004, payload 255
(unknown), duration 20, addr 192.168.192.45
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x16 connection successfully
created
However, the osmo-mgw msc side reports following:
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:1 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x1 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x1 connection successfully
created
<0011> mgcp_protocol.c:453 CRCX: creating new connection ...
<0011> mgcp_protocol.c:79 endpoint:2 RTP-setup: Endpoint is in loopback
mode, stopping here!
<0000> mgcp_network.c:188 endpoint:0x2 Failed to send dummy RTP packet.
<0011> mgcp_protocol.c:653 CRCX: endpoint:0x2 connection successfully
created
Best Regards
Sebastian