This allows starting SCCP conns from within sccp_demo_user, which in
turn allows testing more scenarios in osmo-ttcn3-hacks.git
SCCP_RAW_Tests testsuite.
Related: SYS#6616
Change-Id: I7d5b3534c496dca8a3f3e66025af554bbe860c04
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.
Change-Id: I75881d115b5c2c2567c4731bcf2cabe11f367117
Closes: SYS#6600
The socket is reconfigured (and hence reopened) upon VTY node exit if
changes were stored in the address list of the xua_server
(osmo_stream_srv_link).
Related: OS#4607
Change-Id: I942edff7695efeea7753f22e31c2098c201290ff
The local address is removed dynamically from the socket if it is
already created. For remote addresses, it doesn't make any sense (and
there's no API to do so) because the remote address list passed to it is
only used at connect() time, when the socket is created. During the
initial hanshake, the remote provides its own list of remote addresses.
Related: OS#6077
Related: OS#4607
Depends: libosmocore.git Change-Id Ifc6e7d643c2a0c53f479bfd0d5c36d08c0c01953
Change-Id: I554aee92285bd72eb90c6daf47b37055cb3067aa
This makes it easier to find out where the AS struct is allocated, plus
also split between inst code looking up + checking + allocating and the
code doing the allocation and initialization of the AS.
Change-Id: Ie237ec8ac4b2e15b76fce3b3a56f47a59fdcc76e
* LUDT/LUDTS is now properly received and passed along to the app.
* LUDT/LUDTS is now used if the data to transmit spans more than 255
bytes.
Related: SYS#6566
Change-Id: Ic91abfc921f5e4f36045bfa325333112cddd9fa6
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
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
Max
Pau Espin
Harald Welte
Oliver Smith
Vadim Yanitskiy