aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2018-08-31Release new version for On-Wavesdaniel/onwavesDaniel Willmann1-0/+7
Change-Id: I69275c24aa4faad29f922c87ab72607b9c9abfb4
2018-08-31Merge remote-tracking branch 'origin/master' into daniel/onwavesDaniel Willmann25-164/+402
Change-Id: Ib31f5688771d4bb3916d28bc6613bc99e69d3728
2018-08-20ipa_asp_fsm: init: expect IPA ID ACK, not GETNeels Hofmeyr1-2/+2
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
2018-08-13xua_rkm: Fix xua_msg memleank in handle_rkey_reg_respPau Espin Pedrol1-0/+2
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
2018-08-13sscp_scrc: Fix memleak of xua_msg when handing it to scrc_rx_mtp_xfer_ind_xuaPau Espin Pedrol1-4/+12
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
2018-08-06debian/rules: Don't overwrite .tarball-versionHarald Welte1-4/+0
The .tarball-version file should contain the *source version* uniquely identifying the git commit, and not the Debian package name. With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct .tarball-version file in the .tar.xz of the nightly source packages. Change-Id: I620c96eb311be6fdd4187bdcc311ea893ad93614 Related: OS#3449
2018-08-01Migrate from ipa_ccm_idtag_parse() to ipa_ccm_id_resp_parse()Harald Welte1-1/+1
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
2018-07-27Bump version: 0.9.0.20-6265-dirty → 0.10.00.10.0Pau Espin Pedrol4-7/+41
Change-Id: Ia087b9f03a73a08f0eaa461f61c6244aaf13e3d4
2018-07-24git-version-gen: Don't check for .git directoryDaniel Willmann1-2/+2
This check is not in all our repos that use git-version-gen. Indeed it seems to be a leftover of openbsc where I think it wanted to ensure being called in the openbsc subfolder or something? libosmocore e.g. doesn't have it. In any case .git being a directory is not always true (if using git worktree) so remove this check. Change-Id: Ic14561f3b041bb94d1b60e477b18e37077ce4c32
2018-07-20remove unused -p option from getopt() call in sccp_demo_userStefan Sperling1-1/+1
Change-Id: I31f30d8c855cb5faf3173987bfe5b36f5a585d02 Depends: I7432e6fc2617e0fd77a098fcd7d14abc40db7229
2018-07-20sccp_demo_user: use point code 23 for server and 1 for clientStefan Sperling1-19/+48
Fix previous commit 4dc9088cabedc40cb9072814237ad5926b12bd35 which broke this by using -1 for local and 23 for remote PC, for both server and client. Change-Id: I7432e6fc2617e0fd77a098fcd7d14abc40db7229 Related: OS#2666
2018-07-18comment: explain xua_msg free in m3ua_rx_xfer()Neels Hofmeyr1-0/+1
Change-Id: I6211c8809eefeb94289c4c497553561b043ee619
2018-07-12fix two memleaks in ipa_rx_msg_sccp()Neels Hofmeyr1-2/+5
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
2018-07-12add osmo_xua_msg_tall_ctx_init()Neels Hofmeyr2-1/+9
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
2018-07-11cosmetic: sccp2sua.c: log the IEI for parsed SCCP addrNeels Hofmeyr1-1/+1
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
2018-07-11fix memleak in ipa_rx_msg_sccpNeels Hofmeyr1-0/+1
After m3ua_xfer_from_data() has copied the msgb data, we need to free the msgb. Change-Id: I2263751c0aa3ae32455847c7622af8be0a1e7802
2018-07-02debian: Package installed example doc filesPau Espin Pedrol1-0/+1
Change-Id: I1d955ccf83c825d7a648a7e140bb20e10f5ddff3
2018-07-02build: Install example cfg filesPau Espin Pedrol4-1/+10
Change-Id: I93b73032b9a01a1e121ecf7c0cfcf3d5558efc7f
2018-06-26Release new versionDaniel Willmann1-0/+7
2018-06-14rename m3ua_example to sccp_demo_userStefan Sperling3-6/+6
The new name allows for more natural naming of variables in TTCN3 code when this program is used as a TTCN3 test component. Consider e.g. "SCCP_DEMO_USER_VTY" vs. "M3UA_EXAMPLE_VTY". Change-Id: I92b5e16e765a1ac36371a16933389903628f8dfe Related: OS#2666
2018-06-12make it possible to pass parameters to m3ua_exampleStefan Sperling1-16/+131
There are plans to use the m3ua_example tool as an SCCP peer for a TTCN3 test suite. Make it possible to pass paramters to this tool so the user can override hard-coded default values of IP addresses, ports, and point codes. Change-Id: I52243ae926c76020de41c8dfc7263517c7263d7e
2018-06-08Introduce osmo_ss7_register_rx_unknown_cb() for unknown PPID/StreamIDHarald Welte4-13/+44
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
2018-06-06fix use after free in osmo_sccp_simple_server_add_clnt()Stefan Sperling1-1/+1
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
2018-06-05fix infinite recursion with routing by global titleStefan Sperling1-0/+7
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
2018-05-26osmo_ss7: Register 5000 as default port for IPA/SCCPliteHarald Welte1-0/+1
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
2018-05-16tests: xua_test: Fix array len computationPau Espin Pedrol1-10/+10
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
2018-05-16tests: xua_test: Fix use of wrong buffer for dest addrPau Espin Pedrol1-1/+1
All the others parts use that buffer as its name indicates. Change-Id: Ide7fe148cc762153330b08f66737816ceed96cb2
2018-05-15free msgb for primitive allocated in lm_timer_cb() of lm_fsmStefan Sperling2-0/+2
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
2018-05-08debian/control: match build dependency versions with configure.acHarald Welte1-2/+2
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
2018-05-03Bump version: 0.8.1.43-7e34-dirty → 0.9.00.9.0Pau Espin Pedrol3-5/+62
Change-Id: Ie3d11408f35509138475e7edde285e1bf5bef8e0
2018-04-17use osmo_init_logging2Pau Espin Pedrol3-6/+8
Change-Id: I0d45b9381125c496a691ac5da68190b7b3479fc3
2018-04-16ipa_asp_fsm: Prevent against integer underflowHarald Welte1-0/+5
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
2018-03-05jenkins.sh: use --enable-werror configure flag, not CFLAGSNeels Hofmeyr1-1/+1
Change-Id: I5c3f11586d48a076479eb19ed80a11caad4251d8
2018-03-05configure: add --enable-werrorNeels Hofmeyr1-0/+21
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
2018-02-20contrib: jenkins.sh: Disable doxygen in libosmocore buildPau Espin Pedrol1-1/+1
Change-Id: I7abc8862a63d448408ae43802da689fe436a0ff0
2018-02-15SS7: clarify handling of stream opening errorMax1-0/+2
Add comment clarifying why we've just logged error but continued anyway. Change-Id: I2ce55983b255b0b50fd5142d6ddf188dc8ee20b9
2018-02-10build: AC_PROG_LIBTOOL is the same as LT_INITMartin Hauke1-1/+0
Change-Id: I30f8d289d9dca892e40cd7ed787029fbcafa2dff
2018-02-09debian/control: Fix Vcs-BrowserHarald Welte1-1/+1
Change-Id: I9bc4ee167a141b91f573d038ad524a9cf097ab34
2018-01-17sccp_types.h: Fix value for SCCP_REFUSAL_UNEQUIPPED_USERHarald Welte1-1/+3
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
2018-01-07error log: sccp_scoc.c: log failure to create/resolve conn_idNeels Hofmeyr1-2/+6
Tweak the FIXMEs to clarify that we're lacking a reply to the SCCP user besides log output. Change-Id: Ib235ff8e264aaf0c2e9794f464a3ba7b54816f3d
2017-12-24cosmetic: hmrt_message_for_routing(): use osmo_ss7_route_name()Neels Hofmeyr1-12/+19
Change-Id: Iae524c38cd91383a59c64bf7919d94ba7ff350bd
2017-12-24add osmo_ss7_route_name()Neels Hofmeyr2-0/+60
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
2017-12-24add osmo_sccp_user_name()Neels Hofmeyr2-0/+23
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
2017-12-24typo: osmo-stp main: 'Erro'Neels Hofmeyr1-1/+1
Change-Id: Ibb28f48b46a4b86c62770b4d22dcf735717aeadb
2017-12-24osmo_sccp_addr_name / _dump: drop 'NO_GT' outputNeels Hofmeyr2-10/+12
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
2017-12-21Enable sanitize for CI testsMax1-1/+1
Change-Id: Ida8cfcd9a9f86e65273452afa051381bc0c16421
2017-12-20ss7: Re-bind xUA server socket after setting new IPPau Espin Pedrol5-9/+66
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
2017-12-10Allocate SCCP user primitives with headroomHarald Welte1-1/+1
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
2017-12-10sccp_helpers: don't return msgb with l2h setHarald Welte1-1/+4
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
2017-11-20xua_as[p]_fsm: Use osmo_timer_del() on FSM cleanupHarald Welte2-0/+17
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