When operating an IPA ASP in server mode, we were not counting the
packets using the related stat item:
For example:
OsmoSTP# show stats
Ungrouped counters:
SIGTRAN Application Server Process (6)('asp-dyn-5'):
Total number of packets received: 0 (0/s 0/m 0/h 0/d)
Total number of packets transmitted: 235370503 (129/s 7682/m 442447/h 11342653/d)
This patch adds the missing counter increment.
back-port of Change-Id I75881d115b5c2c2567c4731bcf2cabe11f367117 from master
Closes: SYS#6600
Change-Id: I96488e4ea10e00f5f03387e33dc58e4b5016458f
Support to enable AUTH/ASCONF in the SCTP socket was added recently in
libosmocore and libosmo-netif, in order to support the Peer Primary
Address features used by the libosmo-sccp code.
The code to request the AUTH/ASCONF support through setsockopt() was
internally applied transparently by lisbosmo-netif's osmo_stream. This
is not 100% disarable since other users of the library may not need/want
that behavior.
As a result, libosmo-netif's osmo_stream no longer enables the SCTP
AUTH/ASCONF support by default, but it must be enabled through
the new osmo_stream_{cli,srv_link}_set_param() API.
This change in behavior of the API/implementation can be done because
all these new features are pretty new and no release of
libosmocore/libosmo-netif/libosmo-sccp has been released yet.
Related: SYS#6501
Related: SYS#6558
Depends: libosmo-netif.git Change-Id I2607c1c926a625986cd851adc65dd8b4de83d6ab
Change-Id: I16c97fc148792aa3e39b7414899660990c39dfff
This allows having a clearer picture of the several entities involved,
as well as simplifying the files.
In the future, we can do the same for AS, route, etc. and leave osmo_ss7
for the "instance" object.
Change-Id: I3d43268459d61b0b9f9bec34bf31dc0851fa5e48
when IPA/SCCPlite traffic traverses the osmo_ss7 stack, so far the
SLS of the MTP3 label was always set to 0 (default initialization).
However, in order to achieve a better distribution of signaling traffic
in SS7 networks that actually utilize the SLS to select any links (or
ASPs), it makes sense to use non-zero values.
Instead of introducing some kind of new, configurable attribute for
each ASP (IPA client connection), let's simply use the lower 4 bits of
the file descriptor integer. Those file descriptors should have a
roughly equal distribution, resulting in traffic (from multiple IPA
clients) to be spread across the 4-bit SLS number space.
Also, this mechanism ensures that traffic from one IPA client will
always get the same SLS and hence routed the same way in any underlying
CS7/SS7 network.
Change-Id: Ice7bab997b84cfed00c7d6d780c70f4e9fac6002
Related: SYS#6543
The kernel doesn't store state about a "always-preferred" Primary
address, it simply applies the requested one at the time the request is
done. If afterwards the remote address becomes unavailable, the kernel
will end up giving up on it and selecting anoter one as primary address.
If the VTY-configured Primary Address become available after a while
(signaled by the kernel in the SCTP_PEER_ADDR_CHANGE), make sure to
apply it again.
Similary, if the peer sends us an ASCONF changing our Primary Address,
we should discard that and apply/overwrite *iff* the user explicitly
VTY-configured one (kernel announces the change through
SCTP_ADDR_MADE_PRIM in this scenario).
Related: OS#6076
Change-Id: I2e54e6f9e424350474db6dec6ab604b33a03f88b
This is an initial implementation to set the local SCTP Primary address
as well as the peer's Primary Address (through SCTP ASCONF messages).
The Primary address is only set upon conn establishment (after connect()
for clients, or accept() for severs), which means no logic is
introduced to make sure that primary address is kept during the entire
operation of the SCTP association (for instance if the Primary address
becomes unavailable and the stack changes the primary, and later on that
address becomes available again, the primary addres won't be set back to
the initially configured one).
Related: OS#6076
Change-Id: I4a9fc1a4ad82ed20ece328bc53fca58299d744ca
Since libosmo-netif.git Change-Id
I4cb94d264109f1b763cccd44c6ba049cc7509319, we receive SCTP notifications
in both client and srv, so there's no real need to use sctp_recvmsg()
directly.
Change-Id: If3d78b636e8e224aa9c8597d0b242e29d3e3c84e
Before this patch, the code generating a DUNA or DAVA message would
potentially generate a ROUTE_CTX IE with zero-length content, rather
than skipping such an IE altogether if no routing context[s] are given.
Change-Id: I19d0382cd2d428a91ac716182b9d86dcdc2c2ebd
Related: SYS#6511
Some user run into this scenario recently and it was difficult to find
out why the SCTP links were being restarted. Add a new log line with
NOTICE level explicitly stating the reason to restart the ASP.
Related: SYS#6511
Change-Id: I5a388d2d96bcf1cbb76981c476abf37dbe213df0
Role and SCTP Role are now printed. Several formatting issues are fixed
or improved.
Related: SYS#6488
Change-Id: Id22bd4e74fb6f79950adba58862d379203d36760
Upon connect/accept, update the name to contain both the ASP and the
sockname of the established socked. This allows easily identifying the
stream based on IP layer as well as upper xUA layer.
Example logs:
"""
stream.c:1193 SRV(m3ua,::1:2905) accept()ed new link from ::1 to port 2905
stream.c:1672 SRVCONN(asp-dyn-0,(r=::1:43568<->l=::1:2905)) connected read/write (what=0x1)
stream.c:1589 SRVCONN(asp-dyn-0,(r=::1:43568<->l=::1:2905)) message received
"""
"""
stream.c:521 CLICONN(asp0){CONNECTING} connection established
stream.c:552 CLICONN(asp0,(r=::1:2905<->l=::ffff:127.0.0.2:35911)){CONNECTED} connected read
stream.c:401 CLICONN(asp0,(r=::1:2905<->l=::ffff:127.0.0.2:35911)){CONNECTED} message received
"""
Depends: libosmo-netif.git I539a0d29d11348efe702f971965a55cf56db5c59
Change-Id: I05bc5f6c7795f62c1814c1c774287b41ee85a475
Some apps such as osmo-bsc are accessing some of those fields, so better
add a getter API to make it easier to update the struct contents.
Change-Id: If9acfca1abc9ab7eb6d2388f548d7ee577b9c5ac
A recent commit (83db938859) changed the
behavior of default "sctp-role" and "role" values of ASPs named
asp-clnt-* which are used by osmo_sccp_simple_client_on_ss7_id(), in
order to avoid having different default values when than function is
used, which is totally confusing for end users.
As it was already informed when submitting the mentioned commit, it
changes the behavior on that specific case, and that made some users
start having problems without a proper "your config is wrong!" error.
This commit addresses it by basically forbiding that exact use case,
that is, partially defining an asp-clnt-* ASP through VTY without
explicitly configuring a "role" and "sctp-role". With this patch,
function osmo_sccp_simple_client_on_ss7_id() will print a proper error
informing the user and will return NULL, potentially triggering an early
program exit which can then easily be fixed by using proper
configuration.
Related: SYS#6486
Change-Id: I65b5fad2ec06a9d9c521f1e3ce8aab633da95a47
The VTY config defaults are "role sg" and "sctp-role server".
However, if not set explicitly in VTY,
osmo_sccp_simple_client_on_ss7_id() was replacing them to "role asp" and
"sctp-role client".
This is fine if the ASP is not defined/created at the VTY (aka
dynamically created with no config), but if the ASP is defined in the
VTY it becomes really confusing, since it's picking different defaults
than the usual ones.
Hence, follow always the same VTY defaults in
osmo_sccp_simple_client_on_ss7_id().
As a result of this change:
- Programs not defining the ASP over VTY keep the same behavior (ASP is
created with role=asp and sctp-role=client)
- Programs defining ASP over VTY (eg. "asp asp-clnt-msc-0 5000 0 m3ua")
explicitly setting "role" and "sctp-role": keep the same behavior
- Programs defining ASP over VTY but not explicitly setting "role" or
"sctp-role", will get now the usual defaults instead.
So in summary, strange cases where osmo_sccp_simple_client_on_ss7_id()
is used (osmo-bsc, osmo-hnbgw, osmo-msc) and the dynamically created
ASP is created through VTY, then the config file must also explicitly
define the following lines:
role asp
sctp-role client
This patch also changes the "show running-config" VTY cmd to also always
show the configured role and sctp-role values, which are of vital
importance to understand a given setup.
Change-Id: Ie81987265118e48173211f88b27a006115dc62d4
Right now, if a user configures an cs7 instance, as and asp (with
sctp-role server) in the VTY, then the function
osmo_sccp_simple_client_on_ss7_id() (used by osmo-bsc, osmo-msc,
osmo-hnbgw, etc.) will silently change the config to be SCTP client.
This is really confusing, since the user configured explicitly the ASP
as server but ends up running as client.
Instead, if the user explicitly configured the ASP as SCTP server,
allow it (after validating the user also properly configured a xUA
server through VTY).
Change-Id: I20de33edb8751a515d6719c49efadfc387dd85f8
In struct osmo_sccp_instance, we have a next_id, to find an unused SCCP
connection ID. This is used for inbound SCCP connections.
At the same time, in each of our SCCP client programs, we have a
separate mechanism to find a connection ID for outbound connections.
See for example bsc_sccp.c: bsc_sccp_inst_next_conn_id()
It makes much more sense for callers to use the same
osmo_sccp_instance->next_id counter:
- Currently the inbound and outbound counters go out of sync: For
example, in osmo-bsc, if we have three MS doing a usual Complete Layer
3, osmo-bsc's counter increments by three. If we then have one
Handover Required coming back from the MSC, i.e. inbound SCCP
connection, the sccp_inst->next_id is behind by three, and will
iterate SCCP connections three times before finding an unused id.
- Each implementation has to take care to properly wrap the ID in its
valid range, e.g. in osmo-bsc:
test_id = (test_id + 1) & 0x00FFFFFF;
if (OSMO_UNLIKELY(test_id == 0x00FFFFFF))
test_id = 0;
Add public API so that callers can benefit from the internal
osmo_sccp_instance->next_id and do not need to duplicate the code for
staying within the proper range.
Change-Id: If59d524fbe1088a59ae1b69908e2d4bf67113439
Looking for an unused SCCP connection ID has no exit condition if all
connection IDs are in use. However unlikely it is that there are
16777215 active connections on one SCCP instance, add an exit condition.
Do so by implementing the ID lookup in a new separate function, which
qualifies for public API (upcoming patch).
So far, use an exit condition closest to previous behavior: iterate the
entire SCCP conn id number space before exiting in failure.
Change-Id: Ib64e0cb1ae0cc8b7bebcb2a352d4068b496b304a
So far, the optional data limit can only be modified via cs7 VTY,
because struct osmo_sccp_instance is private. Provide public API to set
this limit from C.
Change-Id: If3d22a0f65a7ed0be043027652402b32c356e322
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
If there is only one routing key (and hence routing context, and hence
AS) within one ASP, *and* the routing context is configured as 0 (zero),
we should not include the routing context IE. This is the way how
libosmo-sigtran has always been special-casing routing context 0 meaning
"routing context is not used". However, that was only working in SG
role (typical STP use case). When operating in ASP role, the
special-case handling was missing, causing a routing context IE
containing zero to be included in the related transmitted M3UA ASPAC
and ASPIA messages.
Change-Id: I5ce89b393a3b950ab7fd1eace9038718c9efcc51
Closes: OS#6003
In sccp_scoc_states, allow the state transitions present in
S_WAIT_CONN_CONF's event handler function scoc_fsm_wait_conn_conf(), and
thus fix handling of N-DISCONNECT while waiting for SCCP Conn Confirm.
Fixes this error:
DLSCCP ERROR SCCP-SCOC(1016){WAIT_CONN_CONF}: transition to state IDLE not permitted! (sccp_scoc.c:1213)
S_WAIT_CONN_CONF happens when the caller sends an N-DISCONNECT during
S_CONN_PEND_OUT -- that means, while we are waiting for a CC from the
peer, the caller ends the conn. SCCP-SCOC still waits for the CC first.
When S_WAIT_CONN_CONF expires, the intended path is state change to
S_IDLE, which then deallocates the connection. Allow this state
transition from S_WAIT_CONN_CONF to S_IDLE.
When S_WAIT_CONN_CONF receives a CC, the intended path is to send a
RELRE and state change to S_DISCONN_PEND. Allow this state transition
from S_WAIT_CONN_CONF to S_DISCONN_PEND.
Change-Id: I8145e53124cabd76bd2cee159ab01306a1afaa27
The field already exists in the struct, but it's not really used
anywhere internally yet (and was not available externally).
Let's make it available to users of the API, similar to osmo_sccp_user_{get,set}_priv().
This way apps can easily store per-sccp-instance state.
Change-Id: I5643e6b14590b1478b3c8dabc8a7a619f5505409
As a result we move from:
INSERT=O(1) SEARCH=O(n) REMOVE=O(1)
to:
INSERT=O(log(N)) SEARCH=O(log(N)) REMOVE=O(log(N))
So we get rid of O(n) complexity every time we need to find a conn
object based on conn_id. When a big number of SCCP conns is handled,
this saves a lot of CPU time every time a conn needs to be looked up,
for instance each time a message is received.
For instance, given 1500 SCCP conns, searching is ~10 steps while it
took 1500 steps beforehand.
Morever, since when creating a new conn_id the code looks if it exists
prior to it, that means in practice inserting used to took O(n), while
now it takes O(log(N)).
Change-Id: I28ac67038207e2fad89ea291629cec5b2f912461
Drop local variable with no real use, dereference sccp_instance pointer
once instead of potentially thousands of times.
Change-Id: Iee333fb38d7a37877c37c1de9719a6b67d9e8ed3
The 0x00FFFFFF source local reference is reserved in M3UA/SCCP, hence
avoid allocating a conn_id with that value since later on when reused as
a source local reference it would fail to be encoded.
Change-Id: Ifcf710ef6024286a1cc3473d6ea3f858552b9926
I would like to tweak the names for the recently added functions, so
that they are more clear -- quickly before we release it or anyone uses
these.
Depends: libosmocore I9f43428af654a5674ac3035fe4db1394aac7a7af
Related: I4c1998fd7fee7282d107846dae2cff4b5ceb3a7b
Change-Id: If381f537ab91af1feef7f0e51921217f27e18e6a
The attempt to route message via AS which is down will fail anyway:
let's make it explicit.
Add osmo_ss7_as_down() and use it to check AS state before transferring the message.
Change-Id: I0d5f3b6265e7fdaa79e32fbc30f829ef79e7dad1
Add non-legacy string functions for osmo_scu_prim_name in the form of
_buf() and _c() signatures.
So far there is only osmo_scu_prim_name() using a static buffer.
Implement that using osmo_scu_prim_name_buf().
Change-Id: I4c1998fd7fee7282d107846dae2cff4b5ceb3a7b
Silence the error log for PCSTATE.indication prims.
When running the HNBGW_Tests.ttcn suite, the osmo-hnbgw LOGL_ERROR is
spammed with messages like:
DLSCCP ERROR unsupported SCCP user primitive N-PCSTATE.indication (sccp_scmg.c:298)
Add this prim to scmg_prim_cb() to just log on DEBUG that it is ignored.
Related: OS#5679
Change-Id: I5fd38afea94f48ed2f2fcd2d9baa8ec22a571b6b
SUA allows references of 4 bytes, but SCCP/M3UA doesn't.
SUA: RFC3868 sec 3.10.4:
The source reference number is a 4 octet long integer.
This isallocated by the source SUA instance.
M3UA/SCCP: ITU-T Q.713 sec 3.3:
The "source local reference" parameter field is a three-octet field containing a reference number
which is generated and used by the local node to identify the connection section after the connection
section is set up.
The coding "all ones" is reserved for future use.
Related: SYS#6211
Change-Id: Ia547346bdae54a032d2198ecd4972fb3f8dd073e
The length limit of optional Data parameter is 130 bytes according to ITU-T Rec Q.713 §4.2..§4.5. If we receive CR, CC or
RLSD message with bigger data - cache it if necessary and send via separate DT1 message after connection becomes active.
Fixes: OS#5579
Change-Id: I0033faf9da393418930252233ce74d62cd1cef8a
Harald Welte
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Max