The lower layer must set the 'POLLING_ONLY' flag and provide frame
number when polling a frame. If T200 is pending, it is started with a
timeout frame number in advance to given frame number.
The lower layer must call lapdm_t200_fn() after a frame has been
received or if a frame has not been received. Also it must be called
after a TCH frame has been received. LAPDm uses this to check the T200
timeout condition.
A new function is used to set the frame number based timeout values.
Related: OS#4074
Change-Id: I6ebe83f829d7751ea9de1d90eb478c7a628db64c
The T200 timer is started when the current frame is polled at
PH-READY-TO-SEND event.
A flag is used to enable this feature. The user of LAPD core must track
frame numbers to check the timeout condition. Then it must call the
external timeout function.
Related: OS#4074
Change-Id: Ib961b5a44911b99b0487641533301749c0286995
- Use forward decl. of struct gsmtap_inst in header
- Remove 'static inline' attributes from gsmtap_inst_fd() declaration,
move function definition to gsmtap_util.c and mark it as deprecated
- Add gsmtap_inst_fd2() as replacement for gsmtap_inst_fd()
Related: OS#6213
Change-Id: Ibe1a51205a6df764571b6d074e365825555609a5
These APIs are used to bind or unbind an active socket adding or
removing addresses from the existing set.
Related: OS#6077
Change-Id: Ifc6e7d643c2a0c53f479bfd0d5c36d08c0c01953
The OSMO_SOCK_F_SCTP_ASCONF_SUPPORTED flag was added recently to enable
use of ASCONF in osmo_sock_inti2_multiaddr. Since we didn't release yet,
we are still in time to get rid of this flag.
It turns out that we'll want to add more features which must be set
before SCTP INIT (connect()) time, like setsockopt SCTP_INITMSG, which
in turn contains a struct with several parameters.
Hence, adding flags for all those makes no sense.
Instead, add a new API which allows passing an extensible struct which
allows much more fine-grained setup from the caller.
The new struct "pars" parameter is non-const on purpose, in order to be
able to extend the struct in the future if we wish to get/obtain some
data from the socket.
Related: SYS#6501
Related: SYS#6558
Change-Id: I1f6fd09a79b0a2bd794e5669d933be25bbf1eeaa
msgb_tv32_put() already exists, but msgb_tv32_push doesn't.
The tv16 counterparts are already present, and having to pass 32bit
integers is also quite common, so let's add an API for it.
Change-Id: I68d5693a18d55ce8d0647359044157d7e5bfae50
The TUAK algorithm is specified in 3GPP TS 35.231, 232 and 233 and
intended as an alternative to MILENAGE. It's based around the
cryptographic function of KeccakP1600, which is part of SHA-3.
This patch adds support for TUAK to the libosmogsm authentication
core API via 'struct osmo_auth_impl'.
Unit tests covering the test cases from the 3GPP specification are added
(and are all passing).
Change-Id: Ib905b8d8bdf248e8299bf50666ee1bca8298433d
3GPP specifies the C2 derivation function (generating GSM SRES from UMTS XRES)
independent of the MILENAGE algorithm. So instead of open-coding it in
milenage.c:gsm_milenage(), let's create a separate public function
osmo_auth_c2() similar to the already-existing osmo_auth_c3() function.
gsm_milenage() can then simply use that function.
Change-Id: I0e7cd55f5578f891cb6cc1b0442920ba5beddae4
3GPP TS 33.102 Section 6.3.7 states that K can be 128 or 256 bits,
while our 'struct osmo_sub_auth_data' had a fixed-size 128bit field.
This means we cannot use our auth_core for algorithms with larger
key sizes, such as TUAK. Let's introduce osmo_sub_auth_data2 for
larger (and variable) sized K and OP[c].
K and OP[c] can even have different sizes in TUAK, where OP[c] is
always 256bit, but K can be 128 or 256 bits. So we need separate
length fields for K and OP[c].
I'm adding backwards-compatibility API wrappers, so old applications
just continue to work as they always did.
However, I'm not adding compatibility wrappers for the plug-in API
that can be used to register additional authentication implementations
at runtime. We don't know of any user of that API outside of
libosmocore, so the function signatures of the 'struct osmo_auth_impl'
are modified in an incompatible way.
Change-Id: Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
The original design of gsm0503_tch_hr_{en,de}code() functions contains
a mistake in that a pseudo-RFC5993 format was chosen for HR codec frame
input and output, instead of "pure" (agnostic to outer RTP encoding)
form of 14 bytes. We would like to change this design so that we can
feed pure 14-byte HR codec frames to the channel coding function and
get such frames back from the channel decoding function - however,
we cannot break libosmocoding API for existing users. In the decoding
direction, create a new function that emits TS 101 318 format, and
turn the legacy gsm0503_tch_hr_decode() API into a wrapper function
for backward compatibility.
Related: OS#5688
Change-Id: If28ddb20789e8993b7558ca08020478615b4c708
* make backend configurable for later
* segmentation callback for chunked streams
* logging target for osmo_io
* support partial writes
Change-Id: I50d73cf550d6ce8154bf827bf47408131cf5b0a0
Related: SYS#5094, OS#5751
The decoding path of TLV_TYPE_SINGLE_TV is wrong, since it is not
shifting right the tag before using it. On the other hand, the encoding
path (tlv_encode_one) is doing that, so it is clear there's a bug.
It seems that in order to workaround the bug some IEs in gsm_04_08.h (TS
24.008 and TS 44.018) were defined incorrectly (eg 0x80) while the spec
clearly assigns eg. "8" to it, and makes sure no full byte IEI collides.
Some other IEIs like GSM48_IE_GMM_CIPH_CKSN which are also of the same
type were already correctly defined as 0x08.
Change-Id: I799e35dc8d4d153fa63bf50563a5482cdf4de2d7
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
Andreas Eversberg
Pau Espin
Harald Welte
Neels Hofmeyr
Daniel Willmann
Oliver Smith
Eric Wild
Vadim Yanitskiy