aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-09-23add osmo_sccp_addr_to_id_c()neels/lcsNeels Hofmeyr2-8/+39
Change-Id: Iadd34a167a7712796b2501f6a75b5a8d26a828eb
2020-09-22add osmo_sccp_addr_to_str_c osmo_sccp_inst_addr_to_str_cNeels Hofmeyr2-14/+46
Change-Id: Ia7f9d891ea92abd20855374b936aac8b28ae15df
2020-09-14sccp_helpers: Support printing IPV6 SCCP addressesPau Espin Pedrol1-2/+8
Change-Id: Ibdae89ed251e46814a4af65c6384225575a29039
2020-09-14xua_msg: Get Rid of confusing double network byte order swapPau Espin Pedrol1-1/+1
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
2020-09-14sua: Support SUA_IEI_IPv6Pau Espin Pedrol2-2/+8
Change-Id: I5bd69e8400fd2d9251b5d4edd9bf3514e1194b5a
2020-09-05add OSMO_SCCP_ADDR_T_MASK for osmo_sccp_addr_cmp()Neels Hofmeyr2-2/+3
Avoid magic number 0xffffffff and rather provide a mask value for all address components. Change-Id: I13ff0858e496c4392b8e1590d62f7eb80f191a07
2020-09-04Fix default ASP local addr if remote addr contains only IPv4Pau Espin Pedrol1-2/+14
Otherwise it would end up attempting to connect "::" -> "1.2.3.4" which would fail during osmo_sock_init2_multiaddr(). If local address is unset (default), but only IPv4 addresses are set on the remote, then one must use "0.0.0.0" instead. Change-Id: I33faf1291e9105bba2e816c01a6b4854cf13d5e0
2020-09-03enum osmo_sccp_ssn: rename to OSMO_SCCP_SSN_SMLC_BSSAP_LENeels Hofmeyr1-1/+4
Quoting 3GPP TS 23.003 8.2: 1111 1010 BSC (BSSAP-LE); 1111 1011 MSC (BSSAP-LE); 1111 1100 SMLC (BSSAP-LE); Hence the SMLC one should also be named *_BSSAP_LE. I'm certain no other osmocom code is using this SSN yet, but anyway keep a backwards compat shim #define. Change-Id: I3e0c1be0ebbd3883d024174d1e7e9167a8281cfb
2020-09-01Fix (2) change in ss7 server default listen addr, keeps ↵Pau Espin Pedrol1-2/+7
backward-compatibility behavior This patch is a fixup or extension of commit 96d348efbf29888f5ef923251c7d51d45a897c0b, which only fixed the default values for "asp" VTY node, but not for the xua server's "listen" node. As a result, without this patch, by default the SCTP server socket will only listen on IPv4's "0.0.0.0", since NULL is resolved by getaddrinfo to it instead of "::" as first candidate. Fixes: 96d348efbf29888f5ef923251c7d51d45a897c0b Change-Id: Ifbc8df854d1f1e9b07b11911ad5da8cdf9f2080a
2020-08-28Fix matching IPv6 anyaddr :: in osmo_ss7_asp_find_by_socket_addrPau Espin Pedrol1-3/+19
Change-Id: I36dd8f1978e3b7b785660745378c9cf77a21a566
2020-08-28Validate correctly against IPv6 addresses in osmo_ss7_asp_peer_set_hosts()Pau Espin Pedrol1-10/+21
Until now, host list validation was only taking into account a set of ipv4-only addresses. As a set can contain now IPv4 and Ipv6 addresses at the same time, we need to do ANYADDAR validation against addresses of that specific version inside the set. Change-Id: I18f3cc59149d478259d7afc456bdc5213c1406e5
2020-08-28Fix change in ss7 server default listen addr, keeps backward-compatibility ↵Pau Espin Pedrol1-4/+39
behavior Previous commit changed the default bind/listen address of the server from NULL (0.0.0.0) to 127.0.0.1, hence breaking some setups where no "local-ip" was defined and hence from then on were only listening on localhost by default. Let's instead bind to "::" if IPv6 is available, which covers any IPv6 and/or IPv4 address. If not available, keep binding to 0.0.0.0. Similarly, if IPv6 is available set default remote to both ::1 and 127.0.0.1 to allow it working against processes listening on IPv4 or IPv6 addresses. Change-Id: Id4718267df2390f70cec519042dc12bac0cd2876
2020-08-28Revert "Revert "Introduce SS7 IPv6 support""Pau Espin Pedrol5-18/+38
Actual fix for the issue is applied in next commit. This reverts commit ee8128929755d88ace4e1e566448a14a970b1b40. Change-Id: I8b66dd97f47f1b2b72c101b9ce4444e75eb744c0
2020-08-28vty: log and return warning if adding ss7 host to set failsPau Espin Pedrol1-2/+8
Change-Id: Ib86ef3c3db6096a1e38690b9e598a58387e6b38e
2020-08-28Revert "Introduce SS7 IPv6 support"neels5-38/+18
This reverts commit 0b39f2cf7bab5cf3924d8b0b753f41b5b0cabd25. Reason for revert: Breaks ttcn test suites (at least for osmo-bsc) with osmo-stp error log: "MTP-TRANSFER.req for DPC 187: no route!" The breakage is fixed by only reverting the NULL -> "localhost" change back to NULL. But the commit log indicated a reason for this, so rather reverting the entire commit for now. Change-Id: Ia97832f4e3ed646457d5c6eeba27352f1153edec
2020-08-24Fix finding ASP on IPv6 connectionsPau Espin Pedrol1-7/+36
Change-Id: I09226a5cecc37dd4676acd61c2051befe5234cb3
2020-08-24Introduce SS7 IPv6 supportPau Espin Pedrol5-18/+38
In osmo_ss7_vty_go_parent, "127.0.0.1" is changed to "localhost" to let local NSS decide whether to use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since IPv6 takes precedence over IPv4. Similarly, the default source addr needs to be changed from NULL to "localhost" since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns first IPv4 "0.0.0.0" and later "::", which is inconsistent with getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and dst=IPv6(::1), which is incompatible and will fail. In any case, this change doesn't affect users of osmo_sccp_simple_client because the APIs set both src and dst addresses. Change-Id: I69c48819b70635c92fa404cafd917af7802d517c Depends: libosmo-netif.git Change-Id Ie6bb17a9af6ca21d5e350f9c9d2d74c97c5a00af
2020-08-20configure.ac: Fix trailing whitespacePau Espin Pedrol1-1/+1
Change-Id: I7df2b2cd0f8fa2f4f9a1e345735aa944f93e95a4
2020-08-20Support setting rt-prio and cpu-affinity mask through VTYPau Espin Pedrol6-5/+49
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c Related: SYS#4986 Change-Id: Ib9faa68c1cd09a026909c792a1fd5557c9893fe3
2020-08-20doc: Update VTY reference xml filePau Espin Pedrol1-3/+126
Change-Id: I83312c3f22af54db346f4babc9470ff9432ceae4
2020-08-13debian/control: change maintainer to the Osmocom team / mailing listVadim Yanitskiy1-1/+1
Change-Id: Ib149fd7716343d0e441c4671832efd05a62d67da
2020-08-13Bump version: 1.2.0.53-d897-dirty → 1.3.01.3.0Harald Welte1-0/+74
Change-Id: I70c01be02bf88ac4191dcd28cb6b3516bc096263
2020-07-29SCOC: log message type that was received for unknown local referenceHarald Welte1-2/+2
A message like DLSCCP <0011> sccp_scoc.c:1653 Cannot find connection for local reference 1154 is not incredibly useful, as you don't even know what type of SCCP/SUA message had been received. Change-Id: I18af9d7e9ea4877b13bf98a980b0ba97c5ed6599
2020-06-26osmo_sccp_simple_client_on_ss7_id(): do not care about ASP nameNeels Hofmeyr1-8/+28
Our manuals explain that the cs7 config automatically adds missing parts. However, previous code requires an ASP to exactly match the default name that the autoconfiguration would choose -- that is unintuitive. If a config included only an ASP, or both AS and ASP but omitting to add the ASP to the AS, auto configuration would pick it up iff it exactly had the name the application chose. For osmo-bsc, that was 'asp-clnt-msc-0', if 'msc 0' is the first MSC in the config file. For osmo-msc, it is 'asp-clnt-OsmoMSC-A' or 'asp-clnt-OsmoMSC-A-Iu' and so forth, so it is not always clear which name the user should pick to get the ASP used by auto config. Refactor so that any ASP with a matching protocol that is not associated with any AS yet is picked up by the auto configuration, i.e. associated with the AS etc., regardless of the name chosen in the config file. Related: OS#4635 Change-Id: I2954e0167729fd0b1a7d0144a5b5775fc1c44c35
2020-06-25osmo_ss7: remove use-after-free of stream_server after close_cbHarald Welte1-1/+2
In I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa we fixed some problems regarding rapid open/close cycles of inbound M3UA client connections. Unfortunately the fix now triggered another bug. xua_srv_conn_closed_cb() is called by libosmo-netif stream code whenever a connection (socket) is closed. As the stream_server is de-allocated right after this call-back, the call-back must make sure to remove any pending references to the stream_server. Change-Id: I2464cf524f1f91bfad10ff1861a03bf1461dfed8 Related: OS#4625
2020-06-25Revert "sccp_simple_client: only restart ASP if it was created"neels1-8/+8
This reverts commit ec20a6164b046f9b6190dc886c3cc8a8e1445739. Reason for revert: this patch makes specific variants of 'cs7' config fail. In short, if AS and ASP are configured and connected, the ASP is never started. See OS#4635 for elaborate details. Related: OS#4635 Change-Id: Id6e1fd69f312e5dc74e8718b2e2e678ad54bc16b
2020-06-24Fix race during fast re-establishment of inbound M3UA connectionsHarald Welte1-1/+12
When a client closes and instantaneously re-opens a SCTP socket for an M3UA connection, there is a chance that both the "shutdwon event" (old connection socket becomes readable for sctp event) and the "init event" (listen-fd becomes readable) happen during the same scheduler interval / select() cycle. As there is no guaranteed order by which we call our file descriptor callbacks, it means that we may end up processing then new connection (accept) before we get the notification that the old one is dead. The fact that the fd number of the accept-fd is mostly lower than the fd number of the individual per-client connection actually makes it likely that the order is exactly the opposite of what would feel "logical". As the ASP is identified by the tuple of (src-port, src-ip, dst-port, dst-ip), both the old connection and the new connection map to the same ASP object. So we need to handle this situation gracefully: If we get a new connection for a tuple that we already [think we still] have one, close the old one and use the new. Change-Id: I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa Closes: OS#4625
2020-06-24sccp_simple_client: only restart ASP if it was createdNeels Hofmeyr1-8/+8
In osmo_sccp_simple_client_on_ss7_id(), only call osmo_ss7_asp_restart() if the ASP was created by that function. If a previously existing ASP was re-used, do not restart it. Background: Recently, osmo-bsc started calling osmo_sccp_simple_client_on_ss7_id() multiple times, once for each configured MSC in an MSC pool. Normally, that ends up re-using the same ASP and SCCP client, so should not change anything. Still, it turns out that the SCTP association was re-launched for every configured MSC, which is obviously not necessary when using the same SCCP connection and SCCP user for multiple MSCs. That happened because osmo_sccp_simple_client_on_ss7_id() calls osmo_ss7_asp_restart() even if a pre-existing ASP is re-used. The rapid restarts also uncovered a problem in osmo-stp, causing it to crash -- that is a separate issue. Independently from an osmo-stp fix, this change should in fact avoid the osmo-stp crash and fix the sporadic massive ttcn3-bsc-test fallout we're seeing since merging the MSC pooling feature to osmo-bsc. Related: OS#4625 Change-Id: I62443edd681a2ec1b38f958520e907f9a7ef285e
2020-06-22libosmo-sccp.spec.in: Use %config(noreplace) to retain current config fileHarald Welte1-1/+1
Change-Id: Ife551573160f9545875eecc2a5bfe8f994249814
2020-06-21M3UA: Accept DATA without routing context IE if only a single AS in ASPHarald Welte1-20/+49
There are some M3UA implementations out there who use a routing context during the ASPAC procedure, but who then don't use it in subsequent DATA transmission. This behavior seems to be at the edge of what's possible within the spec; if you don't configure a routing context, The RCTX IE it is not required to be sent. And if you have multiple routing contexts/AS within one ASP, it *must* be sent. But the situation where a routing context has been configured (but not multiple) is not explicitly covered. Change-Id: I59f47a999f40411aadc88b8f362d8d2b89a66332 Closes: OS#4594
2020-06-15sccp_user_find: optimize: search PC only for valid PC argNeels Hofmeyr1-4/+6
Though, since in current practice, not many users exist, and all incoming messages have a valid PC, this is unlikely to have any noticeable effect. Change-Id: I3533a01e29b97bebe4b8f1f6965444519b3bacfe
2020-06-13Add "no traffic-mode" configuration to ASHarald Welte2-1/+15
As per RFC4666 it is optional whether or not a traffic-mode IE is part of ASPAC requests from ASP to SG. We implemented that so far by having none as default, unless the user specified an explicit traffic-mode in the VTY. However, we had no command to remove that explicit configuration and return to the implicit one. Change-Id: Ibe2b298dd76dc4b02521dc411ae9d570eaf5a9a2
2020-06-02sccp2sua: fix typo: s/omso_sccp_addr/osmo_sccp_addr/Vadim Yanitskiy1-1/+1
Change-Id: I5c37177e9f62eff69bb9d0e7289ecb3c9f9e5f44
2020-05-28RPM spec: fix "E: lto-no-text-in-archive"Oliver Smith1-0/+6
Some opensuse versions failed to build the RPM with: libosmo-mtp-devel.x86_64: E: lto-no-text-in-archive (Badness: 10000) /usr/lib64/libmtp.a libosmo-sigtran-devel.x86_64: E: lto-no-text-in-archive (Badness: 10000) /usr/lib64/libosmo-sigtran.a libosmo-sccp-devel.x86_64: E: lto-no-text-in-archive (Badness: 10000) /usr/lib64/libsccp.a libosmo-xua-devel.x86_64: E: lto-no-text-in-archive (Badness: 10000) /usr/lib64/libxua.a This archive does not contain a non-empty .text section. The archive was not created with -ffat-lto-objects option. Fix it as described here: https://en.opensuse.org/openSUSE:LTO#Static_libraries I've verified in my own OBS namespace, that it works as expected. Related: OS#4550 Change-Id: Iaa0be46838f279af8ea87e00809dd3babd4fcad2
2020-05-22add osmo_sccp_user_find() as public APINeels Hofmeyr2-0/+18
To allow osmo-bsc to add more than one MSC peer on a single SCCP instance, it must add a local SCCP user only once per SCCP instance. The first configured MSC adds a local user, all subsequent MSC should use the same local SCCP user. So, it is most convenient to provide a public function to return such user if it exists. Add as thin wrapper instead of renaming and moving the internal sccp_user_find(): to keep the patch smaller, and to match the way osmo_sccp_user_bind_pc() is a 1:1 wrapper for sccp_user_bind_pc(). Related: OS#3682 Change-Id: I9ecbab16b45268f626950303d6ff8296dd6acda0
2020-05-22Makefile.am: EXTRA_DIST: debian, contrib/*.spec.inOliver Smith1-1/+7
Change-Id: Iacdb3f080dc467398b7b008ffb6068f2dd780ac1
2020-05-19cosmetic: apply changes to match struct_endianess.py outputNeels Hofmeyr2-18/+14
Rationale: the script is a good way to avoid bugs from manually composing the big endian parts (for example, it detected the missing endian.h include, fixed in I5906d94e0e0a74674c3a14cf2ec81c681e696474). However, it becomes cumbersome if it creates numerous edits in the source tree, which cause more time spent for whoever wanted to rather save time with it. So let's keep the code tree matching that script's output. Change-Id: I04ad3795fbaf495cae168aed69124b1dc132a9bd
2020-05-19big endian: add missing endian.h in sccp.cNeels Hofmeyr1-0/+1
sccp.c uses #ifdef OSMO_IS_LITTLE_ENDIAN, but fails to include endian.h, i.e. it would build little endian also on big endian systems. Found by libosmocore/contrib/struct_endianness.py. Change-Id: I5906d94e0e0a74674c3a14cf2ec81c681e696474
2020-05-19contrib: integrate RPM specOliver Smith3-64/+14
Remove OpenSUSE bug report link, set version to @VERSION@, make it build with CentOS 8 etc. Do not try to build libsscp, libmtp and libxua as shared libraries. The imported spec file patched the source with "0001-build-fixes.patch" (not imported) and packaged resulting so files. However, these libraries are legacy and built statically on purpose, as it's stated on the wiki page: https://osmocom.org/projects/libosmo-sccp/wiki Related: OS#4550 Change-Id: Id1d77a79b43a9cb967fe3fe10394cca24757af85
2020-05-14contrib: import RPM specOliver Smith1-0/+235
Copy the RPM spec file from: https://build.opensuse.org/project/show/home:mnhauke:osmocom:nightly Related: OS#4550 Change-Id: Ic5bee5cbb5752afa598d805166061b1f10af41ea
2020-05-12doc: make sure all log categories are set to level noticePhilipp Maier1-4/+1
Lets make sure all logging levels are set to notice Change-Id: I3b17aa4354f30b55da8fc77f4fe6af0373de7983
2020-04-20sccp_internal.h: fix compilation with gcc-10Harald Welte1-1/+1
/usr/bin/ld: .libs/sccp_helpers.o:/home/laforge/projects/git/libosmo-sccp/src/sccp_internal.h:123: multiple definition of `sccp_scoc_fsm'; .libs/sua.o:/home/laforge/projects/git/libosmo-sccp/src/sccp_internal.h:123: first defined here See also https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000646.html Change-Id: Icbc06ed2c8d2bd5c63716945c3df923ea4de7886
2020-04-11configure.ac: fix libtool issue with clang and sanitizerEric1-0/+5
As pointed out at https://github.com/libexpat/libexpat/issues/312 libtool does not play nice with clang sanitizer builds at all. For those builds LD shoud be set to clang too (and LDFLAGS needs the sanitizer flags as well), because the clang compiler driver knows how linking to the sanitizer libs works, but then at a later stage libtool fails to actually produce the shared libraries and the build fails. This is fixed by this patch. Addtionally LD_LIBRARY_PATH has no effect on conftest runs during configure time, so the rpath needs to be set to the asan library path to ensure the configure run does not fail due to a missing asan library, i.e.: SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan' export CC=clang-10 ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`) export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS" Change-Id: I292c303840a76c5042dc077829c5df46158ca8ba
2020-03-19cs7 vty: add 'show cs7 config'Neels Hofmeyr2-11/+31
When 'cs7' was added, it was generally possible to get the full automatic configuration spelled out by using 'show running-config'. Later, the vty was modified so that automatically configured parts were omitted. Since figuring out the 'cs7' configuration is far from trivial, it is very convenient to get the program's current configuration spelled out in detail, whether it is automatic or not. For this purpose, add a new 'show' command which simply calls the ss7 VTY's write function with a new switch to disable all omissions. Change-Id: I84707561a6f54851c5599c39ea9bf1d971a2a1d7
2020-03-19don't use 'debug' log level in example configsHarald Welte2-8/+8
Related: OS#2577 Change-Id: I16807f827f958d48519871355115715b753edfcb
2020-01-21xua_asp_fsm.c: Drop unused definesPau Espin Pedrol1-5/+0
Those values (except for XUA_T_ACK_SEC) are not used at all, and anyway they already exist as timers in osmo_sccp_timer_defaults (sccp_scoc.c). Change-Id: Id5902e809e02b2651e381cd58ef97b77c1143dc2
2020-01-21cosmetic: fix typo in commentPau Espin Pedrol1-1/+1
Change-Id: Ia39d4961a2690ea4c56276db8f1503a75e97d154
2020-01-21sccp: Disarm inactivity timer upon T(iar) active->disconn_pendPau Espin Pedrol1-0/+3
All other code paths moving to state DISCONN_PEND seem to stop them, and anyway that state doesn't permit event SCOC_E_T_IAS_EXP: DLSCCP DEBUG SCCP-SCOC(0){ACTIVE}: Received Event T(iar)_expired (sccp_scoc.c:346) ... DLSCCP DEBUG SCCP-SCOC(0){ACTIVE}: state_chg to DISCONN_PEND (sccp_scoc.c:1095) ... DLSCCP DEBUG SCCP-SCOC(0){DISCONN_PEND}: Received Event T(ias)_expired (sccp_scoc.c:339) DLSCCP ERROR SCCP-SCOC(0){DISCONN_PEND}: Event T(ias)_expired not permitted (sccp_scoc.c:339) Change-Id: Ieb02dedba312ab76890e943934ce6a1e2fe61f74
2020-01-21sccp_scoc: Deliver correct disconnect cause and importance to user on timer ↵Pau Espin Pedrol1-4/+16
expiration Change-Id: I87b84e9c3c4cb35135efdb4ba155c684917fbab7
2020-01-21examples/sccp_test_server: Log disconnect indication in echo servicePau Espin Pedrol1-0/+5
Change-Id: I221519e75800c8bfbe68e24d04913b0c385c521d
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 06:00:32 +0000