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
vty/config tests were added recently, which use python and end up
generating __pycache__/osmoappdesc.cpython-311.pyc when run.
Ignore those files as done in other projects such as osmo-bsc.
Change-Id: I8129a4a124457411c8163089ec2bac32f3e1c2b7
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
This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I9758aaaa56b2453f33f90400342ebd1fd412ec3a
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
By default systemd will execute service with root directory
(or home directory for user instance) which might result in
attempts to create files in unexpected place. Let's set it
to 'osmocom' subdir of state directory
(/var/lib for system instance) instead.
Related: OS#4821
Change-Id: If21e3471ec129892ff8b410db30d8ce0e4014e05
Pau Espin
Harald Welte
Oliver Smith
Vadim Yanitskiy
Neels Hofmeyr
arehbein