If no IP addr is assigned yet, until know it'd print "(:3456". Let's
print ":34456" in that scenario.
Change-Id: Iae85d231093b6f3ce6b969324699858e525c14ea
Config file sets omo-stp instance to bind on 2 IP addresses, and then
the test verfies through linux /proc/net/sctp/* that binding is done
correctly and that it can be reached from another remote address to one
of the configured addresses.
Change-Id: Ifa11b1fc882dff415405f62024e94bed67228866
After this patch, Several "local-ip" and "remote-ip" lines are accepted
under "listen" and "asp" VTY nodes, allowing to configure an SCTP
connection with multiple connections, hence allowing control of SCTP
multi-homing features.
libosmo-sccp clients such as osmo-bsc and osmo-msc also gain support for
this feature with this commit.
Related: OS#3608
Depends: libosmocore.git Ic8681d9e093216c99c6bca4be81c31ef83688ed1
Depends: libosmo-netif.git I0fe62f518e195db4e34f3b0ad1762bb57ba9d92a
Change-Id: Ibd15de7a4e00dbec78ff2e2dd6a686b0f3af22de
Commit 10d4815bb1 already fixed the issue
where binding was done during L_CS7_XUA_NODE (listen) done, meaning
local-ip inside it had no effect. In that comment, binding was moved to
happen during "local-ip" VTY cmd. Furthermore, that commit added a new
osmo_ss7_bind_all_instances() and related APIs to allow osmo-stp to have
all xua servers bound if no "local-ip" was provided.
These APIs have only been used so far by osmo-stp (which lays in the
same git repo that libosmo-sccp) since it's the only program using the
xua server features.
In the present commit, let's drop the APIs added by commit described
above, and instead let libosmo-sccp code to internally bind the xua
server upon exit of the VTY node. As a result, the previously introduced
APIs can be dropped (not used by anyone anymore) and it will provide
ways to support multiple "local-ip" commands in the future, hence
supporting SCTP multi-home features.
It's recommended to require libosmocore.git Ia6d88c0e63d94ba99e950da6efbc4c1871070012
since it fixes a bug where go_parent_cb was not called for nodes at the
end of the file.
Related: OS#3608
Change-Id: I2cff17b5e2e2fbfd4591e23a416e510e94e173d6
The IPA protocol doesn't have the context of routing-keys. We are only
permitting routing key '0' (as the default routing key) when configuring
via VTY.
Change-Id: I3f166f44903d0b93963cc5d0cca73d277d2b7215
Fixes: OS#4234, OS#4233
When receiving SCCP messages from an IPA peer/ASP, osmo-stp so far
unconditionally inserted origin/destination point codes int the SCCP
called / calling party addresses.
This behaviro is now made optional with the introduction of the
following per-AS configuration:
"point-code override patch-sccp (disabled|both)"
The default behavior is switched from 'both' to 'disabled' at the same
time.
Change-Id: I535e2170adadfe755d2bcbf5bbf4556bebb77737
Closes: OS#4219
If an IPA ASP is sending us a SCCP message that cannot be parsed,
we shouldn't crash but handle this gracefully.
Change-Id: Ib7a8c2a36dd1b82ca8ed472760c1682ede50cb90
Fixes: OS#4236
The IPA/SCCPlite stacking is - as the name implies - constrained to
the transport of SCCP messages. We have to reject any non-SCCP payload.
Change-Id: I5e5a2879013ee8cf08aa4199b4bee498dcb61446
Fixes: OS#4235
Consider them as lost by the lower layer, otherwise lots of old messages
and retransmissions can end up queued in there until stream becomes
connected, and then will flood the peer with all those messages.
Depends: libosmo-netif.git 962bf9a48eed418354685dc733b8271d2dd62c27
Related: OS#4188
Change-Id: Ic7d3571848faf28221dcfa8eb8b33b42964d988e
When using osmo_sccp_simple_client(), it will create an sccp instance if
none exists. The sccp instance identifier starts with 0.
The implicit created instance should use sccp instance 0 (the
first connection).
Change-Id: I9d9f65555b9cdc1e3c697c8b834528d51878e1ae
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.
Related: OS#4138
Change-Id: Iedd11f816002b686f0ddb54c0cf7ba4e229e21e3
Run "make maintainer-clean" after publishing manuals, not the other way
around. Otherwise jenkins.sh fails when running for the master branch,
because docs/manuals/Makefile gets deleted although it is still needed
to publish the manuals.
Related: OS#3047
Fixes: 55f03b898a ("contrib/jenkins.sh: run "make maintainer-clean"")
Change-Id: I8bcee9069743b76966a78e1c13d0be9ba62d992c
In Id0789c4946929b783c54220de439958001f94992 I introduced the VTY
commands for talloc-context introspection, but forgot to expose
the root talloc-context.
Change-Id: Id2bf6cdae112f9791c93411c1837de488cab9ee3
Use the new offset based parsing to extract GT and data from the
UDTS/XUDTS message as well. Test vectors are missing right now.
Change-Id: Id0a3a291d8bad3f8c9621e6c97d4ea0b8bbe6035
The cellmgr-ng unfortunately looks at the data being sent and can't
handle the presence of XUDT at all. Add the structure definition
and refactor extraction code to work on offsets. Add a unit test.
Change-Id: I45a7447cc1be432fff34849e0e35abc0410cf153
osmo-msc identifies its BSC and RNC peers by SCCP address, and compares those
by memcmp(), which is not really accurate. Rather provide a meaningful
osmo_sccp_addr_cmp() API to determine whether SCCP addresses are identical.
Go for a full cmp that would also allow sorting.
Change-Id: Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5
Add osmo_sccp_user_sap_down_nofree(), which is identical to
osmo_sccp_user_sap_down(), but doesn't imply a msgb_free().
To implement that, sccp_sclc_user_sap_down_nofree() with the same msgb
semantics is required.
Rationale:
Avoiding msgb leaks is easiest if the caller retains ownership of the msgb.
Take this hypothetical chain where leaks are obviously avoided:
void send()
{
msg = msgb_alloc();
dispatch(msg);
msgb_free(msg);
}
void dispatch(msg)
{
osmo_fsm_inst_dispatch(fi, msg);
}
void fi_on_event(fi, data)
{
if (socket_is_ok)
socket_write((struct msgb*)data);
}
void socket_write(msgb)
{
if (!ok1)
return;
if (ok2) {
if (!ok3)
return;
write(sock, msg->data);
}
}
However, if the caller passes ownership down to the msgb consumer, things
become nightmarishly complex:
void send()
{
msg = msgb_alloc();
rc = dispatch(msg);
/* dispatching event failed? */
if (rc)
msgb_free(msg);
}
int dispatch(msg)
{
if (osmo_fsm_inst_dispatch(fi, msg))
return -1;
if (something_else())
return -1; // <-- double free!
}
void fi_on_event(fi, data)
{
if (socket_is_ok) {
socket_write((struct msgb*)data);
else
/* socket didn't consume? */
msgb_free(data);
}
int socket_write(msgb)
{
if (!ok1)
return -1; // <-- leak!
if (ok2) {
if (!ok3)
goto out;
write(sock, msg->data);
}
out:
msgb_free(msg);
return -2;
}
If any link in this call chain fails to be aware of the importance to return a
failed RC or to free a msgb if the chain is broken, or to not return a failed
RC if the msgb is consumed, we have a hidden msgb leak or double free.
This is the case with osmo_sccp_user_sap_down(). In new osmo-msc, passing data
through various FSM instances, there is high potential for leak/double-free
bugs. A very large brain is required to track down every msgb path.
osmo_sccp_user_sap_down_nofree() makes this problem trivial to solve even for
humans.
Change-Id: Ic818efa78b90f727e1a94c18b60d9a306644f340
Accept the osmo_sccp_user instead of calling conn_create() and setting
conn->user afterwards. Prepare for generating a local_ref inside
conn_create_id() in the future.
Related: OS#3871
Change-Id: I2fb47c8ba6c0ce7cd92c9ac31f15c67eb67fb66e
Move it before sccp_scoc_rx_scrc_rout_fail(), so it can be used in
the latter function to figure out the local_ref from the user (follow
up commit).
Related: OS#3871
Change-Id: Ieabeda3126dcc0349a06c0fc7c9e468b900d7855
Remove all comments, that claim conn_id is the local reference. This
is only a hack, and should not be something to rely on. A properly
separated local reference will be introduced shortly.
Related: OS#3871
Change-Id: I900124037da76caaaf5ecee323eb82e1c6d2e368
We were printing the mask of the route, but not the point code itself.
Best would probably be to print both?
Closes: OS#3835
Change-Id: Ifa4fdbad953d40f222beb470a082eed8c20991ef
"show cs7 instance 0 asp" before this patch would not display the
remote IP/port information about dynamically-added ASPs but instead:
Effect Primary
ASP Name AS Name State Type Rmt Port Remote IP Addr SCTP
------------ ------------ ------------- ---- -------- --------------- ----------
asp-dyn-0 ? ASP_ACTIVE m3ua 0 (null)
With this patch it is now correctly displayed:
Effect Primary
ASP Name AS Name State Type Rmt Port Remote IP Addr SCTP
------------ ------------ ------------- ---- -------- --------------- ----------
asp-dyn-0 ? ASP_ACTIVE m3ua 24905 127.0.0.1
Change-Id: I39a1c57bc72e8aff607f3a551811a2f6372adab4
Closes: OS#3836
Change a loglevel from NOTICE to ERROR, for when a routing key gets
re-purposed.
Add another error log for insufficient resources case.
Change-Id: Id22e3c6bab5f7b597df3514eedb162277ce0ef7d
As osmo_ss7_route_print() returns a static buffer, we cannot use it
twice within a single log/print statement. Rather, we must use
osmo_ss7_route_print2() for the second call, as it uses a separate
static buffer.
Change-Id: Ica32e83cbe8af2317cb07f8d8422a399fa537012
Using osmo_stream_cli_open() with explicit timeout set via
osmo_stream_cli_set_reconnect_timeout() will have the same
effect. Update comment explaining this as well as the code.
Change-Id: Iffe6ea48a170880faef071c7c4a1bc0605aa9855
Pau Espin
Harald Welte
Alexander Couzens
Oliver Smith
Daniel Willmann