Hello,
I have gone through some of the documentations and now trying to install
osmoBSC i.e just the BSC part not the openBSC or osmoNITB. I am kind of
confused , can anyone please tell me if I can build just the BSC part and
in order to do that what are the packages that I have to configure.
Thanks
Anindya
To fix the osmo-msc preliminary debian package build of osmo-msc, I need these
patches in osmo-mgw to be merged:
https://gerrit.osmocom.org/3999https://gerrit.osmocom.org/4000https://gerrit.osmocom.org/4001https://gerrit.osmocom.org/4002https://gerrit.osmocom.org/4003https://gerrit.osmocom.org/4005
(topic 'new_mgw' less 4006 and 4007)
If review takes too long I am tempted to just merge it ahead to fix the state
of osmo-msc.deb in
https://build.opensuse.org/project/show/network:osmocom:nitb-split:nightly
If I do, it means that I would like to fix and improve those patches later, not
that I want to smuggle them past review. I just want to finally get the debian
builds working and off my mind again.
The osmo-msc currently fails because it needs a header file not included in
libosmo-mgcp-client-dev, because that is still tied to libosmo-mgcp headers,
which are of course not included in the libosmo-mgcp-client deb. I want them to
be separated completely to save us this kind of cumbersomeness in the future.
Only one of the above commits unties libosmo-mgcp-client from the other libs,
but small bits here and there make the change depend on the others in that
bunch. I could re-arrange, but that would take time. I'd rather just keep them
in that order, we want them merged anyway.
The large ones in the middle are dexter's work on the next generation MGW that
happened on a branch, being placed beside the legacy code. This way we can move
from legacy to new code in osmo-msc and osmo-bsc independently.
~N
It seems there are a lot more versionings around than I thought...
I am currently deciding on how we want to handle libtool API versions.
These are strings of the form
current:revision_of_current:compat_age
MGCP_LIBVERSION=5:23:4
means that
- We are in API version 5.
- This is the 23rd "small internal" modification of 5.
- We are backwards compatible to 4 previous API versions (1 thru 5).
This is not at all related to release versions of the major.minor.patch form.
For example, each small tweak of the code will bump the middle
'revision_of_current' number, whether it's a minor or patch release bump.
Now I had the plan to actually coincide the major release version with the API
current version. When we are in release 1.0.1 thru 1.23.42 and so forth, keep
the library API current version at 1. Once we do a major version bump to 2.0.0,
we can go on to API current version 2. Coinciding seems to make sense because
we anyway don't want to make API breaking changes unless we bump the major
release number.
BTW the API 'current' version number also appears in the debian package names
like libosmo-mgcp2.deb and the installed library files, like
libosmo-mgcp.so.2...
Keeping the API current the same as release major makes sense to me, but only
up to this point: when we add a new side feature to a library.
When all of the library stays the same and is backwards compatible, and all we
do is add a new function to it, someone linking against it may want to make
sure that this new function is included in the installed version. So even if
we don't bump a major release, don't break API and so forth, we may still want
to increase the API-current version and bump the names of the debian packages
as well as installed .so files.
Why? Because if we had libosmo-mgcp1 and added function mgcp_frobnicate(), and
we want to use mgcp_frobnicate() in osmo-msc.deb, we want to depend on a
libosmo-mgcp that has it added, i.e. we bump to libosmo-mgcp2.deb and depend on
that from osmo-msc.deb. All the while libosmo-mgcp's version tag still remains
at 1.0.23, only the API version changed.
This would be the libtool-intended way, and we'd see a lot of debian package
names' numbers bumping, not at all related to our major-release, whenever we
add any new function to our API.
Only in reality, if I see libosmo-mgcp5.deb, as a user I do expect it to be
libosmo-mgcp release 5.2.3, not release 1.0.23. Right?? Is that only me?
According to libtool, coinciding the API version with the release version is
abuse. OTOH it's what I actually expected for most of my life... :/
Will we have the discipline to bump API current for each addition?
And bump each depending projects' debian depends-clauses?
What do you guys think about this?
See https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info…
Thanks!
~N
--
- Neels Hofmeyr <nhofmeyr(a)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
* Geschäftsführer / Managing Directors: Harald Welte
Hi all,
we have recently merged a profound change to the inner workings of the VTY
configuration. We've hit some fallout due to that, hence I would like to let
you know that you might hit the same.
The VTY parsing of config files is now strict about indenting.
A child node *must* be indented below the parent node,
and indenting must be consistent.
For more details on the reason why and a definition of 'consistent', see the
commit log of
https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a04…
So, if you are in the near future faced with config files being rejected that
worked perfectly before, it is most probably because your indenting was wrong
all the time, and only now did we start checking it.
If the cause is hard to figure out, a good aid is the telnet VTY, where you may
either 'show running-config' or traverse the nodes manually to query which
command exists on which level. If your current config is broken, you may be
able to start the program with an empty or stripped down config file to make
its telnet available.
The above is about reading config files, but we have also dropped the implicit
'exit' to parent level on the telnet VTY console. This caused fallout where
nodes by plain omission lack the 'exit' command: one is unable to leave such a
node once it is entered. That is a fault in the program's VTY setup that was
not found before, because the VTY would often just find the parent node's exit
command instead. I have a patch to avoid all of these everywhere, by
installing the exit and end commands automatically for every VTY node that gets
created; it is not merged yet: https://gerrit.osmocom.org/3998
------ Config Fallout Example ------
For example, we hit a breakage with this osmo-bts-trx.cfg:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
Before, this worked perfectly. Now it says the command 'osmotrx rx-gain' does
not exist. The reason is that 'osmotrx rx-gain' is a child node of 'instance
0'. The first fix looked like this:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
But alas, this time it said the command 'osmotrx ip local' does not exist. I
suspected bugs in the new parsing, but indeed, 'osmotrx ip' is actually a
direct child of the 'phy 0' level. Before, the VTY would implicitly step out of
a child level if it found a matching command one parent above. That is
confusing in other situations (see above commit log), hence we now require
indenting to clarify the structure. This is the correct one:
phy 0
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
Or rephrased:
phy 0
osmotrx ip local 10.23.42.1
osmotrx ip remote 10.23.42.2
instance 0
osmotrx rx-gain 25
osmotrx tx-attenuation oml
To query the structure via telnet, I did:
$ ./osmo-bts/src/osmo-bts-trx/osmo-bts-trx -c osmo-bts/doc/examples/trx/osmo-bts.cfg
$ telnet localhost 4241
OsmoBTS> enable
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# list
[...]
osmotrx ip HOST
osmotrx ip (local|remote) A.B.C.D
[...]
OsmoBTS(phy)# inst
OsmoBTS(phy)# instance 0
OsmoBTS(phy-inst)# list
[...]
osmotrx rx-gain <0-50>
osmotrx tx-attenuation <0-50>
osmotrx tx-attenuation oml
[...]
------ No Exit Example ------
The same osmo-trx VTY nodes also show the exit failure:
$ telnet localhost 4241
OsmoBTS> enable
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# exit
% Unknown command.
OsmoBTS(phy)# instance 0
OsmoBTS(phy-inst)# exit
% Unknown command.
On the phy level, we would previously find the parent's 'exit' command, but in
the 'instance' level, 'exit' has never been available. Above patch should fix
all of these.
~N
--
- Neels Hofmeyr <nhofmeyr(a)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
* Geschäftsführer / Managing Directors: Harald Welte
Hi ,
i’m trying to build osmo-trx master branch .
What i’am doing :
autoreconf -i
./configure
make
In make step i get this error :
Evaluating ‘parse’ option: ‘(?P\d+).(?P\d+).(?P\d+)’ does not parse
current version 'P2.8TRUNK’
usage: bumpversion [-h] [–config-file FILE] [–verbose] [–list]
[–allow-dirty] [–parse REGEX] [–serialize FORMAT]
[–search SEARCH] [–replace REPLACE]
[–current-version VERSION] [–dry-run] --new-version
VERSION [–commit | --no-commit] [–tag | --no-tag]
[–tag-name TAG_NAME] [–message COMMIT_MSG]
part [file [file …]]
bumpversion: error: the following arguments are required: --new-version
make all-recursive
Hi All,
Good day.
If we are going to integrate OSMO-BSC to another MSC, for example, a Huawei MSC, what components do we need?
Is their a link that can help us do this task?
Thank you in advance.
BR,
Bob
Hi all,
I've been creating some test suites for various different interfaces
and Osmocom elements in osmo-ttcn3-hacks.git.
In case you want to use and/or extend them, here is some introduction
in how to build them and how to use them.
I've updated
https://osmocom.org/projects/cellular-infrastructure/wiki/Titan_TTCN3_Notes
with some information on how I build + execute + view the logs, maybe
this is useful to you. Let me know if you have any questions.
For sure this could be more automatized (like cloning the dependencies
or even using them as git-submodule), but so far I'm investing every
minute I have in increasing test coverage, rather than convenience
features.
Regards,
Harald
--
- Harald Welte <hwelte(a)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 Directors: Holger Freyther, Harald Welte
Hi,
I’ve been looking into getting ussd working with an external application. I
found a branch from last year (fairwaves/sup-ussd) that looks like it has
implemented most of ussd sessions and possibly communicates with an
external application. Does anyone know if it was finished or what still
needs to be done?
I also found a python script called ussd_example.py which looks like it is
supposed to act as a gateway and receive used connections from openbsc. Is
this correct and did it work or am I misunderstanding its purpose?
Thanks!
- Rowan Phipps
I implemented https://gerrit.osmocom.org/3880 to use indenting for vty implicit
'exit'.
There's one thing I'm sneaking in there though which I'd like to mention before
I merge:
The patch is storing vty parent node state. This state not only stores previous
indenting, but it also stores the parent's 'node' id and 'priv' data (the
node's object), and puts these back in place after going to a parent.
So far our go_parent_cb()s set these, and AFAIK all of them simply put the
parent's exact node and priv pointer back in place. But technically, a
go_parent_cb() *could* do some magic like going to a completely different node,
or re-creating a new priv pointer. By overwriting from stored state, we will
override such behavior.
I think we want this to happen from stored state in the future, and drop most
of the go_parent_cb(). Does everyone agree?
~N
