Limit length of optional Data parameter to 130 bytes to conform with ITU-T Rec Q.713 §4.2..§4.5 while receiving SCCP messages.
Related: OS#5579
Change-Id: Icc3bd0a71b29cf61a259c5d97e7dd85beb4397bd
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: Ia450b630e0b60b38835f599c93985bbe97c50d2f
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
Use the new offset based parsing to extract GT and data from the
UDTS/XUDTS message as well. Test vectors are missing right now.
Change-Id: Id0a3a291d8bad3f8c9621e6c97d4ea0b8bbe6035
The cellmgr-ng unfortunately looks at the data being sent and can't
handle the presence of XUDT at all. Add the structure definition
and refactor extraction code to work on offsets. Add a unit test.
Change-Id: I45a7447cc1be432fff34849e0e35abc0410cf153
This fixes the following compiler warning when using -Werror on gcc-8.2:
sccp.c: In function ‘sccp_system_incoming_ctx’:
sccp.c:1039:10: error: ‘result.destination_local_reference’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
&& memcmp(&conn->source_local_reference,
result.destination_local_reference,
sizeof(conn->source_local_reference)) == 0
sccp.c:1030:27: note: ‘result.destination_local_reference’ was declared here
struct sccp_parse_result result;
^~~~~~
Change-Id: Ied41f7c8ddaa5f616dd6556079a54d8d70274490
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
presumably, sock->gti_len is always zero when sock->gti is NULL, but ensure
with a check and make coverity scan happy.
Change-Id: I6cf195a3fbda1d9eacbbaec9a0e7f5b4c154f428
Fixes: coverity CID#57683
At the time a SCCP CREF is sent there is no context anymore
and the user of the API might not know where to return the
message to. Allow to specify the incoming context and use it
on the way out.
There are no more callers of _send_msg which passes a NULL
connection and a NULL context.
Fix the code to set the number of consumed bytes correctly
and return the number of bytes consumed for for the address.
Add a simple but expandable test case to test the SCCP address
This allows to identify the sccp connection and send the SCCP
payload down to a different stream depending on the connection. It
will be used by the bsc_msc_ip to keep multiple MSC connections
open.