| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The planned support for true A over IP requires the encoding of
the an Encryption Information element (see also BSS_MAP_MSG_CIPHER_MODE_CMD).
This commt adds encoding/decoding functionality and tests for
the element mentioned above, however, it is not yet actively used.
Change-Id: I8262050a9d9fd3f17462cfbb046c6e034dccc6fb
|
|
|
|
|
|
|
|
|
|
| |
The planned support for true A over IP requires the encoding of
the a Channel Type element (see also ASSIGNMENT REQUEST).
This commt adds encoding/decoding functionality and tests for
the element mentioned above, however, it is not yet actively used.
Change-Id: Id0e2164d84b8cbcc6fe6a090fc7f40a1251421d7
|
|
|
|
|
|
|
|
|
| |
the classic A implementation in libosmocore lacks support for AoIP
message elements. This patch adds support for AoIP by adding a set
of new gsm0808_create_..., which support the missing AoIP message
elements
Change-Id: I77f866abec1822d19871052f3c647ad782785b34
|
|
|
|
|
|
|
|
|
|
| |
The planned support for true A over IP requires the encoding and
decoding of a so called "Speech Codec Element" element.
This commt adds parsing functionality and tests for the element
mentioned above, however, it is not yet actively used.
Change-Id: I0e1e2edf47adaa45b22d4b0bcae3640dba7ca200
|
|
|
|
|
|
|
|
|
|
| |
The planned support for true A over IP requires the encoding and
decoding of a so called "AoIP Transport Layer Address" element.
This commt adds parsing functionality and tests for the element
mentioned above, however, it is not yet actively used.
Change-Id: I57933b0a06a3f54ec2a41e6ecb6ced9fbbc89332
|
|
|
|
| |
Change-Id: I978e1b73aa8097a7db6318d78f9f93457e6ce2af
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of returning maxfd, which is the highest fd ever seen, take
the highest we have seen on this iteration.
This makes a tiny difference for the osmo-sip-connector and its
event loop integration. select.c ignores the return value of this
function right now.
This was seen while debugging the eventloop integration of the
osmo-sip-connector before and after a VTY connection. The fds
being polled didn't go down.
Change-Id: I1a6d7271273ec08bb511c21b936891bc508843e4
|
|
|
|
|
|
|
| |
In Change-Id I61f452208088dc7097165deecef7c058ebb4bd4e we introduced
the #defines but didn't introduce the new log_info_cat information.
Change-Id: I218aa4cb1fc7640a75663be29bac672dfa8770f5
|
|
|
|
| |
Change-Id: I61f452208088dc7097165deecef7c058ebb4bd4e
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To make sure that new patches don't break a build done in another dir than
srcdir, make jenkins verify that it still works.
Even though 'make distcheck' also tests a build from a separate dir, this does
not verify that BUILT_SOURCES are generated properly. If these already exist in
the source tree from a previous 'make' issued in the source tree, the
BUILT_SOURCES are not regenerated during 'make distcheck'. Hence a separate
test run is necessary to ensure stability of new patches.
Change-Id: I4b31538c155941fd241bcd33b0d39f2f8491ac1e
|
|
|
|
|
|
|
|
|
| |
The state check in lapd_dl_reset causes some buffers
never to be released. Using talloc report LAPD UA
message buffers are never released after each call
and cause a memory leak.
Change-Id: I2799b70623f2ec4dbc725eb213e332e98da02a3e
|
|
|
|
|
|
|
|
| |
Expand 3GPP TS 52.021 §9.4.43 Probable Cause with Osmocom-specific value
for PCU version reporting to enable sending it via OML alarms.
Change-Id: If57459c0610f2c7b36d599b13087c8deef8bdd9e
Related: OS#1614
|
|
|
|
|
|
|
|
| |
Add human-readable names for Message Types from 3GPP TS 52.021 §9.1
Related: OS#1614
Change-Id: Ide8202b4387351f57ceee34a9eb8c30aef09a663
|
|
|
|
|
|
|
| |
Add human-readable names for Attributes from 3GPP TS 52.021 §9.4
Change-Id: I861247c01557dac7e484ef6fb9b170f69c8a7f55
Related: OS#1614
|
|
|
|
| |
Change-Id: Id94d2fe83f080a18a2a686206bd21cf5fafe2fa7
|
|
|
|
|
|
|
|
| |
Ensure that a changed conv_gen.py and/or conv_codes_gsm.py result in
regeneration of the gsm0503* generated sources. Before this patch, manual
cleaning of the generated files was necessary to benefit from a code update.
Change-Id: Ib4328662c21280c0ea6aa9391a64ada2c6598704
|
|
|
|
|
|
|
| |
Previously, this would fail when generating to $builddir if that subtree did
not exist yet in $builddir.
Change-Id: Ia4fba96dcf74a25cf3e515eb3e4f970e0c3cdd54
|
|
|
|
|
|
|
|
| |
To ensure that a separate build dir keeps the source dir clean of state,
generate the gsm0503.h to the builddir instead of the srcdir. Adjustments for
everyone to access the right paths were added in previous patches.
Change-Id: Ia773ef5893a2018feb416061aefcf51835df18d2
|
|
|
|
|
|
|
|
| |
To allow building coding/gsm0503_interleaving.c which includes the generated
bit*gen.h (via bits.h), add -I to the builddir include path in order to find
the generated bit*gen.h headers there.
Change-Id: I0d465bc109765b1315d615243bea6af027afa368
|
|
|
|
|
|
|
|
|
|
|
|
| |
osmo-auc-gen on 32bit systems allowed only --sqn up to 32bits width. However,
the recently added regression test for osmo-auc-gen includes an ivocation with
a 48bit wide --sqn, which now causes the builds to fail on 32bit systems.
Fix the --sqn argument parsing for larger integers by using strtoull(). Do away
with the intermediate variable 'ul' and place the value directly in the auth
data struct.
Change-Id: Ifb73b3b3de06576e36076ca573d52327f90a1f77
|
|
|
|
| |
Change-Id: Ic81b68aef010e17f6b18232064958e0d4193e192
|
|
|
|
|
|
|
|
| |
The logging code crashes if osmo_log_info is not set, which is typically
achieved by calling log_init(). Let's fail with a reasonable assert
and error message if the user forgets that.
Change-Id: If3007860d2efe6ea9aec27e7d7439d44a7cd19c2
|
|
|
|
| |
Change-Id: I7fe3678b524d602fc6aa14bc0ed06308df809a3e
|
|
|
|
|
|
|
| |
Let's add some general information about this repository, links to
redmine, gerrit, the mailing list, etc.
Change-Id: If034c6f551ff9bfaff0b8368fd0963f3147155b9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Composing the message type string requires knowing the protocol discriminator.
To ease printing the message type, add this function to switch between the
defined value_string[]s depending on pdisc.
Also publish the message type value_string[]s -- without inline functions to
access them because it is anyway more convenient to use
gsm48_pdisc_msgtype_name() instead.
Since gsm48_pdisc_msgtype_name() is nontrivial, do not add as inline function
-- in case the message type is not known, it needs a static string buffer.
Change-Id: I0fca8e95ed5c2148b1a7440eff3fc9c7583898df
|
|
|
|
|
|
|
| |
I often want to log the protocol discriminator in the openbsc debug log. It's
more useful to get the name directly instead of looking it up every time.
Change-Id: I0f053e2a4360b27ffccda7cf82469fb1b1cbb3ae
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unterminated value_string arrays are dangerous since get_value_string() and
get_string_value() need to know where the struct ends. If the terminator is
missing, they might run through and return arbitrary memory locations.
Employ some regexes to find such unterminated value string arrays and return
nonzero if any are found.
This can be used in our jenkins build jobs to avoid committing unterminated
value_string arrays. In fact I've found one in current libosmocore:
gsm0808_bssap_names in gsm/gsm0808.c, fixed in a separate patch.
Change-Id: I2bc93ab4781487e7685cfb63091a489cd126b1a8
|
|
|
|
|
|
|
| |
To ensure that the IND index appended to SEQ does not affect the SEQ, the check
should read '>= seq_1', not '>'.
Change-Id: Ib1251159eee02aa07fae1b429ffec2e4604bf6a8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To be able to use OSMO_VALUE_STRING() on a #defined constant, don't use
OSMO_STRINGIFY(): the second indirection resolves the #define to its value, so
for example
OSMO_VALUE_STRING(GSM48_PDISC_MM)
would resolve to
{ 0x05, "0x05" }
When using '#x' directly, this becomes the desired
{ 0x05, "GSM48_PDISC_MM" }
With enum values as we've used until now, this problem does not appear, because
enum values are not resolved by the preprocessor.
Keep OSMO_STRINGIFY() because it is used directly in openbsc (composing FSM
state names).
Change-Id: I91ecfcef61be8cf73d59ea821cc4fd9d2ad5c9c7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't use CTRL_TYPE_UNKNOWN as value_string[] terminator, use an explicit, more
obvious { 0, NULL } termination. Set an explicit string for CTRL_TYPE_UNKNOWN.
No other value_string[]s to date have such a "hidden" terminator.
BTW, a { 0, "string" } item is not a terminator, only { 0, NULL } is, so we can
set a string for CTRL_TYPE_UNKNOWN == 0.
Also, having a string value for CTRL_TYPE_UNKNOWN is not harmful because all
code paths explicitly check for the CTRL_TYPE_*s that are valid.
Adjust the test expectation.
From the ctrl_type_vals enum, remove the = 0, because it is implicitly 0
anyway.
One motivation to press this fixup: I am trying to add a script that checks
whether all value_string[]s are terminated to our jenkins jobs, and to find
that this one is terminated, it would need to interpret the CTRL_TYPE_UNKNOWN
constant, which would make things far more complex. At this point, all of the
value_string[]s have an explicit termination, and I would like to enforce this
from now on -- for readable code and to not spend more time on the validator.
The patch adding ctrl_type_vals (Icd4e96dd9f00876cb70b43cfcf42ab4f10311b28) was
accepted by another reviewer before I could reconfirm my -1, so this is a fixup
to enable the termination checking script patches.
Related: I2bc93ab4781487e7685cfb63091a489cd126b1a8 (adds script to libosmocore)
I7fe3678b524d602fc6aa14bc0ed06308df809a3e (uses in jenkins.sh)
Icd4e96dd9f00876cb70b43cfcf42ab4f10311b28 (adds ctrl_type_vals)
Change-Id: Ia99f37464c7b36b587da2cc78f52c82725f02cbc
|
|
|
|
|
|
|
|
| |
In a comment and by code #if'd away, illustrate that the AUTS used in the unit
test is accurate.
Related: OS#1968
Change-Id: Iefeaaf33570f8e40245fdf9b810390ec61cfc7e0
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we are a daemon, we do not need to daemonize again.
On the other hand everything is fine and we also do not need
to bail out with an error.
The daemonize template at [1] does the same.
[1] http://www.itp.uzh.ch/~dpotter/howto/daemonize
Change-Id: Ia4dcf7344bd65934faa3d7d46563f6e0532c232e
|
|
|
|
|
|
|
|
|
|
|
| |
Copy list_first_entry, list_first_entry_or_null and list_last_entry from
current linux kernel's tools/include/linux/list.h and rename to llist_*.
Slightly adjust API doc but stay as close to the source as possible.
This can replace similar implementations in osmo-bts-octphy's l1_if.c,
in openbsc's gtphub.c and in osmo-hlr's gsup_server.c.
Change-Id: I4eac5be0c0b2cede04464c4c3a0873102d952453
|
|
|
|
|
|
|
|
|
| |
After the legacy mode incrementing with ind_bitlen == 0 is through, do another
AUTS run with sensible ind_bitlen and ind, and then two more normal vector
generations to verify proper SQN increments.
Related: OS#1968
Change-Id: Id6947899ff7b1c82b939f969e163e51ce282bce2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we incremented SQN by 1, which doesn't match the procedures described in
3GPP TS 33.102. An IND (index) denotes a non-significant part of SQN, and the
significant SEQ part needs to be incremented.
In OsmoHLR we furthermore want to use the "exception" suggested in annex C.3.4,
so that each HLR's client has a fixed IND index. In other words, we will not
assign IND cyclically, but keep IND unchanged per auth vector consumer.
Add 'ind_bitlen' and 'ind' to the osmo_sub_auth_data.u.umts structure and
increment SQN accordingly.
Add a comment explaining the details.
Because 'ind_bitlen' is still passed as zero, the milenage_test does not change
its behavior, which is a feature I want to clearly show in this patch. The test
will be expanded for the newly implemented SQN scheme in a subsequent patch.
Adjust osmo-auc-gen.c to still show the right SQN and SQN.MS -- because it is
passing ind_bitlen == 0, osmo-auc-gen can rely on single increments and know
SQN.MS is sqn - 1. Note that osmo-auc-gen_test output remains unchanged.
Related: OS#1968
Change-Id: Ibc97e1736a797ffcbf8c1f7d41c5c4518f4e41bf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prepare for the implementation of splitting SQN increments in SEQ and an IND
part; particularly to clearly show where the changes in auth/milenage_test's
expectations originate.
Rationale: the source of UMTS auth vectors, for us usually OsmoHLR, typically
stores the last used SQN, not the next one to be used. Particularly with the
upcoming fix of the SQN scheme, this change is important: the next SQN will
depend on which entity asks for it, because each auth consumer may have a
particular slot in the IND part of SQN. It does not make sense to store the
next SQN, because we will not know which consumer that will be for.
The milenage_test has always calculated a tuple for SQN == 34. To account for
the increment now happening before calculating a tuple, lower the test_aud->sqn
by one to 0x21 == 33, so that it is still calculating for SQN == 34.
Because we are no longer incrementing SQN after the tuple is generated,
milenage_test's expected output after doing an AUTS resync to 31 changes to the
next SQN = 32, the SQN used for the generated tuple.
(BTW, a subsequent patch will illustrate AUTS in detail.)
osmo-auc-gen now needs to pass the user requested SQN less one, because the SQN
will be incremented befor generating the auth vector. Also the SQN remains the
same after generating, so SQN output needs less decrementing. Note that the
expected output for osmo-auc-gen_test remains unchanged, hence the same input
arguments (particularly -s <sqn> and -A <auts>) still produce the same results.
Note: osmo-hlr regression tests will require adjustments when this patch is
merged, because it must now pass desired_sqn - 1 instead of just desired_sqn.
See osmo-hlr change-id I4ec5a578537acb1d9e1ebfe00a72417fc3ca5894 .
Related: OS#1968
Change-Id: Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upcoming patches will change the way SQN are incremented. Change the SQN
related output by osmo-auc-gen so that it also makes sense after these changes,
and so that its output is proven to remain unchanged for the same arguments:
Always show the SQN used for vector generation when a UMTS vector was generated.
Don't show the next SQN, it will not make sense anymore (see later patches).
The adjustments of expected output of osmo-auc-gen_test illustrates how the
output changes.
Related: OS#1968
Change-Id: I35d9c669002ff3e8570e07b444cca34ce57c3b0c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add test for osmo-auc-gen invocations to ensure stability across upcoming SQN
increment scheme changes.
The test comprises of a shell script that invokes the osmo-auc-gen binary with
various milenage parameters, of which the stdout/stderr are verified.
More osmo-auc-gen invocations could be added, but my main focus is on the SEQ
changes. Instead of manually testing that it still works for each SQN patch, I
want this test to do it for me.
To make sure that osmo-auc-gen is build before the tests are launched, place
'utils' before 'tests' in the root Makefile.am.
Related: OS#1968
Change-Id: Ib4af34201cd2e7d76037bcd31dd89ef18c1a9aec
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the milenage_test, the console output printed "SEQ.MS = 33", but 33 is
a) the SQN, not SEQ;
b) the SQN *after* the next auth generation, i.e. SQN.MS would have been 31.
While at it also use the proper PRIu64 from inttypes.h to output the sqn value.
This prepares for upcoming sparation of SQN incrementing by SEQ and IND,
particularly to clearly show where the changes in auth/milenage_test's
expectations originate.
Related: OS#1968
Change-Id: Ie83201f1362f3d793ada774f3fc5f89cc0b3fbb7
|
|
|
|
|
|
|
|
|
| |
We don't really use state numbers without bounds check into string
tables since March 2010, when value_string became part of libosmocore.
It's time to catch up, 7 years later...
Change-Id: I1dac7b4cb441a1119cc167112521e8b8aae62e63
|
|
|
|
|
|
|
|
|
| |
We don't document the header files that define structs/enums/types
that are taken 1:1 from the relevant GSM specifications. So let's avoid
having doxygen generate tons of warnings for related undocumented
members.
Change-Id: I231f78972a015902e4085aa80fcbc04009ae9f13
|
|
|
|
|
|
| |
_NUM_CHREQ_T defines the last element of the enum
Change-Id: Id67ba8de89dd6288e449197438e9e1c5d7f5a134
|
|
|
|
|
|
|
|
|
|
| |
The previous version of this commit got reverted to avoid a breakage in openbsc.
The problem is openbsc use an array of chreq_type with a manual defined size. This array
is using enums as index which breaks if any elements got added into the
middle, because the size of the array can't hold elements greater or
equal than the size.
Change-Id: I6676105507fe4e5627f740dfe4c2770f766ad068
|
|
|
|
|
|
| |
Matches our general scheme and helps readability of an upcoming patch.
Change-Id: I174086a988b51b6e80f3661609069b69a3d41cc7
|
|
|
|
|
|
|
| |
dpkg-buildpackage fails due to missing file descriptions - add necessary
.install and .doc-base files to fix it.
Change-Id: I5fb7e813c0860a3b5037e805deb84f9bf649ffa3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are some projects, such as GR-GSM and OsmocomBB, which would
benefit from using one shared implementation of GSM 05.03 code. So,
this commit introduces a new sub-library called libosmocoding, which
(for now) provides GSM, GPRS and EDGE transcoding routines, migrated
from OsmoBTS.
The original GSM 05.03 code from OsmoBTS was relicensed under
GPLv2-or-later with permission of copyright holders (Andreas Eversberg,
Alexander Chemeris and Tom Tsou).
The following data types are currently supported:
- xCCH
- PDTCH (CS 1-4 and MCS 1-9)
- TCH/FR
- TCH/HR
- TCH/AFS
- RCH/AHS
- RACH
- SCH
Change-Id: I0c3256b87686d878e4e716d12393cad5924fdfa1
|
|
|
|
|
|
|
|
| |
To be able to add some more tests, related to convolutional coding,
without duplication of code, the test logic was separated from the
conv_test.c into conv.c and conv.h.
Change-Id: Idbdc7e19cb9b9a36cd1fccd621cd858e87530d98
|
|
|
|
|
|
|
| |
Since we have automatic header generation, implemented in the
utils/conv_gen.py, it's time to use this feature!
Change-Id: I21caa4e433b2cc1861611e35350a9671da444c2a
|
|
|
|
| |
Change-Id: Iae830d716f01810972edbef14fc5383ac647d0ea
|
|
|
|
| |
Change-Id: Ie10c47ee952f253b1ba77ecf6e79f2c033545bc1
|