As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: If9aa8a066d81cf378d6bbc0fa95ad6e985408af8
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
This check was added during libosmo-netif's initial commit, and there's
nothing requiring DAHDI in here. It's most possible a copy-paste
artifact when creating configure.ac.
Change-Id: Ief25a12696d797eaf50b0373e8310add93b9dc9e
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
I will soon apply struct_endianess.py to this code, and then the comments that
are now only in the big endian part would be lost. Copy them to preserve them.
Change-Id: Ie4279928bd77a5d425d0e7a3c4d58bac3cf0230a
osmux implementation randomizes those values. It seems build in OBS
sometimes provide different values than the ones expected in the test
result. Let's hardcode them to make sure we always have the same values
regarless of the random() implementation.
Values chosen are the one matching the current expected test output so
it doesn't need any change.
Change-Id: Icc553c83ddff41900ae3d5990a655c29c9073e01
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
Currently osmux related code uses both gettimeofday on some parts and
clock_gettime(CLOCK_MONOTONIC) on others (for different purposes).
Let's fake both clocks and not only the one used by gettimeofday API.
Change-Id: I4e1a0eb4f8c4ea1bc0f963afa18b116d3af9978c
It allows easy verification that timing is correct and makes it easier
to debug time related race conditions.
Change-Id: I86eb1d7a8096011fd273f067255eb8d6484be65c
By using fake own-controlled time we get two benefits:
* Test doesn't take 9 seconds to run anymore
* More fine-grade control of different events happening (and associated
race conditions).
Change-Id: I16b2884b289bfe40dfb8d743dce01bb4c208d117
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
Fix a symbol lookup error when building a new test on systems where
a previous libosmonetif.so is installed. Symptoms described here in
detail: https://osmocom.org/issues/3812#note-10
-no-install causes libtool to generate output files that link against
libraries in the build tree, instead of linking against the future
installation paths and generating a wrapper script. The wrapper script
should override the library paths, but at least on Debian, it does not
work as it should. Test binaries won't be installed anyway, so we can
safely use -no-install and work around the problem.
See also:
https://autotools.io/libtool/wrappers.htmlhttps://www.gnu.org/software/libtool/manual/html_node/Link-mode.html
Related: OS#3812
Change-Id: I94ccff42dfba71aaf59bb30ca312db0bac58c27d
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
The debian packaging wants to execute "make check" which in turn
wants to build the jitterbuffer tests, which in turn require pcap.h
to be present, which is provided by libpcap0.8-dev.
Closes: OS#3818
Change-Id: Iab471de9fb276a436332241337539eab544f965a
Previously stream client and server code were only used in examples
which means regressions could be easily introduced unnoticed until they
trigger bugs in external code which relies on osmo_stream_*()
Fix this by adding basic client-server interaction tests with and
without reconnection.
Change-Id: I336f79970982ed8e1d73b73d54fa4c27ba8bce8e
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
Eric Wild
Pau Espin
Neels Hofmeyr
Oliver Smith
Harald Welte
Philipp Maier