Age | Commit message (Collapse) | Author | Files | Lines |
|
Now that we're adding support for M3UA-over-TCP, the transport layer
role is no longer an SCTP specific paremeter, but rather a generic one.
This is also the case for the OSMO_SS7_ASP_PROT_IPA, which employs TCP,
and for which we can also choose between the client and server role.
The 'sctp-role' now becomes an alias to 'transport-role', so that
we keep backwards compatibility with old config files.
Change-Id: Iab6c898181d79a5ed2bea767ee90e55bc3af16a5
Related: SYS#5424
|
|
RFC 4666 section 1.3.1 states that "TCP MAY be used as the underlying
common transport protocol" under certain scenarios. There is even
IANA-allocated TCP port 2905 for that purpose (see section 1.4.8).
Since TCP is a stream oriented protocol, so we need to handle message
boundaries ourselves by reading the M3UA header to know the PDU length.
Change-Id: I8c76d271472befacbeb998a93bbdc9e8660d9b5d
Related: SYS#5424
|
|
Change-Id: Ia90776c9c3efc3402d59c4f10e5f2cf26274b3f8
Related: SYS#5424
|
|
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
|
|
* 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
|
|
Change-Id: Ia75502874e3a07dbd6b685a6721adaedb429e904
|
|
Related: SYS#6558
Depends: libosmo-netif.git Change-Id I5343c7659881b29e0201e72badbc2d07e1ef2dca
Change-Id: I4c104f0313b549efab7fae2e81a163474e9bcd4b
|
|
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
|
|
Caught by linter:
ERROR:POINTER_LOCATION: "foo* const* bar" should be "foo * const*bar"
Change-Id: Icb3adff115e77fca273fdbfda6c7de1ddf1b61cd
|
|
Related: SYS#6511
Change-Id: Ib62e19f2e528e8b2792cbb51a5900dc3463ebd06
|
|
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 (83db938859428ce3835239e2692d93c557b750e1) 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
|
|
was explicitly defined in VTY
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
|
|
sctp server
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
|
|
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
|
|
Change-Id: I1c0f501a7f828499c6112cab8aece20f7c34c118
|
|
Related: SYS#6319
Change-Id: I873ea30e8f64280487769668c748c67ce4ff4023
|
|
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
|
|
Change-Id: I6b9cb5acffdf690f65e14dbdda7213b2e75c7ee1
|
|
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
|
|
Ensure there is no diff to prepare to run this in CI.
Related: OS#5884
Change-Id: I3909fd5a406e21f348ad8c1d5adc267551bfe2b2
|
|
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
|
|
SCCP RLSD message might have up to 130 bytes of optional data according to ITU-T Rec Q.713 §4.5 - add helper which
allows sending it and use it in example code.
Related: OS#5579
Change-Id: I92ae22d2cab5863245fba3d904a300055fda34fe
|
|
Previously DT1 message sent via osmo_sccp_tx_data() was silently truncating data if it was over 256 bytes. Let's fail
explicitly and let caller handle this.
Related: OS#5579
Change-Id: I8a67bc40080eb1405ab3b0df874e3ea20941a850
|
|
Add convenience helper to check if particular connection ID exists and use it to
properly report errors when attempting to send messages over non-existent connections.
Change-Id: Iffedf55b4c292ee6b2f97bcdeef6dc13c050ce01
|
|
Related: OS#5579
Change-Id: I398e3efa3e097de8907617cfdf363e1d3b96f666
|
|
Limit length of optional Data parameter to 130 bytes to conform with ITU-T Rec Q.713 §4.2..§4.5 while receiving SCCP messages.
Related: OS#5579
Change-Id: Icc3bd0a71b29cf61a259c5d97e7dd85beb4397bd
|
|
Add a new function similar to osmo_sccp_addr_by_name, but search in a
specific ss7 instance's addressbook instead of searching in the global
address book. This is needed for osmo-bsc-nat, which uses two separate
instances at the same time.
Related: SYS#5560
Change-Id: I0f38b0d038b0dd8cd355e7284e5b56d438811bd9
|
|
Move return type to the same line as the name of the function to follow
coding guidelines.
Change-Id: I10475aa395a1cfd49ff62c758f99f9689a0038d0
|
|
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ia450b630e0b60b38835f599c93985bbe97c50d2f
|
|
This adds some very basic rx/px rate counters to the SS7 AS and ASP
OsmoSTP> show rate-counters
SIGTRAN Application Server 0 (as-rkm-1):
rx:msu:total: 86078 (1888/s 86078/m 0/h 0/d)
tx:msu:total: 0 (0/s 0/m 0/h 0/d)
SIGTRAN Application Server Process 0 (asp-dyn-0):
rx:packets:total: 86081 (1888/s 86081/m 0/h 0/d)
tx:packets:total: 5 (0/s 5/m 0/h 0/d)
Change-Id: Idb811ca81adfe47152d484f6b981e661dc569e15
|
|
XUDT and XUDTS can be used in two situations:
a) because the sender wants to use segmentation
b) because the sender wants to include a hop counter
In this patch, we implement support for case "b" only.
Change-Id: Ic5b9486f1aeb4bb90cfe702a7ce996f5d82ded2c
Related: OS#5281, SYS#5674
|
|
This quirk allows the M3UA + SUA code to accept SSNM/SNM traffic despite
being in AS-INACTIVE state. This is forbidden by the RFCs but there
are some implementations that apparently just don't care what is
specified.
Change-Id: I193dd546b3e3c00e29f192d0d1bf7819b3e194be
Closes: OS#5148
|
|
The M3UA RFC talks about this message being used in ASP->SG direction,
not the other way around.
Closes: OS#5147
Change-Id: I36ff172b47142a877b37bbd149073bef35b36a74
|
|
A quirk is an implementation work-around in order to establish
interoperability with another implementation, either a buggy one or
one that follows a different interpretation of a given spec.
For now, we introduce a first quirk affecting when we (in ASP role)
send an ASP-ACTIVE message to the SG.
Closes: OS#5145
Change-Id: Idd947ea39d743eb1bc9342ad9d098036821da45b
|
|
Otherwise we run into the problem that a route with mask 0xffffff
differs from one with a mask of 0x3fff despite having only 14 bit
point code length and them being logically equal.
Change-Id: I5d5c828de45724d93a0461bb0dd7858fd8378acd
Related: SYS#5422
|
|
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
|