It's similar to osmo_sock_get_name_buf() but supports multi-homed SCTP sockets
bound to several addresses.
Related: OS#5581
Change-Id: If76595ebd1cf26ba904887a36c4cc14a1b5c4521
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
Make sure that there is no undefined references in shared libraries.
Inspired by GitHub PR#6 [1] by Michael Dickens. Tweaked by me.
Change-Id: I7ddd6c75935b0f25d78a948f1577656d77a204e3
Related: [1] https://github.com/osmocom/libosmocore/pull/6
This brings the tables up-to-date with Release 16 of both
ETSI 102 221 + 3GPP TS 31.102 specifications.
Change-Id: I7100f326f45f1f8742363eace0531a4ef3f049c0
Coverity complains that we do check if osmo_tdef_get_entry() returns
NULL 39 out of 40 times. Check it in test_tdef_set_and_get() too.
Change-Id: I96041eab2786d850a49cb38a60a368cef2e476d3
Related: CID#274729
As was demonstrated in [1], osmo_fsm_inst_state_chg_ms() is broken.
The problem is in state_chg(): this function is passing *milli*seconds
to osmo_timer_schedule(), while it expects *micro*seconds.
Change-Id: Ib0b6c3bdb56e4279df9e5ba7db16841645c452aa
Related: [1] I5a35730a8448292b075aefafed897353678250f9
Fixes: I35b330e460e80bb67376c77e997e464439ac5397
Fixes: OS#5622
This change adds test_state_chg_Ts() and test_state_chg_Tms() checking
state timeout s/ms accuracy when using osmo_fsm_inst_state_chg() and
osmo_fsm_inst_state_chg_ms() calls, respectively.
test_state_chg_Tms() demonstrates that osmo_fsm_inst_state_chg_ms()
is not working as expected: the timeout fires earlier than expected.
Change-Id: I5a35730a8448292b075aefafed897353678250f9
Related: OS#5622
Jumping to label 'error' before allocating memory and storing an
address to pointer 'rim_cont_buf' would result in passing garbage
to talloc_free(). Found with clang 14.
Change-Id: I9420615b64d3755fd9131e8561c516c39f83a15b
The testcase in gsm0408_test is still failing because the encoder
produces a different result (with octet 3a present). There is no
way to tell the encoder to use the implicit coding, and in general
this is not that critical, so we can live with that.
Change-Id: I722c168f01bffa915cb155eac234a796549d3762
The new testcase contains a Bearer capability IE from Siemens S11E,
which does not use octet 3a (no extension bit set in octet 3).
gsm48_decode_bearer_cap() currently fails to parse it.
Change-Id: Ia19f3f6d80bc09ca3f8d39d35b148a0c0245141f
Currently, if one of the testcases fails, test_bearer_cap() would
abort and skip the remaining testcases. Also, a msgb would not
be free()ed making the LeakSanitizer unhappy.
Instead of returning early, jump to the end of loop to ensure that:
* the verdict ('passed' or 'failed') is always printed,
* all remaining testcases are still executed,
* the msgb is free()ed.
Change-Id: I39ac801e59ba56dfe3bcd4603b48f6fbf7cfb21c
That code path should not happen since this function is only called for
data frames coming with IUUP_FSM_EVT_IUUP_DATA_IND.
Control frames should come with specific events like
IUUP_FSM_EVT_IUUP_CONFIG_REQ.
Hence, let's add an assert to make sure we early exit if that ever
happens (it shouldn't), instead of carrying on reading uninitialized var
"dt".
Fixes: Coverity CID#272996
Change-Id: Iaeba59bc9ebfe817dbb7528572dc669c010ef14d
osmo_bssap_le_dec() dereferences value of the given pointer and
checks it against NULL. The caller must always initialize it.
Change-Id: Id91dc73da1ca71827183564eb68b12c03ba332b3
a program being developed right now crashed at this point, without
providing any meaningful information on where did it crash.
Change-Id: Ia14f43142e7409f72eb9efd5c9131bea5eed6e82
This patch addes support for GlobalPlatform command. Android is using
STORE DATA commands on a logical channel.
simtrace2-cardem-pcsc is failing otherwise e.g. on an Pixel 4 with Android 12.
Change-Id: Ib734fc852e7b63b9efdc414adccbd796a572eb55
Once the IuUP FSM moved away from Init state, it stopped handling
Initialization messages received from peers and simply ignored them
starting from that point. As a result, if the first IuUP Init ACK it
sent to the peer was lost, the peer would keep retrying with more IuUP
Init and getting no answer.
In any case, it seems possible and desirable that a peer may send an
IuUP Init at a later point, as pointed out vaguely in 3GPP TS 25.415.
sec 6.5.2.1:
"""
Upon reception of a frame indicating that an Initialisation procedure is
active in the peer Iu UP entity, the Iu UP protocol layer forwards the whole
protocol information contained in the INITIALISATION control frame to the
upper layers. It also stores the RAB sub-Flow Combination set (and thus
replaces a possible previous set) in order to control during the transfer of
user data, that the Iu UP payload is correctly formatted (e.g. RFCI matches
the expected Iu UP frame payload total length). The peer Iu UP entity
receiving the INITIALISATION control frame shall choose a version that it
supports among the proposed versions indicated by the sender for which it
has enough initialisation information.
"""
sec B.2.2 "Initialisation State":
"""
After sending a positive acknowledgement of the last INITIALISATION control
frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that
CN does not know if the initialisation ACK was correctly received by the RNC
(and Initialisation procedure successfully completed) until it receives RAB
assignment response, or use data from the RNC. The CN must therefore be able
to continue receiving INITIALISATION control frames by re-entering the
Initialisation state (from Support Mode Data Transfer Ready State), if the CN
has started to send user data before receiving the indication that
Initialisation was successfully completed
"""
sec B.2.3 "Support Mode Data Transfer Ready State":
"""
In case of handover or relocation, Initialisation procedures may have to be
performed and Iu UP instance may have to enter the initialisation state.
"""
Related: SYS#5995
Change-Id: I5cb740702805693cc7f0a550e2e093f9bfdd507c
This test shows a bug in IuUP stack which makes it only handle the first
Initialization IuUP message. After it moves to SMpSDU, it stops handling
Initialization messages.
A fix is provided in a follow up patch.
Related: SYS#5995
Change-Id: I72c2c2d88f158f3ef35724fcb73854a1827aaab4
Max
Vadim Yanitskiy
Neels Hofmeyr
Pau Espin
Daniel Willmann
Oliver Smith
Harald Welte