Not only we call this function from vty_read_config_file(), but
also from config_write_file_cmd. Thus we leak memory when doing
'write file FILE' in the VTY.
Change-Id: I356818aae3addab6db39de9a625453b7435b7cc1
Add functions to pass struct osmo_sockaddr to the
osmo_sockaddr_str_{to,from}* API directly.
So far the interface to osmo_sockaddr_str_ is:
osmo_sockaddr_str_from_sockaddr(&my_sa_str, &my_osa->u.sas);
I'm working a lot with osmo_sockaddr at the moment, and the cumulated
time of forgetting to add 'u.sas' and having another compilation cycle
because of those is justifying this additional API.
Change-Id: I0df84b4bb8cb5d8434b735fa3a38e7f95be43e91
This reverts commit 7f1fb3ea81 - slightly
amended with the new log_cache_enalbe() function. The cache is hence
disabled by default, and applications can enable it, if they wish to
benefit from it.
Reason for the original revert was: some fallout expected due to log
manipulation in test code
Change-Id: I539872fc9e3c50b407e6bc388f1e091fa2c826c3
There are situations (like multicast datagram transmit) where we don't
really care about the result of a write operation, and hence don't need
a write completion callback.
As the completed message buffer is free'd by core osmo_io, there is no leak
in doing so.
Change-Id: I0c071a29e508884bac331ada5e510bbfcf440bbf
* introduce a new "Osmocom I/O interface" group to show up in API docs
* expand the documentation to turn it into something useful for somebody
wanting to write an application using it.
Change-Id: I6315cfc7ff34a0f8971517edf035e1efcef3ed5c
osmo_io (unlike its io_uring backend) is not linux specific, so putting
it in an "#ifdef __linux__" block is plain wrong.
A side-effect is that all our doxygen comments are not processed as
__linux__ is not set while doxygen parses the source file.
Change-Id: I260443ba3cd0bb81dade434208dea4ea70fe8ad8
"Assert failed 0 osmo_io_uring.c:94" is rather useless in terms of an
error message. Let's improve upon that.
Change-Id: I0ac9ae59e99c3704b3ce33919c9e7d11024476e3
Right now stream_cli/srv print "<error-in-getsockname>" when using an
AF_UNIX socket. This commit fixes the problem.
Change-Id: I224c3712a029ee338ee1209a67d820b887170910
This was done for read error in a previous patch. This is required
because osmo_io_uring does not support errno, instead it uses the
result code. To have a unified API, set the result code equally.
Related: OS#5751
Change-Id: I405094449a6644db37534757f2fbccbcff982f23
Both of our back-ends have a register_fd and unregister_fd back-end.
Let's simplify the code by not treating them as optional, which
introduces code paths that we never take, adds small runtime overhead
and makes the code harder to follow.
Should we ever introduce more backends which might not need those
call-backs, we can either have empty functions or think about how to
make them optional.
Change-Id: I0077151eb676f61320b3fa2124448852aa8fd4a9
There's only one way to set the osmo_iofd_ops, which is by environment
variable during the constructor time at shared library load time.
There's hence no point in doing OSMO_ASSERT() on each and every call to
osmo_iofd_notify_connected() at runtime. We can move those kind of
asserts to the one-time load-time constructor instead.
At the same time, we can extend those asserts to all the mandatory
call-backs to be provided by the backend.
Change-Id: Id9005ac6bb260236c88670373816bf7ee6a627f1
Let's not pretend we support backends without a close_cb. In such
situations nobody would actually close(2) the file descriptor,
but we would set iofd->fd to -1, effectively creating a file descriptor
leak.
Both of our two back-ends provide a close_cb, and we don't need to
consider hypothetical future back-ends that would not like to register
such a call-back.
Related: OS#6393
Change-Id: Id285f1d7b73ae5805aa618897016ae8b73bf892d
Let's return an error if both osmo_iofd_setup() and osmo_iofd_register()
are called with an invalid file descriptor like -1. Either one of them
must have been called with a valid file descriptor.
Change-Id: Ie4561cefad82e1bf5d37dd1a4815f4bc805343e6
Setting ioops is optional when calling osmo_iofd_setup(). If it is not
set, do not call check_mode_callback_compat() to check for
compatibility.
Closes: Coverity CID#349578
Change-Id: I1e25f3e420f25a44cbf73a4da9a498b7561e9ddd
This call-back can for example be used as segmentation call-back
for libosmo-netif stream_cli/stream_srv or directly for osmo_io.
Related: OS#5755
Change-Id: I5e922c54b3431d759b38e81e55076125c5a34008
ctrl_cmd_send() should always have taken a 'struct ctrl_connection'
as argument, not directly its write_queue member.
Let's offer a ctrl_cmd_send2() which fixes the problem, and deprecate
the old ctrl_cmd_send().
Related: OS#5751
Change-Id: Ic81af56e7ea6921ba39168727ef64c308e9c6754
If it fails, do not set the IOFD_FLAG_NOTIFY_CONNECTED flag and log an
error message.
Closes: Coverity CID#349579
Change-Id: I34e8cc9a2b9df0c624841e5f9268a15c32418da1
All TX messages are moved from iofd instance to the user's context.
iofd may be destroyed, but the message is still available to the user.
To prevent a use-after-free bug, the context name must be changed from
iofd->name to a constant that does not belong to iofd.
Change-Id: Ib8dae924fa2d94a7f636136ba7279b965a18cf5b
This function can be used by user code to obtain the currently-set io
operations, it's the inverse of osmo_io_set_ioops().
Change-Id: I03398c811b9534f50c6644b21eea89a04be29fb0
msghdr must be detached, because subsequent callback at
iofd_handle_send_completion() may destroy the iofd (which in turn
frees this msghdr, if still attached) and frees the msghdr, causing a
double free.
Related: OS#5751
Change-Id: Ia349f73de2145fa360b20dd40deb73a8ffc71f07
There is always a completion after cancelling a uring request.
Because uring requests use msghdr pointer as user data, we cannot just
free the msghdr after cancelling. Upon completion (received after
cancelling), the user data still points to the msghdr. To prevent a
use-after-free bug, msghdr is not freed, but detached from iofd
instance. Then upon completion, the msghdr (if it was detached from
iofd) is freed.
Additionally it is not required to keep IOFD_FLAG_IN_CALLBACK set
anymore, if there is a msghdr attached to iofd. As described above,
all msghdr get detached, if iofd is freed (uring request get cancelled)
during callback.
Related: OS#5751
Change-Id: Ic253f085dd6362db85f029f46350951472210a02
In order to receive a connect notification from SCTP socket,
poll/select event must be used instead of a write notification via
io_uring completion event.
Once the connect notification has been received, subsequent write
notifications via io_uring are used.
Change-Id: I4eca9ea72beb0d6ea4d44cce81ed620033f07270
Related: OS#5751
Add support osmo_io operations resembling sendmsg() and recvmsg() socket
operations. This is what will enable the implementation of higher-layer
functions like equivalents of sctp_recvmsg() and sctp_send() in
libosmo-netif and/or other users.
Change-Id: I89eb519b22d21011d61a7855b2364bc3c295df82
Related: OS#5751
This relocation is necessary as the backend (osmo_io_fd or
osmo_io_uring) requires a different approach in handling connect
notifications. As a result, a function call has been introduced to
struct iofd_backend_ops.
In a subsequent patch, the process for the osmo_io_uring backend will
be modified to handle SCTP connect notifications using poll/select.
If connect notification is requested using poll/select, the file
descriptior must be registered to osmo_fd, using osmo_fd_register. If
read / write notification is requested by application, the file
descriptior must be registered also. A flag is used prevent calling
osmo_fd_register / osmo_fd_unregister multiple times, which would cause
a crash.
Change-Id: I905ec85210570aff8addadfc9603335d04eb057a
Related: OS#5751
PCO - Protocol Configuration Options 3GPP TS 24.008 / 10.5.6.3.
The PCO will be used by the osmo-epdg to pass PCO internally.
The PCO will be passed towards to the PGW in the Session Request.
Related: OS#6369
Related: osmo-gsm-manuals.git Change-Id Id912ead4e1205f84a40af6505a5ddf050d1e086d
Change-Id: I0f9de90c7c67fe194b441a9d118eba70f09afb5e
As we introduce more modes, and each mode aliases call-back function
pointers to those of another mode, we have more and more error cases
where we (for exampele) access read_cb, but in reality the user has
populated recvfrom_cb.
Let's use a struct, meaning that call-backs of one mode no longer alias
to the same memory locations of call-backs fro another mode. This
allows us to properly check if the user actually provided the right
callbacks for the given mode of the iofd.
This breaks ABI, but luckily not API. So a simple recompile of
higher-layer library + application code will work.
Change-Id: I9d302df8d00369e7b30437a52deb205f75882be3
In gsm0503_pdtch_decode(), we decode CS2 and CS3 as if no puncturing
was employed, reordering the coded bits and setting punctured ones
to 0 manually. Because of that, osmo_conv_decode_ber_punctured()
reports n_bits_total higher than we actually receive over the air.
Change-Id: I6b20cc450f25c48175a61da02644d66c08e22ece
Related: OS#6342, OS#6200
GPRS coding schemes CS2 and CS3 (defined in 3GPP TS 45.003 sections
5.1.2 and 5.1.3, respectively) employ so-called puncturing, which
can be described as intentional removal of coded bits. The goal
of puncturing is to reduce the number of coded bits, so that they
fit into 4 bursts. The receiving side recovers punctured bits,
as if they were received corrupted.
The puncturing is also used for other channel types like TCH/F9.6,
TCH/F14.4, TCH/AFS and TCH/AHS, but only for CS2 and CS3 we're
doing puncturing/depuncturing *manually*. This explains why
we're seeing artificial bit errors only for CS2 and CS3.
gsm0503_pdtch_decode() should not be reporting punctured bits as
bit errors, fix this by using osmo_conv_decode_ber_punctured().
Change-Id: I024276d167e769396187998d881f8e7626461249
Related: OS#6342, OS#6200
Adjust osmo_timers_nearest_ms() to round up the remaining time.
Note that poll() has a granularity of 1 millisecond.
Previously, when rounding down the remaining time, osmo_select_main()
would return too early, before the nearest timer timed out.
Consequently, the main loop repeatedly called osmo_select_main() until
the timer actually timed out, resulting in excessive CPU usage.
By modifying osmo_timers_nearest_ms() to round up the remaining time,
we ensure accurate timeout calculations, preventing unnecessary CPU
consumption during the main loop.
The patch only applies to non-embedded version of libosmocore, because
the impact on embedded systems is not verified tested.
Related: OS#6339
Change-Id: I79de77c79af4d50d1eb9ca0c5417123ff760dca3
Let's be smarter and call the status update callback iff the V.24
flagmask was actually changed.
Change-Id: I9626d3e737d4e072fa163115c4cdf9ee6ee0968e
Related: OS#4396
The previous PDP-Type IE should have been a PDP-Address from the
start, since having only PDP-Type with no address is only a specific
case (dynamic addressing).
This becomes clear by looking at other similar protocols like:
* MAP: APN-Configuration IE has servedPartyIP-IP{v4,v6}-Address IEs
* Diameter S6b, 3GPP TS 29.272 7.3.35 APN-Configuration contains
Served-Party-IP-Address AVPs
* Diameter SWx, 3GPP TS 29.273 APN-Configuration.
* GTPv1C Ts 29.060 7.7.29 PDP Context containing PDP Address.
Since PDP-Type on its own really makes no sense, being it a special case
of PDP-Address, let's keep the IE by renaming it (keeping old name too
for API backward compat) and extend it to support lengths > 2 bytes.
Old implementation of libosmogsm gsup actually ignored lengths > 2
bytes, so we are safe acting against older implementations here, both
on the sending and receiving side on the wire.
The big drawback of this commit is that it breaks ABI compatibility due
to adding "struct osmo_sockaddr pdp_address[2];" to struct
osmo_gsup_pdp_info, which in turn affects shift of fields in struct
osmo_gsup_message. Unfortunately, there's not much that can be done to
improve the situation when adding the missing field, due to existing API
having the same struct for all messages. Ideally we'd have 1 union with
structs per message type inside, this way the ABI break would be far
less pronounced.
The GSUP test output change is becaue we now accept some of the len>2
cases for PDP-Type/Address IE which were being rejected since a couple
commits ago.
libosmogsm gsup code is now disabled in EMBEDDED mode, since it nows
depends on core/socket.h (struct osmo_sockaddr) which is not available
in EMBEDDED, and hence fails during build:
"""
In file included from /build/include/osmocom/gsm/gsup.h:45,
from /build/src/gsm/gsup_sms.c:28:
/build/include/osmocom/core/socket.h:15:10: fatal error: arpa/inet.h: No such file or directory
15 | #include <arpa/inet.h>
| ^~~~~~~~~~~~~
"""
Related: OS#6091
Change-Id: I775ff9c3be165d9f30d6ab55d03f99b6104eadd6
Having both fields in an uin16_t integer makes it difficult and
confusing for users for no good reason. Let's have separate fields for
each of them.
The new fields are defined so that they are ABI compatible with previous
uin16 field.
Change-Id: Ie31c6080c90e468c01186259f2c42621e39b5cc6
As documented in gsup.adoc, this field is expected to be 2 bytes.
This is only a intermediate step to showcase the related test scenarios
submitting IE with len > 2. The logic will be changed in a follow-up
patch when changing the IE to also encode/decode the missing Address
part.
Change-Id: I0d024a9a4fb10beeff39ac33a9d2ed02f88f4580
Let's make those E1/E2/E3 bit combinations publicly available in
form of a lookup table (key is enum osmo_v100_sync_ra1_rate).
Add convenience macros for setting and comparing these bits.
This lookup table will be used by osmocom-bb.git.
Change-Id: I6d2f8e250df31c233a2741163113dc07515409ae
Related: OS#4396
This ensures multithreaded logging attempts, in particular ones that do
nothing, do not hold the lock just for checking the level, which
interferes with other logging attempts.
Closes: OS#5818
Change-Id: I35f8dd9127dd6e7feae392094fd6b3ce2d32558d
ITU-T recommendation V.110 defines Terminal Adaptor (TA) functions
for the connection of Terminal Equipment (TE) having standard V-series
interfaces to the ISDN. This patch brings "software" implementation
of the TA to libosmoisdn.
The primary user for this soft-TA is the mobile-side implementation
of CSD (Circuit Switched Data) in osmocom-bb. CSD is heavily based
on V.110, which is not surprising given that GSM is a "wireless ISDN".
Nevertheless, this code will likely also be useful in the context
of retro-networking.
Similarly to the existing V.110 code in libosmoisdn, the present
implementation aims to be functional and correct, rather than
efficient in any way. It also has several limitations, which are
not critical for the CSD use case, but eventually may be a problem
for other use cases in the context of retro-networking.
Therefore, the V.110 TA API should be considered _unstable_,
and may be subject to change in the future.
+-------+ +------+ B-channel +------+ +-------+
| TE1 |------| TA |~~~~~~~~~~~~~~~| TA |------| TE2 |
+-------+ +------+ +------+ +-------+
TE (also known as DTE) is basically a computer, having a V-series
(usually RS-232) connection to TA (also known as DCE). The TA acts
like a regular analog modem, except that it is not performing any
kind of modulation or demodulation itself.
The TE-TA interface is implemented by the user supplied callback
functions, configured during the allocation of a TA instance:
* .rx_cb() - receive call-back of the application,
* .tx_cb() - transmit call-back of the application,
* .status_update_cb() - status line update call-back.
In addition to that, the application (TE) can interact with the
V.24 status lines (circuits) using the following API:
* osmo_v110_ta_{get,set}_status(),
* osmo_v110_ta_{get,set}_circuit().
The Rx and Tx between TE and TA is always driven by the TA itself,
as a result of an interaction with the lower layer implementing
the B-channel interface. There is currently no buffering and thus
no way for TE to initiate transmission or pull data on its own.
The TA-TA (B-channel) interface is implemented by the following
functions, which are meant to be called by the lower layer
transmitting and receiving V.110 frames over certain medium:
* osmo_v110_ta_frame_in() - indicate a received V.110 frame,
* osmo_v110_ta_frame_out() - pull a V.110 frame for transmission,
* osmo_v110_ta_[de]sync_ind() - indicate a synchronization event.
The lower layer is responsible for finding the synchronization
pattern (if needed), aligning to the frame boundaries, and doing
the V.110 frame coding.
The D-channel signalling is behind the scope of this module.
Initial (Work-in-Progress) implementation by Harald Welte,
completed and co-authored by Vadim Yanitskiy.
Change-Id: I5716bd6fd0201ee7a7a29e72f775972cd374082f
Related: OS#4396
This API predates commit 7b74551b9, which added support for millisecond
granularity to osmo_fsm. Let's do the same for the tdef FSM wrapper
API, allowing the millisecond precision without rounding-up to seconds.
Of course, this patch changes behavior of the existing API, but having
more precise state timeouts is not going to make the API user
experience worse.
The old behavior of using seconds is for kept for:
* OSMO_TDEF_CUSTOM -- still treated as if it was OSMO_TDEF_S.
* \param[in] default_timeout -- still expected to be in seconds.
Change-Id: I4c4ee89e7e32e86f74cd215f5cbfa44ace5426c1
Related: 7b74551b9 "fsm: Allow millisecond granularity in osmo_fsm built-in timer"
Vadim Yanitskiy
Neels Hofmeyr
Eric Wild
Harald Welte
Andreas Eversberg
Pau Espin