Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Iabfa9a706c6456bf554ba59badbc3cbfc9210423
|
|
Fixes: CID#205089, CID#205087
Change-Id: I65714f214b9962862cda01605c7c2c578c78d3c7
|
|
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
|
|
Change-Id: I03b05179f5656ab81e5e14cd146f82a471f7b071
|
|
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
|
|
Change-Id: I1ef73807c3300cbcc332f32e6bb905d9b30557be
|
|
Change-Id: I7acaba9429466db6cb5700b206d6b42da5e4627a
|
|
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
|
|
Can be used by users to fetch current status of the stream.
Change-Id: I5402430e5f39eef22dfa18f33807ab6b1e771f1b
|
|
Change-Id: I3af3b7aaff5c6dc3ac94e942191e27af4bf5392a
|
|
Previously payload_type was always hardcoded to 98 for generated rtp
packets from incoming osmux frame.
Change-Id: I5cbeb494a8932953d9fd2dc24dacf8cd97fd84e4
|
|
Change-Id: Iea2da939e259d0a9e7c5dad14d7a961434c276ef
|
|
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
|
|
Change-Id: Ie4ad6b1a2382da4dc21e66a45c2a96224cab5752
|
|
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
|
|
It's similar to connect_cb() but called once client has been
disconnected.
Change-Id: I905adb2d6191216551a3bcdcd1aec1f96f01612a
|
|
This helps to avoid unnecessary debug output in reconnection logic tests
in follow-up patches.
Change-Id: Ic96430a9e9294e72de23b0bbacdbf3e99a453f1d
|
|
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
|
|
Change-Id: Ic45d3e0520db4060c5c24e5ef5a766a52f060a34
|
|
Change-Id: I99a3244f922382468251df675287520ca40d9d0d
|
|
Change-Id: I5dcae1f19e18f04709ce7585943af1d582ebc7ed
|
|
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)
|
|
Change-Id: I3cb356a4a13d53e7f88a5e4595899bb2eb510d20
|
|
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
|
|
Change-Id: I2f3b7888acb4f25da22ffef4391e1d0831485483
|
|
Change-Id: Ic9bbe8427c44ef2a9ee02537f17821048f177cdd
|
|
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
|
|
Fixes: OS#3262
Change-Id: Ib8c61dbe6261cf73d6efcd7873e23b7656117556
|
|
Change-Id: Ic8a9e44b2f930fed024040777eab58699fdcaadc
|
|
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
|
|
Change-Id: Ifae633d53107417a8e2f9b0f200d2711db72d199
|
|
Change-Id: I33556b33d7549654442d9bdd7f31128792506652
|
|
Change-Id: Ie142acfb45650e0af775f58226fd191beaf8178e
|
|
Change-Id: I9688ba9c4d5b733b9f29d0f15f73750f9271ef55
|
|
Change-Id: I143805bb5ee9f5e3ada46114e380a03ede80df9f
Related: SYS#4182
|
|
Documentation of osmo_sock_init2 doesn't provide information of any
specific value of errno set/expected after running the function. It is
incorrect to expect a specific value of errno and looking at the
implementation it is actually not a good idea to check it.
If reconnect flag is set, let's reconnect always instead of looking at
errno to decide.
Change-Id: I25b33f4cdc496ae31ff240d445b9b2805091845c
|
|
Change-Id: I77f4593941207689f714d15304dcce40b21d4bd8
|
|
Introduce osmo_stream_srv_set_flush_and_destroy() which marks a
stream to be 'flushed and destroyed'. No new messages will be
received on this stream, and no new messages can be queued.
Once the Tx queue has been drained, the connection is destroyed.
The API user is given a chance to perform cleanup operations
in the closed_cb() callback for the connection.
The same mechanism will be added for client-side connections
in a follow-up patch.
Change-Id: I8ed78fe39c463e9018756700d13ee5ebe003b57f
Related: OS#2789
Suggested-by: Harald Welte
|
|
On destroying a client or server stream, deallocate any msgbs that are still
pending in the queue.
In libosmo-sccp, the ss7_test.c in test_as(), messages are queued and were,
before this, left floating after the stream was destroyed, causing a sanitizer
memory leak. This patch fixes the leak.
Depends: Ia291832ca445d4071f0ed9a01730d945ff691cf7 (libosmocore)
Change-Id: Iaad35f03e3bdfabf3ba82b16e563c0a5d1f03639
|