Currently there's a big mess where include dir osmocom/gprs/ is used by
both libosmogsm and libosmogb.
Most of the header files under osmocom/gprs/ are actually all the
headers of libosmogb (there's no osmocom/gb/ dir). But a couple files
are actually RLC/MAC (TS 44.060) related are are also stored in there.
Those files have no relation/use in Gb, and are actually interused with
GSM (eg System Information 13 Rest Octets).
Hence, it makes sense to have the RLC/MAC related parts inside
osmocom/gsm/ as they should be in libosmogsm (and they actually are,
see gprs_rlc.h function implemented in src/gsm/gsm48_rest_octets.c).
The fact that some libosmogsm headers were placed in osmocom/gprs
instead of osmocom/gsm already created some issues, like
libosmocore.spec.in putting "%_includedir/%name/osmocom/gprs/" under
libosmogb, which is wrong.
As a first step to fix the mess, we move the 2 RLC/MAC headers currently
under osmocom/gprs/{gprs_rlc,protocol/gsm_04_60}.h under a single header
gsm/protocol/gsm_44_060.h
The two old headers are left existing for backward compatibility and now
simply include the new libosmogsm header, plus a warning asking users to
switch to the new header so we can eventually get rid of them.
This means libosmogb depends on libosmogsm, which is fine and was
already the case beforehand (libosmogb using functions like
gsm48_encode_ra() and linking against it in src/gb/Makefile.am).
Change-Id: I70cc21bf25a7081070738abacb409ed19094c3b2
This module provides several operations on network devices
(interfaces), like monitoring changes, setting addresses, routes, link
state, etc.
It also supports managing network interfaces on several different netns
concurrently.
These functionalitites will be used by the tun module included in a
follow-up patch.
Change-Id: I7a00c0445a89e088676a4897061b65196d9197f1
Write a new API and implementation to manage network namespace related
operations.
This will be used by the upcoming tundev module.
Change-Id: I0f2fba2fa42250a07211a7b7f479498f27c529da
Implementation is imported from osmo-ggsn.git
97f60e3dca581797007524e0006ca9fafad59713 in46a_netmasklen() and adapter
to work with an osmo_sockaddr.
This will be used by osmocom-bb's "modem" app.
Change-Id: I75e75e251c6776801fffdde745aebedf21c68799
The initially merged IuUP API and implementation assumed that RFCI with
ID was always in the position of its ID inside the list of RFCIs. This
was the case for messages sent by ip.access nano3g as well as our own
osmocom implementation. However it was noticed that other nodes from
other vendors actually use other order, as allowed by the IuUP message
format.
Hence, we need to break the assumption and provide explicit ID
information in the list.
NOTICE: This commit breaks API and ABI compatibility with older versions
of libosmogsm, but not with any previous release of libosmocore since
the API is only available in master so far (it was added in
9fe1f9fb0b).
Similary, it's only user (osmo-mgw) only uses the API in master, so
there's no API breakage with older releases.
Related: SYS#5969
Change-Id: Ib21cee2e30bf83dff4e167f79541796007af9845
There are cases where we want to be notified of a successful BVC reset,
e.g. for a signalling because we can then start resetting the PtP-BVCs.
With this hook it's now possible to do that.
Change-Id: If240dd13f0f674693018c93390386b2c8afb97af
Related: SYS#5908
Those are available in 3GPP TS 48.008 version 16.0.0 Release 16, section
3.2.2.17 Cell Identifier. It can be seen that we have a collision
between the osmocom non-standard format and the SAI standard one.
This is because CGI-PS is not really a TS 48.008 Cell Identifier, but only
specified in TS 48.018 and has no ID number assigned. The CGI-PS was
added there because the whole osmo-bsc neighbour configuration works
with CellIds to manage neighbours, so it felt natural to extend the APIs
to also provide means to use CGI-PS format (TS 48.018 even refers 48.008
existance and mentions there's no explicit ID).
At the time this Cell Identifier was added, the firstly available number
(11) was taken, which was of course a really bad idea since newer
versions of the spec can at some point use it, which is the case if one
checks for instance TS 48.008 Release 16 SAI Cell Id.
There no perfect way to fix this bad decision at the time, but the
CGI-PS is only used in osmo-bsc and only for RIM related purposes, so by
changing the ID of CELL_IDENT_WHOLE_GLOBAL_PS, we only break RIM under
some specific CIs being used, and when an osmo-bsc is built against
older libosmocore and then used at runtime against a newer libosmocore
(which should be rare).
Hence, the downside is acceptable, and by moving the new ID number to be
ouside of the spec proto TS 48.008 range (4 bits), we make sure we don't
have the same problem again in the future.
Related: SYS#5838
Fixes: ca33a71ca8
Change-Id: Id25e563febdb7640174540136225f399515a0089
Change the functionality of skipping unchanged values: instead of
looking up whether new values have been set on a stat item, rather
remember the last reported value and skip reporting identical values.
stats_test.c shows that previously, a stat item reported a value of 10
again, even though the previous report had already sent a value of 10.
That's just because the value 10 was explicitly set again, internally.
From a perspective of preserving all data points, it could make sense to
send consecutive identical values. But since we already collapse all
data points per reporting period into a max, that is pointless.
Related: SYS#5542
Change-Id: I8f4cf34dfed17e0879716fa2cbeee137c158978b
Intead of attempting to store all distinct values of a reporting period,
just store min, max, last as well as a sum and N of each reporting
period.
This gets rid of error messages like
DLSTATS ERROR stat_item.c:285 num_bts:oml_connected: 44 stats values skipped
while at the same time more accurately reporting the max value for each
reporting period. (So far stats_item only reports the max value; keep
that part unchanged, as shown in stats_test.c.)
With the other so far unused values (min, sum), we are ready to also
report the minimum value as well as an average value per reporting
period in the future, if/when our stats reporter allows for it.
Store the complete record of the previous reporting period. So far we
only compare the 'max' value, but like this we are ready to also see
changes in min, last and average value between reporting periods.
This patch breaks API by removing:
- struct members osmo_stats_item.stats_next_id, .last_offs and .values[]
- struct osmo_stats_item_value
- osmo_stat_item_get_next()
- osmo_stat_item_discard()
- osmo_stat_item_discard_all()
and by making struct osmo_stats_item opaque.
In libosmocore, we do have a policy of never breaking API. But since the
above should never be accessed by users of the osmo_stats_item API -- or
if they are, would no longer yield useful results, we decided to make an
exception in this case. The alternative would be to introduce a new
osmo_stats_item2 API and maintaining an unused legacy osmo_stats_item
forever, but we decided that the effort is not worth it. There are no
known users of the removed items.
Related: SYS#5542
Change-Id: I137992a5479fc39bbceb6c6c2af9c227bd33b39b
Background:
* Individual values can be added to osmo_stat_item.values at any time.
* Stats are reported at a fixed interval (see vty 'stats interval'),
e.g. every 10 seconds.
* In order to report a new stat value, we use the maximum of all
osmo_stat_item.values added since the last report.
* By default, we do not send new stat values if they did not change
(see vty 'config-stats' -> 'flush-period' default of 0).
Fix the following bug:
* If 'flush-period' is 0, and no new osmo_stat_item.values are coming
in, the last value that gets reported is not necessarily the last
entry in osmo_stat_item.values.
* For attached reporters (statsd), it could then be that the given stat
stays at the wrong value for a long stretch of time (think of several
hours/days/forever).
Explanation of how the test shows that it is fixed:
* stats get reported (value is irrelevant)
* osmo_stat_item gets a new value: 20
* osmo_stat_item gets a new value: 10
* stats get reported (value: 20, the maximum of both new values)
* osmo_stat_item gets no new values
* stats get reported (value: 10, this is new because of the bug fix,
the real last value in osmo_stat_item, different from the 20 sent
earlier, without the fix it would not send anything here and the last
sent value would be 20)
* osmo_stat_item gets no new values
* stats get reported (nothing gets sent, since the real last value was
already sent and 'flush-period' is 0)
Fixes: OS#5215
Change-Id: Ibeefd0e3d1dbe4be454ff05a21df4848b2abfabe
generic sha code from git://w1.fi/hostap.git commit
5ea93947ca67ba83529798b806a15b247cdb2e93 which also happens
to be the source of our milenage code.
Related: SYS#5324
Change-Id: Ibf2e49edada944d91ceba62bd0d6b6ce69261fcd
This patch adds a new field "name" to the rate_ctr and osmo_stat_item_group
structs, together with an API to set it. This new field allows for easy
identification of specific group instances when several of them exists,
rather than using a sometimes random/increasing index value.
If set, this name (string) is used instead of the index by the stats
reporter.
The name, if set, is also printed during "show stats" VTY commands.
It's up to the user or application to set up unique or meaningful names
to fullfill one's needs.
WARNING: this commit breaks ABI and possibly creates unexpected behavior
when run with non-rebuilt apps which use the modified structs directly
to get the coutners, or if use the static inline API rate_ctr_inc2().
Existing users of these structs should migrate to use new APIs
introduced in follow-up commits instead of accessing the field directly.
Related: SYS#5456
Change-Id: I0dc510783dd9ae8436dae8005a7b3330e80d36f3
This is required to reset and close a card under software control
after opening it with osim_card_open()
Change-Id: Ie9ec66db4d54fdb1331f4ae05ca3ca4274912e9d
This new API doesn't use host_config_set(), and allows passing a FILE*
from any source, not only a filesystem path.
Related: SYS#5369
Change-Id: I720ac04386261628c0798a1bfcaa91e2490a86c3
The api doc indicates the possibility to pass -1, and calling
osmo_tdef_get() actually casts the arg to a signed long. To end the
confusion, change default_timeout from unsigned long to long.
Change-Id: I51b9172603984839448346c9836e43c8c802fcf8
We've used up all but one "library reserved" VTY nodes at this point,
and we should definitely add some more reserved nodes in the next
libosmovty ABI version / release.
Change-Id: Idfe1e7d97f3f29fc219e80dcb6ce6bb768733adf
Prior to this patch, it was not possible to gather SET/GET reply
information when implementing a CTRL client using libosmocontrol. This
is specially important when using the GET command, since one wants to
receive the queried value.
CTRL traps can also be handled this way by extending this patch in the
future if needed.
Change-Id: Id3c4631cd32c13e78e11b6e8194b8c16307ec4f1
Some averaging methods may have additional parameters, so let's
make it easier to access them for the API user.
Change-Id: I2f4ed56837dd479dbbd10c0a7df0ed7565d3946a
Related: SYS#4918
This is required in order to tell MS that osmo-pcu now supports
Network Assisted Cell Change (NACC).
Related: SYS#4909
Change-Id: I2aaa8c1107c977f711c2d7530034f57e36e3a237
This is basically a successor of gsm0808_create_sapi_reject(), but
instead of hard-coding GSM0808_CAUSE_BSS_NOT_EQUIPPED, it allows
the caller to specify a cause value to be used. The old function
is now deprecated and should not be used.
Change-Id: Iefe5484d0fa02d5722b628b1dc237d51d3fb1a9b
Related: OS#4728
If a BVC-RESET is sent from SGSN, there must not be a cell ID IE
included. See "Note 1" of TS 48.018 Section 10.4.12.
Change-Id: I11d4e70d510265b9c09dffccdab10b3f0816715a
At the moment we print the pointer address to identify the log lines
belonging to a specific connection. Since pointer addresses are
difficult to work with, a human readable ID should be printed instead.
e.g. "This is LAPD instance for SAPI3 on bts0/trx1/ts5/lchan3"
Change-Id: Ie6742843fff809edffcac24c4dce4edf66bc71be
Closes: OS#1938
This function may be useful in a case when most of the BTS models
do support some feature, but just a couple models do not. It's
much easier to unset that feature 2/10 times than set it 8/10
times individually for each BTS model.
Change-Id: Ib5fa27287be7f1ecf2f82249b1e8c848465cbac0
Related: I431c8ab9478cbc40179903edc21043623d805da1
So far we only looked at SW definitions of the card profile. However,
if we have a currently selected application, we also must check
that application for SW definitions.
This breaks ABI and API all over the place, but as there are no
known users beyond osmo-sim-test, this is acceptable.
Change-Id: I3a1d60898529c173f73587e34c155660ba5f5fb1
In order to dissolve info_meas_ind_param in ph_data_param and
ph_tch_param we need to add the measurement related struct members to
ph_data_param and ph_tch_param as well so that those indications can
also carry measurement data.
Change-Id: I2c34b02d329f9df190c5035c396403ca0a4f9c42
Related: OS#2977
Follow up for patch I3cf150cc0cc06dd36039fbde091bc71b01697322
osmo_sockaddr_str_{from,to}_32n actually use host byte order. Deprecate these
and introduce a more accurately named version ending in h.
Change-Id: Ic7fc279bf3c741811cfc002538e28e8f8560e338
So far we had a function to allocate a new bssgp_bvc_ctx, but not
the opposite one. Let's finally introduce it, so it will be used
at least in OsmoPCU.
Please note that the new symbol has 'bssgp_' prefix, not 'btsctx_'.
Change-Id: Ia78979379dbdccd6e4628c16f00d0c06d9212172
Pau Espin
Harald Welte
Daniel Willmann
Neels Hofmeyr
Oliver Smith
Eric Wild
Neels Hofmeyr
Vadim Yanitskiy
Philipp Maier