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"
This commit fixes the following warning seen with CC=clang:
utils.c:376:6: warning: variable 'len' set but not used [-Wunused-but-set-variable]
int len = 0, offset = 0, ret, rem;
... and finally allows to build libosmocore with --enable-werror.
Change-Id: I0040ef20ba3fc53ee7ccefc4885170f333f80566
This code predates 2cbe25f4, adding osmo_strbuf API and so using its
own append-to-strbuf implementation. Let's use the new generic API.
Change-Id: Ifdfd18eeef6a0932995063259f9f179b22e781de
The member data[0] in struct osmo_ecu_state is used as an anchor to
attach private structs for a concrete ECU implementation. This works by
allocating more memory then struct osmo_ecu_state actually needs and
then using the excess memory to store the private struct of the concrete
ECU implementation.
However, this poses a problem since data[0] is at the end of the struct
it may land in an unaligned position. This also means that the struct we
store there is also unaligned.
We should fix this enclosing the public struct osmo_ecu_state into our
private struct fr_ecu_state. Then we can use container_of to cast from
osmo_ecu_state to fr_ecu_state and correct alignment is ensured as well.
Related: OS#6286
Change-Id: I28672856e8e8f47e04ffe09ee3e07b577108cdc7
bitvec.c:543:14: warning: variable 'pos' set but not used [-Wunused-but-set-variable]
unsigned i, pos = 0;
Change-Id: I17df6f9263bee06676309c00837f12220803c814
This can be seen when building with CC=clang:
utils.c:150:22: runtime error: applying non-zero offset 100 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior utils.c:150:22 in
utils.c:150:33: runtime error: addition of unsigned offset to 0x000000000064 overflowed to 0x000000000063
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior utils.c:150:33 in
The *dst pointer may be NULL (e.g. bcd2str_test() is passing it).
This makes tests/utils/utils_test fail. Let's fix this.
Change-Id: I542aef1ac220891b6bbdb0c60c39232f0df0a43c
The code so far only supported 240bit RLP frames; Add support for
576bit in this patch. We still only support versions 0+1 and not
version 2.
Change-Id: Idfdcabb19fe8733fb9c5ee76a39b0bf4cdf60c2c
- Use defines instead of repeating string literals
- Use enum for indexing same data everywhere consistently
Related: OS#5915
Change-Id: I11c926dd4125c6657ae3cd21d8038f161d9fd9c3
These values end up being used by API users of
osmo_sock_multiaddr_get_name_buf() and
osmo_multiaddr_ip_and_port_snprintf().
Change-Id: I18a0e1a652a3e8ef3e97154355eb1d07a14ef0bd
Coverity tells us that with the current logic it's possible (in theory)
that we may dereference NULL pointer in osmo_soft_uart_flush_rx(). This
is highly unlikely, because the Rx buffer gets allocated once when the
Rx is enabled and remains even after the Rx gets disabled. The Rx flags
cannot be anything than 0x00 before the Rx gets enabled.
Even though this NULL pointer dereference is unlikely, the Rx flushing
logic is still not entirely correct. As can be seen from the unit test
output, the Rx callback of the application may be called with an empty
msgb if the following conditions are both met:
a) the osmo_soft_uart_flush_rx() is invoked manually, and
b) a parity and/or a framing error has occurred previously.
We should not be checking suart->rx.flags in osmo_soft_uart_flush_rx(),
since this is already done in suart_rx_ch(), which is calling it.
Removing this check also eliminates a theoretical possibility of the
NULL pointer dereference, so we're killing two birds with one stone.
- Do not check suart->rx.flags in osmo_soft_uart_flush_rx().
- Add a unit test for various flush()ing scenarios.
Change-Id: I5179f5fd2361e4e96ac9bf48e80b99e53a7e4712
Fixes: CID#336545
This is a convenience helper to reetrieve the whole set of remote
addresses and call getsockopt() on them, making it easy for users to
analyse the full set of remote addresses of a socket simply providing an
fd.
Related: SYS#6636
Change-Id: I3e1c84526b006baff435bbbca49dc6cf7d201cf5
In the _output_buf() we explicitly initialize only the 'buf' and 'len'
fields of the struct osmo_strbuf, leaving the 'pos' field implicitly
initialized to NULL. Later, in this function, 'sb.pos' is passed to
ctime_r() and strlen(), leading to a NULL pointer dereference (segfault)
in certain scenarios.
This situation can occur when color logging is disabled or when
a specific logging subsystem has no associated color. Any application
using libosmocore's logging API would crash with the following config:
log stderr
logging filter all 1
logging timestamp 1
logging color 0
Fix this by initializing the 'pos' field explicitly.
Change-Id: I7ec9badf525e03e54e10b725d820c636eaa3fd1c
Fixes: d71331bc "logging: fix nul octets in log output / use osmo_strbuf"
Fixes: CID#336550
The goto tag was wrong, probably due to a copy-paste mistype while
reimplementing the function.
Closes: Coverity CID#336546
Change-Id: I06b810fde7bf750fcb42d6d9e6223883e26f5f0b
If the given queue is empty, queue->list.next points to &queue->list.
Current implementation would call llist_del() on the queue's llist_head,
decrement queue->current_length (which will be 0), and return a pointer
to &queue->list to the caller. This is completely wrong.
- Use the existing item_dequeue(), which does exactly what we need.
- Do not decrement the current_length if nothing was dequeued.
- Uncomment code in the unit test, we should not crash anymore.
Change-Id: I63094df73b166b549616c869ad908e9f4f7d46d1
Fixes: CID#336557
This patch brings decoding of the CS1 in consistency with the other
three coding schemes, for which we support decoding USF independently.
Change-Id: I61a3628741c0ac68374fc7f077cf3a07e51277c3
The USF (Uplink State Flag) field is present in the MAC header of all
Downlink PDCH blocks. It is used by the network to indicate which MS
can transmit on subsequent Uplink PDCH block(s). This field is of a
high importance for the MS, thus the decoder API allows the caller
to obtain USF value separately from the actual data bits.
In the case of gsm0503_pdtch_decode(), if the 'usf_p' pointer is not
NULL, the USF value would be assigned for CS2/CS3/CS4 (but not CS1)
even if the CRC check fails (negative return value). A subsequent
patch is to bring the CS1 in consistency with CS2/CS3/CS4.
In the case of gsm0503_pdtch_egprs_decode(), decoding of the USF
field separately from data bits is not implemented, and moreover
the function itself cannot be used for decoding Downlink blocks.
Change-Id: I43e8bfb4003f34766ace7c5c6080ca583ce5efbb
An extra osmo_multiaddr_ip_and_port_snprintf() API is introduced which
is used by osmo_sock_multiaddr_get_name_buf() but which will also be
used by other app uers willing to use
osmo_sock_multiaddr_get_ip_and_port() according to its needs (eg. only
printing the local side).
Related: SYS#6636
Change-Id: I48950754ed6f61ee5ffa04a447fab8903f10acc0
This API will be used internally by osmo_sock_multiaddr_get_name_buf()
in a follow-up patch.
This API can also be used directly by user who wish to obtain a list of
local/remote IP addresses and port from an SCTP socket.
Related: SYS#6636
Related: OS#5581
Change-Id: I19d560ab4aadec18a4c0f94115675ec1d7ab14d7
Patch [1] merged few weeks ago, for yet unknown reasons, sprinkles nul
characters at seemingly randomly chosen log line ends.
Trying to figure out why that happens, i got tired of the unreadable
cruft, and decided to migrate the _output_buf() implementation to
osmo_strbuf first.
With osmo_strbuf in use and implementing 1:1 what the previous code did,
the odd nul octets have disappeared. So the bug was caused by unreadable
code.
[1] 11a416827d
Ia7de9d88aa5ac48ec0d5c1a931a89d21c02c5433
"logging: ensure ANSI color escape is sent in same line/before newline"
Related: OS#6284
Related: Ia7de9d88aa5ac48ec0d5c1a931a89d21c02c5433
Change-Id: Ib577a5e0d7450ce93ff21f37ba3262704cbf4752
Upcoming patch adopts osmo_strbuf in logging.c, which sometimes needs to
steal and re-add trailing newline characters, and also needs to let
ctime_r() write to the buffer before updating the osmo_strbuf state.
Related: OS#6284
Related: Ib577a5e0d7450ce93ff21f37ba3262704cbf4752
Change-Id: I997707c328eab3ffa00a78fdb9a0a2cbe18404b4
Those parameters are not related to binding and hence should be
applicable before binding. This allows a caller setting them while not
caring about explicit binding (OSMO_SOCK_F_BIND).
Until recently calling this function without OSMO_SOCK_F_BIND was not
really supported, so the previous placement setting these params in the
function didn't matter much. It does now.
Change-Id: Ia32510e8db1de0cc0dc36cebf8a94f09e44fda70
This is an attempt to fix several downsides of current
osmo_sock_init2_multiaddr() API, mainly the requirement to pass an explicit
local address (!NULL). It also now works fine if OSMO_SOCK_F_BIND flag
is not used.
This reimplementation is based on the follwing logic:
- If caller passed family=AF_INET or family=AF_INET6, that same family
is used and kernel will fail if something is wrong.
- If caller passes family=AF_UNSPEC, the function will try to find the
required family to create the socket. The decision is taken on the
assumption that an AF_INET6 socket can handle both AF_INET6 and AF_INET
addresses (through v4v6 mapping). Hence, if any of the addresses in the
local or remote set of addresses resolves through getaddrinfo() to an
IPv6 address, then AF_INET6 is used; AF_INET is used otherwise.
Related: OS#6279
Change-Id: I2641fbaca6f477404b094dbc53c0c1a3dd3fd2fd
This is a partial revert of 0887188c6b.
We actually want to return number of bits pulled, because in the upcoming
commit implementing the flow control we want to be able to signal to the
caller that the buffer was not completely filled, but only partly.
Change-Id: I47a56f0fc36f2bc8f5a797d7fec64dfb56842388
Related: OS#4396
Check it once rather than doing this in a loop. Return -EAGAIN if
Rx or Tx is not enabled when calling osmo_soft_uart_{rx,tx}_ubits().
This [theoretically] improves performance by reducing the number of
conditional statements in loops. In the Tx path, this also prevents
calling the .tx_cb() when the transmitter is disabled, so that we
don't loose the application data.
Change-Id: I70f93b3655eb21c2323e451052c40cd305c016c8
Related: OS#4396
Andreas Eversberg
Harald Welte
Vadim Yanitskiy
Pau Espin
Eric Wild
Philipp Maier
Neels Hofmeyr