This extends our existing TLV parser with the ability to
* validate that mandatory IEs of a given message are present
* validate that all present IEs are of required minimum length
Introducing this generic layer will help us to reduce open-coded
imperative verification across virtually all the protocols we
implement, as well as add validation to those protocols where we
don't properly perform related input validation yet.
Change-Id: If1e1d9adfa141ca86001dbd62a6a339f9bf9a912
When importing the hashtable code in I8ef73a62fe9846ce45058eb21cf999dd3eed5741
I didn't import actual implementations of the fls() and fls64()
implementations, as at least gcc-10 was smart enough to detect
we only use it on constant types and hence the computation can happen
at build time via const_ilog2()
However, in our jenkins build verification' this doesn't appear to
happen, as we get below errors:
/build/deps/install/stow/libosmocore/include/osmocom/core/log2.h: In function ‘__ilog2_u32’:
/build/deps/install/stow/libosmocore/include/osmocom/core/log2.h:20:9: error: implicit declaration of function ‘fls’ [-Werror=implicit-function-declaration]
return fls(n) - 1;
^~~
/build/deps/install/stow/libosmocore/include/osmocom/core/log2.h: In function ‘__ilog2_u64’:
/build/deps/install/stow/libosmocore/include/osmocom/core/log2.h:28:9: error: implicit declaration of function ‘fls64’ [-Werror=implicit-function-declaration]
return fls64(n) - 1;
^~~~~
Let's provide some generic implementations for this case. If needed
one could also introduce architecture-specific assembly implementations
like in the Linux kernel, but so far we managed to keep libosmocore free
of any assembly tweaks.
Change-Id: Ifa4898eb66c8d949618edd47961b7a0330ed35b5
In I7da8b25c9a89a7e3ae6c1680ba838e136d7d5293 I seem to have failed
to realize that 3GPP TS 48.018 v15.0.0.0 Table 11.3.26 continues
on yet another page. Let's add those missing PDU types definitions.
Change-Id: I9173c35240ff78048b2b76a1155d90467ef16b2d
'new' is a reserved keyword in C++, so including this header from
a C++ project (like osmo-pcu) breaks compilation. Let's rename
it in the same way as it's already done in this file: add '_'.
Change-Id: I7f7d9143edca75ce932601386a8766b0a62c0e24
Fixes: I8ef73a62fe9846ce45058eb21cf999dd3eed5741
For more than a decade we've used the linuxlist.h for double-linked
lists. Let's also add the hlist (double-linked lists with single
pointer sized head, and the hashtable that builds on top of it.
This reflects the versions included in Linux 5.8 with some modifications
to make them build in userspace (remove RCU versions, adjust for
userspace include files and types, convert to doxygen).
Change-Id: I8ef73a62fe9846ce45058eb21cf999dd3eed5741
NSVC filtering was only implemented on sending messages, this also adds
log_set_context() calls to ns2_recv_vc()
Filtering by NSE is implemented similar to NSVC.
Change-Id: I63c0e85f82f5d08c5a6f535da94b8648498439d2
Related: SYS#5232
This adds an easy way to listen to netlink events form the Linux kernel
from within libosmocore applications.
The new dependency can be disabled via the "--disable-lbimnl" configure flag.
Change-Id: I4f787ee68f0d6d04f0a5655eb57d55b3b326a42f
Even it was in theory possible to mix NS-VC ll types within
a NSE. This is an unrealistic configuration.
Further more to select the correct load sharing mechanism
the NSE must know the correct link layer.
Change-Id: I18dfd40a2429cd61b7c4a3dad5f226c64296f7d8
Add support for frame relay over dahdi hdlc device.
It's supporting lmi by q933 and supports both
SGSN and BSS.
Change-Id: Id3b49f93d33c271f77cd9c9db03cde6b727a4d30
In order to transfer an RXQUAL threshold to the BTS as well, the struct
that defines the contents of RSL_IE_OSMO_REP_ACCH_CAP needs to be
updated with a 3 bit field to contain the RXQUAL value.
Change-Id: I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Related: SYS#5114 OS#4796 OS#4794 OS#4795
The recently added IE is used to transfer a bitfield, lets add a struct
that describes the bitfield. This makes the IE easier to use.
Change-Id: I326e66dae25acfab0b3fddc7278b39a8cbf7d385
Related: SYS#5114, OS#4796, OS#4794, OS#4795
This allows usual integer parsing at app level and calling this function
to make sure correct values will be passed to
osmo_serial_set_baudrate().
Change-Id: I41415c99d26128b33a8bf5ef7b38948bd1fe5d50
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
This is fixed version of Ic8b2bfd00330235f5bed00771e421588abfaac1f,
which got reverted because it used the keyword "class" as struct member,
which lead into problems with c++ builds. This is now fixed.
Change-Id: Id8732551b33616227609cd6fcf6c3133751a89eb
Related: OS#4796 SYS#5114
This reverts commit a4939dc846,
which caused massive build failures in C++ programs like osmo-pcu
- unsurprisingly, as it calls a struct member "class", which is a
reserved keyword in C++.
Change-Id: Ia43e56385e7b580f492c560aee8ff8b1e8a0e1d8
Some applications may need submillisecond timers, such as those
interacting with modbus serial lines (RS-485, RTU), which require
timers of values around 1.5 char-time (T1.5), where a data char is
composed of 11 bits sent on the line: 1 start bit, 8 data bits,
1 stop bit, and and parity bit (or 2nd stop bits if no parity).
For instance, for a baudrate of 9600:
1.5 * 11 / 9600 = 1.718 ms = 1718 us
So having a granularity of MS is not enough here.
Change-Id: I71848d7c1ee0649929ce07680ee7320bb2a42f0e
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
Change-Id: Ic8b2bfd00330235f5bed00771e421588abfaac1f
Related: OS#4796 SYS#5114
3GPP TS 24.008, section 10.5.1.7 specifies a Repeated ACCH Capability
bit in the Classmark 3 IE. Unfortunately, there is no way specified how
the Repeated ACCH feature should be controlled on RSL level. Since it is
not unusual that BTS/BSC vendors occassionally add proprietary IEs to
different RSL messages we may pick this as a solution as well and add a
propritary RSL_IE_OSMO_REP_ACCH_CAP IE, so that we can enable repeated
FACCH/SACCH on the BTS side when we send RSL CHAN ACT or RSL CHAN MODE MODIFY
messages.
Change-Id: I61ea6bf54ea90bd69b73ea0f0f3dc19a4214207b
Related: OS#4796 SYS#5114
The gprs_ns2_prim_strs was merged to early. The renaming
in the last gerrit patchset wasn't done correct.
Change-Id: Ie8e1e003d70af48f2d647b2c2701d4fc0f17e307
NS_AFF_CAUSE_VC_* failure and recovery should indicate the NSVC in
question. Use the string representation reported by gprs_ns2_ll_str()
for that.
NS_AFF_CAUSE_VC_RECOVERY was never sent so do that on unblock as well.
Change-Id: Iad6f0dc4565a46868cbbe17c361dcd473006c83d
Related: SYS#4998
Having the expert mode flag stored in the global 'host' structure
was a bad idea, because this way it applies globally. In other
words, if user Bob activates the expert mode in his dedicated
session (e.g. a telnet connection), then not only him, but all
other users would see the hidden commands in their VTYs.
Moreover, if somebody deactivates the expert mode, it would also
affect the Bob's VTY session. And finally, terminating a VTY
session would not deactivate the expert mode.
Let's move that flag from the global 'struct host' to 'struct vty'
representing an individual VTY session, so then the expert mode
would only affect the session where it was activated.
In functions related to the XML VTY reference generation we don't
have access to 'struct vty' (there may be no VTY session at all).
Add two additional arguments to vty_dump_nodes(), indicating the
global flag mask and a matching mode. This would allow to match
the VTY commands in many different ways, e.g. one can dump hidden
commands only, or all commands except the library specific ones.
Change-Id: Iba13f0949061e3dadf9cf92829d15e97074fe4ad
Related: SYS#4910
select is an ancient interface with weird restrictions, such as
the fact that it cannot be used for file descriptor values > 1024.
This may have been sufficient 40 years ago, but certainly is not in
2020. I wanted to migrate to epoll(), but unfortunately it doesn't
work well with the fact that existing programs simply set osmo_fd.flags
without making any API calls at the time they change those flags.
So let's do the migration to poll() as a first step, and then consider
epoll() as a second step further down the road, after introducing new
APIs and porting applications over.
The poll() code introduced in this patch is not extremely efficient,
as it needs to do extensive linked list iterations after poll() returns
in order to find the osmo_fd from the fd. Optimization is possible,
but let's postpone that to a follow-up patch.
At compile time, a new --enable-force-io-select argument can be given
to configure, forcing the use of the old select() backend instead of the
new poll() based backend.
Change-Id: I9e80da68a144b36926066610d0d3df06abe09bca
This change introduces an enumerated type 'vty_ref_gen_mode' that
(as the name suggests) defines the VTY reference generation mode:
- DEFAULT - all commands except deprecated and hidden,
- EXPERT - all commands including hidden, excluding deprecated;
and a new function vty_dump_xml_ref_mode(), that allows to specify
that mode. The old vty_dump_xml_ref() is now deprecated.
Change-Id: Ie2022a7f9e167e5ceacf15350c037dd43768ff40
Related: SYS#4910
Some VTY commands are intentionally hidden, e.g. because they might
by relatively dangerous if used in production operation. We equip
such commands with a special attribute - CMD_ATTR_HIDDEN.
The problem is that neiter they appear in the XML VTY reference,
nor in the online VTY help, so it's a bit tricky to invoke them.
This change introduces so-called 'expert' mode, in which hidden
(but not deprecated) commands are getting visible.
In the (telnet) VTY session, this mode can be activated by passing
an additional argument to well-known 'enable' command:
OsmoApp> enable ?
[expert-mode] Enable the expert mode (show hidden commands)
OsmoApp> enable expert-mode
OsmoApp#
so then hidden commands will appear together with all the other
commands. They will be marked with a special '^' flag:
OsmoApp# list with-flags
^ ... foo-hidden [expert-mode]
. ... foo-regular-one
! ... foo-immediate
^ u.. app-hidden-unbelievable
For the XML reference generation, additional API needs to be
introduced. This will be implemented in subsequent patches.
Change-Id: Ie69c2a19b22fb31d7bd7f6412f0aeac86ea5048f
Related: SYS#4910
This change implements 'systemd-journal' logging target, that is
similar to the existing 'syslog' target. The key difference is
that 'systemd-journal' allows us to offload rendering of the meta
information, such as location (file name, line number), subsystem,
and logging level, to systemd. Moreover, we can attach arbitrary,
user-specific fields [1] to the logging messages, so they can be
used for advanced log filtering (e.g. by IMSI/TMSI/TLLI):
$ journalctl OSMO_SUBSYS=DMSC -f
Since we don't want to make libsystemd a required dependency, this
feature is optional, and needs to be enabled at build-time:
$ ./configure --enable-systemd-logging
The new logging target can be configured in the same way as any
other one - via the VTY interface, or using the configuration file:
log systemd-journal [raw]
logging level set-all notice
logging filter all 1
Two logging handlers are available: generic and raw. The first one
behaves similarly to both 'syslog' and 'stderr', i.e. all the meta
information is rendered by libosmocore itself, and then passed to
systemd together with the logging message. The later is more like
the 'gsmtap' target, so all available meta information is handed
over to systemd in form of fields [1]:
- CODE_FILE / CODE_LINE - location info,
- PRIORITY - syslog-compatible logging level,
- OSMO_SUBSYS - Osmocom-specific sub-system (e.g. DMSC),
- OSMO_SUBSYS_HEX - same as OSMO_SUBSYS, but encoded in hex,
- MESSAGE - the logging message itself,
and then can be rendered in any supported format (e.g. JSON).
More details about the API can be found in [2].
[1] https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html
[2] https://www.freedesktop.org/software/systemd/man/sd-journal.html
Change-Id: I609f5cf438e6ad9038d8fc95f00add6aac29fb23
If we watn to migrate to something like epoll(), user application
code must call a function of the libosmocore API whenever it changes
its read/write interest in a file descriptor.
Let's introduce API so applications can be ported to this API,
before making direct 'ofd->when' manipulations illegal as a second step.
Change-Id: Idb89ba7bc7c129a6304a76900d17f47daf54d17d
It's more clear which part of the address is returned.
In preparation to add a gprs_ns2_ip_vc_local.
Change-Id: I6110ff573362961c713a990da7ef3f3dbedf6c57
The sockaddr should not be changed.
free and create the bind/nsvc if the address should be changed.
Change-Id: I371ac2361b569e36722b02fc9cd82ec8da2fa9e3
Using the 'const' qualifier allows the compiler to spot some
programming errors and further optimize the code.
Change-Id: I0df6a00ac1830bd64a10b9336b827e113fa772bb
BSSLAP: there are APDUs transferred in BSSMAP-LE Connection Oriented
Information messages on Lb between BSC and SMLC.
Add BSSLAP coding for these APDU messages:
- TA Layer3
- TA Request
- TA Response, possibly containing Location Estimate coded in GAD
- Reject
- Reset (for intra-BSS handover during TA Request)
- Abort (for inter-BSS handover)
Add encoding and decoding tests.
Change-Id: I6409c4bcac402dc7626a3afce9081c59cd715fe8
GAD, Universal Geographical Area Description:
- raw coding for all GAD elements.
- SI-units encoding and decoding for Ellipsoid point with uncertainty circle,
which I presume is the typical "at most N meters away from cell tower located
at X,Y", which corresponds to the TA positioning currently being implemented.
- other SI-units GAD element encodings are so far not implemented.
Add encoding and decoding tests.
In gsm/protocol/gsm_23_032.h are the raw coding structs as defined in 3GPP TS
23.032.
In gsm/gad.h are structs carrying consistent units based on meters and degrees,
for convenient / less error prone handling of GAD data, and for human readable
representations of the GAD data.
The separation of the two is desirable because OsmoBSC will receive GAD data
from OsmoSMLC on the Lb interface, and pass on this data to the MSC via the A
interface. It is better to pass the GAD data as-is without de/encoding.
Change-Id: I7a9dd805a91b1ebb6353bde0cd169218acbf223c
This will be useful to handle latitude and longitude numbers for GAD, which is
the location estimate representation used for LCS (Location Services).
The OsmoSMLC VTY user interface will provide floating-point strings like
"23.456" while GAD stores them as micro-degress 23456000. The osmo_gad_to_str*
will also convert latitude and longitude to floating-point string.
There was code review concerns against adding this API, upon which I tried to
use floating point string formats. But I encountered various problems with
accuracy and trailing zeros. For global positioning data (latitude and
longitude), even inaccuracy on the sixth significant decimal digit causes
noticeable positional shift. To achieve sufficient accuracy on the least
significant end, I need to use double instead of float. To remove trailing
zeros, the idea was to use '%.6g' format, but that can cause rounding. '%.6f'
on a double looks ok, but always includes trailing zeros. A test program shows:
%.6g of ((double)(int32_t)23230100)/1e6 = "23.2301" <-- good
%.6g of ((double)(int32_t)42419993)/1e6 = "42.42" <-- bad rounding
%.6g of ((double)(int32_t)23230199)/1e6 = "23.2302" <-- bad rounding
%.6f of ((double)(int32_t)23230100)/1e6 = "23.230100" <-- trailing zeros
%.6f of ((double)(int32_t)42419993)/1e6 = "42.419993" <-- good
%.6f of ((double)(int32_t)23230199)/1e6 = "23.230199" <-- good
It looks like when accepting that there will be trailing zeros, using double
with '%.6f' would work out, but in the end I am not certain enough that there
aren't more hidden rounding / precision glitches. Hence I decided to reinforce
the need to add this API: it is glitch free in sufficient precision for
latitude and longitude data, because it is based on integer arithmetic.
The need for this precision is particular to the (new) OsmoSMLC vty
configuration, where reading and writing back user config must not modify the
values the user entered. Considering to add these functions to osmo-smlc.git,
we might as well add them here to libosmocore utils, and also use them in
osmo_gad_to_str_*() functions.
Change-Id: Ib9aee749cd331712a4dcdadfb6a2dfa4c26da957
This new attribute would allow to distinguish commands provided
by libraries from commands registered by the application itself,
so vty_dump_element() would print proper description for the
library specific attributes.
All VTY commands defined by the libraries need to use the new API:
- install_lib_element(), and
- install_lib_element_ve,
instead of the old functions (respectively):
- install_element(), and
- install_element_ve().
See https://lists.osmocom.org/pipermail/openbsc/2020-October/013278.html.
Change-Id: I8baf31ace93c536421893c2aa4e3d9d298dcbcc6
Related: SYS#4937
The SGSN will always bind to 0.0.0.0 in difference the PCU bind is depending
on the info indication. Allow to the user to define a default bind
address.
Change-Id: I2a9dcd14f4ad16211c0f6d98812ad4a13e910c2a
Both flags are required to allow the NS user to sent BVC RESET for persistent NSE.
On persistent NSE with persistent NS alive configuration (no RESET/UNBLOCK/BLOCK) the
PCU can't detect if the SGSN has restartet or crashed.
Change-Id: Iaad7b53d44338e5dd81dc2202f23bdcb715af804
The NM_ATT_OSMO_NS_LINK_CFG is used for NSVC configuration of osmocom based BTS to support
IPv6 NSVCs.
Change-Id: I9e279bb20940c66eea5196f281184cb4f8a5cc5f
gprs_ns2_nsvc_by_sockaddr_nsei is doing the lookup within a NSE.
gprs_ns2_nsvc_by_sockaddr_bind is doing the lookup within a bind.
Make both function look similiar and take similiar arguments.
Change-Id: Ia499fc279013668abe7348e578a0768f7d16faf9
utils.h is needed for struct value_string
This probably never caused a problem because every file including
gsm_08_16.h also included utils.h, but we should still include the file
here.
Change-Id: Iae09b4e8e42be6c371fb34279b7981db2af8cf4c
So far there is only osmo_use_count_name_buf(). Also provide a use count to
string using a talloc context, allowing to use OTC_SELECT.
- instead of foo_name(), rather use foo_to_str().
- osmo_use_count_name_buf() returns the buf and not the chars_needed. So add
osmo_use_count_to_str_buf() with a signature that is usable by
OSMO_NAME_C_IMPL().
- provide osmo_use_count_to_str_c() using OSMO_NAME_C_IMPL().
Change-Id: I1d2e7ee979f8c316ef99f7c65675b36d092ddfca
Originally we only learned about the protocol from looking at hexdumps
without any specification or the like.
Due to a GPL request to ip.acecss, we actually do have an 'official'
resource: The packet-ipa.c from their wireshark-1.0.6ipa27.tar.gz
Let's use its contents to complete our definitions here.
Change-Id: Ic1f2b32c72d162f31b422293d2a361d528443f01
As shown in the recently added bitgen_test.c, using osmo_loadXXbe_ext() with a
smaller n produces results aligned on the most significant bytes, which is
cumbersome, since it does not return a previously stored value. This problem
exists only for the big-endian functions, the little-endian osmo_loadXXle_ext()
properly return values adjusted on the least significant octets.
Add osmo_loadXXbe_ext_2() variants that properly right-adjust the returned
value. Prominently highlight this behavior in API doc. Test the new functions
in bitgen_test.c.
For example, this eases handling of 24bit integers (e.g. loaded from buffer to
uint32_t, and stored into buffer from uint32_t). Also explicitly show this 24
bit case in bitgen_test.c
Change-Id: I2806df6f0f7bf1ad705d52fa386d4525b892b928
Add OSMO_ASSERT()s to ensure bounds checking.
For example, for osmo_store32le_ext(), passing n > 5 would read past the end of
the uint32_t. Similarly, osmo_load32le_ext() for n > 4 would write past the
uint32_t's end.
Change-Id: I2dc21582cd8a679b6624cefbc0c1678b093a3d08
In case the port isn't known at the time osmo_sockaddr_str_from_str2()
parse only the ip and don't touch the port.
This is the case when a user has different vty commands for ip and port.
Change-Id: Ifd4e282586b8bd40b912a9f1c25f9e8208420106
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
Harald Welte
Pau Espin Pedrol
Vadim Yanitskiy
Daniel Willmann
Pau Espin
Philipp Maier