Not having a second leg of an MGCP endpoint is a normal situtation
and can't be treated as an ERROR message, especially not as an ERROR
message logged on every RTP packet. This happens routinely at
the beginning of call setup and we get tens of ERROR messages in
the logs for every call.
Change-Id: If741a742208772bda4e59236345d7ae650368d5a
New define is available since libosmocore 1.1.0, and we already require
1.1.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: I9b6463af713f76c06a144bdbf202c0d91eef4d21
Right now a lot of errors with MGCP processing are invisible in rate
counters which makes them difficult to trace or even notice in
a production environment. E.g. reaching a limit of MGCP endpoints
is completely invisible even though it's a critical opertion alarm.
Change-Id: I6db68f044255c927dfd534fed880e405ec3ed4d6
Before this patch rate counters started right after trunk information
with no visual separation which was quite confusing. We're adding
a new line and a header to warn a user of the section change.
Change-Id: I3943def03ab821b05ac597f40bdfa4a3a71ddca3
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: I2314ef45e6f588e88d5aab8213cc7b5cdef11325
The example config bind the MGW to a random ip-address, lets use the
loopback address here, this will suit cases where osmo-bts runs on the
same machine as the MGW (nitb). For all other cases were an external BTS
is used the ip-address still needs to be changed.
Change-Id: Iae52c671c48953ea6b52b18c5d77347343cde0df
Enlarge the MGCP client workqueue maximum limit by factor 100.
During Abis load testing, a BSC trying to DLCX 200 conns at the same time hit
the limit of 10 very very quickly, and everything broke down.
Change-Id: I8980cce37bae0757828b28455b25c77bcb6316d0
We used to update only the per-connection rx/tx packet/byte counters
on-the-fly, but not the per-trunk global counters. The latter would
only be updated at the end of a connection. As MGCP connections
can last quite long (think of a long phone call) this is maybe
not the best of ideas.
Note: The all_rtp:err_tstmp_in and all_rt:err_tstmp_out are still
only updated at the end of a connection.
Change-Id: Ib3866cb8149d3257fcf39733846c97c33881c4ee
Related: OS#4437
OsmoMGW has a lot of nice built-in statistics (rate_ctr,...) but it
seems the only way to look at them is via the VTY. While libosmocore
contains automatic exposure of all rate counters via CTRL, the CTRL
interface simply is not used by osmo-mgw so far.
Closes: OS#4441
Change-Id: I7ed6bdb9f4749c24ca11a5905a620546cfe42952
If a config file doesn't have a 'number endpoints' config line,
we would use -1 as unsigned integer and end up with
number endpoints 4294967295
if the config file is re-written
Change-Id: I05a3814117b1d6e0cdc30740da31709ce333df4b
Closes: OS#4034
libosmocore required version increased due to include used from
libosmo-netif including an include from libosmocore which in previous
versions misses including an include from a symbol used.
Change-Id: I1d5f14b1ad36b2ed94343fca71fdc622424403d3
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I48f4c2c520e8285aff5d6d65f95bd041c13466e8
This way we can avoid the runtime overhead of checking whether or not
it is initialized over and over again. It also brings this code more
in line with other users of osmo_fsm_register().
Change-Id: Ia73ba8e46c13d925e88203e08a8966839e573183
API doc: require osmo_fsm_set_dealloc_ctx().
mgcp_client during delete: do not reparent the FSM when it is already
terminating.
I have recently discovered a vulnerability: if an endpoint FSM deallocates
during event handling of a successful MGCP response, this causes a
use-after-free; and once that is fixed, a state change on the already
terminated FSM causes a pointer corruption by using already cleaned data
structures. osmo_fsm_set_dealloc_ctx() fixes the use-after-free, and
osmo_fsm_set_term_stops_actions() fixes the pointer corruption.
Related: Ib7fce7b7d54dfb87af97544796680919e5929a50 (osmo-bsc),
I08c03946605aa12e0a5ce8b3c773704ef5327a7a (osmo-msc)
Depends: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78 (libosmocore),
I0adc13a1a998e953b6c850efa2761350dd07e03a (libosmocore)
Change-Id: I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3
SDP is an optional part of MGCP messages. Do not fail when there is no SDP part.
Practically this is useful to compose simpler MGCP responses from TTCN3 tests.
osmo-mgw itself always includes SDP, so there is no real impact on operating
libosmo-mgcp-client with osmo-mgw from osmo-bsc or osmo-msc.
Change-Id: I608001626459ea72415fb142f857550bbb90c683
If an API user only has access to the ci FSM (which is managed via an opaque
struct), provide this function to obtain the backpointer to the parent endpoint
FSM, mostly to be able to call osmo_mgcpc_ep_cancel_notify() on it.
osmo-msc's rtp_stream FSM will use this in
I351bb8e8fbc46eb629bcd599f6453e2c84c15015.
Change-Id: I14f7a46031327fb2b2047b998eae6ad0bb7324ad
There is a use-after-free problem if a 'notify' FSM as passed to
osmo_mgcpc_ep_ci_request() deallocates before the notify event has been
dispatched. To avoid that, add API to allow cancelling a notify.
Change-Id: I41687d7f3a808587ab7f7520f46dcc3c29cff92d
In case the ep gets deallocated during event dispatch, move all ci[] cleanup to
*before* dispatching a DLCX OK event. Afterwards, it might become a
use-after-free.
Change-Id: Ib2032e5566e465c02a9a525ccd38f9dcc84fb669
Upcoming patches introduce copying notify information. Prepare by combining
notify info into a separate sub-struct.
Change-Id: I47c0dd112011b8cb4dc88e8efd010466d4ba6308
If an MGCP operation on one conn of an endpoint fails, no longer carry out
other pending requests for that endpoint. Only allow pending DLCX to be sent.
If the caller schedules two CRCX at the same time, the first CRCX is sent with
a wildcarded endpoint name like "rtpbridge/*@mgw". Only when the OK for that
returns an allocated endpoint, will the second CRCX be sent, using that actual
allocated endpoint name. But, if the first CRCX fails, then we should not send
another wildcard CRCX, but rather assume both as failed.
Since a failed MGCP message means that the endpoint becomes unusable /
undefined and typically deallocates directly, we can actually discard all other
pending requests except for DLCX.
Change-Id: Icb1d485224bb486b84eff6329f0bd95932e63246
During FSM instance cleanup, a DLCX message composition may fail if a preceding
received MGCP message was missing parameters. If that occurs, don't crash, just
log an error and deallocate.
Change-Id: Ic1c3c4deeb4703b60e870af9d5d7be216a87fff8
Currently in handle_create_con(), mgcp_conn_alloc() is called with NULl
ctx. As soon as this ctx is changed to be part of the trunk's endpoint
array (tcfg->endpoints), test will segfault because some fds from
previous tcfg are still registered after the whole tcfg object was freed
with talloc_free() by previous test. That's because
mgcp_endpoint_release() must be called on all endpoints to make sure all
registered components are correctly unplugged.
Related: OS#3950
Change-Id: I813d52b518ed0bb8db4e42dff83e040b0891fee2
If a ptmap appears in the SDP, always store it in the ptmap array. No longer
attempt to drop entries if they match the conventional payload type number.
- One reason is that the past code only matched full explicit "FOO/8000/1"
strings, while the channel number "/1" can be omitted to imply 1; by simply
storing everything received in the SDP, there is no need to add complexity
to match both "FOO/8000" and "FOO/8000/1".
- The other reason is to rather parse exactly what was received, instead of
filtering entries, to take away a degree of implied magic.
Change-Id: I2a69c21e68c602daf804744212d335ab1eafd81b
- move the error logging up to the actual errors. Each appear only once, no
goto labels needed.
- instead of strstr("rtpmap"), use osmo_str_startswith("a=rtpmap:") to more
concisely trigger on the actual syntax of the audio parameters. Same for
"a=ptime:".
Change-Id: I730111e245da8485c1b5e8811f75d140e379cec6
There are allocated bits in conn->end.codecs[], free them.
This is not fixing a memleak, since mgcp_rtp_conn_cleanup() is currently only
called from mgcp_conn_free(), which soon after frees the conn; the conn serves
as talloc parent for the codec strings freed in this patch.
The rationale: it is better style to explicitly free them, to also guard
against future callers of mgcp_rtp_conn_cleanup() which might expect complete
cleanup.
Change-Id: Ic471107ce6e94d9ce582d887429c744ff93e3053
In codec_set(), for each 'goto error', log the specific error cause.
Also add a TODO and a FIXME comment about inventing dynamic payload type
numbers.
Change-Id: I0b44b574c814882b6f8ae7cd738a6f481cd721fd
In codecs_same(), do not compare the complete audio_name. The parts of it are
already checked individually:
- subtype_name ("AMR"),
- rate ("8000"; defaults to 8000 if omitted) and
- channels ("1"; defaults to 1 if omitted)
So by also checking the complete audio_name, we brushed over the match of
implicit "/8000" and "/8000/1", which otherwise works out fine.
As a result, translating payload type numbers in RTP headers now also works if
one conn of an endpoint set an rtpmap with "AMR/8000" and the other conn set
"AMR/8000/1".
It seems to me that most PBX out there generate ptmaps omitting the "/1", so
fixing this should make us more interoperable with third party SDP.
See IETF RFC4566 section 6. SDP Attributes:
For audio streams, <encoding parameters> indicates the number
of audio channels. This parameter is OPTIONAL and may be
omitted if the number of channels is one, provided that no
additional parameters are needed.
Also allowing to omit the "/8000" is a mere side effect of this patch.
Omitting the rate does not seem to be specified in an RFC, but is logical for
audio codecs defined to require exactly 8000 set as rate (most GSM codecs).
Add tests in mgcp_test.c.
Change-Id: Iab00bf9a55b1847f85999077114b37e70fb677c2
Instead of manually entering codec values, use mgcp_codec_add() to populate
test conns with codecs. The idea is to better test what actually happens when
parsing SDP codec strings.
Rewrite current test_mgcp_codec_pt_translate() from procedural to a data model
with human readable stdout logging.
This prepares to enable interpreting codec strings like "FOO/8000/1" as
equivalent with "FOO/8000": the SDP standard defines the final "/1", indicating
the nr of channels, as optional for a single channel, but osmo-mgw currently is
unable to match these two formats as identical. So prepare the
test_mgcp_codec_pt_translate() so that upcoming patches can incorporate strings
with and without the final "/1" by extending the struct arrays.
Change-Id: I888000d77512cfecb0f199b86ef6003e7fc0e6cb
The audio_name and subtype_name are allocated from talloc, so they need to be
freed before resetting the codec array. Use mgcp_codec_free() to ensure this.
Change-Id: I07f207dcb7ce66bbf3445a30af41e696677b384f
Both are used only in the same .c file, so make them static.
Move codec_set() guts into codec_add(): codec_set is only called by codec_add.
If codec_set were left separate, it'd look like the codec_init() is a bug and
lacks a codec_free() first. When looking at the entire context in codec_add(),
it becomes obvious that codec_init() should be called, not codec_free(),
because it is populating a previously unused entry.
Preparation to fix a memleak in a conn's codec list.
Change-Id: I120cab0a352a1e7b31c8f9c720c47b2c291311d7
If mgcp_send() runs a transcoder loop, break the loop if rfc5993_hr_convert()
or amr_oa_bwe_convert() return with error. Possibly fixes an infinite loop
situation for erratic packets? (Didn't check for that in detail.)
Change-Id: Iba115a0b1d74e7cefba5dcdd777e98ddea9eba8c
Remove various OSMO_ASSERT() on size of incoming packets. Doing an assert on
incoming data is a DoS attack vector, absolute no-go. Instead, return -EINVAL
and keep running.
Change some return values to be able to distinguish successful operation from
invalid RTP sizes. In rtp_data_net(), make sure to return negative if the RTP
packet was invalid.
Some of the error return codes implemented here will only be used in upcoming
patch Iba115a0b1d74e7cefba5dcdd777e98ddea9eba8c.
Change-Id: I6bc6ee950ce07bcc2c585c30fad02b81153bdde2
The name 'cmp' implies a return value of -1, 0, 1 to indicate smaller, match or
larger. Since this function returns bool, it should not be named with 'cmp'.
Change-Id: I2d41b1a32300e295551e85d3f9ab82dd2b0e86b8
Current code uses APIs like osmux_xfrm_output_init2() and osmo_amr_*(),
that are only available in libosmo-netif 0.6.0 onwards. Let's update
configure.ac accordingly.
Change-Id: I3bc0196bb6b5c5e5cf96935422fd56c4582ed7f5
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Icf4d18969488c9eacca7a597d4071828e649e772
Related: OS#4138
Return variable specified by strtoul() is "unsigned long int". If
"unsigned int" is used, according to Coverity the return value can never
be ULONG_MAX:
CID 202173: Integer handling issues (CONSTANT_EXPRESSION_RESULT)
"pt == 18446744073709551615UL /* 9223372036854775807L * 2UL + 1UL */" is always false regardless of the values of its operands. This occurs as the logical second operand of "&&".
Furthermore, PT is 7 bit in RTP header [1], so let's avoid accepting
incorrect values.
[1] https://tools.ietf.org/html/rfc3550#section-5
Fixes: c5c1430a1c ("Catch unsigned integer MGCP parsing errors with strtoul")
Fixes: Coverity CID#202172
FIxes: Coverity CID#202173
Change-Id: Ice9eee6a252fab73dbab5ebf3cfc83c1b354fd08
Kirill Zakharenko
Pau Espin
Eric Wild
Philipp Maier
Harald Welte
Oliver Smith