| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
3GPP TS 48.058 has a very clear definition of which messages are
"transparent" and hence have the T-bit == 1. This is *not* just
all RLL messages, but basically only RLL_DATA.{ind,req} and
RLL_UNITDATA.{ind,req}. All other messages are non-transparent.
Change-Id: I9f83654af189d818563d799bf623325b7fee8e70
Closes: OS#3188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide comprehensive API to obtain string representations of Cell Identifiers
and -Lists.
Change gsm0808_test.c to use the new functions (which simplifies the output a
bit), so that we don't duplicate printing code in gsm0808_test.c, and so that
the not-so-trivial printing code is also tested.
In gsm0808_test, also test gsm0808_cell_id_list_name_buf()'s return value and
truncation behavior.
The rationale for gsm0808_cell_id_list_name(), i.e. printing an entire list of
cell identifiers, is that even though the maximum is 127 elements, a list of
more than a few elements is hardly ever expected in practice (even more than
one element isn't actually expected: either "entire BSS" or a single LAC). It
is thus useful to log the entire list when it shows up in Paging and Handover.
Change-Id: I9b2106805422f96c5cc96ebb9178451355582df3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The uninitialized members of enc_sc sporadically hit address sanitizer failure
during gsm0808_test, like:
../../../../src/libosmocore/src/gsm/gsm0808_utils.c:187:8: runtime error: load of value 13, which is not a valid value for type '_Bool'
../../../../src/libosmocore/src/gsm/gsm0808_utils.c:191:8: runtime error: load of value 119, which is not a valid value for type '_Bool'
How the test survived so long is a mystery to me; as soon as some uninitialized
members would by coincidence not be zero, the test should always have failed at
OSMO_ASSERT(memcmp(&enc_sc, &dec_sc, sizeof(enc_sc)) == 0).
Related: OS#3148
Change-Id: Iaa20c59f624fbdc69a018cabd0f7e9c5a1389519
|
|
|
|
| |
Change-Id: I7535166a2827c03a954fe72d5d99217e4f25868f
|
|
|
|
| |
Change-Id: I81b1ffbe6a5ec566c112492c2cbaf99c018c45bb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clarify semantics and micro-optimise for the case of single Cell Identifer IEs.
Test in gsm0808_test.c
So far we have gsm0808_enc_cell_id_list2(), but there also exist instances of
single Cell Identifiers (3GPP TS 48.008 3.2.2.17).
It is possible to decode the same using the cell identifier list API, but this
forces the caller to also keep a full struct gsm0808_cell_id_list2 with all its
127 entries around.
E.g. for handover, there are two Cell Identifiers (Serving and Target); I'd
need two full cell id lists for each, and these would be dynamically allocated
for each handover operation, whether it uses them or not.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: I9f9c528965775698ab62ac386af0516192c4b0cc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow passing multiple struct tlv_parsed in an array, to allow parsing as many
repeated IEs as are expected by the caller.
From tlv_parse(), call tlv_parse2() with dec_multiple = 1 to yield the previous
behavior. tlv_parse() remains valid API.
An example of multiple IEs is the BSSMAP Handover Request, containing Cell
Identifier (Serving) and Cell Identifier (Target), both defined by 3GPP TS
48.008 3.2.2.17 with identical IE tags; both are mandatory.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: Id04008eaf0a1cafdbdc11b7efc556e3035b1c84d
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will be used by the upcoming neighbor_ident API in osmo-bsc, where the vty
interface allows composing neihbor BSS cell identifier lists, and we want to
allow adding individual items from individual user commands.
It will also be useful to accumulate cell identifiers in case a subscriber sees
multiple alternative cells from a neighboring BSS, and we want to pass these on
to the MSC in a Handover Required.
Related: OS#2283 (inter-BSC HO, BSC side)
Change-Id: I5781f5fa5339c92ab2e2620489b002829d206925
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the osmo-msc, I would like to set the subscr conn FSM identifier by a string
format, to include the type of Complete Layer 3 that is taking place. I could
each time talloc a string and free it again. This API is more convenient.
From osmo_fsm_inst_update_id(), call osmo_fsm_inst_update_id_f() with "%s" (or
pass NULL).
Put the name updating into separate static update_name() function to clarify.
Adjust the error message for erratic ID: don't say "allocate", it might be from
an update. Adjust test expectation.
Change-Id: I76743a7642f2449fd33350691ac8ebbf4400371d
|
|
|
|
|
|
|
|
|
| |
On erratic id in osmo_fsm_inst_update_id(), don't say "Attempting to allocate
FSM instance".
Escape the invalid id using osmo_quote_str().
Change-Id: I770fc460de21faa42b403f694e853e8da01c4bef
|
|
|
|
|
|
|
|
|
|
| |
Since alloc relies on osmo_fsm_inst_update_id() to set the name, never skip
that.
In osmo_fsm_inst_alloc(), we allow passing a NULL id, and in
osmo_fsm_inst_update_id(), we set the name without id if id is NULL.
Change-Id: I6d6b09a811b82770818f19b189a57d9fc4a8133b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Place id and name testing in its separate section, test_id_api().
Add a test that actually allocates an FSM instance with a NULL id, which is
allowed, but uncovers a bug of an unset FSM instance name. osmo_fsm_inst_name()
falls back to the fsm struct's name on NULL, but osmo_fsm_inst_find_by_name()
fails to match if the instance's name is NULL (and until recently even
crashed). Show this in fsm_test.c with loud comments.
Add test to clear the id by passing NULL.
Add test for setting an empty id.
Add test for setting an invalid identifier (osmo_identifier_valid() == false).
Change-Id: I646ed918576ce196c395dc5f42a1507c52ace2c5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In fsm_test.c, we have FSM instance cleanup after the select main loop, but we
exit(0) in the timer cb; hence the final code is never called.
Rather clean up the instance and hence also test that, by using a global flag
to exit the main loop upon timeout.
Adjust expected stderr output.
BTW, in a subsequent commit, I want to move the fsm instance id testing to
below the main loop, to more clearly group the tested bits.
Change-Id: Ia47811ffcc1bd68d2630c86be7ab98fc1f338773
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale: with osmo_escape_str(), you get the escaped contents of the string,
but not so graceful handling of NULL strings. The caller needs to quote it, and
for NULL strings not quote it.
osmo_quote_str() is like osmo_escape_str() but always quotes a non-NULL string,
and for a NULL string returns a literal NULL, i.e. it should (tm) give the
exact C representation of a string.
That's useful in testing, to show exactly what char* situation we have, without
jumping through hoops like
if (str)
printf("\"%s\"", osmo_escape_str(str, -1));
else
printf("NULL");
Copy the unit test for osmo_escape_str() and adjust. To indicate that the
double quotes are returned by osmo_quote_str(), use single quotes in the test
printf()s.
I considered allowing to pick the quoting characters by further arguments, but
that complicates things: we'd need to escape the quoting characters. Just
hardcode double quotes like C.
Change-Id: I6f1b3709b32c23fc52f70ad9ecc9439c62b02a12
|
|
|
|
|
|
|
|
| |
Ironically, when deprecating osmo_init_logging() in
I216837780e9405fdaec8059c63d10699c695b360, I forgot to change the callers
within libosmocore itself, i.e. in the various regression tests.
Change-Id: Ia36c248f99353d5baaa2533f46a2f60a8579bdf8
|
|
|
|
|
|
|
| |
Add logging to root ctx, add msgb ctx to root ctx, free wqueue to simulate the
msgb being sent, and assert final talloc size.
Change-Id: Ief3d5e7b6c4d781b3854e230e45a67d5281b94cd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CTRL interface has a ctrl_cmd_def_* API that allows deferring a CTRL
command reply until later. However, the command handling currently fails to
acknowledge this and deallocates the struct ctrl_cmd anyway.
Fix: in struct ctrl_cmd, add a defer pointer to be populated by
ctrl_cmd_def_make(). A cmd thus marked as deferred is not deallocated at the
end of command handling. This fix needs no change in calling code.
(Another idea was to return a different code than CTRL_CMD_HANDLED when the
command is to be deferred, but that would require adjusting each user of
ctrl_cmd_def_make(). The implicit marking is safer and easier.)
Show that handling deferred commands is fixed by adjusting the expectations of
ctrl_test.c's test_deferred_cmd() and removing the now obsolete exit_early
label.
One symptom of the breakage is that osmo-bts-sysmo crashes when asked to report
a trx's clock-info, which is aggravated by the fact that the sysmobts-mgr does
ask osmo-bts-sysmo for a clock-info.
The crash appears since Id583b413f8b8bd16e5cf92a8a9e8663903646381 -- it looked
like just fixing an obvious memory leak, which it did as shown by the unit
test, but deferred ctrl commands actually relied on that leak. Both fixed now.
Related: OS#3120
Change-Id: I24232be7dcf7be79f4def91ddc8b8f8005b56318
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handling a deferred command currently deallocates the struct ctrl_cmd upon
exiting the initial command handling, while it should actually stay around for
the asynchronous/deferred handling of the ctrl command.
Show the current bug by means of a ctrl test. The test will be adjusted to
expect the correct result when the bug is fixed in a subsequent commit
(I24232be7dcf7be79f4def91ddc8b8f8005b56318).
Change-Id: Ibbc847fc583bdd8e5e53a008258805e634ea12b4
|
|
|
|
|
|
|
| |
Recent commit I77cd4b9142510c6914298b720d9c19ab68f9ebef left an obsolete
assertion around. It is already done in the if-body now.
Change-Id: I1bb2ea363e8a9d86b24338df3584abc93ebc6dd4
|
|
|
|
|
|
|
|
|
| |
Use non-deprecated API to decode encode in gsm0808_enc_cell_id_list2().
Adjust gsm0808_test.c to now expect the correct results instead of previous
failure.
Change-Id: I1ce78883995e0d484368046b69db5afb2b4adc97
|
|
|
|
| |
Change-Id: I763b18d2922701ad97382269747ff0cbb7bd657b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test currently sets the MCC by a hex value, which is a weird choice. The
MCC gets BCD'd and hence we will see the decimal values 1:1 in the encoded
octets as hex digits. Using hex as input obscures that:
Right now it sets mcc = 0x123, which is actually 291 in decimal, and we hence
see "92 .1" in the expected BCD result. Using 0x124 in the test source actually
makes it hard to see where the 0x123 went.
Change the MCC to decimal notation (123, 124, 125) and adjust the expected
encoded output.
Change-Id: I973835c54a90fefe50d2b3581324d12556715f58
|
|
|
|
|
|
|
|
|
|
|
| |
I am going to ehance the test to actually include leading-zero MNC, but first I
would like to simplify how the test source struct is initialized, before I edit
around in it.
Also, when the memcmp() fails, print hexdumps of expected and actual result for
comparison. I needed it to figure out a test failure, might as well keep it.
Change-Id: I77cd4b9142510c6914298b720d9c19ab68f9ebef
|
|
|
|
|
|
|
|
|
|
|
|
| |
The speech codec defaults are not correct. The defaults recommended
in 3GPP TS 28.062, Table 7.11.3.1.3-2 are limited by 3GPP TS 48.008,
Section 3.2.2.103. Some defaults are actually reserved for future
use. Also the endianess of the 16 bit values is reversed.
- correct values so that they match the specification
- transmit bytes in the correct endianess
Change-Id: I6c3a34d39a375d71c4128fd38f06629e8b98b100
|
|
|
|
|
|
|
|
|
| |
If the name stays the same the log messages will still log with the old
id. Since we can now change the id we need to update the name as well.
NULL as id was allowed before so we should allow that as well.
Change-Id: I6b01eb10b8a05fee3e4a5cdefdcf3ce9f79545b4
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit bf383a1d83661af26ccd6521c49b655fb22531d4 tlv_parse()
will return the first occurrence of a repeated IE. Add a test to
verify this behaviour. This test passes with the current code and
fails if bf383a1d83661af26ccd6521c49b655fb22531d4 is reverted.
While here, fix lies in documentation about the return value of tlv_parse()
and fix a typo in another comment.
Change-Id: I041f38548c5e4236920991d6c681c1c1e04de9ca
Related: OS#2904
|
|
|
|
|
|
|
|
|
| |
Add a regression test which encodes and decodes a cell identifier
list of type CELL_IDENT_WHOLE_GLOBAL.
Change-Id: Ie633d9e55c6a30555c0153d35aaf9f982d6e0088
Depends: If0fafbc7171da2a3044bfa9a167208a1afa1c07b
Related: OS#2847
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation was entirely broken, reading data from wrong offsets
and always writing to the first element of the decoded list.
Also, add a new test for this function which found the problems.
Change-Id: If0fafbc7171da2a3044bfa9a167208a1afa1c07b
Related: OS#2847
Depends: Ife4e485e2b86c6f3321c9700611700115ad247b2
|
|
|
|
|
|
|
|
|
|
|
| |
Cell ID lists with CI were misparsed because parse_cell_id_ci_list()
failed to report the amount of consumed bytes to its caller.
Also add a regression test which uncovered the bug.
Change-Id: Ife4e485e2b86c6f3321c9700611700115ad247b2
Depends: If6b941720de33dca66b6b1aa2cb95a3275708b7f
Related: OS#2847
|
|
|
|
|
|
|
|
| |
This makes gsm0808_dec_cell_id_list() properly decode 3-digit MNCs.
Add a test which encodes/decodes a LAI_AND_LAC list with 3-digit MNCs.
Change-Id: If6b941720de33dca66b6b1aa2cb95a3275708b7f
Related: OS#2847
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cell ID list decoder merged in 11a4d9dd91216fe353e94bfdbbab53bc4f891c0d
has a bug which was introduced part-way through the review process in
gerrit at https://gerrit.osmocom.org/#/c/6509/
When Neels suggested "why not just {...}id_list[MAXLEN] once?" I changed
the cell identifier list from a union of arrays to an array of unions.
After this change, elements smaller than the largest type in the union
were not laid out consecutively in memory anymore. E.g. uint16_t lac
values now occur at offsets of sizeof(id_list[0]) instead of offsets
of sizeof(uint16_t).
The problem is that I forgot to adjust the decoder accordingly, so the
decoder writes to the wrong offsets and returns cell identifier lists
which appear to contain uninitialized values when read back by API
consumers.
I found this problem while adding new regression tests to libosmocore to
test encoding and decoding. This commit adds one such tests for LAC list
decoding, which failed due to the above bug. I plan to write more tests,
however because this first test already uncovered a severe issue I chose
to submit a fix now and work on additional tests in later commits.
Change-Id: Ie1a5a9d858226be578cf11a03cf996d509bd51fb
Related: OS#2847
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce gsm0808_dec_cell_id_list2() with supports additional types of
cell identifier lists. The new parsing routines are based on similar
routines used by the paging code in osmo-bsc's osmo_bsc_bssap.c.
Likewise, introduce gsm0808_enc_cell_id_list2() with support for the
same additional types of cell identifier lists.
The old API using struct gsm0808_cell_id_list is deprecated.
The previous definition was insufficient because it assumed that all
decoded cell ID types could be represented with a single uint16_t.
It was declared in a GSM protocol header (gsm/protocol/gsm_08_08.h)
despite being a host-side representation of data in an IE.
The only user I am aware of is in osmo-msc, where this struct is used
for one local variable. osmo-msc releases >= 1.1.0 make use of this API.
While here, fix a small bug in a test:
test_gsm0808_enc_dec_cell_id_list_bss() set the cell ID type to 'LAC'
but obviously wants to use type 'BSS'.
Change-Id: Ib7e754f538df0c83298a3c958b4e15a32fcb8abb
Related: OS#2847
|
|
|
|
|
|
|
|
| |
In osmo_mnc_from_str() do not try to return some values even if the validation
fails; hence don't try to decode a NULL pointer. That whole idea was half-baked
and a can of worms to begin with.
Change-Id: Ibaaa128ac60b941a015a31134eb52aef56bc6e22
|
|
|
|
|
|
|
|
|
|
| |
In certain builds (for me a build with no -O2 flag) the recently added
gsm23003_test test_mnc_from_str() fails, because bcmp() compares all bytes of
sizeof(struct test_mnc_from_str_result), which has valid data for 7 bytes plus
one padding byte that may contain arbitrary values. Instead of bcmp(), rather
compare the actual members one by one.
Change-Id: I28b28457c7b0462c950612fd9b87b5c7181d8bad
|
|
|
|
| |
Change-Id: I5bebc6e01fc9d238065bc2517058f0ba85620349
|
|
|
|
|
|
|
|
|
|
|
| |
osmo_mnc_from_str() preserves leading zeros in the string and is useful for
VTY config parsing (osmo-bsc, osmo-msc, osmo-sgsn, osmo-pcu).
osmo_{plmn,mnc}_cmp() takes care of the slight intricacy of ignoring the 3-digit flag
if the MNC is anyway >99. Will be used by osmo-sgsn.git and osmo-bsc.git. (All
current users just care about identical MNC, but a proper cmp doesn't hurt.)
Change-Id: Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6
|
|
|
|
| |
Change-Id: I9b387e09293a6bbef84b9620ccf21ee2f9ec751c
|
|
|
|
| |
Change-Id: I4c8492b8055803d2857f1ef30aede088778b085b
|
|
|
|
|
|
|
| |
Note that on the input side, the 3-digits flag may be left false when the MNC
is >99 anyway. On the decoded side, the flag is set accurately.
Change-Id: I89765613d8c5bd939a6957f7443ac88475f1b93c
|
|
|
|
|
|
|
|
|
|
|
|
| |
Event names are displayed in VTY commands so all FSM should have them.
Print an error message if an FSM is registered without event names.
We could also return an error code, however at present no caller checks
the return value of osmo_fsm_register() so this would be pointless.
Add event names to the test FSM and update expected output accordingly.
Change-Id: I08b100d62b5c50bf025ef87d31ea39072539cf37
Related: OS#3008
|
|
|
|
|
|
|
|
|
|
|
|
| |
For all other decode operations we report the BER, but not for the
RACH. This results in osmo-bts-trx not being able to report BER
to the higher layers, which is possible on other BTS backends.
Let's close this gap by introducing gsm0503_rach_ext_decode_ber()
and gsm0503_rach_decode_ber() with the usual n_errors / n_bits_total
arguments.
Change-Id: I2b1926a37bde860dcfeb0d613eb55a71271928c5
|
|
|
|
| |
Change-Id: Idd6cee090464bc92b654332904a9a08edf16e5c9
|
|
|
|
|
|
| |
(Preparation for adding 3-digit MNC)
Change-Id: Ifbc167de0cc039858112677b8d0cd14a2c8af086
|
|
|
|
|
|
| |
(Preparation for adding 3-digit MNC)
Change-Id: I7f8ae05fa3e4a6fc004212757b05ca8a14c9ef45
|
|
|
|
|
|
| |
For consistency in human readability, MCC simply should come first, always.
Change-Id: Idb86a7088fac4d8a8c41190ab46f9801635f4eee
|
|
|
|
|
|
| |
(Preparation for adding 3-digit MNC)
Change-Id: Ic6c645ebf82d5f8d9d51c4c4cc804a0172008156
|
|
|
|
| |
Change-Id: Ibe5c0831268c788ceecd10fd7b22ece6480da817
|
|
|
|
|
|
|
|
|
| |
It seems with default flags in_buf was being memzeroed by the compiler.
When compiling with -O0, that's not the case anymore and printf prints
after first 16 bytes, printing extra garbage which doesn't match the
expected output.
Change-Id: I736c1e4d625f647d3bb794fa717256e9dbf36e87
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inline keyword is a hint for the compiler to inline the function, but
it's not mandatory. If no static or extern is specified, the definition
is only visible in the current unit but the identifier still has
external linkage.
When running with -O0 it seems the compiler (gcc 7.2.1) decides to use
the external linkage but at the same time it seems it's not generating
the function symbol. Fix it by explicitly stating that we want to use
static linking for this function.
coding/coding_test.o: In function `test_xcch':
libosmocore/tests/coding/coding_test.c:86: undefined reference to `dump_ubits'
libosmocore/tests/coding/coding_test.c:87: undefined reference to `dump_sbits'
Change-Id: I18018adec05ce1c2ddbca38653311d74c7454ce8
|
|
|
|
|
|
| |