@fixeria: re the C compiler used on the FreeBSD build slave:
it is actually, apparently:
FreeBSD clang version 3.4.1
20140512
x86_64-unknown-freebsd10.3
At least that's what a libosmocore ./configure step shows in its config.log.
~N
Hello,
is it possible to connect the openbsc from the vlr_3G Branch with sip-connector to asterisk as described on https://osmocom.org/projects/osmo-sip-conector/wiki/Osmo-sip-connector, or are there changes in the vlr_3G Branch that makes this impossible?
When trying to set this up I was able to call an UMTS-Phone which was connected to the nano3G from a softphone using jitsi, and the UMTS-Phone was ringing, but it was not possible to answer the call.
I have only limited experiences with asterisk and so I am for example unsure about what voice-codecs to use, if my asterisk-config is correct,... and so I would like to know if it should work in principle and I have to find the correct configuration.
have a nice weekend,
Andreas
Hi,
for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR).
I could envision we have:
* A simple build shell script to build/install everything
* A script to update (and tag) the default.xml to make new releases available.
How to use it (if repo is installed):
repo init -u git://git.osmocom.org/osmocom-cellular-manifest
repo sync
./build_all.sh --prefix=/opt/cellular
aand on a new release
repo sync
./build_all.sh ...
ideas? comments?
holger
default.xml:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote fetch="git://git.osmocom.org" review="gerrit.osmocom.org" name="osmocom"/>
<default revision="refs/heads/master" remote="osmocom"/>
<!-- base libraries -->
<project name="libosmocore" revision="9e83c3d5ca64428befe74e5aad61bd84bccaf309"/>
<project name="libosmo-abis" revision="bf7976c0b0076410ad1bd67061dd18d0f33a7f43"/>
<project name="libosmo-netif" revision="c108c9db969c4d4abaccc88419b4ac0c44957365"/>
<project name="libsmpp34" revision="cc0bcd6bc051d5ccaf32cdbbc28f073369900857"/>
<project name="libosmo-sccp" revision="57d0449d4ed5d82050c52551c8ad6195db38fdf1"/>
<!-- RAN -->
<project name="osmo-trx" revision="de116e90c03c534fa4b51ef40dfd2bb9e843c86e"/>
<project name="osmo-bts" revision="25742a5929edecc545a4fc254f678cc834f8c3b3"/>
<project name="osmo-pcu" revision="e6d26ec09c2bcd2126416a58cb23af27318ec67e"/>
<project name="osmo-iuh" revision="46fea15afc38fb995baf4100f4de1d6a3565899f"/>
<project name="openggsn" revision="19e19e3609508d121ba46c165e5ed1502a3cf9da"/>
<project name="openbsc" revision="d75f11e6f26a50c11f73625de5c0833971900cde"/>
<project name="osmo-sip-connector" revision="417f2542163edfe8ac8729918e2452dc7787a3d7"/>
<!-- Core -->
<project name="osmo-hlr" revision="743cf42ac5dfa2661317e73f70b204bde7450ff2"/>
<!-- Misc -->
<project name="osmo-gsm-manuals" revision="4b593a2259a107211489940b8b59f44219e73b2d"/>
<!-- Copying a build script to the top level directory -->
<project name="osmo-ci" revision="e72f35cfa9969e52d0018ba4661f4519519c39ba">
<linkfile src="build/build.sh" dest="build.sh"/>
</project>
<project name="python/osmo-python-tests" path="osmo-python-tests" revision="baa6f12260c383f40a477b71743b16940c50e5aa"/>
</manifest>
Hi Tomas,
I again have a question related to your SSE accelerated Viterbi
decoder, and I hope it's the last issue, which prevents us from
finishing this work. In short, SSE based implementation provides
one-byte different decoding result for SCH transcoding test. So,
the whole GSM 05.03 coding test fails.
I have done some debugging, and would like to share some results.
Have a look at the tests/coding/test_sch(), which first encodes
a L3 packet into ubits and sbits, then some bits are getting
destroyed, then the gsm0503_sch_decode() is being called to get
decoded bytes back, and finally decoded bytes are being compared
with original bytes.
As long as encoder implementation is not covered by SSE code,
it works as before. But SSE accelerated decoder outputs one-byte
different result in case of SCH:
int gsm0503_sch_decode(uint8_t *sb_info, sbit_t *burst)
{
ubit_t conv[35];
int rv;
osmo_conv_decode(&gsm0503_sch, burst, conv);
rv = osmo_crc16gen_check_bits(&gsm0503_sch_crc10,
conv, 25, conv + 25);
if (rv)
return -1;
// ...
}
// Original implementation
ubit_t conv[35] = {
0x01 0x01 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00
};
// Accelerated implementation
ubit_t conv[35] = {
0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00
0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00
};
As you can see, the conv[3] isn't the same in both cases. So,
at the next step the osmo_crc16gen_check_bits() returns -1.
Latest version of this change:
https://gerrit.osmocom.org/#/c/2454/
Do you have any ideas? Despite SCH decoding isn't required on
BTS side, the problem may be more global, than the test shows.
With best regards,
Vadim Yanitskiy.
Just asked holger: the osmo-stp build from cellmgr in the nightly debian
packages can be switched off. Since you've been fixing debian these days, could
you do that one as well? Hopefully we will have no more failures then.
(...except on the new ubuntu 17.04 of course, no idea what's up with that. Not
sure who added it and who will resolve those, or whether that's already done?)
Thanks!
~N
Hi,
I am trying to setup the 3G Project and have bought a used nano3G BTS (S8 - Model 237A) .
The problem i am facing is that the telnet port is not open. I have tried to reset the device using the pin-hole reset button as per documentation but it still doesn't open up the ports and still tries to lookup operator's NTP and tries to establish a IPSEC tunnel.
Any pointers on how i can reset this so that I can get it to work with the project?
Thanks,
##Resending again as the previous message didn't make it to the list.
Hi,
I am trying to setup the 3G Project and have bought a used nano3G BTS (S8 - Model 237A) .
The problem i am facing is that the telnet port is not open. I have tried to reset the device using the pin-hole reset button as per documentation but it still doesn't reset or open up the ports and still tries to lookup operator's NTP and tries to establish a IPSEC tunnel.
Any pointers on how i can reset this so that I can get it to work with the project?
Thanks,
Hi All,
Using zebra/quagga VTY code was a great idea back then and has served us
nicely in all those years. I like the general style of the command-line
based interface with its various nodes, the strict syntax checking, the
tab completion and the interactive context-sensivive help.
However, it feels a bit 20ieth-century-ish to have to manually write
code to parse and to save the respective values. This is not a
productive way to spend our development resources, and it is error
prone. The "save" can be forgotten, resulting in non-saveable config
parameters. The save can store values that the "parse" function will
not be able to read again, etc.
Furthermore, the VTY is inherently a human user interface, not intended
for programmatic consumption. For programmatic access, we have
developed the control interface. In reality though, only 1% of the
parameters available in the VTY are exported via the control interface.
And rather than adding all the missing bits and pieces with hand-crafted
code to the control interface, we should have a generic way to define a
new configuration value, and that value should then be automatically
parse- and storable via VTY as well as a programmatic interface.
The next "problem' is that the current telnet connections live within
the process of the application. This means that a user can effectively
"stall" the main application by performing I/O intensive operation on
the VTY, or even on as many VTY/telnet sessions as he wants. There
shouldn't be any need for this, at least not for something as mundane as
performing configuration changes. Of course the VTY has different use
cases such as runtime introspection of system state as well as logging.
But still.
Yet another concern is "VTY and telnet port proliferation".
Particularly with the conversion from NITB to BSC+MSC+HLR, we are yet
again getting more network elements with their own telnet ports.
Remembering the port numbers is clumsy. It would be more convenient if
a single command line interface could provide access to the
configuration and the state of multiple different processes / network
elements.
Last, but not least, the current implementation is fixed to telnet,
without any form of authentication, and without a path to migrate e.g.
to something like SSL or SSH. I don't think it is a major concern (you
can always SSH to the system and then telnet locally).
So what I had in mind for quite some time (actually since netconf 1.2
about one year ago), is to have some kind of an external "VTY/MIB
daemon" (or even separate daemons for each) which maintains a
hierarchical database of configuration values. The MIB deamon simply
offers an API (via client library) to GET or SET the individual values,
or to NOTIFY an application about a changed value. This API is both
used by the actual Osmocom programs to obtain their configuration (and
obtain updates to it during runtime), as well as by the "VTY daemon"
providing interactive shell access to it. Finally, other external
applications could use the same interface/client library to do the same.
A proxy to SNMP or REST interfaces can be imagined, for even more
interfacing with the outside world.
What I don't like about many existing MIBs I've used (as a
sysadmin/user, not a developer) is their simple type system. You can
often specify any random value to such a MIB, even one that is
completely useless. A simple INT or STRING type is not sufficient, we
really want the ability to have ENUM types, to have integers with
ranges, etc. - just like we have in the VTY.
Also, the MIBs I've used typically are nothing more than a hierarchical
key-value store. They do not contain the information required for
interactive, context-sensitive help needed for the "VTY" feel :( This
is btw also the problem I have with OpenWRT's uci: It just has keys and
values, with no way to constrain those values to something that's
reasonable to the given program/context that is being configured, and
there's no help or other information associated with those keys and
values.
So what I would like to see in this context, is some way to have a
machine-parseable description of a "MIB/config item", together with
syntax, ranges, enum values, help texts, etc (ideally in the C source
code, possibly in comments?) which is used by some kind of MIB compiler
to build up the hierarchical structure of the MIB and all of its keys as
well as their permitted values and syntax reference. This information
is then available to the VTY/telnet connections, irrespective of whether
a given application [using those values] is running at all.
Once an application starts, it can query for the configuration values it
is interested in and populate its internal data structures from it.
Ideally, one would even be able to generate a 'struct' from the MIB
compiler, so that there is no need to explicitly call a "get" function
on each single configuration value, but one simply gets a C-language
'struct' with all the values filled in by the client library.
As stated above, there should be some way how he MIB can notify
applications about changes to certain nodes in the MIB tree, so the
application[s] can react to that. I don't have a clear picture yet how
transaction logic (like changing multiple values and then committing
them at once) would work, or whether applications should even be able to
reject/revert a modification?
In either case, I just wanted to share my thoughts on this. I know it
sounds rather complex, but I think the investment in some kind of
unified configuration database system would save us of a lot of
boilerplate code and subtle bugs and inconsistencies.
I've created https://osmocom.org/issues/1975 with above text to keep
track of it, but I think at this point it's more of a mailing list
discussion rather than something we can put into an issue. I guess the
progress would rather be
* first discuss it here and/or at OsmoDevCon
* create something like a specification in the wiki
* then follow-up with actual tickets on the work items
All of this is brainstorming and vaporware, but I can't help to think of
better ways of doing this. If somebody has experience with any existing
systems and wants to share if and how they might fit, or what other
ideas are useful to borrow: Please share!
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)
