Thanks to the CLI of nanoBTS, I noticed that upper and lower RxQual
thresholds are sent in wrong order. Only the little-endian variant
needs to be fixed, the big-endian one looks good.
Change-Id: If6ab2377bae6742f871589b529a349498775552f
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
The RIM Routing Information IE (see also 3GPP TS 48.018, section
11.3.70) is used to control the flow of BSSGP rim messages at the SGSN.
Change-Id: I6f88a9aeeb50a612d32e9efd23040c9740bc4f11
Related: SYS#5103
The IP-SNS requires at least one initial remote address of the SGSN.
However it should be multiple initial remote address instead of a single
in case the interface might fail.
Rework the SNS to support multiple initial remote addresses.
Change-Id: I71cdbfb53e361e6112fed5e2712236d797ef3ab2
Add gprs_ns2_fr_connect2() and change gprs_ns2_fr_connect() to
be similar to gprs_ns2_ip_connect() and gprs_ns2_connect2().
This is an API break but there wasn't yet a release with NS2.
Change-Id: I4e1374b0e979b3293302c5ed46a91a58f3a5a916
Every bind will have a unique name. Add a name argument
to all bind creating functions and require them to be unique.
This is an API break but there wasn't yet a release with NS2.
Change-Id: I8f1d66b7b3b12da12db8b5e6bd08c1beff085b3e
A NS dialect describes how the NS Entity interacts with
different virtual circuits. E.g. ipaccess use reset/block on udp
and is a dynamic connection.
A single NS Entity can only support one dialect. This can be later
used to protect a NS Entity against dynamic NS virtual circuits of a
different type.
It further allows a bind to support multiple dialects at the same time.
Change-Id: Ia118bb6f994845d84db09de7a94856f5ca573404
The FSM doesn't actually implement the flow control logic,
it only decodes / dispatches and encodes messages.
Related: OS#4891
Change-Id: Ie59be6761177c43456898be9148727f15861a622
Similar to ns2 superseding ns, we now also intoduce a next generation
of BSSGP related code to libosmogb. However, this is not aiming to
be a full implementation yet, but simply those parts that we currently
need from the revamped osmo-gbproxy.
The gprs_bssgp2.[ch] differs in two ways from the old code:
* it separates message encoding from message transmission
* it supports more recent specs / IEs
bssgp_bvc_fsm.c is a genric implementation of the BSSGP BVC
RESET/BLOCK/UNBLOCK logic with support for both PTP and signaling,
both on the SGSN side and the BSS side.
Change-Id: Icbe8e4f03b68fd73b8eae95f6f6cccd4fa9af95a
Historically, BSSGP uses a non-constant, user-configurable integer
varieable for the logging sub-system. Let's replace this with a
statically-allocated library logging constant.
This is required if we want to use the subsystem number in e.g.
static initialized for osmo_fsm.log_subsys.
Change-Id: I506190aae9217c0956e4b5764d1a0c0772268e93
Those routines are very useful when puzzling together BSSGP messages
with 16-bit and 32bit sized IEs.
Change-Id: I033f9a708c9d7ffad91336178231dc66233e1693
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
When dealing with IPv4 and IPv6 address, the struct sockaddr
allows to hold IPv4 and IPv6.
However even when struct sockaddr is being used, a cast to the
IPv4 or IPv6 family must happen. To work around this additional code,
use a union for the most common types.
Change-Id: If80172373735193401af872b18e1ff00c93880e7
Process willing to support this kind of configuration through VTY simply
need to call "osmo_sched_vty_init(tall_ctx);" during startup to register
the commands.
For multithreaded processes, new threads willing to get their
cpu-affinity mask according to VTY config should call
osmo_sched_vty_apply_localthread() (potentially after
setting the thread name through pthread_setname_np()).
Related: SYS#4986
Change-Id: If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
The sysmobts uses the same OML attributes as IP.access. Because the IP.access
attribute only supports IPv4 as NSVC configuration, add an own attribute.
Change-Id: Ic261bc43a07fa741b97a9c6ec5a9ed6f5ecae588
Add bssgp_ns_send callback() to set the transmission path into the
NS library. This allows to use the Gb implementation with
the old NS and the new upcoming NS implementation.
Users of the old NS implementation don't have to set the callback as
the default is the old NS implementation.
Only users of the new NS implementation need to set the callback and
the callback data.
Change-Id: I3a498e6a0d68b87fed80c64199b22395796761b4
When calling a user-provided call-back function for the i460 mux
or demux, always pass a pointer to the osmo_i460_subchan the callback
relates to. This way, the user can walk the i460 data structures
to obtain information about which mux/demux instances is calling.
Change-Id: Id842c72ce371a67fe5df6694e195c281aaf607ab
There is no way for the API user to know if the TX queue of the
multiplexer runs empty. However, this is criticil since an empty TX
queue will cause dropout of a TRAU frame, which can have quite severe
effects to the receiving end. Lets add a callback that allows the APU
user to insert appropiate idle frames or silent frames into the queue
before it runs empty.
Change-Id: I88a87724235fe50d55ce6215bb385c044072226e
Related: OS#2547
The define constants for the cause codes "BTS not equipped",
"remote transcoder failure" and "notification overflow" are missing.
Lets add them including value strings.
Change-Id: Ic3e936da00bd256bae03867887851f1a4e30e218
Previous both the IPA nanobts and the sysmobts has been using the IPv4 only OML
attribute NM_ATT_IPACC_NS_LINK_CFG.
A bts with BTS_FEAT_IPV6_NSVC supports IPv6 for NSVC (PCU<Gb>SGSN) using
the new OML attribute NM_ATT_OSMO_NS_LINK_CFG.
Change-Id: I9ef7949f66764b3c639e45eb440122e318da44a0
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
This feature indicates if the given BTS supports paging coordination,
that is the transmission of CS paging (received on Abis) to be sent
via PACCH/PCU in PS domain fro MS with active TBF.
Change-Id: Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38
Related: OS#2406
These TDMA constatns and modular arithmetic operations are used in
a number of osmo-* projects, so it makes sense to have them all
in a single header file, with minimalistic documentation.
Change-Id: Ic291fd3644f34964374227a191c7045d79d77e0d
Implement better API around 3GPP TS 24.008 Mobile Identity coding.
struct osmo_mobile_identity is a decoded representation of the raw Mobile
Identity, with a string representation as well as dedicated raw uint32_t TMSI.
The aim is to remove all uncertainty about decoded buffer sizes / data types.
I have patches ready for current osmo CNI programs, replacing the Mobile
Identity coding with this new API. Deprecate the old MI API.
osmo-bsc: I71c3b4c65dbfdfa51409e09d4868aea83225338a
osmo-msc: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
osmo-sgsn: I4cacb10bac419633ca0c14f244f9903f7f517b49
Note that some GPRS and SGs related coding is done here in libosmocore and
hence currently remains using the old implementation (see previous version of
this patch: Ic3f969e739654c1e8c387aedeeba5cce07fe2307).
New API functions provide properly size-checking implementations of:
- decoding a raw MI from a bunch of MI octets;
- locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb;
- encoding to a buffer;
- encoding to the end of a msgb.
Other than the old gsm48_generate_mid(), omit a TLV tag and length from
encoding. Many callers manually stripped the tag and value after calling
gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely,
especially since some callers need to use a TvL, i.e. support a variable-size
length of 8 or 16 bit.
New validity checks so far not implemented anywhere else:
- stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI.
- stricter on filler nibbles to be 0xf.
As a result, applications using osmo_mobile_identity will be stricter in
rejecting coding mistakes (some of which we currently have in our test suites,
and which we'll need to fix).
Rationale:
While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be
used to reduce the number of times a Mobile Identity is extracted from a raw
RSL message.
Extracting the Mobile Identity from messages has numerous duplicate
implementations across our code with various levels of specialization.
https://xkcd.com/927/
To name a few:
- libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf()
- osmo-bsc: extract_sub()
- osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(),
vlr_proc_acc_req()
We have existing functions to produce a human readable string from a Mobile
Identity, more or less awkward:
- gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use
hexadecimal TMSI everywhere.
- osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd
need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the
wrong signature, it should return a length like snprintf().
- osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the
raw uint32_t TMSI to a string, and then calls strtoul() via
tmsi_from_string() to code those back to a raw uint32_t.
Each of the above implementations employ their own size overflow checks, each
invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling.
Too much code dup, let's hope that each and every one is correct.
In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits
from a TMSI Mobile Identity. Since none of the above functions are general
enough to be re-used, I found myself again copy-pasting Mobile Identity code:
locating the MI in a 24.008 message with proper size checks, decoding MI
octets.
This time I would like it to become a generally re-usable API.
This patch was first merged as Ic3f969e739654c1e8c387aedeeba5cce07fe2307 and
caused test fallout, because it re-implemented old API with the new stricter
decoding. In this patch version, old API remains 1:1 unchanged to avoid such
fallout. Applications will soon switch to the new osmo_mobile_identity API and
become stricter on MI coding when that happens, not implicitly by a new
libosmocore version.
Change-Id: If4f7be606e54cfa1c59084cf169785b1cbda5cf5
This reverts commit d1ceca9d48, as it
introduces regressions in both osmo-msc and osmo-nitb which have been
causing failing builds for several days now.
Change-Id: I4bd958d0cd2ab4b0c4725e6d114f4404d725fcf7
Implement better API around 3GPP TS 24.008 Mobile Identity coding.
struct osmo_mobile_identity is a decoded representation of the raw Mobile
Identity, with a string representation as well as dedicated raw uint32_t TMSI.
The aim is to remove all uncertainty about decoded buffer sizes / data types.
I have patches ready for all osmo programs, completely replacing the Mobile
Identity coding with this new API. Hence deprecate the old MI API.
New API functions provide properly size-checking implementations of:
- decoding a raw MI from a bunch of MI octets;
- locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb;
- encoding to a buffer;
- encoding to the end of a msgb.
Other than the old gsm48_generate_mid(), omit a TLV tag and length from
encoding. Many callers manually stripped the tag and value after calling
gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely,
especially since some callers need to use a TvL, i.e. support a variable-size
length of 8 or 16 bit.
New validity checks so far not implemented anywhere else:
- stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI.
- stricter on filler nibbles to be 0xf.
Rationale:
While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be
used to reduce the number of times a Mobile Identity is extracted from a raw
RSL message.
Extracting the Mobile Identity from messages has numerous duplicate
implementations across our code with various levels of specialization.
https://xkcd.com/927/
To name a few:
- libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf()
- osmo-bsc: extract_sub()
- osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(),
vlr_proc_acc_req()
We have existing functions to produce a human readable string from a Mobile
Identity, more or less awkward:
- gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use
hexadecimal TMSI everywhere.
- osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd
need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the
wrong signature, it should return a length like snprintf().
- osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the
raw uint32_t TMSI to a string, and then calls strtoul() via
tmsi_from_string() to code those back to a raw uint32_t.
Each of the above implementations employ their own size overflow checks, each
invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling.
Too much code dup, let's hope that each and every one is correct.
In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits
from a TMSI Mobile Identity. Since none of the above functions are general
enough to be re-used, I found myself again copy-pasting Mobile Identity code:
locating the MI in a 24.008 message with proper size checks, decoding MI
octets.
This time I would like it to become a generally re-usable API.
Change-Id: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
So far, we have msgb_tl_put(), which allows putting the TL header of a TLV,
without the value part. Add the same for a variable-size length TvLV: put a TvL
header of a TvLV without the value part.
In a subsequent patch, osmo_mobile_identity will be introduced, which will
allow writing the encoded MI directly to the end of a msgb. For BSSGP_IE_IMSI,
which is a TvLV, it would hence be simplest to write only the TvL first.
Change-Id: I02cca5182fe42e40b63680a2fd470f03bcc11076
These utilities will be used by osmo-bsc to determine the Network Resource
Indicator seen in the TMSI, and (potentially) by osmo-msc to compose a TMSI
with a specific NRI, for osmo-bsc's load balancing between several MSCs.
Add utility functions to:
- extract an NRI value from a TMSI.
- overwrite the NRI value in a TMSI.
- limit an NRI in a (random) TMSI to a given list of ranges.
- add NRI value ranges to a list.
- remove them from a list.
- match NRI value (range) to a list.
- parse NRI values from string, for VTY.
- common VTY functionality of adding/removing NRI values from argv.
Add C tests for the above.
Why we need public API for NRI ranges: In osmo-bsc alone, we need the same NRI
API twice, 1: to manage/list NRI value ranges per-MSC, and 2: to manage/list
NULL-NRI values. If we also consider (potentially) adding NRI support to
osmo-msc, we need the same API twice again there. Hence it is useful to define
re-used API up here in libosmocore.
Related: OS#3682
Change-Id: Icb57a2dd9323c7ea11b34003eccc7e68a0247bf5
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
3GPP TS 48.016 is quite clear in that no NS-{RESET,BLOCK,UNBLOCK}
procedures shall be used over an IP based transport. They are only
for use in Frame Relay based transport.
However, as libosmogb was first developed against ip.access nanoBTS,
and their Gb implementation mandates those procedures, we
unconditionally implemented those procedures back then. Let's
give the user the option of disabling this behavior to become
more spec compliant (and interoperate with more other vendors out
there).
Change-Id: Ic4eba1b4dcbeac00f5879db295e0a9f1a50f71d8
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
If a feature index does not fit to the feature vector, this
function would return a negative number that would be casted
to true. This is wrong, we should return false instead.
Change-Id: Id1ad92e7654a806bb920ae9507c88a122e8d09f0
This implements a multiplexer and de-multiplexer for the ITU-T I.460
standard. The latter covers the transmission of sub-slots of 32/16/8k
inside 64k timeslots.
Change-Id: Id522f06e73b77332b437b7a27e4966872da70eda
Allow dumping the VTY XML reference (for generating manuals) to a normal FILE*
stream instead of a vty output buffer.
We currently generate the VTY reference by starting the client program,
connecting to the VTY telnet and dumping the reference. That is weirdly
convoluted, especially since there has to be a valid config file that
successfully starts up a minimal set of external links before the reference can
be generated. IMO we should have dumped the XML reference to stdout from the
start, and never to a VTY session.
With this patch, it is trivial to generate the XML VTY reference by a
commandline switch. The client program will set up the entire VTY, and
immediately after parsing the cmdline options but before parsing a config file,
just dumps the reference and doesn't even start establishing local ports. That
would allow generating the XML reference on the fly during the build process of
the manuals, without the need of a docker container or somesuch.
A first implementation of such a commandline switch is `osmo-bsc -X`, added in
I316efedb2c1652791434ecf14a1e261367cd2fb7
This patch jumps through a bit of a hoop to still allow dumping to a VTY buffer
without code dup, to still allow dumping the XML reference through telnet VTY,
until all our programs have implemented an -X switch (TM).
Change-Id: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492
This implementation is taken from OsmocomBB, in particular from:
target/firmware/layer1/rfch.c
Change return type to uint16_t, because neither ARFCN, nor MAI
can be negative. Add prefix 'gsm0502_' to the function's name.
Change-Id: I8aba1578cc9d1bd89d4f5d33a6e8fedc8bea789a
Related: OS#4546
gsm48_pag_resp and gsm48_service_request: omit comments in big endian part.
dtap_header: better segment the substruct.
gsm23041_msg_param_gsm: match up whitespace / comments.
Rationale: the script is a good way to avoid bugs from manually composing the
big endian parts (for example, it detected the missing endian.h include, fixed
in I593cc5e8272469b570559206bb02b6e79797340b). However, it becomes cumbersome
if it creates numerous edits in the source tree, which cause more time spent
for whoever wanted to rather save time with it. So let's keep the code tree
matching that struct's output.
Change-Id: I7432f5337d6589262c31f5186dfd0ac32221c467
These functions implement re-ordering of bits as per TS 06.90 / 26.101
based on the already existing tables we've had in libosmocoding.
Change-Id: Ia4ac2aea2e96f9185f082a07ca64dfc5276efb46
In Change-Id Idf2b99e9ef014eba26e3d4f0f38c2714d3a0520a we accidentially removed this
symbol, let's re-introduce it.
Change-Id: I9fbcbcc6619ef0c63d3682fc86adc80045baab02
Cause class is in bits 5-7 of the cause value.
For the cause value 0x52 old version returned 0xa instead of
a correct 0x5.
See section 3.2.2.5 Cause of TS 08.08 for the details.
Change-Id: I46646740c5daaafe20123e709f26dd1d2c1b6f8d
Function gsm0808_get_cipher_reject_cause() was previously available
in private gsm0808_utils.h. In practice, the exact same code is useful
to extract Cause IE value from any of the many other BSSMAP messages
which use it.
So let's rename it to gsm0808_get_cause() and make it avilable
to everyone to use.
Change-Id: Idf2b99e9ef014eba26e3d4f0f38c2714d3a0520a
Affected:
- struct gsm48_range_1024
- struct gsm48_range_512
- struct gsm48_range_256
- struct gsm48_range_128
In commit [1], the automatic little-to-big-endian compatibility by
struct_endianness.py introduced doubled little/big endian struct listings by
accident, resulting in a wrong big endian structure (due to double reversal in
the original big endian part). Remove the old conditionals around the new
automatic ones to fix the structs for big endian.
[1] Ia0b99d76932aeb03e93bd0c62d3bf025dec5f9d2
Change-Id: Iaccdd4a204841209f5eb50f336b30962ff00da0b
This function offers the highest level of API among all libosmousb
helper functions. It is intended as a one-stop shop for everything
related to grabbing an interface.
Change-Id: I748ded6cc7b73a73625588bd7a34a017a905b6bf
Reliable monitoring requires regular flush of all stat values, even
if they have not changed. Otherwise (1) the monitoring app has to
maintain state and (2) can go out of sync if it's restarted while
the app is still running.
Change-Id: I04f1e7bdf0d6f20e4f15571e94191de61c47ddad
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
this causes problems when compiling user applications
/usr/bin/ld: ../../src/libvlr/libvlr.a(vlr_lu_fsm.o):/usr/local/include/osmocom/gsm/protocol/gsm_29_118.h:184: multiple definition of `sgsap_ie_tlvdef'; msc_main.o:/usr/local/include/osmocom/gsm/protocol/gsm_29_118.h:184: first defined here
Change-Id: Iaa1d36c7a9bb64aa84ee85fa3e40f6b3560fe693
Each struct already contains different definition based on endianess, so
there's no reason to re-define all of them again based on endianess.
Probably at some point somebody run the script
./contrib/struct_endianess.py on those structures but forgot to remove
the old way of supporting differnet endianess.
Change-Id: Ibd002e52979950e09013767fa643b2a3c52dfea9
/usr/bin/ld: .libs/gsm0503_coding.o:/home/laforge/projects/git/libosmocore/src/coding/../../include/osmocom/coding/gsm0503_parity.h:16: multiple definition of `gsm0503_mcs_crc12'; .libs/gsm0503_parity.o:/home/laforge/projects/git/libosmocore/src/coding/../../include/osmocom/coding/gsm0503_parity.h:16: first defined here
Change-Id: I15945bbf59c873e50154c40fed0ba3d6b4d7c399
The signalfd(2) mechanism of Linux allows signals to be delivered
and processed via normal file descriptor I/O. This avoids any of the
usual problems about re-entrancy of signal processing, as signals can
be processed from the osmocom select() loop abstraction just like any
other event.
Change-Id: If8d89dd1f6989e1cd9b9367fad954d65f91ada30
For a process running as root, it may be desirable to drop privileges
down to a normal user before executing an external command. Let's
add a new API function for that.
Change-Id: If1431f930f72a8d6c1d102426874a11b7a2debd9
gsm0503_coding contains AMR decoder functions for HR and FR. Those can
only decode AMR payload frames but not amr DTX frames. Lets add
functionality to detect DTX frames. Also lets add decoding for SID_UPDATE
frames as well as error checking for the SID frame recognition patterns.
Related: OS#2978
Change-Id: I2bbdb39ea20461ca08b2e6f1a33532cb55cd5195
Before this change, a card application (USIM, ISIM, ...) didn't
exist as a separate concept from a card profile. This meant,
we had a manual combination of UICC card profile with USIM application,
and another one of UICC card profile and ISIM application. But what
if there's a combined USIM+ISIM?
In reality, applications exist as separate objects, on top of an
ETSI UICC. Lets therefore register all known applications to the
osim library core, and add code to osmo-sim-test which dynamically
detects all applications present on a given card (by reading EF.DIR).
Change-Id: Ic4b4ac433a9976842b30a017fb0fc347d87201cd
AMR not only specifies a 6 bit CRC for regular voice information. It also
specifies a 14 bit CRC to protect the comfort noise updates contained in
the SID_UPDATE frames.
Change-Id: I5cfd8ca806aba8d42cb9787f69605cea7de6e900
Related: OS#2978
* What we used to call TCH/F and TCH/H in gsmtap are actually only
FACCH/F and FACCH/H, i.e. the signaling part of Bm/Lm channels
* Give them proper names with backwards compatibility #define
* Split VOICE into VOICE_F and VOICE_H. If we don't differentiate this,
a receiver is not able to determine the RSL channel ID of a frame
without looking at external state/context. That in turn has been a
design feature of GSMTAP Um format so far, and programs like
osmo-bts-virtual rely on it.
Change-Id: I952044a17334f35712e087dc41781805000aebc1
Related: OS#2557
We so far are only able to transmit signalling data inside GSMTAP,
but not actual voice / user plane payload data.
we cannot use the existing TCHF/TCHH sub-types, as those are already
used [without further discrimination] for FACCH + SACCH Data on those
channels.
Instead, we will introduce a new GSMTAP_CHANNEL_VOICE sub-type, which
then will have the first byte for a sub-sub-type specifying the payload
format in detail.
Change-Id: If223020933b083fe359a2e8ff5fab1ce64a363d8
Related: OS#2557
If selection of ADF_USIM fails, let's fall-back to reading/dumping
a classic TS 11.11 (51.011) SIM card.
Change-Id: I5a986fc65de76c24c5af52ce7e8c699cf302fda9
Some osmo-* applications may need to use their own VTY node as a
parent for the timer configuration commands. Therefore it makes
more sense to use 'unsigned int' instead of 'enum node_type'.
Let's also clarify that osmo_tdef_vty_groups_init() accepts parent
node for configuration commands only: 'parent_node' -> 'parent_cfg_node'.
Change-Id: Ifb4c406c85d76a25fc53fc235484599aa87dc77c
There's nothing really preventing a user from user negative values.
Otherwise if we keep it like this then g++ is not happy when passing eg.
{ -2, "foobar" } when initializing a value_string array.
Change-Id: I754fa7e054cb89801ef82edc82199dcfbe59c6ab
Thise two helper functions allow the user application to find
a unique match among the existing USB devices, using either a user-
provided iSerial string, or a user-provided physical USB path.
Change-Id: I8ff3fb3e1a77e10cb313473480ce5e7673749a93
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
In some situations, we want to execute an external shell command
in a non-blocking way. Similar to 'system', but without waiting for
the child to complete. We also want to close all file descriptors
ahead of the exec() and filter + modify the environment.
Change-Id: Ib24ac8a083db32e55402ce496a5eabd8749cc888
Related: OS#4332
Those functions were originally developed as part of simtrace; let's
import them to libosmousb as they are truly generic.
Change-Id: I2c18b938e4e1ea5b8a521a386f00db3a7389e47a
Related: OS#4299
Osmocom applications typically use libosmocore select.[ch] event loop
code as their main event dispatch mechanism. When they want to deal
with libusb in a non-blocking/asynchronous way, they need to integrate
libusb into that select().
The new libosmousb is doing exactly that: Providing a shared utility
library for Osmocom programs that wish to use libusb. This is useful
for example in simtrace2 host utilitie as well as osmo-e1d.
Change-Id: I656a1a38cbb5b1f3a9145d2869d3b4d0adefcae3
Closes: OS#4299
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I84ef43f700e125c7a65f92347f12844e07e65655
The new OSMO_DEPRECATED_OUTSIDE macro is similar to the existing
OSMO_DEPRECATED_OUTSIDE_LIBOSMOCORE, but allows to override the
deprecation message.
Let's use it to suspend deprecation warnings related to:
- gsm48_decode_bcd_number(),
- osmo_ecu_fr_conceal(),
- osmo_ecu_fr_reset(),
as they're intentionally used in scope of the library.
Change-Id: I1b0eff1396776900c1286e41da3aee3ff78b326e
This is a bit of a hack, as we want to maintain binary compatibility
without breaking existing users of libosmocore. To do so, we use the
'num_auth_vectors' field in two ways now:
* In the existing use case as part of SEND_AUTH_INFO_RESPONSE, it
indicates the number of vectors stored in the 'auth_vectors' field
* In the new use case as part of SEND_AUTH_INFO_REQUEST, it indicates
the number of vectors actually requested by the MSC/SGSN/MME.
Change-Id: Iaecc47280f8ce54f3e3a888c1cfc160735483d0f
OSMO_GSUP_TO_MSGT_RESULT() is needed by osmo-hlr for osmo_gsup_req.
The others are added for completeness' sake.
Related: I3a8dff3d4a1cbe10d6ab08257a0138d6b2a082d9
Change-Id: I6e38a3bb8447f8f212f8d6f5b10a5d0df59323d7
Provide string escaping that
- returns the required buffer size, so it can be used with OSMO_STRBUF_APPEND().
- uses C compatible string constant escaping sequences.
This is intended as a replacement for all previous osmo_escape_str* and
osmo_quote_str* API. It pains me that I didn't get them right the first nor the
second time:
- The buffer functions do not return the chars needed, which is required for
allocating sufficient memory in the *_c versions of the functions.
- Because of that, these functions are accurately usable for
OSMO_STRBUF_APPEND(), producing truncated strings, for example when dumping a
GSUP message.
- They do not use the C equivalent string constant escaping: for some reason I
thought "\15" would be valid, but it should be "\x0f".
If I could, I would completely drop those mislead implementations ... but
backwards compat prohibits that.
A previous patch already provided internal static functions that accurately
return the required buffer size. Enhance these to also support C compatible
string escaping, and use them as implementation of the new functions:
osmo_escape_cstr_buf()
osmo_escape_cstr_c()
osmo_quote_cstr_buf()
osmo_quote_cstr_c()
In the tests for these, also test C string equivalence.
Naming: from API versions, it would be kind of logical to call them
osmo_escape_str_buf3() and osmo_escape_str_c2(). Since these anyway return a
different escaping, it makes sense to me to have distinct names instead.
Quasi missing are variants of the non-C-compatible weird legacy escaping that
return the required buffer size, but I refrain from adding those, because we
have enough API cruft as it is. Just always use these new cstr variants.
Change-Id: I3dfb892036e01000033dd8e7e4a6a0c32a3caa9b
Although this OSMO_DEPRECATED doesn't seem to generate a warning when compiling
code that sets .is_config_node = foo, it seems a good idea to add the
deprecation tag.
It is deprecated since commit "vty: track parent nodes also for telnet sessions"
I2b32b4fe20732728db6e9cdac7e484d96ab86dc5
Change-Id: I800507b27cb0d536c1a4c203d7f7b90eec05a69c
Keep track of parent nodes and go back hierarchically, not only for .cfg file
reading, but also for telnet VTY sessions.
A long time ago cfg file parsing was made strictly hierarchical: node exits go
back to parent nodes exactly as they were entered. However, live telnet VTY
sessions still lacked this and depended on the go_parent_cb().
From this commit on, implementing a go_parent_cb() is completely optional. The
go_parent_cb() no longer has the task to determine the correct parent node,
neither for cfg files (as already the case before this patch) nor for telnet
VTY sessions (added by this patch). Instead, a go_parent_cb() implementation
can merely take actions it requires on node exits, for example applying some
config when leaving a specific node.
The node value that is returned by the go_parent_cb() and the vty->node and
vty->index values that might be set are completely ignored; instead the
implicit parent node tracking determines the parent and node object.
As a side effect, the is_config_node() callback is no longer needed, since the
VTY now always implicitly knows when to exit back to the CONFIG_NODE.
For example, osmo_ss7_is_config_node() could now be dropped, and the
osmo_ss7_vty_go_parent() could be shortened by five switch cases, does no
longer need to set vty->node nor vty->index and could thus be shortened to:
int osmo_ss7_vty_go_parent(struct vty *vty)
{
struct osmo_ss7_asp *asp;
struct osmo_xua_server *oxs;
switch (vty->node) {
case L_CS7_ASP_NODE:
asp = vty->index;
/* If no local addr was set */
if (!asp->cfg.local.host_cnt) {
asp->cfg.local.host[0] = NULL;
asp->cfg.local.host_cnt = 1;
}
osmo_ss7_asp_restart(asp);
break;
case L_CS7_XUA_NODE:
oxs = vty->index;
/* If no local addr was set, or erased after _create(): */
if (!oxs->cfg.local.host_cnt)
osmo_ss7_xua_server_set_local_host(oxs, NULL);
if (osmo_ss7_xua_server_bind(oxs) < 0)
vty_out(vty, "%% Unable to bind xUA server to IP(s)%s", VTY_NEWLINE);
break;
}
return 0;
}
Before parent tracking, every program was required to write a go_parent_cb()
which has to return every node's parent node, basically a switch() statement
that manually traces the way back out of child nodes. If the go_parent_cb() has
errors, we may wildly jump around the node tree: a common error is to jump
right out to the top config node with one exit, even though we were N levels
deep. This kind of error has been eliminated for cfg files long ago, but still
exists for telnet VTY sessions, which this patch fixes.
This came up when I was adding multi-level config nodes to osmo-hlr to support
Distributed GSM / remote MS lookup: the config file worked fine, while vty node
tests failed to exit to the correct nodes.
Change-Id: I2b32b4fe20732728db6e9cdac7e484d96ab86dc5
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
When finding a char in a string, I want to be able to limit the search area by
size, not only by nul terminator.
Change-Id: I48f8ace9f51f8a06796648883afcabe3b4e8b537
Vadim Yanitskiy
Pau Espin Pedrol
Philipp Maier
Harald Welte
Daniel Willmann
Pau Espin
Sylvain Munaut
Oliver Smith