Age | Commit message (Collapse) | Author | Files | Lines |
|
In IPA, unlike M3UA/SUA, we often have clients connecting from
random/unknown ports. In such cases, the configured remote port is '0'.
Let's use getsockname to determine the actual source ip/port of the
connected client (if any) during "show ... asp"
Change-Id: I1327a46d0b74c572d2ad828a958090af53b9fa37
Closes: SYS#5429
|
|
It's confusing to keep around a string representation of what peer the
socket was previously connected to.
Change-Id: I00d47fc355bfe24915653767ad75c1f491c060d5
|
|
Change-Id: I97a072ca32820ad34785ac6a54b00ed51b519305
|
|
The IPA server worked as expected, but the IPA client has some clear
logic bug that prevented it from working. It shows that we never
really use any of that IPA/SCCPlite stuff after years in spec-compliant
SIGTRAN land.
A client now first waits for the IPA_REQ, sends its IPA_RESP, then
waits for the ACK, ...
Change-Id: Icfc32cad7d65c94dc21754b8f879afcf34d34a92
|
|
The current code would potentially delete a route that was statically present in the
configuration in the following situation:
* route exists in config
* identical route is attempted to be added at AS-ACTIVE time, but fails
* route is unconditionally deleted at AS-DOWN time
* user now does 'write file' and has lost a route
Let's make sure we only delete the route if we added it previously.
Change-Id: I9ad5f7ebe0790e6c186b8ea1b12f204860a00cd2
Related: SYS#5422
|
|
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
|
|
SS7 routes operate on AS level, not ASP level. However, the
automatic SS7 route creation/destruction for IPA was implemented
at the ASP level. This works for single-connection ASs, but
obviously fails in load-share situations: We attempt to add the
same route several times, and we delete it at the first ASP
disconnect, even while other ASPs still exist.
This patch moves the IPA route creation/deletion from the ASP level
to the AS level. When the AS becomes active, the route is added;
when it goes to DOWN state, it is removed.
Change-Id: Idb602beae3e9bc19f7bd96355c02ec8dfd9c5d6c
|
|
Let's refuse to create exactly identical routes
Change-Id: I520415d4499a4017dfdbdfc3cd67522e1bbd1627
Related: SYS#5422
|
|
Contrary to proper SIGTRAN, IPA/SCCPlite cannot support multiple
AS within one ASP. When looking up the AS from the ASP, we cannot
blindly use routing context 0 to find the AS, as there may very well
be multiple IPA AS, and all of those have routing context 0.
As a result, the exiting look-up by osmo_ss7_as_find_by_rctx(inst, 0)
will return the wrong AS, and we will try to add/delete routes for
a completely different AS when ASPs are coming up or going down.
Instead, we need to use xua_find_as_for_asp() in order do the look-up:
It will resolve the single AS within the ASP.
Change-Id: Id295daf84f6ba1cc56cbe1761f874bea329e17ea
Cloess: SYS#5422
|
|
Change-Id: I503cc97db5f907610074cb513299a3a8505e00e5
|
|
The xua_srv_conn_closed_cb() function is shared/generic. Let's simply
write "connection closed" to avoid any confusion. As the ASP name is
printed, it should be clear which L4 protocol was used.
Change-Id: I506ccc2665a6b0af0fde3961e7e7937af7a81219
|
|
Let's inform the user about situations in which we'd want to delete
the route for an IPA client, but we run into some problem and
bail out early.
Change-Id: Ie3f57d22901f169afb2c844476b5839cc36752aa
Related: SYS#5422
|
|
When we receive a message from an IPA/SCCPlite connection, we only
have SCCP global titles and no underlying M3UA. We since have
to introduce a fake M3UA header. While we correctly set the SI,
OPC and DPC, we didn't set the NI to what is configured as default
for the cs7 instance in the VTY. For international, this problem
was hidden by the fact that international is '0' and hence our
default memory initialization.
Change-Id: I02c618fa0a0aa2a859fcd56397df9637043c8e6e
Closes: SYS#5421
|
|
Change-Id: I965dadf1ef4a8340f6995ec745607c28e7bb1f89
|
|
Change-Id: I017147905ffb69829d010f3e8416c8c5d80e7040
|
|
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Idca8e360968cb6998591737348ce520954e251b2
Fixes: OS#4865
|
|
Rremove osmo-stp_vty_reference from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-stp --vty-ref-xml cmdline switch.
Change-Id: I5bcbbdf7b737d2ce36ea877bc78c8cf191a64e1b
Depends: I613d692328050a036d05b49a436ab495fc2087ba
Related: OS#5041
|
|
Change-Id: Ia5abf7457ee7e97ec3fcd5520e5ef82ef808667a
Related: OS#5041
Depends: Ie2022a7f9e167e5ceacf15350c037dd43768ff40
|
|
Like osmo_ss7_pointcode_print(), but prints into an user-supplied
buffer.
Change-Id: I5fc7d7746eb90a9d404b6b50bf9ded6789a1c33c
|
|
Change-Id: Id09f903fc5008d074763441a26d71c4fbaf394d8
|
|
Change-Id: Ia9f01761b595d9b082d78b05d71ff549b8e33d91
|
|
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I899e63ab2702bf25514f6585fb45f5bbf60a9ac9
Related: OS#5034
|
|
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
|
|
When a SSP (Subsystem Prohibited) or SSA (Subsystem Available) SCMG
message is received, we must generate the respective primitives towards
the SCCP user.
Change-Id: I149166a25113f5d3e3536f9297bf89ff3139b9e3
|
|
Unlike M3UA, in SUA a DUNA/DAVA message can contain not just the point
code that became available / unavailable, but it can also include a SSN.
In that case, it is just the SSN that became available/unavailable, and
not the entire point code. Hence, a N-STATE.ind and not a N-PCSTATE.ind
must be delivered to the SCCP user.
Change-Id: Ie9a45b905bc17e7b695e15fe12ba4bbadcd032bf
|
|
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
|
|
M3UA and SUA have one sub-protocol called [S]SNM, through which the
SG informs the ASP about certain destinations (point codes) becoming
available (DAVA) or unavailable (DUNA) in the SS7 network.
This patch adds support for
* generating DAVA/DUAN on a SGP when the AS FSM changes to/from AS-ACTIVE
* receiving DAVA/DUNA on an ASP and informing other "SG role" AS/ASP
* processing DAUD from ASP received by SG, generating relate DAVA/DUNA
responses
Related: OS#2623
Change-Id: Id92be4691b0fd77598a6edb642c028bbd8c5b623
|
|
When receiving user-data (connectionless / connection-oriented),
we must make sure that there either
a) no routing context IE in the message, and only one AS within the ASP, or
b) a valid routing context IE for an AS within the ASP
This important input validation has been done in M3UA for a long time,
but somehow never been implemented on the SUA side so far.
Change-Id: Icc232250513009137add3b45fecbb5d2a07c0645
|
|
This way the function can be re-used by SUA.
Change-Id: I0dfc5a7a24dd068002e837dc47eb0778c503cac5
|
|
Let's factor-out the lookup of the AS into the separate function
find_as_for_asp(). This enables us to reuse this code in upcoming
support for SNM messages.
Change-Id: If58ea24efe7d54994a7ca2f0a97944bd297a8cc6
|
|
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: Ib42f46661e27b1730badc3647ca2e021e93021b7
|
|
Change-Id: Id23d90ffea855680cd7d4a16b89e652eed0cf39f
|
|
Change-Id: I517943bd11d73195de9418fb1c5d4151dab77873
|
|
We only read from it.
Change-Id: I12c17273b9d64a084f59d91fc06ae1512d70855b
|
|
Fix 'error: initializer element is not constant' with debian 8's gcc
4.9.2, triggered by XUA_HDR. Create a new _XUA_HDR without the type cast,
and use it inside of const struct definitions in xua_test.c. The new
macro is needed, because removing the type cast from the original
XUA_HDR would break other uses.
Related: OS#5004
Change-Id: I890432ee976043d012b01023f7dd2cfecf79d115
|
|
Change-Id: Iabe929a29a3c7fed2726329215097f7254cf20ca
|
|
Related: OS#4912
Change-Id: I511b2e1f4c3a9e0897cff4241ab5df12327de10d
|
|
* extend year to 2020
* Pau and Vadim have contributed significatnly
* fix typo (ot -> to)
Change-Id: I5c23e704dd958faf450b2427ff706ac65d4848f4
|
|
Change-Id: I667b245e468b9a2bcc5c9a1a04d59a940e71b24c
Related: OS#4421
|
|
Change-Id: If77aea2223891663d465f162614ce8db18168c09
Related: SYS#4937, OS#1601
|
|
See https://lists.osmocom.org/pipermail/openbsc/2020-October/013278.html.
Change-Id: I727e27f4d4d9550e34cb0073134a9ed7faae3c66
Depends: I8baf31ace93c536421893c2aa4e3d9d298dcbcc6
Related: SYS#4937
|
|
Change-Id: Iadd34a167a7712796b2501f6a75b5a8d26a828eb
|
|
Change-Id: Ia7f9d891ea92abd20855374b936aac8b28ae15df
|
|
Change-Id: Ibdae89ed251e46814a4af65c6384225575a29039
|
|
The ipv4 addr in addr->ip.v4 is already in network byte order, as it's
usual in struct in_addr (see sua_addr_parse_part()).
So the code in there was simply calling ntohl() because
msgb_t16l16vp_put_u32() is calling htonl() on the given parameter before
storing it. Let's simply use msgb_t16l16vp_put() directly and avoid a
double byte swap which only adds confusion.
Change-Id: I70a94ee1b459d56116f0c6a6c7c3b778a939b7ea
|
|
Change-Id: I5bd69e8400fd2d9251b5d4edd9bf3514e1194b5a
|