As warned by gcc 8.1.0:
In file included from libosmo-sccp/include/osmocom/sigtran/osmo_ss7.h:7,
from libosmo-sccp/include/../src/xua_internal.h:3,
from libosmo-sccp/tests/xua/xua_test.c:21:
/include/osmocom/core/utils.h:13:34: error: division ‘sizeof (const uint8_t (*)[12] {aka const unsigned char (*)[12]}) / sizeof (const uint8_t[12] {aka const unsigned char[12]})’ does not compute the number of array elements [-Werror=sizeof-pointer-div]
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
^
libosmo-sccp/tests/xua/xua_test.c:371:45: note: in expansion of macro ‘ARRAY_SIZE’
#define PARTARR(x, data) { .tag = x, .len = ARRAY_SIZE(data), .dat = (uint8_t *) data }
Change-Id: Iad5703d68fee26fc83958741512820d2539e604e
A primitive allocated in lm_timer_cb() with xua_xlm_prim_alloc()
was never freed. Don't forget to free the msgb in osmo_xlm_sap_down().
Found by code inspection.
Also, assert that allocation suceeded like we do elsewhere.
Change-Id: Ie667b1b8beeda2aa4520a1413f51101435215cc0
Related: OS#2449
So far, 'debian/control' didn't express the minimum version numbers
of the libosmocore + libosmo-netif build dependencies. This resulted
in build failures against older libosmocore/libosmo-netif versions,
so let's make sure the minimum veresion requirements are expressed
also in debian/control.
Change-Id: I1c874880d8b2569df7acc1af554f7a4dd30e649e
Ensure we don't pass a negative integer as "unsigned int len" to
ipa_asp_fsm_wait_id_get(). This could result in a remotely-triggered
integer underflow.
Change-Id: Idf9a5c0938e6ae6d47bf85ddfec3306fa3ddb3ce
Provide a sane means of adding the -Werror compiler flag.
Currently, some of our jenkins.sh add -Werror by passing 'CFLAGS="-Werror"',
but that actually *overwrites* all the other CFLAGS we might want to have set.
Maintain these exceptions from -Werror:
a) deprecation (allow upstream to mark deprecation without breaking builds);
b) "#warning" pragmas (allow to remind ourselves of errors without breaking
builds)
As a last configure step before generating the output files, print the complete
CFLAGS and CPPFLAGS by means of AC_MSG_RESULT.
Change-Id: Idb579d546d6f228e86bd49ca15aa87b86978205a
It seems we have been sending the wrong numeric value in SCCP connection
refusal due to an unqeuipped user. It turns out our list of refusal
causes was missing one entry, causing an off-by-one for this refusal
cause. While at it, add a comment which section of which spec is
relevant for this enum.
Change-Id: I113645bd6df1ec9ae5137977028df38560fc4789
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ia0d15a2814b08bc3f052a1ed12dbb68bade55309
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ib7abf69cfcf4c56273223054b280458451e6c2f6
Do not print the GTI if gti is set to OSMO_SCCP_GTI_NO_GT and no GT is present
in the address.
If addr->gt.gti is set to OSMO_SCCP_GTI_NO_GT, i.e. currently always,
osmo_sccp_addr_name() and osmo_sccp_addr_dump() output
",GTI=NO_GT" in every address dump, which is useless clutter. Drop that.
However, if a Global Title is flagged in addr->presence, still output the GTI
to highlight situations where GTI might mismatch the presence of a GT.
Change-Id: I9f87b2b703223ecb5d0442b6199c5b779fe544a1
In osmo-stp, cmd "local-ip" inside node "listen m3ua 2905" was actually
not being applied, because the server was created + bound at "listen" command
time using NULL as IP, and at "local-ip" time the IP was changed but the
server was not re-bound using the new IP, so it kept listening at
0.0.0.0.
With this patch, we defer binding the socket to "local-ip" cmd time,
after the IP has been applied.
As a result, if no "local-ip" command is provided, then the bind never
happens, which means it is now mandatory that users of osmo_ss7_xua_server_create
API not using osmo_ss7_xua_server_set_local_host call new provided API
osmo_ss7_xua_server_bind. Another new API osmo_ss7_bind_all_instances is
provided to easily make sure all servers are bound after configuration
process. This is specially important for servers which doesn't contain
the "local-ip" parameter.
Users of osmo_sccp_simple_server API are not affected by this change,
and they not requrie to call any new API.
Furthermore, using osmo_ss7_xua_server_bind in VTY code ensures the xUA
server is automatically bound to the new address if the operator changes
the "local-ip" cmd at runtime.
Related: OS#2647
Change-Id: I79738963d633bec70705ff159c5b2127cd498aa2
In I19cb83302aaa404ab1a2d92e6f2aec43d0380426 I set the headroom of
msgb's for SCCP User primitives to zero, assuming that we wouldn't
need any headroom in those primitives.
According to pespin, osmo-msc however needs this headroom:
DLSCCP <002e> sccp_user.c:156 Delivering N-CONNECT.indication to SCCP User 'OsmoMSC-A'
msgb(0xadfba0): Not enough headroom msgb_push (0 < 264)
So let's make sure the new SCCP User primitives are allocated with the
same headroom, just like before I19cb83302aaa404ab1a2d92e6f2aec43d0380426.
Change-Id: I92d7648f8ffd034341e2f12aa79dd3d16ec3a98d
It's a bad idea to use sccp_msgb_alloc() for SCCP User Primitive msgbs.
The rationale is quite simple: The SCU msgb's are used for wrapping
osmo_prim. The user payload data (e.g. BSSAP) in such primitives is
found at msgb->l2h. However, user payload data is optional. So in a
SCU primitive without user data, we must have msgb->l2h == NULL.
The old behavior resulted in bogus data (actually the sccp_user_prim)
to be contained in the DATA section of SCCP messages such as RLSD/RLC.
Also, the old implementation of scu_msgb_alloc() discarded the 'name'
argument and replaced it with a static "SCU" which was of course another
bug.
Change-Id: I19cb83302aaa404ab1a2d92e6f2aec43d0380426
Related: OS#2732
When we destroy a FSM, we (logically) must osmo_timer_del() any running
timers that the FSM might have been using. This was not implemented
for xua_as_fsm, xua_asp_fsm and also missing from ipa_asp_fsm.
Change-Id: I670df831d7bc30de48ed4277648a461e1e1968fa
Related: OS#2668
The first port is the remote one, and the second port is the local one,
according to cs7_asp_cmd doc and code. In the same config, the ports for
the servers are used and for the local port in the client we don't care,
that's why we use 0 there.
Change-Id: I0fafd07614068a27c19bc2dfa6491b4b0c6737fb
In all other Programs we have the VTY like OsmoBSC, OsmoMSC, etc.
so let's make sure osmo-stp also uses OsmoSTP and not osmo-stp.
Change-Id: Ic91010779ad22c41e28ed4cf43c2e3ab679214b5
From the STP point of view: In order to be able to route messages back
to an IPA client, we need to create a route at the time we have
successfully identified the AS for this client based on the name
presented in the IPA CCM ACK "name" field. Once the IPA client is
destroyed, the route must be deleted again.
With this commit present, we can have an IPA client (such as
osmo-bsc-sccplite) connect to OsmoSTP and exchange BSS[M]AP
with an M3UA-speaking osmo-msc. Basically, the STP reaches
the point where it can translate between IPA-style SCCPlite
and proper M3UA/SUA on the other side.
Change-Id: I901f06c5d0f2eae60f8d931215ed65190330ce66
When we receive a SCCPlite message from an IPA peer, it may simply
contain a SSN number but no point codes. Similarly to creating a fake
MTP routing label from override DPC and routing key OPC, we can also
add that point code information to the SCCP header. This way the rest
of the SS7 network can handle the message and route it accordingly.
Change-Id: I4a2ff063e3c060641b3fd181a1cd600da3ec568b
As IPA is a transport layer underneath SCCP, and we don't have MTP-level
OPC and DPC fields in it, we are using the "point-code override dpc"
feature for setting the pseudo-M3UA DPC on incoming Rx packets,
and we use the PC from the routing context as pseudo-M3UA OPC.
However, we were so far only storing this in the M3UA data header,
and not in the xua->mtp.{opc,dpc} members, which are consulted
during the routing decisions.
Change-Id: I5e2244620cd48f848382eb595ce59c6212069788
So far, the config would log an error upon config parsing, and then continue to
use defaults, which is super easy to miss. On errors, return CMD_ERR_INCOMPLETE
to abort the program in a config parsing error.
Be fatal for re-using an already defined addressbook entry in another cs7
instance, and for having a too long addressbook entry name.
Though it is mixing in cosmetic changes, add "Error:" to the output and arrange
the erratic name to the end of the message, as is customary for error messages.
Related: osmo-bsc Ia4e58902a2d3757b266cf35ac89f256cfb8f0eec
Change-Id: I2f71b9c4dd30f919d2054da81283dd7035f44f60
It can be cumbersome to derive the ss7 instance needed to pass to
sccp_addr_name(), because struct osmo_sccp_instance is opaque and only
available in sccp_internal.h, within libosmo-sccp.
Add osmo_sccp_inst_addr_name() which derives the ss7 instance from the internal
knowledge of the osmo_sccp_instance struct. This can save calls to
osmo_ss7_instance_find() just to do some logging of an sccp address.
Naming: first I thought to pick osmo_sccp_addr_name2(), but for some of the
string composing functions, adding a 2 already means that it is identical but
using a second static buffer (to be used twice within the same printf).
Change-Id: I70ec5c8b42682a23f11a5820431c7e34e225709b
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I185aa3a11cb63c893ed80f326f852bde95217321
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I6e3a24a32b8e06d89ac11b59bca052d56f00c78c
Pau Espin
Stefan Sperling
Harald Welte
Martin Hauke