Age | Commit message (Collapse) | Author | Files | Lines |
|
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 (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
|
|
Avoid magic number 0xffffffff and rather provide a mask value for all address
components.
Change-Id: I13ff0858e496c4392b8e1590d62f7eb80f191a07
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I36dd8f1978e3b7b785660745378c9cf77a21a566
|
|
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
|
|
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
|
|
Actual fix for the issue is applied in next commit.
This reverts commit ee8128929755d88ace4e1e566448a14a970b1b40.
Change-Id: I8b66dd97f47f1b2b72c101b9ce4444e75eb744c0
|
|
Change-Id: Ib86ef3c3db6096a1e38690b9e598a58387e6b38e
|
|
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
|
|
Change-Id: I09226a5cecc37dd4676acd61c2051befe5234cb3
|
|
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
|
|
Change-Id: I7df2b2cd0f8fa2f4f9a1e345735aa944f93e95a4
|
|
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
Change-Id: Ib9faa68c1cd09a026909c792a1fd5557c9893fe3
|
|
Change-Id: I83312c3f22af54db346f4babc9470ff9432ceae4
|
|
Change-Id: Ib149fd7716343d0e441c4671832efd05a62d67da
|
|
Change-Id: I70c01be02bf88ac4191dcd28cb6b3516bc096263
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Change-Id: Ife551573160f9545875eecc2a5bfe8f994249814
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I5c37177e9f62eff69bb9d0e7289ecb3c9f9e5f44
|
|
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
|
|
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
|
|
Change-Id: Iacdb3f080dc467398b7b008ffb6068f2dd780ac1
|
|
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
|
|
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
|
|
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
|
|
Copy the RPM spec file from:
https://build.opensuse.org/project/show/home:mnhauke:osmocom:nightly
Related: OS#4550
Change-Id: Ic5bee5cbb5752afa598d805166061b1f10af41ea
|
|
Lets make sure all logging levels are set to notice
Change-Id: I3b17aa4354f30b55da8fc77f4fe6af0373de7983
|
|
/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
|
|
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
|