The newly-introdiced pragma to disable strict-prototypes checking works
in C, but creates a -Werror=pragmas error in C++ code:
In file included from osmo-trx.cpp:45:
/build/deps/install/stow/libosmocore/include/osmocom/vty/logging.h:10:32: error: option
‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [-Werror=pragmas]
#pragma GCC diagnostic ignored "-Wstrict-prototypes"
So let's also suppress those errors for that one line of code...
Change-Id: I85596cf4538d7a8c522f4bce1620a2d19e2a910e
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea0). However,
its declaration in C file didn't contain "(void)", which meant the
number of parameters is undefined and thus compiler doesn't complain.
However, in recent Change-Id I84fd99442d0cc400fa562fa33623c142649230e2
we changed the declaration to '(void)' to allow building with
-Wstrict-prototypes. This caused downstream build-failures of osmo-mgw (1.4.0)
and osmo-e1-recorder (master).
So let's make one very small-scoped exception here.
Change-Id: Iadb54848b67db937b640dc2102dddb6e708a6a9f
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: I84fd99442d0cc400fa562fa33623c142649230e2
Those are similar to existing *msgb_alloc*() functions but allows
to change the size of destination msgb provided it fits the
data from source msgb.
Change-Id: I36d4c16241d19f0f73c325be4d0e0bdef6813615
Signed-off-by: Max <msuraev@sysmocom.de>
The OS#4993 has nothing to do with AF_PACKET/ENOBUFS,
the proper ticket is OS#4995 as referenced later in the same file.
Change-Id: Icf13b351dc74508fc312c535d68b13b7ce9b7e1e
The weird formatting not only makes it hard to read but caused linter to fail in the follow-up patch.
Change-Id: Ie4e56b4796c1b8f270a692453faccf102c963db5
The macro msgb_sms() is basically an alias for msgb_l4(). Lets use
msgb_l4() in msgb_l4len() instead of msgb_sms().
Change-Id: I90d4f5c07fbaadd9e022752a2c64c4855f0b4227
When any of l1h, l2h, l2h or l4h is set to NULL (which is the default
for newly allocated message buffers). Then the msgb_lXhlen() functions
will return the address value of msgb->tail. This can lead to unexpected
results at a later point. We should have an OSMO_ASSERT to catch the
problem early.
Change-Id: I1795c559f190713ebbabfbabf3453ab77da46a49
Related: OS#5645
gsm0808_create_lcls_conn_ctrl() was adding the LCLS-Configuration IE twice.
Correct is LCLS-Configuration followed by LCLS-Connection-Status-Control
(TS 48.008 3.2.1.91)
Change-Id: I455ac7695ad33ef9073bea7d1711508717732607
This makes it possible to pass expressions to the abovementioned
macros without any side-effects. Strictly speaking, this is only
necessary for argument 'b' of GSM_TDMA_FN_SUB, but let's also add
them to GSM_TDMA_FN_SUM for consistency.
Change-Id: I7f26156813139bbb7774e1eb342c91bc84fdad38
Ranges can now be specified in hexadecimal notation. In this case, only
hexadecimal values are accepted (prefixed with "0x").
In order to allow using a hexadecimal value as an input argument, the
command must specify the range in hexadecimal form.
This way all existing commands (decimal) won't get an hexadecimal value
unless they are further extended in the future, avoiding hard to notice
breakage due to use of stroul() without using base=0 or even worse,
using atoi() directly (which only understands decimal and provides no
error checking mechanism).
A command argument can be expanded to accept both decimal and hex in a
range by means of specifying both, example:
"mycmd (<0-255>|<0x0-0xff>)".
Related: OS#5631
Change-Id: Ia2b7fbbf5502c28374c21dbff548232680da27d4
While at it, drop 8-1 in favour of 7. I don't think it is really more
understandable for readers to see some subtraction there...
Change-Id: I8b21eba9b9aa952f86abe7a6d4cdb1d1a61d9deb
The errno values are platform dependent. Printing them in the expected
output causes failure on some systems that don't match my development
system.
Still check for match with the expected errno value, but don't print the
actual value in gsm0408_test.ok.
Related: OS#4842
Change-Id: I87d125fb4e04b2130f653db1ed76691528e43411
The documentation for osmo_use_count_get_put states the return value is
"Negative on range violations or USE_LIST == NULL, the use_cb()'s
return value, or 0 on success"
However, the code in _osmo_use_count_get_put doesn't check if uc is NULL
- instead it would crash in osmo_use_count_find() where it is dereferenced.
Add a check for uc and return -EINVAL if it is NULL.
Change-Id: I792563696860a3100e95cafdd5fe57511819ef56
Related: SYS#5895
This reverts commit a4063efa7d.
Reason for revert: It is not possible to guess the IP address
family from uninitialized memory. This function simply glorifies
random noise into an IPv6 address. It makes no sense to have it.
Change-Id: Ifadd614604cf9d0c2ed1a405493c1c3fcb37ae23
This reverts commit e145e28a91.
Reason for revert:
The function osmo_sockaddr_strs_to_str() should not be part of the
osmo_sockaddr_str API. The implementation of this should live in
the function multiaddr_snprintf() added in patch
Icef53fe4b6e51563d97a1bc48001d67679b3b6e9
and should not use dynamic allocation.
Change-Id: I263dfd68313b896c5b474025fbca13c22ce41cdc
Sometimes we receive generic "struct sockaddr" with unspecified (AF_UNSPEC)
address family. It's handy to try to guess
the proper address (there're just 2 variants ATM in most practical applications).
Use the added function to relax input checks in osmo_sockaddr_str_from_in*()
Related: OS#5581
Change-Id: I1c90c56ce832f53b65e0d18d3cea94621c02a69a
This is similar to what we already do between BSC<->MSC to pass Osmux
CID (GSM0808_IE_OSMO_OSMUX_CID).
We now want to support Osmux between BSC and Osmocom BTS, hence add an
extension IE which will be used in ipaccess CRCX messages to tell the
BTS to use Osmux.
Change-Id: I580fe99c01bc0a844d877994ec6cd954310e265d
This feature is used by the BTS to signal to the BSC that it supports
using Osmux instead of RTP on the BTS<->BSC(MGW) data plane.
Related: SYS#5987
Change-Id: Ie79bfb6d0a7a8fe2842d2596b3244e7b74a0d5b6
I was warned by gcc about comparing a pointer with an integer when using
TLVP_PRESENT with something like:
bool expect = ...;
if (expect != TLV_PRESENT(...))
That's indeed dangerous because TLV_PRESENT is considered to return a
boolean, as opposite to TLV_VAL.
Change-Id: I45cc2745c695e30c37b10f592903ec3775a55492
Allow to restart SNS procedure and initiate a SNS-SIZE procedure with Reset.
SGSN side SNS restart will stop answer on ALIVE and is sending NS STATUS
invalid protocol state.
BSS side SNS restart will send a SNS Size procedure to reset the state.
Change-Id: Icb55d8449908d348ab10572eebcf971737fba00d
The decoding pointer was not increased correctly, ending up in reading
by 1 byte offset for each item in the list.
Change-Id: I16ed9bd65109a7ce32ff43c5789b4544479838e7
Some initial testing for that module was writen to apparently do some
manual tests (rand()) but were never added to testsuite.at.
Let's make sure they run during make check (make the test deterministic
by removing rand()).
Change-Id: Icd4feced06afb749de994195c6b338df006749ad
Vadim Yanitskiy
Harald Welte
Philipp Maier
arehbein
Keith Whyte
Pau Espin
Neels Hofmeyr
Daniel Willmann
Oliver Smith