stream.h uses msgb from libosmocore without corresponding #include
It's odd that we haven't hit this issue earlier.
Change-Id: Ib8b4f4965af0fefa7dac3f2a56a5a4b76a03fd57
Stream server example had an error which resulted in infinite loop on
client disconnect. Fix this by properly handling client closing
connection to allow it to reconnect multiple times.
Change-Id: Icfc2cf7f971b9e3a4abc34cc18d8a44c811c5617
Set category filter to make sure internal library logging won't
interfere with example's own logging. It's also nice example
illustrating log_set_category_filter() usage.
Change-Id: I17d7878d302f011d8ff0d86708d677f5b559299e
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 .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: I8915ebbf7d3a64a9474e1aeb49b1d192a388ef53
Related: OS#3449
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
This test is aimed at testing several specific scenarios related to how
osmux manages in/out of osmux/rtp packets over time.
Change-Id: I3bf59276424ea87c4e66a6ff46de1e3e9a06a904
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
pcap/dlt.h only exists on newer versions of libpcap. On older versions,
same defines are available in pcap/bpf.h, which in newer versions
include pcap/dlt.h, so we are always fine include pcap/bpf.h.
As a side note, there's a lots of comments in pcap/dlt.h stating that
those symbols used to reside in pcap/bpf.h but were moved there at some
point.
Change-Id: I824671a415eb3f35f480c934b9780ff13510011a
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
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: I68e4781ec5dfaf1dac46510a092a87e35691f082
In the previous implementation, the processing time was not being taken
into account, which was implicitly added for each new packet to be sent,
which caused a steady incremental drift in the clock clearly visible
when analysing a RTP stream.
As it uses timespecsub, it depends on libosmocore Change-Id
I45fc993b9bb0a343763238bf463c8640f47b00f1.
Change-Id: I11cb9a63e16e829ccd4af1096b9f473c802d822f
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
Max
Harald Welte
Pau Espin