Age | Commit message (Collapse) | Author | Files | Lines |
|
Like osmo_ss7_pointcode_print(), but prints into an user-supplied
buffer.
Change-Id: I5fc7d7746eb90a9d404b6b50bf9ded6789a1c33c
|
|
A DUPU message in SUA and M3UA indicates the unavailability of
a (MTP-level) user, i.e. the entire SCCP, ISUP, ... is not available.
If we receive a DUPU (destination user part unavailable) message in ASP
role, then we must
* distribute it to any other ASPs for which we operate in SG mode
* pass it as MTP-STATUS.ind to SCCP, which can then generates
N-PCSTATE.ind to the SCCP User
Change-Id: I1559ed0f761a8495b222df48c6bd43798e220471
|
|
Change-Id: Id7780074b82bc668ae148456750b1a01799decd1
|
|
SCMG (SCCP Management) is a special sub-system that normally resides
at SSN=1. In Osmocom we so far ignored its existence. However,
in terms of interop with other implementation, we should implement
at least some basic features.
The only procedure implemented in this initial commit is the response
to an incoming SST (Subsystem Test) message. If we don't respond to
this message, a remote SCCP entity could assume the SSN is dead on
our side, rendering communication impossible.
Change-Id: I04b162476f7652ef0540b5ea7299e9447efd1d09
|
|
* add N-PCSTATE.ind and N-STATE.ind definitions to SCCP user SAP
* add minimal SCMG (SCCP Management) and LBCS (Local Broadcast)
* generate MTP-PAUSE.ind/MTP-RESUME.ind based on received xUA DUNA/DAVA
* generate N-PCSTATE.ind towards the local SCCP users
Change-Id: Idb799f7d7ab329ad12f07b7cbe6336da0891ae92
Related: OS#2623, OS#3403, OS#4701
|
|
This will allow us to write generic code that uses DLM3UA/DSUA depending
on the ASP protocol.
Change-Id: I7c015b3a2727deff4fc4e6f3bc7bdeeb57e86166
|
|
We copy the contents to a static thread-local buffer to ensure
zero termination of the string received by a remote entity.
Change-Id: I8cbb7aeaf0cb64db0ce01c21e5fca9ab3cd932b6
|
|
Change-Id: Id23d90ffea855680cd7d4a16b89e652eed0cf39f
|
|
Change-Id: I517943bd11d73195de9418fb1c5d4151dab77873
|
|
We only read from it.
Change-Id: I12c17273b9d64a084f59d91fc06ae1512d70855b
|
|
Change-Id: Iadd34a167a7712796b2501f6a75b5a8d26a828eb
|
|
Change-Id: Ia7f9d891ea92abd20855374b936aac8b28ae15df
|
|
Avoid magic number 0xffffffff and rather provide a mask value for all address
components.
Change-Id: I13ff0858e496c4392b8e1590d62f7eb80f191a07
|
|
Quoting 3GPP TS 23.003 8.2:
1111 1010 BSC (BSSAP-LE);
1111 1011 MSC (BSSAP-LE);
1111 1100 SMLC (BSSAP-LE);
Hence the SMLC one should also be named *_BSSAP_LE.
I'm certain no other osmocom code is using this SSN yet, but anyway keep a
backwards compat shim #define.
Change-Id: I3e0c1be0ebbd3883d024174d1e7e9167a8281cfb
|
|
To allow osmo-bsc to add more than one MSC peer on a single SCCP instance, it
must add a local SCCP user only once per SCCP instance. The first configured
MSC adds a local user, all subsequent MSC should use the same local SCCP user.
So, it is most convenient to provide a public function to return such user if
it exists.
Add as thin wrapper instead of renaming and moving the internal
sccp_user_find(): to keep the patch smaller, and to match the way
osmo_sccp_user_bind_pc() is a 1:1 wrapper for sccp_user_bind_pc().
Related: OS#3682
Change-Id: I9ecbab16b45268f626950303d6ff8296dd6acda0
|
|
The code managing addresses is decoupled from xua_server since they will
also be used to manage addresses for ASPs.
Change-Id: I4af2a6915ac57c7baa67343bd9414c65154d67f7
|
|
This is like osmo_ss7_asp_find_and_create(), i.e. it's doing a full
match for an ASP within the specified SS7 instance, of the specified
port numbers. It just doesn't create it if it is missing.
Change-Id: I1ed3cf2b69ee622d6f9d8b50487f392fe913ae90
Related: OS#4271
|
|
Change-Id: I356d90642a500be6a70f60c8240ce1211fd0d934
|
|
Change-Id: I4f1d1aa9395698e5b6b930a5092a4b914dd15fb3
|
|
So far, we had a static role model:
* SCTP servers (listening, such as OsmoSTP) are role SGW
* SCTP clients (connecting, such as OsmoMSC) are role ASP
While this is customary, it is not actually required by the
specification. The SGW can establish the SCTP connection to an ASP
but still remain "SG" role.
Let's make things more flexible by having the role configurable.
Related: OS#2005
Change-Id: I2df9cd9747ad5c9a05d567d9a71bab6184c53674
|
|
This supersedes the library-internal enum xua_asp_role.
Change-Id: I28b0888b8f8206e9dd67ef64ce0f71ba9a7105ce
|
|
If the AS is e.g. configured as broadcast, then individual ASPs cannot
be activated in loadshare or override. Everyone must agree.
Change-Id: Ic73410fbc88d50710202453f759fa132ce14db4c
|
|
Change-Id: I8ca17439b4dd023625f8f22689c0432341986099
|
|
RFC 4666 (SS7/MTP3/M3UA) states in isection 4.3.4.3 ASP Active Procedures:
"""
If the traffic handling mode of the Application Server is not already known via
configuration data, then the traffic handling mode indicated in the
first ASP Active message causing the transition of the Application
Server state to AS-ACTIVE MAY be used to set the mode.
"""
In section 3.6.1 Registration Request (REG REQ), no related information
is provided on how to handle it, but still makes sense to apply same
behavior as in 4.3.4.3.
Related: OS#4220
Change-Id: Iaebe3a93ad8d2d84ae01e41b02674f8ece9dfc95
|
|
Related: OS#4220
Change-Id: I98144dde237672df2e78c7c92923e6f4cb77a271
|
|
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 10d4815bb1b4b548ec0bc97611b2e7ac45e0ebc5 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
|
|
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
|
|
Change-Id: Ic85fc460cc1f31d0fb407095afe417ceaa60e7bd
|
|
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
|
|
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
|
|
That's useful for external programs veryfying pointcode validity. For
example if used as part of BSS-related identity in GCR construction by
LCLS code we should be able to double.check that no significant bits off
pointcode are lost/ignored.
Change-Id: I5a9981dd2c1d78966c61a3f6b50c7c0d9b542caf
|
|
When saving the current VTY config to a configuration file,
do not write out AS/ASP configuration items which are generated
as a fallback by osmo_sccp_simple_client_on_ss7_id().
Since the user did not explicitly configure these configuration
items they should not be saved to the user's configuration file.
Change-Id: Id8a3afc6dee29ae1ee9c862cbe404a61fe979dba
Related: OS#3616
|
|
Instead of allocating ss7->sccp in various places, unify that in one common
function. We shouldn't spread the decision what to pass as priv pointer around
everywhere. There is no functional difference.
This is preparation for a patch where the sccp_instance gets allocated from the
telnet VTY: I would prefer to hide all allocation details from that code; which
also makes sense for the other callers of osmo_sccp_instance_create().
Change-Id: Ie912898c66d31ce4ac8eeeea5a6ddc3f821c06f7
|
|
So far the tall_xua ctx used to allocate from in xua_msg_alloc() was never
initialized, actually hiding memory leaks from the talloc report.
Add this API to allow branching the xua_msg ctx off a sane root ctx.
Explicitly initialize tall_xua to NULL, so that, if xua_msg_ctx_init() isn't
called, tall_xua is still guaranteed to not be a random pointer.
osmo-bsc will use this function to hook the tall_xua ctx to osmo-bsc's own root
ctx.
Change-Id: I618878680a096a7f7fc2d83098590f2e4cb08870
|
|
Applications may be interested in handling data for those SCTP PPID or
IPA StreamID which libosmo-sigtran doesn't implement
natively/internally.
Let's add osmo_ss7_register_rx_unknown_cb() using which applications
can register a call-back to implement whatever behaviour they'd want for
those PPID/StreamIDs.
Change-Id: I8616f914192000df0ec6547ff4ada80e0f9042a2
|
|
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ia0d15a2814b08bc3f052a1ed12dbb68bade55309
|
|
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ib7abf69cfcf4c56273223054b280458451e6c2f6
|
|
In osmo-stp, cmd "local-ip" inside node "listen m3ua 2905" was actually
not being applied, because the server was created + bound at "listen" command
time using NULL as IP, and at "local-ip" time the IP was changed but the
server was not re-bound using the new IP, so it kept listening at
0.0.0.0.
With this patch, we defer binding the socket to "local-ip" cmd time,
after the IP has been applied.
As a result, if no "local-ip" command is provided, then the bind never
happens, which means it is now mandatory that users of osmo_ss7_xua_server_create
API not using osmo_ss7_xua_server_set_local_host call new provided API
osmo_ss7_xua_server_bind. Another new API osmo_ss7_bind_all_instances is
provided to easily make sure all servers are bound after configuration
process. This is specially important for servers which doesn't contain
the "local-ip" parameter.
Users of osmo_sccp_simple_server API are not affected by this change,
and they not requrie to call any new API.
Furthermore, using osmo_ss7_xua_server_bind in VTY code ensures the xUA
server is automatically bound to the new address if the operator changes
the "local-ip" cmd at runtime.
Related: OS#2647
Change-Id: I79738963d633bec70705ff159c5b2127cd498aa2
|
|
It can be cumbersome to derive the ss7 instance needed to pass to
sccp_addr_name(), because struct osmo_sccp_instance is opaque and only
available in sccp_internal.h, within libosmo-sccp.
Add osmo_sccp_inst_addr_name() which derives the ss7 instance from the internal
knowledge of the osmo_sccp_instance struct. This can save calls to
osmo_ss7_instance_find() just to do some logging of an sccp address.
Naming: first I thought to pick osmo_sccp_addr_name2(), but for some of the
string composing functions, adding a 2 already means that it is identical but
using a second static buffer (to be used twice within the same printf).
Change-Id: I70ec5c8b42682a23f11a5820431c7e34e225709b
|
|
Since the NI is in bits DC, not BA, it needs to be shifted by 6, not 4, to end
up in the two most significant bits. Also, NI is two bits wide, hence & 0x3.
(The m3ua.c side of this is already correct.)
See ITU-T Recommendation Q.704 (07/96), 14.2 "Service information octet".
Before this patch, NI was always sent as 00 == International regardless of the
VTY configuration.
This patch was verified to work by a wireshark trace of osmo-bsc connecting to
osmo-msc, showing the NI decoded as configured by an osmo-bsc.cfg file in the
BSSMAP Reset message MTP 3 / Protocol data.
Change-Id: I7bb4eb6518a1e0d74313bda776d2a6acd0b02e1b
|
|
* BSSAP is 254 on both MSC and BSC side: Add missing define
* BSSAP-LE (LCS Extension) has 250/251, adjust name to add -LE suffix
Change-Id: Iccec75cfc0cf16bd717a9bd4606d1e772c332ccc
|
|
osmo_sccp_get_ss7() has the risk of a nullpointer dereference, when
sccp is NULL.
Return NULL when the sccp instance is NULL.
Add doxygen comment
Change-Id: I84d484e4441fd37443fff8c67e17df8fb15d5b2e
|
|
It is currently impossible to find out which SCCP instance handles
a particular user.
Introduce function to lookup the SCCP instance from a given SCCP
user.
Change-Id: I9562c4f1d00e2ebb3252c5dea598b643aa393719
|
|
osmo_sccp_addr_name() is not listed in any header file.
Add osmo_sccp_addr_name() to sccp_helpers.h in order to make
it available.
Change-Id: I092dd55948faeeff78f28f7d50c5b84b9e69ef24
|
|
The simple client takes certain parameters (pc, ip and port
numbers) which serve as a fallback default in case the user
did not configure any suitable parameters via the VTY.
Prefix all default variables with default_ to make the
purpose clear to the API user
Change-Id: Id9e697e8b198e4f58a79e59aaf2e649e84a3eb63
|
|
osmo_sccp_addr_dump() just prints the raw values. In osmo_sccp_addr_name(), use
osmo_ss7_pointcode_print() and newly added RI, SSN and GT value_string[] to
print more human readable log output.
Change-Id: Ie1aedd7894acd69ddc887cd65a8a0df4b888838c
|
|
Allows to automatically set an RI in future change
I75c67d289693f1c2a049ac61cf2b2097d6e5687d
"sccp-addr vty: set RI to SSN_PC when setting a point-code"
Change-Id: I6e2f31b023b08cba2f2ee8234e6108efcaca41c0
|
|
Change-Id: I8c6b7188d004033e75e9c41f4a65c418d13a79c5
|