Hi.
When we're making new library release we got to make sure that the API/ABI versions
are properly updated by correctly setting *_LIBVERSION which has 3 components:
current[:revision[:age]].
That's documented in
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info…
The rules are as follows:
1. If the library source code has changed at all since the last update, r++;
2. If any interfaces have been added, removed, or changed since the last update, c++,
r=0;
3. If any interfaces have been added since the last public release, a++;
4. If any interfaces have been removed or changed since the last public release, a=0.
What's not clear to me is how those rules should be used. Do we apply them sequentially?
For example, I've added function lol_what() to public API of my library with previous
LIBVERSION=3:2:1 and would like to compute new LIBVERSION properly.
According to rule #1 I've got to update revision: 3:3:1
According to rule #2 I've got to update current and reset revision: 4:0:1
The rules are conflicting so let's assume latest rule wins and apply further rules:
According to rule #3 I've got to increase age: 4:0:2
So far so good but do correct me if I'm misunderstanding it.
Now LIBVERSION=4:0:2 is released, I've removed lol_what() and added foobar()
functions. Let's bump the LIBVERSION:
#1: 4:1:2
#2: 5:0:2
#3: 5:0:3
#4: 5:0:0
Am I interpreting this right? We only increase revision if no interfaces have been
added, removed, or changed since the last update? This means that "current" and
"revision" increments are mutually exclusive.
--
Max Suraev <msuraev(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 Director: Harald Welte
Hello everyone,
we are struggling to set up an 2G network using single bsc and msc
components rather than osmo-nitb.
We successfully managed to run an 2G-Network with osmo-nitb using an
usrp-n210 as trx.
Now how is the BSC supposed to connect to the MSC? In an older build of the
osmo-bsc and like described in the osmo-msc user manual I was able to setup
an cs7 instance using the m3ua via osmo-stp to the msc. But as I'm using
the nighlty-packages now there is no longer a way to configure cs7
instances in the BSC and since we are completely new to this project we
aren't up to date with all the recent changes. Apologizes for that.
We're also struggling to build the osmo-bsc sources. It quits with
"bsc_vty.c:313:5: error: implicit declaration of function ‘OSMO_SEC2DAY’".
So I guess there is a package missing but I couldn't find out which one it
is.
TIA
Best regards,
Ralf
Hi,
I have even tried authorizing imsi via sql. I could able to authorize by following https://osmocom.org/projects/osmonitb/wiki/OsmoNITB and it lists the extension number, exactly what I have assigned.
But the error still persists.
Issues listed below is similar to what I'm facing but is there any solution for this?
http://lists.osmocom.org/pipermail/openbsc/2012-February/004695.htmlhttps://osmocom.org/issues/1648#note-19
Thanks,
Sudhanthiradasan R
From: Sudhanthiradasan R
Sent: Monday, October 16, 2017 6:28 PM
To: openbsc(a)lists.osmocom.org
Subject: Location Update Error
Hello,
I'm getting below error, when I ran "/usr/local/osmo_built/bin/osmo-nitb -c ./../osmo_cfg/osmo-nitb_2trx.cfg -l ./../osmo_cfg/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM"
<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> gsm_04_08.c:3960 Dispatching 04.08 message, pdisc=5
<0002> gsm_04_08.c:1389 LOCATION UPDATING REQUEST: MI(IMSI)=901550000001016 type=NORMAL
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x18 to MS.
<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ERROR INDICATION
<0000> abis_rsl.c:1954 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION cause=SABM frame with information not allowed in this state in state=ACTIVE
<0002> gsm_04_08.c:596 Location Updating Request procedure timedout.
<0002> gsm_04_08.c:474 Subscriber 901550000001016:
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x04 to MS.
Anyone had the same issue earlier? Is there any solution for this error?
Thanks,
Sudhanthiradasan R
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
Hi All,
We tried to edit the maxdly and maxdlynb in osmo-bts-trx through CLI and everything works fine.
But after saving the configuration and restarting the osmo-bts-trx instance, it give an unable to parse error.
The reason we found is that, the osmo-bts-trx needed the “osmotrx maxdly 2” string to parse the config file correctly but the CLI config save is only “maxdly 2”.
So we need to edit the config file manually so that the osmo-bts-trx can parse the config file correctly.
Best Regard,
Ron Menez
ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>
[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org]
Dear all,
time is flying, and I would like to start early with discussions and planning
about OsmoCon and OsmoDevCon in 2018. It helps to start early.
Side note: We have some pending issues about the events from last year at
http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them
in the text below.
== OsmoDevCon ==
For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as
every year, which means:
* same venue, same catering options
* same concept of 'anyone contributing to Osmocom can apply for
registration until all seats are taken'
* same idea of inviting some few speaker[s] doing other FOSS mobile
communications work to join us
The parts that we need to change, IMHO:
* don't reduce from 4 to 3 days like last year. Have full 4 days again
* sort topics per day / half-day, i.e. have "GSM/UMTS Cellular
Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co,
but then have other days for other projects. This would enable people
not interested in the [continued evolvement] of the cellular projects
be able to skip those days, or to simply meet in an adjacent room for
parallel hacking sessions/discussions
* try to be a bit more structured with the schedule in general. The
existing approach works for people who attend all the event all day
long, but not so well for people with other plans / limited time
Any further change requests or topics to discuss?
Please note that Pablo Neira has offered to kindly host an OsmoDevCon in
Seville (Spain). I've attended a number of netfilter workshops he
organized there, and he's doing a great job! However, given the large
number of attendees from Berlin (and Germany in general), I think this
would make things more complicated, and more expensive for most
attendees. If you disagree with that assessment: I'm open for having
the discussion, I just thought it's more practical/economic to do it in
Berlin.
=== 10 year Anniversary Party ===
Given that 2018 marks the 10 year anniversary of Dieter and me hacking
with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves
some special celebration of some form. I have no concrete idea yet, but
for sure we should so something, and it should be at/around
OsmoDevCon. And for sure we should have a BS-11 around :)
== OsmoCon ==
The public OsmoCon was welcomed and was a success. However,
let's start this discussion with a review of last years event.
=== Registration ===
* Registrations came in way too late. Two weeks ahead of the event, we were
considering to cancel it. And then within the last few days, we had
to turn people down due to limited seating capacity
* To make planning more reliable, we see on other option but to
significantly raise the registration fee combined with an equally
significant discount for early booking
=== Duration ===
* Many people requested multiple days rather than just one, in order to
make more out of (long distance) travels. This is obvious, but as we
had no idea how many people would attend at all (or if we have to
cancel due to lack of attendance), planning multiple days in the first
incarnation would have been high risk and a multitude of work
* I would suggest to expand to two or even three days this week,
possibly one days with tutorials and the other day with tech talks
* Slightly less crammed schedule due to multiple days
=== Venue ===
We recognize this yearso venue was not the best option, due to
* Bad ventilation in the basemenet
* Difficult to find
* No space next to the conference room where people can meet / hang out
in parallel to talks (not everyone attends every talk)
I still like the "understatement" of the venue. I'd prefer any hostel /
non-profit / hackerspace / university over luxurious hotels any time.
Going to an expensive venue means more or less automatically more
expensive ticket fees, which again is more likely to exclude pure
community members without a commercial activity related to Osmocom.
So any future venue would ideally:
* be able to hold slightly more people than this year
* have a second room or large lobby in which people can meet for
extended coffee breaks in parallel to some talks, as needed
* be slightly easier to find (and we have to put up some signs outside
and in the lobby)
* have better WiFi and/or wired connectivity
=== Programme / Format ===
* less crammed over multiple days
* some more "interactive" formats were requested, for users to provide
feedback to developers
* there was some discussion about topics / speakers in redmine last
year, but not too much participation [until it was too late].
* I'd suggest a more formal CfP process with a submission deadline that
allows us to publish a preliminary schedule long ahead of the event
=== Video Recordings ===
I think they were a big success, and it was a very big surprise that the
CCC Video Operations Center was volunteering to help such a small and
niche-interest event like OsmoCon. We should make sure that we can
repeat this for 2018.
== Dates / Frequency ==
Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if
OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at
a full week for those of you who would like to attend both events. But
then, I think the number of people attending both events is actually not
all that big. Without checking the details, I think not more than half
of the OsmoDevCon attendees were attending OsmoCon. I would expect that
tendency to remain or even increase.
I still think it's good to keep them back-to-back.
In terms of frequency, I would actually suggest we move to a 6-month
cycle rather than a 12-month cycle. There's a lot of development going
on at all time. I understand that not everyone is able to attend two
events just on Osmocom, especially if it's a spare time / hobby type
activity. That's ok, I think there's no problem with attending either
of the two only, and catching up by video recordings and/or mail on the
other.
The qeustion is: Should that second event be developer-oriented or
user-oriented? Or again both? Any comments here?
Ok, that was a somewhat lengthy e-mail. Please make sure to provide any
feedback you may have as early as possible, to increase the chances of
your feedback being reflected in the planning.
Happy hacking,
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)
Hello,
I need some help regarding configuration of 3rd party msc to the openbsc.
I have seen the msc command in the openBSC terminal which I entered and
felt like a profile creation for MSC's. But I got little confused doing it,
can anyone provide me any documentation regarding basic connection that I
need to do in order to get a up and running GSM network.
Thanks
Anindya
Hi Max!
Since https://gerrit.osmocom.org/#/c/3148/
I am no longer able to individually control log levels in
the vty.
I used to use logging level all everything, then this
allowed me to do such as
logging level smpp fatal (get rid of annoying bind check
every 30 secs)
logging level [category i'm interested in] debug
Now, all I seem to be able to do is turn all categories to a
level with
logging level all debug or logging level all notice.
individual category directives such as logging level pag
fatal make no difference.
What am I missing?
Thanks!
BTW, I get the behaviour I need back by moving your check
below the check for "all"::
diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c
index 01480b1..fb2cab8 100644
--- a/src/vty/logging_vty.c
+++ b/src/vty/logging_vty.c
@@ -213,17 +213,18 @@ DEFUN(logging_level,
return CMD_WARNING;
}
- if (strcmp(argv[1], "everything") == 0) { /* FIXME:
remove this check once 'everything' is phased out */
- vty_out(vty, "%% Ignoring deprecated logging
level %s%s", argv[1], VTY_NEWLINE);
- return CMD_SUCCESS;
- }
-
/* Check for special case where we want to set
global log level */
if (!strcmp(argv[0], "all")) {
log_set_log_level(tgt, level);
return CMD_SUCCESS;
}
+ if (strcmp(argv[1], "everything") == 0) { /* FIXME:
remove this check once 'everything' is phased out */
+ vty_out(vty, "%% Ignoring deprecated logging
level %s%s", argv[1], VTY_NEWLINE);
+ return CMD_SUCCESS;
+ }
+
+
if (category < 0) {
vty_out(vty, "Invalid category `%s'%s",
argv[0], VTY_NEWLINE);
return CMD_WARNING;
Hello,
I'm getting below error, when I ran "/usr/local/osmo_built/bin/osmo-nitb -c ./../osmo_cfg/osmo-nitb_2trx.cfg -l ./../osmo_cfg/hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM"
<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ESTABLISH INDICATION
<0000> gsm_04_08.c:3960 Dispatching 04.08 message, pdisc=5
<0002> gsm_04_08.c:1389 LOCATION UPDATING REQUEST: MI(IMSI)=901550000001016 type=NORMAL
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x18 to MS.
<0000> abis_rsl.c:2013 (bts=0,trx=1,ts=0,ss=0) SAPI=0 ERROR INDICATION
<0000> abis_rsl.c:1954 (bts=0,trx=1,ts=0,ss=0) ERROR INDICATION cause=SABM frame with information not allowed in this state in state=ACTIVE
<0002> gsm_04_08.c:596 Location Updating Request procedure timedout.
<0002> gsm_04_08.c:474 Subscriber 901550000001016: LOCATION UPDATING REJECT LAC=1 BTS=0
<0001> gsm_04_08.c:149 (bts 0 trx 1 ts 0 pd 05) Sending 0x04 to MS.
Anyone had the same issue earlier? Is there any solution for this error?
Thanks,
Sudhanthiradasan R
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
