The test that tests the cancelation of a pending mgcp message
uses an integer as connection identifier, which leads to a
segfault since connection identifiers are represented as strings.
Use a string as connection identifier.
Change-Id: I395a23c1828cf216031d69d481ad35dd458ee7d4
So far, if an MGCP message is sent, the transaction gets enqueued, but there is
no way to end the transaction other than receiving a valid reply. So, if the
caller decides that the transaction timed out and tears down the priv pointer
passed to mgcp_client_tx, and if then a late reply arrives, the callback will
dereference the invalid priv pointer and cause a segfault. Hence it is possible
to crash an mgcp_client program by sending a late response.
Furthermore, if no reply ever arrives, we would keep the pending response in
the list forever, amounting to a "memory leak".
Add mgcp_client_cancel() to discard a pending transaction. The caller can now
decide to discard a pending response when it sees fit (e.g. the caller's
timeout expired). This needs to be added to OsmoMSC and OsmoBSC.
Add mgcp_msg_trans_id() to provide an obvious way to obtain the transaction id
from a generated MGCP message.
No public API is broken; but refine the negative return code from
mgcp_client_rx(): return -ENOENT if no such transaction ID is found, and still
-1 if decoding failed. This is mainly for mgcp_client_test.
Implement a test for mgcp_client_cancel() in mgcp_client_test.c.
Tweak internal mgcp_client_response_pending_get() to take only the transaction
id as argument instead of the entire mgcp message struct.
Found-by: dexter
Related: OS#2695 OS#2696
Change-Id: I16811e168a46a82a05943252a737b3434143f4bd
OsmoMSC is in the odd situation that it is already using the new
libosmo-mgcp-client, which is targeted at osmo-mgw, to configure talking to the
old osmo-bsc_mgcp. By removing the bts_base, we break current OsmoMSC.
Removing bts_base makes sense, but let's revert this until OsmoMSC is ready
after merging Ieea9630358b3963261fa1993cf1f3b563ff23538 (which moves the
osmo-msc over to osmo-mgw).
This reverts commit 0be3ce66c0.
Change-Id: Ibce214c2bfc35623097abbb647619426ef3dcc94
The log prints the endpoint numbers as hexadecimal numbers, but
it does not prefix them with "0x".
Add "0x" prefixes to all endpoint number outputs in the log
Change-Id: I284627de02cd140a894445375e9152ff007a71e6
The MGCP connection identifier is allocated by the MGW while processing
the CRCX, see RFC3435 2.1.3.2:. Including/Accepting a connection
identifier in CRCX is "forbidden" as per RFC3435 Section 3.2.2.
So the MGW side must *reject* a CRCX message with 'I' parameter, and
allocate a connection identifier which is subsequently returned in the
response.
Closes: OS#2648
Change-Id: Iab6a6038e7610c62f34e642cd49c93d11151252c
The MGCP spec in RFC3435 is quite clear: Connection Identifiers are
hexadecimal strings of up to 32 characters. We should not print and
parse them as integers on either client or server.
Change the internal uint32_t representation of connection identifiers
to a string representation in the client and also in the server.
Closes: OS#2649
Change-Id: I0531a1b670d00cec50078423a2868207135b2436
There should not be any BTS base port to be configured at an MGCP client.
Possibly this is related to the legacy behavior of libosmo-legacy-mgcp, and
certainly has no place in libosmo-mgcp-client.
Further changes may be needed to follow up on removal of the BTS base port
concept, at least drop it from the VTY for now.
Change-Id: I36e46208d7b75611e5ade3c74d8e1c25870de511
The variable number_endpoints is used as a length indicator
for the array that contains the trunk endpoints at all times.
When osmo-mgw is startet up, the variable is set and osmo-mgw
will allocate the memory for the endpoints. However, it is
still possible to manipulate the variable via the telnet
interface. When the value is increased osmo-mgw might start
using unallocated memory at some point.
Store subsequent changes of number_enspoints in a separate
variable in order to write them to the config file. The
changes will then take effect after a restart.
Closes: OS#2632
Change-Id: I3994af016fb96427263edbba05f560743f85fdd4
mgcp_parse_config() uses a helper function allocate_trunk() to
perform the trunk allocation. This helper function only calls
mgcp_endpoints_allocate() and checks the return code.
Call mgcp_endpoints_allocate() directly from mgcp_parse_config()
Change-Id: Iefdc5b905d76d2cd97f26584261fe5cbefb699cf
osmo-mgw currently uses VTY port number constant of osmo-bsc_mgwp,
however, libosmore now offers a constant specifically for osmo_mgw,
which has the same value, but is intended to be used by osmo-mgw
use the new port number constant for osmo-mgw
Closes: OS#2628
Change-Id: I63c3b300cc9287d1755a3f2c5b5ade7fc6398f6e
Depends: libosmocore I1770787e697906322ce5815fcaadba06c01ddee9
Ensure that all msgb were cleaned up, then free the overall msgb_ctx, in order
to not leave any memory leaks the sanitizer build complains about.
Change-Id: I53373023a6c3f490d6d6cb1c283db5dfb915882c
Ensure that all msgb were cleaned up, then free the overall msgb_ctx, in order
to not leave any memory leaks the sanitizer build complains about.
Change-Id: I84e0ac7f0928f04ffddd7da18200466841589c25
The copyright statement and contribution notices were copied 1:1
from OpenBSC, which is of course not correct for OsmoMGW.
Change-Id: I6143becdd0da589451efcbda530a78f655b7ce0b
sysmocom (specifically Philipp) was doing all the new osmo-mgw
development, but that is not yet reflected in the Copyright statement
for some reason. Let's fix it.
Change-Id: I4cad29daaabec1caec1bd09088414e59fa15a17e
mgcp_conn.c: In function ‘mgcp_conn_dump’:
mgcp_conn.c:248:30: warning: ‘/rtp, id:’ directive output may be truncated writing 9 bytes into a region of size between 0 and 255 [-Wformat-truncation=]
snprintf(str, sizeof(str), "(%s/rtp, id:%u, ip:%s, "
^~~~~~~~~~~~~~~~~~~~~~~~~
mgcp_conn.c:248:30: note: directive argument in the range [0, 65535]
mgcp_conn.c:248:30: note: directive argument in the range [0, 65535]
mgcp_conn.c:248:3: note: ‘snprintf’ output 32 or more bytes (assuming 295) into a destination of size 256
snprintf(str, sizeof(str), "(%s/rtp, id:%u, ip:%s, "
as mgcp_conn->name can already be up to 256 bytes, a total buffer size
of 256 is insufficient!
Change-Id: I5d48132b1358d19fe72e3901117737b09a42c69c
When the library version was bump, the dependency of osmo-mgw
was forgotten.
Change-Id: I3eeafa3c294d9ec71a72fb2833fe3b2bdef05a50
Fixes: e7d27aeae1 ("Tag/Release Version 1.2.0")
Parse the endpoint index from the MGCP messages as base-10, not 16.
If osmo-mgw parses the endpoint IDs as base-16 numbers while OsmoMSC and
OsmoBSC pass in decimal endpoint numbers, the consequence is, for example:
- I configure 32 endpoints in osmo-mgw,
- I tell OsmoBSC to use endpoint range 1-32,
- At some point OsmoBSC may pass in, say, "30@mgw",
- "30" is parsed base-16 and ends up being endpoint index 48, instead of 32,
- OsmoMGW sees that 48 > number_endpoints and barfs.
Related: OS#2633
Change-Id: Ic18608ff23303c1564548a86d5f6bfa539fe555e
There the prefix "net" is a leftover from the time when
there was a bts and a net side. Now we do not distinguish
anymore between the two.
remove prefix "net"
Change-Id: Id627e2ef6f725979ed52a585ca09686e1a049adf
Since currently osmux is not available we decided to lock down the
respective VTY command with an early return CMD_WARNING, making
the code after this line unreachable.
Guard the dead code with an ifdef
Fixes: Coverity CID#178648
Change-Id: I2ad9579453f52fe129cf120801a2efa19a26304e
in point_lookup() the connection pointer is determined using
mgcp_conn_get_rtp() this function may return 0. At the moment
there are no nullpointer checks implemented
Add checks to test for nullpointer.
Fixes: Coverity CID#178662
Change-Id: If9a3c1ac002bc8adc90ca1c1c3dd1db4feea07ac
The function that forwards the tapped (voice ebug) traffic returns
its status (sendto) to the caller. However, none of the callers
seem need this info.
Remove the return code and print an error message on failure
Fixes: Coverity CID#178666
Change-Id: I16c12c4565bccbc0d75c412b43469bf70b6b7ea5
When sending rtp packets sizeof(buf) is used as length. This causes
all RTP packets to be the size of the buffer (4096) containing the
rtp payload and random excess data from previoes memory usage
Use the actual length of the received RTP data, rather then the
full buffer size.
Change-Id: I47a15701f9a7e7a492df183b67ec971f5be61069
Fix errors like "remote bind address", mention 'MGW' instead of 'MGCP gateway',
minor typos and wording tweaks.
Change-Id: Ie1a408f9e651c5fb3424a84ceaaa603e20ad595c
Commit 87203f2a37 renamed some cmds to use
mgw instead of mgcpgw, and added deprecated alias for the old commands,
but forgot to add one for 'mgcpgw bts-base'. This commit fixes
backawards compatibility with old config files that mentioned commit
introduced.
Change-Id: Ib1c58945f4203b05d79f367afb3082b9a6a2c4e3
'mgcpgw' was a working title for the osmo-mgw. Before this takes hold out
there, let's rename the VTY commands to 'mgw'. I'd rather have some local
fallout in our testing environments now than drag the stupid name along.
Keep deprecated 'mgcpgw' commands for backwards compat.
Change-Id: I1d43d42929dc9162e57640499526fb7cadbcfbe6
Currently there are two ways to set the rtp bind ip-address (local
ip address where the rtp streams are bound to). It is possible to
set no set an rtp bind ip, if none no address is configured, then
the ip address where the mgcp service is bound to is used.
On a system with multiple network interfaces it is likely that
there are the remote end is not reachable through the interface
that has been configured. In this case rtp ip-probing can be
enabled via vty option in order to automatically detect the
ip address of the interface that points towards the remote end.
The autodetection can only work if the ip-address is known when
a CRCX is performed. For this the remote entity must include the
remote ip address in the sdp trailer.
Implement probing to determine te right local ip address
Add debug log to display which ip address is actually used
Add a VTY option for the probing functionality.
Change-Id: Ia57cf7dab8421fd3ab6e1515727db0080373485e
The way how osmo-mgw decides when to send a dummy packet and
when not is not very obvious.
use more explicit if statements, and define constants. Also add
comments that explain how it works.
Change-Id: Ie7ee9409baec50a09fb357d655b5253434fae924
the network (mgcp_network.c) part and the protocol part
(mgcp_protoocl.c) share a single loglevel DLMGCP. This
makes debuging hard because when debugging the protocol
we also get the log output from the RTP packets.
assign the network part a private loglevel and keep DLMGCP
for the directly MGCP related code
Change-Id: I55a2711798d1d1c2c9ef2f3b7ebb8fdd78bd6ea2
the functions rtp_calculate_port(), mgcp_timeslot_to_endpoint(),
mgcp_endpoint_to_timeslot() were a hack to map CIC addresses
to endpoints and ports. This is no longer needed.
Remove the affected functions.
Change-Id: I9ef14396dc9f97e570d9bcfb4d9b4a94e650ad46
In many cases it is simpler to instruct the mgcp-gw to drop all
connections at once instead of removing each connection
individually.
drop all connections and release the endpoint in when no connection
id is supplied with the DLCX command.
Change-Id: Ib5fcc72775bf72b489ff79ade36fb345d8d20736
currently the only way to generate MGCP messages is to use
mgcp_msg_crcx(), mgcp_msg_mdcx() and mgcp_msg_dlcx(). All
three function take a fixed set of parameters via their
parameter list. There is no way to add or leave away optional
parameters.
add function mgcp_msg_gen(), this function takes a unified
message struct. The struct features a presence bitmask which
allows to enable and disable parameters as needed. It is also
possible to add new parameters in the future without breaking
the API.
Depends: libosmocore I15e1af68616309555d0ed9ac5da027c9833d42e3
Change-Id: I29c5e2fb972896faeb771ba040f015592487fcbe
When testing the file name and the line numbers are output to
stderr, this causes the test to fail when change moves the
lines.
Disable line numbers in the stderror log when testing, also
disable timestamps and colors. Make sure the log category
is print.
Change-Id: I7f1bd9454188f0ca869dada1fcc2877b789cc0ac