This allows easily identifying and following state and lifecycle of
CIDs when looking at logs.
Related: SYS#6161
Change-Id: I6a3113dfaef0adbb20162985e3b7d57c46dbc016
Previously, if RTP jumps were detected in the incoming RTP stream and
osmux state for that circuit was to start the next batch, the hole would
not been filled during queueing time and instead the encoder would have
set the M bit in the osmuxhdr to announce a sync point.
For small holes (eg less than the batch factor) it makes sense to start
filling the batch with crafted RTP packets in order to avoid the encoder
later on setting the M bit and hence avoid the peer receiving the Osmux
frame having to start a new syncrhonization point.
Related: SYS#6161
Change-Id: I9596501adf5b7b91983618c92c7b1792ee9461a3
So far only small intra-batch seqnum jumps are filled in with forged RTP
packets when storing the incoming RTP packets.
Under some conditions, holes may still exist in the queue of RTP packets
for a stream:
* Seqnum detected when first incoming RTP in batch is queued (this can
be improved in the future).
* Big seqnum jumps > batch_factor or simply filling out of bounds for currently
enqueued batch.
Specially the second case can come from long network dropouts, or simply
due to a bug in the RTP being feed to osmux layer (be it from local code
or peer). In that case (long jumps) we don't want to generate tons of
packets filling in several entire batches (potentially incredibly big
amount of batches).
Instead, in these scenarios, simply let the osmux peer know there was a
jump by setting the M bit on the next osmux header for that circuit
after the seq jump has been detected.
Related: SYS#6161
Change-Id: I05b1eae400cb60d1f4e927f853619d5ff470163f
osmux_link_add() is renamed to osmux_link_handle_rtp_req(), and the last
part of it is split out and kept as osmux_link_add().
hence osmux_link_handle_rtp_req() does proper input checking (like
duplicates, holes, etc.) while osmux_link_add() expects all that to be
sorted out.
Reuse osmux_link_add() in osmux_replay_lost_packets() to properly update
the link state of the to-be-transmitted packet, circuit state, etc.
Change-Id: I4ea435bfb2490a375ad3e5068ee926e48b53cf5c
If the last RTP we received from the user is a Marker bit (which is
expected to be the first in the batch), then there's no need to keep
marking the forged RTP packets to fill holes also as Marker bit.
Change-Id: I5cef6185afbfce748473a096e8ebabd9c9628e12
In the event we need to fill in the batch with intermediate lost RTP
packets, we must do so before handling the last one.
Change-Id: Ib5dd7b1fa6213c96ece803b781a7ef1cf102a1d4
When RTP packet provided by user to osmux layer, it may contain a seq
gap, and osmux will refill the packets to avoid losing that information
on the other side when it receives the batch.
If out of order UDP packets are received, it can happen that we first
detect a gap and later on we receive the previous RTP packet, which we
is then detected as duplicate because it was previously forged to fill
the hole. In that case, let's better keep the incoming packet instead of
the potentially internall forged one which doesn't contain the real AMR
payload.
Related: SYS#6161
Change-Id: I82e11ef3dcd20ffea33c94ed83abcedf0f186871
We need to filter duplicate messages before checking the Mark bit and
returning 1 to tell the user to deliver the current batchset content.
Otherwise, a repeated RTP packet with an M bit would trigger delivery,
which is wrong.
Change-Id: I4a01b0935f112d650d8fc161b3389eda6c8e75ec
This allows incrementally gathering all the information once and only
once. While doing so, this patch tends to move the decoding/parsing of
the incoming RTP packet further towards the start of the code, hence
detecing errors in the input data early in the process and avoiding
touching internal state in this case.
Change-Id: I55e0d2772e7054c0d734f5918c6938a5c8a6e781
A lof of mess is inherited from the fact that there's a public object
(struct osmux_in_handle) which internally uses a private object (struct
osmux_link).
The struct osmux_in_handle fields are no longer expected to be accessed
or allocated by the user, hence the struct is only kept in the header
for backward compatibility with older versions.
At some point, both structs can be moved to the C file and merged,
simplifying the code further.
For now, let's simply add a backpointer from struct osmux_link to the
related struct osmux_in_handle, so that we can pass 1 pointer and have
all fields accessible in the code.
This allows further simplifying the code.
We could also add an extra backpointer from osmux_circuit to osmux_link,
but that's not really estimated as needed as of now since we can easily
pass the osmux_link pointer down the called functions.
Change-Id: I5c226c5c809a240f9eb80aa2e83679adc717d717
This struct matches the lifecycle of the link, holds all the circuits
acting as a trunk. The previous name was utterly misleading since "batch"
usually is per circuit group of AMR frames with an osmux header.
Change-Id: Ib118fd2c1fead78655756156ce5d4ce4a6d080df
This API allows retrieving back the private pointer set previously by
osmux_xfrm_input_set_deliver_cb().
Change-Id: I95433b18802f73fa70e758f4aa02128eee940d88
Until now, the osmux_in_handle was allocated by the client, and passed
to the API to initialize it. This makes it really hard to improve the
implementation without breaking the ABI.
Let's break the ABI now one last time (hopefully) by allocating the
struct through an API. With only this change, the already built users
(osmo-mgw, openbsci, osmo-bts) can still work fine, since there's no
change on the struct osmux_in_handle. However, they will somehow break
next time thestruct is changed until they are ported to the same API
(easy to do).
Change-Id: I752ab031f935f04731bb1a354333f1682a1aa5bd
Related: SYS#5987
The output and input paths are totally independent, they share no code
or structures holding state. They can be operated totally independently.
Hence, let's split the code into separate file since when someone looks
at the osmux code one is really looking specifically at Tx or Rx side,
but not at both sides.
Moreover, the "input" and "output" concepts have always been a bit
difficult to understand (would have been better calling them "src" and
"sink" instead), which adds more confusion when trying to find the
relevant part of code.
Change-Id: Ia72995092a36ca50147611e617cb88c4dcf231d5
It was not being used anywhere, yet older applications used to set it
(always to 0, which was the default value applied internally).
Let's make use of it and apply it as first seqnum to be used on a
circuit.
This value is applied upon call to osmux_xfrm_input_open_circuit(),
hence it can be set independently for every new circuit.
Change-Id: Ia26fcba5d7364a5744b2d64d0542a2b3880eee34
There's no real use in having it split, it just makes it more difficult
to extend since extra prams must be passed over 2 functions.
In fact, the duplicity of "struct osmux_in_handle" and "struct
osmux_batch" as its ->internal_data should go away in the future.
Change-Id: Ie4c6b55827ac27bcdfbe1b14fb238f5873243000
It was seen on a real pcap trace (sctp & gsmtap_log) that the Linux
kernel stack may decide to kill the connection (sending an ABORT) if
it fails to transmit some data after a while:
ABORT Cause code: "Protocol violation (0x000d)",
Cause Information: "Association exceeded its max_retrans count".
When this occurs, the kernel sends the
MSG_NOTIFICATION,SCTP_ASSOC_CHANGE,SCTP_COMM_LOST notification when
reading from the socket with sctp_recvmsg(). This basically signals that
the socket conn is dead, and subsequent writes to it will result in
send() failures (and receive SCTP_SEND_FAILED notification upon follow
up reads).
It's important to notice that after those events, there's no other sort
of different event like SHUTDOWN coming in, so that's the time at which
we must tell the user to close the socket.
Hence, let's signal the caller that the socket is dead by returning 0,
to comply with usual recv() API.
Related: SYS#6113
Change-Id: If94d44f25b76a96a5ea402fec9fc14c4e6296ba3
It could be that the user reuses the msgb passed to
osmo_stream_srv_recv() all the time, hence we need to reset the flags,
otherwise it may end up being set forever.
Change-Id: Id358140db82b018e3973111e530834589c0b7224
This allows the user to properly check the size of the content in case
the struct ABI changes.
-EAGAIN is still returned to avoid older users of the API reading SCTP
notifications as user data.
Change-Id: I95e2457498fd8e0d790d221cb97695ace0dd673e
The wrap around case was not properly considered in the condition
setting the Marker bit. Let's fix it.
Related: SYS#5987
Change-Id: I6e01f29a6239f930c9be2bcb2efe447e5de8fedf
There's no real use in having a global seqnum. The seqnum, as specified
by the osmux protocol specification, relates to that of the RTP
seq+timestamp, hence it is per circuit.
Having it per circuit allows detecting gaps and lost batches on the
receiver side, applying the Marker bit on the re-assembled RTP packets.
As a resut of the fix, tests/osmux/osmux_test part validating Marker bit
started failing. It failed because it was wrongly written to start with,
since it used only one osmux_out_handle for the 4 CIDs in use, which was
wrong, since each CID must have its own osmux_out_handle as state is
kept there per circuit.
Related: SYS#5987
Change-Id: I562de6a871d8a35475c314ca107c2a12b55d6683
The value of the first RTP packet in the batch was being encoded,
instead of the last one (as documented in the Osmux protocol
specification).
Related: SYS#5987
Change-Id: I06f3d07a05181d938c22bbd0da7172b5dad6659a
The AMR FT (and hence payload content and size) may well change over the
lifetime of an RTP stream. Since all AMR payloads in an osmux batch
share the same FT (its joined payload is calculated based on
osmuxh->ctr*amr_bytes((osmuxh->amr_ft)), if a new RTP/AMR with a
different FT arrives we cannot simply append it to the current batch.
Instead, the current batch must be considered done and a new batch with
anew osmuxh header must be prepared for the resulting osmux frame to
send over UDP.
Before this patch, when a packet with a different AMR FT was submitted
for batching, it would be added in the same batch and decoding would
fail since the sizes of the batches would be wrong.
Related: SYS#5987
Change-Id: I25eb6ee54c898f575cc71ccfd6d190fe51d56dbe
If there's an error while replaying lost packets, return the error to
the caller.
If the batch is found full, early return indicating so, there's no need
to continue flow calling osmux_batch_enqueue() in osmux_batch_add()
again.
Change-Id: I62f494d2b2e7903a6683f6dea00781bb721a3d41
The osmux header goes before in the packet, so let's move the line
checking is size before the content.
Change-Id: I33feac834700d22ed06472d8971abd0567ce623b
The RTP msg will be dropped, so it makes no sense to signal the caller
to deliver the batchbeing built, since it may still have space for next
non-duplicated message.
The exception is the case where the new packet has the M marker bit set,
since the sequence numbers can be reset or jump in those scenarios.
Change-Id: Idc457bc3b26bed68796d714bc3f37a2d016ba5c3
This way the caller can log or make statistics based on the return code.
All known implementations simply check the return code to be >0, so we
are fine here.
Change-Id: I981cc7e560cd9c792a8a2a219b3612f9834296ce
The user may want to check the flags in order to know if the content
pointed at by msgb is an sctp_notification structure, and not in-band
data.
This is useful for the user in order to gain connection state such as
SCTP RESET notification, which means the client reconnected reusing the
same socket, loosing all higher layers state.
The MSG_NOTIFICATION from netinet/sctp.h is not reused, and instead an
osmocom specific flag (and bitmask) is used. This is done in order to
fit the flags in one byte, since for instance MSG_NOTIFICATION requires
2 bytes in my system (0x8000).
Related: SYS#6113
Change-Id: I0ee94846a15a23950b9d70eaaef1251267296bdd
The fd is not valid anymore after close() call, so let's set it to a
clearly invalid value, to avoid confusion on closed_cb() users
attempting to use the fd get info about the socket at that time.
Change-Id: I82d9bdfb38cf5e9f689eca0d9a4c19ddd5541af7
This is useful for users of the API which need to keep forwarding the
msgb to lower layers which may need prepending a new header to the msgb,
like osmo-bts with l1sap.
Related: SYS#5987
Change-Id: I632654221826340423e1e97b0f8ed9a2baf6c6c3
Until now, the osmux_out_handle was allocated by the client, and passed
to the API to initialize it. This makes it really hard to improve the
implementation without breaking the ABI.
Let's break the ABI now one last time (hopefully) by allocating the
struct through an API. With only this change, the already built users
(osmo-mgw, openbsc) can still work fine, since there's no change on the
struct osmux_out_handle. However, they will somehow break next time the
struct is changed until they are ported to the same API (easy to do).
Related: OS#5987
Change-Id: Ie8df581f375c9a183a7af60b431561bda82f6e34
Those APIs where deprecated 4 years ago (end of Aug 2018), and they have
not been used since around that time. Hence it can be considered safe to
drop them, since they only make the whole code more complex to
understand.
API osmux_xfrm_output_init() is left since openbsc.git is still using
it.
Related: OS#5987
Change-Id: Icbdd364a8161a8113dbf1406716946f684d0a853
Found out by following gcc warning:
"""
libosmo-netif/src/stream.c:147:11: warning: argument to variable-length array may be too large due to conversion from ‘int’ to ‘unsigned int’ [-Wvla-larger-than=]
147 | uint8_t buf[sctp_sockopt_event_subscribe_size];
| ^~~
"""
Change-Id: I181ae5c0480788fc96abd2bb1edf003244884c8f
Make coverity happy, since this seems to spread as a tainted error
further below.
Related: Coverity CID#273000
Change-Id: I5d457183043d4c902f473b828815b9c62a01d47d
The check was wrong for format types containing extra bits not aligned
to byte boundaries, such as FT7 (AMR Code 12.20, 244 bits, 31 bytes).
if the source has 1-6 extra bits, they can be fit with one less byte
when shifting 10 bits to the left.
Change-Id: I0552d727585886d25f613e64ca815fb6dcd53f25
The proper order is CMR(4)+F(1)+FT(4)+Q(1).
Hence, FT is 3 least significant bits of first byte and 1 most
significant bit of secont byte.
Change-Id: I66f39d3b9a608f07c202e7a5084a8537e9978a94
These APIs allow for easy re-formatting of received AMR to forward
between regular RTP and IuUP.
Related: OS#1937
Change-Id: Id2bd32d5f2060abe581730996dc4251381bf7d4f
This commits adds a generic mechanism for applications to validate
support for SAPs and specific versions of them.
A new special SAPI is introduced to manage inbound control messages for
the protocol.
In that SAPI a new primitive HELLO.req/.cnf is added to negotiate
support for versions of any given SAP.
The idea is that the client upon connecting submits a HELLO.req(SAP,
VER) for each SAP it plans to use, including the version of the special
CTL SAPI itself (preferrably to be checked first).
Upon receiving such a message, osmo_prim_srv handles it using a special
path, which ends up calling the user provided rx_sapi_version_cb(SAP,
VER). In there, the user can either:
* Accept the version (return same VER value)
* Reject the requested version but propose another candidate version
(return some positive VER value other than received VER). In this
case, the client can decide whether to request another VER or close the
connection.
* Reject the proposed version and close the connection.
Change-Id: I0c2d92cfdb5433e3caab51d712fd947d51eeef23
This new module allows easy exchange of osmo_prim based data types over
IPC communication (UD socket supported only so far), by replacing the
osmo_prim_hdr struct with a serialized header when submitting/receiving
it from the IPC socket.
This patch introduces the server side of the UD socket, but the client
side can easily be introduced in the same file whenever needed.
Related: SYS#5516
Change-Id: I7cab15ac092e45a256c4f0bab11b3962df861044
This makes it easier to follow the general path selection based on
protocol type. It will also make it easier when we add new paths based
on socket domain.
Change-Id: Ia3e0f4407e00a2dac9ee885fe1cc1cb4b463898a
These value_strings are taken from existing private ones in
libosmo-sccp.git osmo_ss7.c, and are moved here in order to be
reused by other projects, such as osmo-hnodeb.
Change-Id: Ica6f01851fb94e31f4ef097494bb1b8a95597ba6
In the case of SCTP, an association supports now containing both IPv4
and v6 addresses.
Depends: libosmocore.git Change-Id I36d8ab85d92bba4d6adb83bc1875eb61094ed2ef
Change-Id: Ie6bb17a9af6ca21d5e350f9c9d2d74c97c5a00af
Some previous commit added some code to workaround some kernel ABI
unstabilities but forgot to add the code inside a conditional
preprocessor block.
Fixes: 157ad6d707
Change-Id: Ibee01222d8d11cf2520cdbd4d0d5bed6b72d2107
The for loop in osmo_amr_bwe_to_oa, that converts the body part of the
AMR payload runs one byte too far. This may cause that some of the
padding bits in the end are not set to zero. The loop is designed to
convert n-1 bytes and the nth byte is done separately at the end.
Change-Id: I91e755b83aaac722079879c026d913cc446812d1
Size of a single AMR frame doesn't always shrink by a byte when
converted from octet-aligned to bandwidth-efficient mode. It does
shrink for AMR modes 2, 3, 4, 6, and 7 but doesn't shrink for
AMR modes 0, 1, 5, and SID frames because we only remove 6 bits.
So old code generated truncated AMR packets for those AMR modes.
This patch fixes the length calculation by properly counting bits.
Proper bit counting is also bringing us one small step closer to
properly handlig multi-frame AMR packets.
Change-Id: I0462e054a0adc9080456f3eeea9cab7c229cdb70
This reverts commit 002a51e218.
Reason for revert: amr_test fails with sanitizer build:
Sample No.: 6
bw-efficient: a7bfc03fc03fc03fc03fc03fc03fc03fc03fc03fc03fc03fc03fc03fc03fc03f
1010011110111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111110000000011111111000000001111111100000000111111
../../../src/libosmo-netif/src/amr.c:63:24: runtime error: index 15 out of bounds for type 'size_t [9]'
../../../src/libosmo-netif/src/amr.c:63:24: runtime error: load of address 0x7f69498e56b8 with insufficient space for an object of type 'size_t'
0x7f69498e56b8: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 5f 00 00 00 00 00 00 00 67 00 00 00 00 00 00 00 76 00 00 00
^
=================================================================
==489935==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f69498e56b8 at pc 0x7f69498abec7 bp 0x7ffeafb35330 sp 0x7ffeafb35328
READ of size 8 at 0x7f69498e56b8 thread T0
#0 0x7f69498abec6 in osmo_amr_bytes ../../../src/libosmo-netif/src/amr.c:63
#1 0x7f69498ac661 in osmo_amr_bwe_to_oa ../../../src/libosmo-netif/src/amr.c:193
#2 0x5648b11afb96 in osmo_amr_bwe_to_oa_test ../../../src/libosmo-netif/tests/amr/amr_test.c:134
#3 0x5648b11af31d in main ../../../src/libosmo-netif/tests/amr/amr_test.c:235
#4 0x7f6948d5de0a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26e0a)
#5 0x5648b11af3d9 in _start (/n/s/dev/make/libosmo-netif/tests/amr/amr_test+0x43d9)
0x7f69498e56b8 is located 8 bytes to the left of global variable 'amr_ft_to_bits' defined in '../../../src/libosmo-netif/src/amr.c:32:15' (0x7f69498e56c0) of size 72
0x7f69498e56b8 is located 48 bytes to the right of global variable 'amr_ft_to_bytes' defined in '../../../src/libosmo-netif/src/amr.c:44:15' (0x7f69498e5640) of size 72
SUMMARY: AddressSanitizer: global-buffer-overflow ../../../src/libosmo-netif/src/amr.c:63 in osmo_amr_bytes
Change-Id: I8232521c513722435e71dc90bdbfee10f8f83496
Size of a single AMR frame doesn't always shrink by a byte when
converted from octet-aligned to bandwidth-efficient mode. It does
shrink for AMR modes 2, 3, 4, 6, and 7 but doesn't shrink for
AMR modes 0, 1, 5, and SID frames because we only remove 6 bits.
So old code generated truncated AMR packets for those AMR modes.
This patch fixes the length calculation by properly counting bits.
Proper bit counting is also bringing us one small step closer to
properly handlig multi-frame AMR packets.
Change-Id: I9fc5fb92e9bada22a47a82fcfb0925e892e50ced
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: I269690c1c9e4d19b5b69eef206b95e71f7931188
It makes a lot more sense calling it this way since it matches the state
of the stream at that point.
Change-Id: Ic02aec3f7f095e0e0e1f940425f577be5048e98f
It's not really needed right now from logic point of view, since we
reused NONE for that. But it makes logging and logic clearer, and will
make it easier if we decide to move it to FSMs at a later point in time.
Other state value_string names are also modified with its whitespace
removed since anyway we'd need to change them to match WAIT_RECONNECT
length. Let's drop the space because imho it's not that useful and
anyway if we move to FSMs at some point then we won't have them anyway.
Change-Id: I7b9a6da87081c418b0d14bab5f34369c5eca6fe8
With previous state, osmo_stream_cli_close() could be called from
osmo_stream_cli_open()(), and in that case state was kept as NONE while
ending up with an associated fd being registered in the select loop.
As a result, osmo_stream_cli_fd_cb() could be called while in state
NONE, which was not expected and would simply return without modifying
fd state flags, causing it to be called again and again.
Related: OS#4378
Change-Id: Ie3342f882893a71ad1538c17ad9ee9fa4433eaa4
It should not happen anyway because no fd should be active if state is
NONE, but still it's an extra check.
Change-Id: I6d58762b7d10078eb8d0981c13d35cb6f85cfe86
Similar to what we do in libosmocore already, we want to
deterministically enable or disable support for the feature without
having into account if the system has a libsctp. If libsctp is missing
and support is enabled, then fail.
Extra checks are also added:
* Check netinet/sctp.h header
* Check libosmocore was built with libsctp support (API
osmo_sock_init2_multiaddr() we require).
* In stream.c make sure it can be built without HAVE_LIBSCTP, and that
set_addrs() fails for more than 1 address (since that feature is only
supported through osmo_sock_init2_multiaddrs()).
Change-Id: I4b3e1f1894f13ac1175a71a5139c02a2633be26d
This API will be later used to set multiple addresses for SCTP sockets.
Depends: libosmocore.git Ic8681d9e093216c99c6bca4be81c31ef83688ed1
Related: OS#3608
Change-Id: I09f0d989f2309abdeb304fe570355abed2cd107b
This API will be later used to set multiple addresses for SCTP sockets.
Depends: libosmocore.git Ic8681d9e093216c99c6bca4be81c31ef83688ed1
Related: OS#3608
Change-Id: I0fe62f518e195db4e34f3b0ad1762bb57ba9d92a
It seems different compiler versions (jenkins and my workstation) are
generating different line number for that message, and it makes osmux_test
fail when improving logging on next commit.
Change-Id: Ie2bb0ecf4cc165b9a1080e2558b33ba37014278c
If messages are sent using osmo_stream_cli_send() while the stream
is still (re)connecting, they won't have a chance to be sent until the
stream is connected, and hence they are queued until
CONNECTING->CONNECTED is done. However, at that time
(osmo_stream_cli_fd_cb), the WRITE flag was dropped unconditionally,
which meant already queued packets didn't have the opportunity to be
sent by the same callback until first message is enqueued and WRITE flag
is set (again by osmo_stream_cli_send()).
Let's make them be sent as soon as possible once the connection is
available.
Related: OS#4188
Change-Id: I289495f9aad6389c5f2623fb072d676235b7d24c
Previously payload_type was always hardcoded to 98 for generated rtp
packets from incoming osmux frame.
Change-Id: I5cbeb494a8932953d9fd2dc24dacf8cd97fd84e4
The header of an AMR header payload is 2 bytes long. At the moment we
use just a constant of 2 when we refer to the header length, but we have a
struct amr_hdr defined. Lets use sizeof(struct amr_hdr) to make it more
clear that we are refering to the header length.
Change-Id: Ic7ca04b99a97d7d3b91717b0c3e6c55ef3001a3e
This supposed to be variant of osmo_stream_cli_open() with explicit
control over reconnection logic but it's plain broken: doxygen docs
contradict the code, actual reconnection logic is affected by timeout
parameter directly which is set in different function.
It seems like we haven't been affected by this so far because we always
use it in auto-reconnection mode which is triggered by default due to
positive reconnection timeout value (5 sec) automatically used in the
absense of explicitly set timeout.
Looking at commit history, this function already been source of
confusion in the past. Instead of trying to fix this mess, let's just
deprecate it entirely and properly document use of
osmo_stream_cli_set_reconnect_timeout() to control reconnection logic.
The only known user is libosmo-sccp which won't use it as of
0a93a683f3cb8e5977eb4a666ab207db6e7d7af9 commit.
Change-Id: Id988ed0274b363db049f59cbf6a193727c8c3c8a
osmo_amr_bwe_to_oa() uses an internal buffer with static size to store
intermediate results. The buffer is large enough for any real world
situation, but the check that tests if the result would fit into the
internal buffer is incorrect. It checks if there is enough room for the
existing payload, but does not include the expected growth of the
payload. Eventually the buffer could be overrun by one byte if one would
put a 256 byte long AMR payload.
Fixes: CID#195926
Change-Id: I4d7ac570a0b48368a82183673c46bca5f235f228
RFC 3267 describes two different AMR frame formats. Octet Aligned and
Bandwidth efficient mode. In Bandwith efficient mode the padding bits,
which are used to align CMR, TOC and payload on octet boundaries are
saved and the fielda are packed directly one after another.
- Add functions to convert from one mode to the other and vice versa.
- Add function to detect in which mode an AMR frame is encoded.
Change-Id: I5b5a0fa644d8dbb1f04f9d7e35312683c7b3d196
Related: SYS#4470
AMR uses different payload sizes, those sizes are well defined in RFC
3267. Lets add define constants and replace the magic values with the
define constants.
Also correct the value for AMR_FT_SID in amr_ft_to_bytes from 6 to 5
(39bits / 8 = 4.875 bytes ==> 5 byte, see also RFC 3267, chapter 3.6)
Change-Id: I65b5da920d58015b875d6dcf17aacdc04b58955e
Previously closing the client did not alter its state, so we might
end-up with a client without any file descriptors, but being in state
STREAM_CLI_STATE_CONNECTED. Fix this inconsistency by setting
appropriate state.
Related issue is that reconnect function, which is always (at least in
the library and examples) called when some problem with the connection
is detected, closed the connection only after checking whether
reconnection is enabled. This might result in another inconsistency
fixed in this patch by moving the check below connection cleanup.
While at it, also move connection close logging to appropriate place:
it's confusing to see logs about connection being closed while in
reality it wasn't even established.
Change-Id: If41ed60bd625488c283d1e8a2b078e640f04c78e
Add functions to get the description of a server link or client
connection which examine data on corresponding socket.
Those functions use static buffers and intended for single use in
log/printf statements as illustarted by corresponding example changes.
Change-Id: If9a8e211da85956781479862a63c4fc6e53ed6be
Introduce logging macro wrapper to properly log current client state and
function to aid in debugging.
Change-Id: Ie22a80dcec95998cce0b25053fdf74f23eab6e53
While we are processing a read event, the connection's
callback might free the connection. Check for this and don't
attempt to process further events on an already freed connection.
Change-Id: I0a9c7d8e3263c73440f7084dbb1792a4ca5038f0
Related: OS#3685
Depends: g#11704 (for libosmo-sccp)
The recently-introduced dependency to libosmogsm symbols needed
some explicit addition of linker flags to avoid user applications
to fail linking with
/usr/bin/ld: /usr/local/lib/libosmonetif.so: undefined reference to `ipa_ccm_id_resp_parse'
Change-Id: I07a28f8970b90f82736e2de783bafc9d2c5ea0e5
In libosmocore Change-ID I1834d90fbcdbfcb05f5b8cfe39bfe9543737ef8f
we have introduced ipa_ccm_id_resp_parse() as a bugfixed replacement
of ipa_ccm_idtag_parse().
The main difference is that the returned "value" parts now have
a correct reported "length", whereas before this commit they all
reported a one-byte too-long "length" for each IE.
Let's use this opportunity to remove the copy+pasted
osmo_ipa_idtag_parse() function from the libosmo-netif codebase.
Change-Id: I4626d247626543e032593bf226b6c233f6678562
When establishing a client-side stream connection via libosmo-netif,
we must using non-blocking connect if we want to avoid blocking/stalling
the entire process. The libosmocore socket API provides the
OSMO_SOCK_F_NONBLOCK flag for this. Make use of it!
Change-Id: I9bfcb39b5801a36ef32ca0d1f3eb8236687d7ed6
Related: OS#3383
The "channel" layer on top of IPA client + server was introduced in
2011 but never used in any osmocom program/project so far. Contrary
to the several other IPA multiplex related implementations in libosmo*,
it did not deal properly with segmented IPA messages, i.e. where a
single TCP segment (and hence recv/read call) does not contain a full
IPA message.
So rather than fixing it up and having yet another IPA related API in
our libraries, let's remove it.
Change-Id: I97c378750acb1637ee032fa88a968edf68d8979f
This message is expected as all code filling batches call
osmux_batch_enqueue() and checks for error to know if it must tell the
user of the lib to call osmux_xfrm_input_deliver.
Change-Id: I3d8227f2281f6ca92fd2502d3e328765dc7ecfe9
In Change-Id: I2efed6d726a1b8e77e686c7a5fe1940d3f4901a7 we're adding a
new member to 'struct osmux_out_handle' which is not initialized.
Rather than initializing this single new member, let's do a memset()
over the entire osmux_out_handle at the beginnign of
osmux_xfrm_output_init().
Change-Id: I751e9414c6de2413a9f977e5ae5655ebfd114f45
Closes: OS#3219
Until this patch, we didn't notify in any way to the RTP reader when an
Osmux frame was lost. Instead, we updated the seq×tamp as if there
was no lost, and as a result the RTP reader would only see a steady
increase of delay every time an osmux frame was lost.
As the batch_factor for the lost packet is unknown, we cannot assume any
number of amr payloads lost, and thus we cannot simply increment seq and
timestamp for a specific amount. Instead, the only viable solution seems
to set the M marker bit in the first rtp packet generated after a
non-consecutive osmux frame is received.
The implementation may act differently with the first generated RTP
packet based on the first osmux seq number used for the stream. In case
0 it's used as first osmux seq number, M will be set depending on
request from original RTP packet having the M bit set. If it's not 0,
the first RTP packer will unconditionally have the M bit. That's not an
issue because it's anyway expect for receiver to sync on the first
packet.
Related: OS#3185
Change-Id: I2efed6d726a1b8e77e686c7a5fe1940d3f4901a7
With old implementation, in conditions with jitter we could end up
scheduling RTP generated packets from two consecutive osmux frames in an
interleaved way (from seq field point of view).
This new implementation should make it easier for any RTP
reader/playback to have better results in those conditions.
Old APIs osmux_xfm_output and osmux_tx_sched are marked as deprecated in
favour of the new one, which has a better control of generated RTP
packets. However, they are still usable despite the implementation changes
done to support the new API.
Related: OS#3180
Change-Id: I4e05ff141eb4041128ae77812bbcfe84ed4c02de
Pau Espin
Max
Philipp Maier
Harald Welte
Vadim Yanitskiy
Neels Hofmeyr
Sylvain Munaut