Anywhere else in the Osmocom code base, we arrange headers in
include/osmocom/foo/ and pass -I ${root_srcdir}/include/.
This way including an osmocom header always has the format
#include <osmocom/foo/bar.h>
whether we are including from the local source tree or from $prefix.
For some reason not clear to me, the mtp and sccp folders, even though they are
being installed to $prefix/include/osmocom/, were kept *next* to the osmocom/
dir, instead of inside it. Fix that weird situation.
The motivation is that I wanted to use a definition from sccp_types.h in a
public-API header. That is impossible if it requires
#include <sccp/sccp_types.h>
in a local build, but
#include <osmocom/sccp/sccp_types.h>
for any other source tree using libosmo-sccp. After this patch, both are
identical and including works without quirks. (The other patch that needed this
has changed in the meantime on and no longer needs this, but this still makes
sense for future hacking.)
The installed result does not change, since both mtp/*.h and sccp/*.h have
always been installed to $prefix/include/osmocom/{mtp,sccp}/. This merely
changes their position in the source tree.
The most curious situation before this is that any patch #including
<osmocom/sccp/sccp_types.h> might not get a notice that the header didn't
exist, but might instead include an older system-installed file.
Change-Id: I1209a4ecf9f692a8030b5c93cd281fc9dd58d105
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
For 'show cs7 instance 0 ssn', fix doc string for 'ssn', and add missing one
for the SSN arg. This fixes depending builds that see VTY test failures due to
the missing doc string.
For 'show cs7 instance 0 connectsion', fix doc string for 'connections'.
Change-Id: I214ea51fc6bfa2a9a4dd7c34b43add0c77ffe22e
Instead of allocating ss7->sccp in various places, unify that in one common
function. We shouldn't spread the decision what to pass as priv pointer around
everywhere. There is no functional difference.
This is preparation for a patch where the sccp_instance gets allocated from the
telnet VTY: I would prefer to hide all allocation details from that code; which
also makes sense for the other callers of osmo_sccp_instance_create().
Change-Id: Ie912898c66d31ce4ac8eeeea5a6ddc3f821c06f7
The 'show cs7 instance 0 sccp-addressbook' command should not be inside the
'cs7' node. That defies the point of naming the instance again, and it falls
out of place of all the other 'show cs7' commands on the VIEW and ENABLE nodes.
Drop the old command within the 'cs7' node without substitution or deprecation.
At the same time, drop dash from 'show cs7 i 0 sccp-addressbook'
There are various other show cs7 commands already defined in sccp_vty.c, which
have 'sccp' as a separate string. Conform to that.
Change-Id: I80e0bc0a91bcd3fb75372045db34592d2d663d41
Fix typo "to long".
Say 'cs7 instance' instead of 'ss7 instance': we are interacting with a user on
the telnet VTY, and that user is configuring a 'cs7 instance'. Especially a
lowercase 'ss7' is potentially confusing ("is there an 'ss7' node?").
Changes show in ss7_asp_test.vty.
Change-Id: Iebb976531576268d58338895a4baadbca6137b80
Define SCCP_STR in sccp_internal.h, because I know that I want to also use it
in osmo_ss7_vty.c.
Fix "Signaling" to "Signalling" upon copying the old string.
Change-Id: Ic93e4771147070a9222c73f80b5f7c29ae7eec35
Allowing a whole line of characters as address book name would be a lot,
allowing 512 characters is completely ridiculous. That's more than this entire
commit log message! 32 is plenty.
All linking programs should automatically get the limitation in their VTY
parsing without any changes.
Configs with sccp-addr names > 31 chars will no longer work after this.
Change-Id: I3ecf83d620e46f7bf9857fc60a93d4e240ee3b8a
When entering an 'cs7' / 'asp' node, and invoking 'do show cs7 i 0 asp', the
ASP's FSM instance is not yet allocated. Hence attempting to print its status
will result in a segfault.
Spotted this while writing VTY tests that will follow shortly in another patch
(I6a28684fa24d6e7de568623444297028eba2ab8c).
Change-Id: I3ebf498492c6ba69a5dd1c9f36acdabfd6fbdfe1
The SCCP timer units are not what the comments say:
Milliseconds are 1000 * seconds, not 100.
Also, microseconds are 1000000 * seconds.
Interestingly enough, MSEC_TO_US() tried to fix the wrong hundredth-seconds to
microseconds by multiplying by 10, however, it should end up at a factor of a
million, not a thousand, hence would result in wrong sub-second fractions.
But, since none of the current timers use sub-second fractions, none of the
timers are actually affected in practice. Hence this patch is merely cosmetic.
Since all use of the timer constants is wrapped in MSEC_TO_US(), we can
transparently fix all those values and their use:
- define the constants in milliseconds (replace "100" with "1000").
- in MSEC_TO_US(), divide-and-mod by 1000.
- in MSEC_TO_US(), actually calculate microseconds.
BTW, I am about to make the timers VTY configurable, but before I get confused,
I'd rather fix these units first.
Change-Id: Ia6c893f734fbdc88873c4ef80f6cacf01ee7763a
Testing with an actual SCCPlite MSC, I see the IPA connection starting out by
the MSC sending an IPA ID ACK. Make the ipa_asp_fsm match that.
Change-Id: Icffda98579e676ab6ca63c9c22cf5d151c4fe95f
From LeakSanitizer report:
Indirect leak of 384 byte(s) in 3 object(s) allocated from:
#0 0x7f986da27d99 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7f9868d0cb61 in _talloc_zero (/usr/lib/libtalloc.so.2+0x5b61)
#2 0x7f986ad33766 in xua_msg_add_data /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:73
#3 0x7f986ad343c3 in xua_from_msg_common /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:143
#4 0x7f986ad347d2 in xua_from_nested /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:201
#5 0x7f986ad65563 in m3ua_rx_rkm_reg_rsp /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_rkm.c:431
#6 0x7f986ad65f96 in m3ua_rx_rkm /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_rkm.c:510
#7 0x7f986ad31ef7 in m3ua_rx_msg /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:749
#8 0x7f986ad7c1e8 in xua_cli_read_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7.c:1590
#9 0x7f986a66cdb4 in osmo_stream_cli_read /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:192
#10 0x7f986a66e091 in osmo_stream_cli_fd_cb /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:276
#11 0x7f986994e795 in osmo_fd_disp_fds /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:217
#12 0x7f986994eabb in osmo_select_main /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:257
#13 0x5630cb294bd3 in main /home/pespin/dev/sysmocom/git/osmo-msc/src/osmo-msc/msc_main.c:697
#14 0x7f98678b806a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#15 0x5630cb292649 in _start (/home/pespin/dev/sysmocom/build/new/out/bin/osmo-msc+0x185649)
Following code paths:
m3ua_rx_rkm_reg_rsp
xua_from_nested
xua_from_msg_common
xua_msg_add_data
talloc_zero (part)
handle_rkey_reg_resp
Take the chance to fix the same issue in m3ua_rx_rkm_dereg_rsp.
Change-Id: I0b15d81099a9f8274b7e39962caa339da644e0dc
Fixes following error provided by LeakSanitizer:
Indirect leak of 1496 byte(s) in 11 object(s) allocated from:
#0 0x7f1eb3332d99 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7f1eae617b61 in _talloc_zero (/usr/lib/libtalloc.so.2+0x5b61)
#2 0x7f1eb063e365 in xua_msg_alloc /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:49
#3 0x7f1eb0650ee3 in osmo_sccp_to_xua /home/pespin/dev/sysmocom/git/libosmo-sccp/src/sccp2sua.c:1298
#4 0x7f1eb0668d6a in mtp_user_prim_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/sccp_user.c:173
#5 0x7f1eb068ba86 in deliver_to_mtp_user /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:94
#6 0x7f1eb068bf00 in hmdt_message_for_distribution /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:133
#7 0x7f1eb068d345 in m3ua_hmdc_rx_from_l2 /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:275
#8 0x7f1eb063c08f in m3ua_rx_xfer /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:586
#9 0x7f1eb063cea6 in m3ua_rx_msg /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:739
#10 0x7f1eb0687188 in xua_cli_read_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7.c:1590
#11 0x7f1eaff77db4 in osmo_stream_cli_read /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:192
#12 0x7f1eaff79091 in osmo_stream_cli_fd_cb /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:276
#13 0x7f1eaf259795 in osmo_fd_disp_fds /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:217
#14 0x7f1eaf259abb in osmo_select_main /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:257
#15 0x55666c1bebd3 in main /home/pespin/dev/sysmocom/git/osmo-msc/src/osmo-msc/msc_main.c:697
#16 0x7f1ead1c306a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#17 0x55666c1bc649 in _start (/home/pespin/dev/sysmocom/build/new/out/bin/osmo-msc+0x185649)
The code path is the following, starting from mpt_user_prim_cb:
mtp_user_prim_cb
osmo_sccp_to_xua
xua_msg_alloc
scrc_rx_mtp_xfer_ind_xua
sccp_scoc_rx_from_scrc
scrc_node_6
scrc_node_4
scrc_translate_node_9
So the xua_msg is created in mtp_user_prim_cb through osmo_sccp_to_xua
and then handed over to scrc_rx_mtp_xfer_ind_xua which transfers the
xua_msg and thus should take ownserhip of it, and consecuently freeing
it once it's done using it.
Change-Id: I43e159c82b64bd85b185f77ee19b6455a96e082f
In libosmocore Change-ID I1834d90fbcdbfcb05f5b8cfe39bfe9543737ef8f
we have introduced ipa_ccm_id_resp_parse() as a bugfixed replacement
of ipa_ccm_idtag_parse().
The main difference is that the returned "value" parts now have
a correct reported "length", whereas before this commit they all
reported a one-byte too-long "length" for each IE.
Change-Id: I3c79d3bb56cc1370b9922e64d13d2d5508fd8039
1: Do not call xua_msg_alloc() which is later bluntly overwritten by
m3ua_xfer_from_data().
2: After dispatching to m3ua_hmdc_rx_from_l2(), call xua_msg_free().
Related: OS#3393
Change-Id: I0918f9bbc15b036619f1c25a133b69819b2a30fa
So far the tall_xua ctx used to allocate from in xua_msg_alloc() was never
initialized, actually hiding memory leaks from the talloc report.
Add this API to allow branching the xua_msg ctx off a sane root ctx.
Explicitly initialize tall_xua to NULL, so that, if xua_msg_ctx_init() isn't
called, tall_xua is still guaranteed to not be a random pointer.
osmo-bsc will use this function to hook the tall_xua ctx to osmo-bsc's own root
ctx.
Change-Id: I618878680a096a7f7fc2d83098590f2e4cb08870
Before this, the log looked like it parsed the same address twice with
differing results:
DLSUA DEBUG sccp2sua.c:333 Parsed Addr: RI=2,PC=1196,SSN=254
DLSUA DEBUG sccp2sua.c:333 Parsed Addr: RI=2,PC=100,SSN=254
Adding the IEI clarifies this:
DLSUA DEBUG sccp2sua.c:333 IEI 259: Parsed Addr: RI=2,PC=1196,SSN=254
DLSUA DEBUG sccp2sua.c:333 IEI 258: Parsed Addr: RI=2,PC=100,SSN=254
(I'd have liked to print the IEI name from sua_iei_names, but I frankly can't
figure out how to reach that value_string array "hidden" behind a xua_msg_class
struct, and neither can I find any other code doing so.)
Change-Id: I64adb31129684b2eb66fff581040017ce2f6d163
Applications may be interested in handling data for those SCTP PPID or
IPA StreamID which libosmo-sigtran doesn't implement
natively/internally.
Let's add osmo_ss7_register_rx_unknown_cb() using which applications
can register a call-back to implement whatever behaviour they'd want for
those PPID/StreamIDs.
Change-Id: I8616f914192000df0ec6547ff4ada80e0f9042a2
The variable as_name was freed before being passed to the
osmo_ss7_route_create() function. Free it later to avoid
a use-after-free crash with address sanitizer.
Found by running 'examples/m3ua_example aaa' with address
sanitizer enabled.
Change-Id: I9d724bc1d2aa8d6f8b6a67bdeafdb5f0f9136413
Related: OS#2666
We don't implement routing by global title address.
When processing an SCCP message which is routed by global title,
don't recurs indefinitely until the stack is exhausted.
Instead, return an error with cause SUBSYSTEM_FAILURE, which we
also do in other routing failure cases.
Change-Id: I24621e77ffc979bc337775f9c6a4ad9a9068625a
Related: OS#2666
Makes sure that in absence of a user-specified port number,
osmo_ss7_asp_protocol_port() will return 5000 as default port number.
Change-Id: I628ee095603742a652fd971887e02cc17d1f71b8
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
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
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
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
Neels Hofmeyr
Pau Espin
Harald Welte