| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I84ef43f700e125c7a65f92347f12844e07e65655
|
|
|
|
| |
Change-Id: I4b1abc8d8aae4bd9a32f927269d7ebfef902d7c5
|
|
|
|
| |
Change-Id: Icc76cae2225ec4e664b950176dd861fa15712f59
|
|
|
|
| |
Change-Id: I13decca25dcdb75191c1e78058704ae8efa69b33
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
log_enable_multithread() enables use of locks inside the
implementation. Lock use is disabled by default, this way only
multi-thread processes need to enable it and suffer related
complexity/performance penalties.
Locks are required around osmo_log_target_list and items inside it,
since targets can be used, modified and deleted by different threads
concurrently (for instance, user writing "logging disable" in VTY while
another thread is willing to write into that target).
Multithread apps and libraries aiming at being used in multithread apps
should update their code to use the locks introduced here when
containing code iterating over osmo_log_target_list explictly or
implicitly by obtaining a log_target (eg. osmo_log_vty2tgt()).
Related: OS#4088
Change-Id: Id7711893b34263baacac6caf4d489467053131bb
|
|
|
|
|
|
|
|
| |
Receive gsmtap logs and feeds it into the python logging
framework. Allows to use generic logging features and
further utilities.
Change-Id: I24478d8e16066c6118e867bdba54c6418c15e170
|
|
|
|
|
|
|
|
|
|
| |
That's pretty straightforward and convenient extention: handle all
extra positional arguments as patch file names. This makes it similar to
'cp' and other coreutils basic tools. For example:
osmo-config-merge base.cfg patch1.cfg patch2.cfg patch3.cfg
will apply 3 patches to the base config file.
Change-Id: I212cbdc3bf6f251c1a3175737ac74242fb004c6d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARFCNs are values in well defined ranges. Until this patch, ARFCNs not
belonging to any band were blindly assigned to DCS1800 by
gsm_arfcn2band, causing unnoticed bugs and misconfigurations in
osmo-bsc.
Previous API gsm_arfcn2band cannot accomodate this kind of check easily,
so let's deprecate it to tell people to use a new API gsm_arfcn2band_rc
which performs this kind of checks and allows callers to log failures,
misconfigurations, etc.
At the same time, modify implementation of gsm_arfcn2band to abort if an
invalid ARFCN is passed, this way users of this API can notice they are
passing wrong data to it that most probably will produce unexpected
results.
Related: OS#3063
Change-Id: I780d452dcebce385469e32ef2fd844df6033393a
|
|
|
|
|
| |
Change-Id: Ib44f902e5bca2277f1b340d34fabbd2a298d683e
Fixes: Coverity CID#188851
|
|
|
|
|
|
|
|
|
| |
Allocate NULL context after exit_usage() calls and free it before exit
so * sanitizer is happy.
Also handle the error cases gracefully when a file is unreadable or
formatted wrong.
Change-Id: I966e63a3f7d0ff71ee0b88922aa3807d073aa232
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes the following compiler warning:
osmo-config-merge.c: In function ‘main’:
osmo-config-merge.c:268:1: warning: control reaches end
of non-void function [-Wreturn-type]
Despite it isn't critical, let's get rid of this warning.
Change-Id: I7a80a85c8b3180dc086cd9fd20356aab16ea8100
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code passed gerrit build verification but failed the master
builds with the following error:
osmo-config-merge.c:148:4: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
for (int i = 0; i < cur_indent - indent; i++) {
^
osmo-config-merge.c:148:4: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your
code
Change-Id: Ia29e85b648c1a427be88242306634efe890e250d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This utility allows you to merge an incremental config "patch"
into an osmocom-style config file.
The patch file follows the same syntax as the original config file.
It works by appending the leaf nodes of the patch file to the respective
nodes of the input config file.
This process allows configuration file changes/updates to be performed
in a more stable/reliable way than by means of [unified] diff files,
as they break every time the context lines break.
osmo-config-merge doesn't suffer from this problem, as it understands
the tree-like nature of VTY config files.
NITE: This only works with configuration files that have proper
indenting, i.e. every level in the hierarchy must be indented excatly
one character, not multiple.
Change-Id: I61997a3668cc3a40d12ca023272f6d782e6fbefe
|
|
|
|
|
|
|
| |
gcc 8.1.0 complains that the terminating \0 is not copied by strncpy, while
this code intends to do exactly that. Use memcpy instead.
Change-Id: I8d66fa22502c04d11ae153b9856d7e54f3492dd6
|
|
|
|
|
|
|
|
|
|
|
| |
The conv_gen.py utility was tested against both Python 2 and 3,
so there is no need to enforce Python 2. Also, having:
#!/usr/local/bin/python{2|3}
is a bad idea, because Python may be installed in a different location.
Change-Id: I6007d481047b584db13d6eda70fb99f11f9ddaa1
|
|
|
|
|
|
| |
This reverts commit 76c6c50405c6cbb1d08bdd7b5d27c657fa5d38b6, which broke the obs builds. I'm really starting to get annoyed by ongoing python related breakage without ever fixing any bugs!
Change-Id: I4d76e897d4f746ff9ea4e06f2efc708a12cc2944
|
|
|
|
|
|
|
|
| |
There're no python2-specific code in there so we can switch right away
without waiting till 2020 for python 2 deprecation.
Related: OS#2819
Change-Id: I8d34aed124b00c5dd2ab1bcc84bbfa8c620282cc
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for extended RACH (11 bit) according 3GPP TS 45.003 §5.3.2:
* convolutional code with puncturing
* encoding/decoding routines
* corresponding tests
Change-Id: I85a34a82d5cd39a594ee89d91a2338226066ab5d
Related: OS#1548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the warning below:
warning: ‘sqn’ may be used uninitialized in this function [-Wmaybe-uninitialized]
fprintf(stderr, "Requesting --sqn %"PRIu64" implies IND=%u,"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
" so no further --ind argument is allowed.\n",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sqn, test_aud.u.umts.ind);
~~~~~~~~~~~~~~~~~~~~~~~~~
The warning is a false positive as sqn is only used in case
sqn_is_set!=0, and in that code path, sqn is set.
Change-Id: Ib5903db01ea6765bd6bb688e63f70925c5012f98
|
|
|
|
| |
Change-Id: I54f4e439cc232d926b42ddba9648d4f5e7487c3e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function is a wrapper on top of getrandom() (if available via glibc) or
corresponding syscall. If neither is available than failure is always
returned.
It's intended to generate small random data good enough for session
identifiers and keys. To generate long-term cryptographic keys it's
better to use special crypto libraries (like GnuTLS for example)
instead.
As an example it's used to replace old insecure random number generator
in osmo-auc-gen utility.
Change-Id: I0241b814ea4c4ce1458f7ad76e31d390383c2048
Related: OS#1694
|
|
|
|
|
|
|
|
| |
The compiler thinks that ind or ind_mask may be used uninitialized, because it
doesn't analyze the conditionality of command line arguments and other
variables set accordingly. Make the compiler happy by zero initializing.
Change-Id: I9ddcb0525159da520aceaeb6e908a735a003bb5a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing UMTS AKA with AUTS, it can be interesting to know the SQN.MS that
was encoded in the AUTS. The only way to know this is to provide it as a
separate out-parameter from milenage_gen_vec_auts(), because the SQN.MS from
AUTS stored in umts.sqn is immediately modified non-trivially by
milenage_gen_vec(). Add sqn_ms to struct osmo_sub_auth_data to retain SQN.MS
even after a vector was generated.
Use this to print out SQN.MS for 'osmo-auc-gen -3 -A'.
Adjust test suite expectations.
Related: OS#2464
Change-Id: I9fc05bbf169d06716f40b995154fd42a3f91bef3
|
|
|
|
|
|
|
|
|
|
| |
Make ind_mask available in the main(){} scope, in order to print out
IND = SQN & ind_mask.
Adjust test suite expectations.
Related: OS#2465
Change-Id: I91eac53c4af66a58b9372d9baf5781fc9f29b1fc
|
|
|
|
|
|
|
|
|
|
|
| |
osmo-auc-gen so far does not allow indicating the IND bit length of SQN. A
default of 5 serves most practical cases, nevertheless we should allow passing
arbitrary IND lengths.
Enhance the test suite to test --ind-len.
Related: OS#2465
Change-Id: Ia1d8b6a823ffc92290b3e39e4e4665aeff80ccc0
|
|
|
|
|
|
|
|
|
|
|
|
| |
During UMTS AKA, the caller typically indicates which IND slot the next used
SQN should belong to. Without this option, osmo-auc-gen will always produce SQN
from IND-slot 0. Add --ind option.
Enhance the osmo-auc-gen_test.sh to expect errors with useful printouts on
stderr, and add tests that verify valid --ind ranges.
Related: OS#2465
Change-Id: Ib60eec80d58ca9a0a01e7fbd2bcbbd4339b1a6d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most USIM out there seem to use IND-length = 5 bits, so do sysmousim-sjs1.
Currently from initialization we are using an IND length of zero in
osmo-auc-gen, which produces confusing SQN results after AUTS:
Where want SQN to be incremented to the next IND array, usually +32, an IND-len
of 0 makes for only +1.
As result, the osmo-auc-gen_test.sh produces SQN 32 instead of 24 after
receiving SQN.MS = 23 from AUTS: adjust test expectations.
Related: OS#2465
Change-Id: I9fcc11fa2b5816302dcc6b72249b1ee40d5a61f5
|
|
|
|
|
|
|
|
|
|
|
|
| |
The user supplied an --sqn to generate a vector for, but milenage_gen_vec()
performs a nontrivial SQN increment before generating the vector. To end up
with the user supplied SQN, we need to reverse this increment beforehand.
Do this after all cmdline args have been parsed, in case one of them modifies
the IND-bitlen parameter, which affects the SQN calculations.
Related: OS#2464 OS#2465
Change-Id: Ic51a8f6333fee9c02b4073ca360991d0aa69c74f
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
osmo-auc-gen tries to be helpful by deriving the SQN.MS from the SQN that
resulted from AUTS + milenage_gen_vec(), but there is actually no way to derive
the actual AUTS SQN.MS from the resulting SQN.
Completely drop the printout to prevent confusion.
Adjust test suite expectations.
Related: OS#2464
Change-Id: Ie2432c6d6a23818f7b3a29b1295dcbb505e2be53
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Considering the various styles and implications found in the sources, edit
scores of files to follow the same API doc guidelines around the doxygen
grouping and the \file tag.
Many files now show a short description in the generated API doc that was so
far only available as C comment.
The guidelines and reasoning behind it is documented at
https://osmocom.org/projects/cellular-infrastructure/wiki/Guidelines_for_API_documentation
In some instances, remove file comments and add to the corresponding group
instead, to be shared among several files (e.g. bitvec).
Change-Id: Ifa70e77e90462b5eb2b0457c70fd25275910c72b
|
|
|
|
|
|
|
|
|
|
| |
Especially for short descriptions, it is annoying to have to type \brief for
every single API doc.
Drop all \brief and enable the AUTOBRIEF feature of doxygen, which always takes
the first sentence of an API doc as the brief description.
Change-Id: I11a8a821b065a128108641a2a63fb5a2b1916e87
|
|
|
|
| |
Change-Id: I3060cfee8ece86c4c89a65f93c9f5424df0c410b
|
|
|
|
| |
Change-Id: Id577d9df5a814ad5aa00e1d04c4790d75d17ad7e
|
|
|
|
| |
Change-Id: Id94d2fe83f080a18a2a686206bd21cf5fafe2fa7
|
|
|
|
|
|
|
| |
Previously, this would fail when generating to $builddir if that subtree did
not exist yet in $builddir.
Change-Id: Ia4fba96dcf74a25cf3e515eb3e4f970e0c3cdd54
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Iae830d716f01810972edbef14fc5383ac647d0ea
|
|
|
|
| |
Change-Id: Ie10c47ee952f253b1ba77ecf6e79f2c033545bc1
|
|
|
|
|
|
|
|
|
|
| |
This change makes the conv_gen application more interactive
and flexible, allowing to generate not only code definitions
but also the test vectors and header files in the future.
Moreover, it becomes possible to select exact code family,
such as GSM, GMR etc.
Change-Id: I0b476b00234c17f78b41d695cf3bfd13edb64c28
|
|
|
|
|
|
|
| |
FreeBSD 11.0 uses clang version 3.8.0 which spits various warnings
during libosmocore compilation. Let's clean this up a bit.
Change-Id: Ic14572e6970bd0b8916604fabf807f1608fa07e5
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the -h help output, list the names of available algorithms.
In case of option parsing failure, also print help() (so that e.g. for a typo
in the algorithm, the list of algorithms is printed along with the error
message).
If there are -2/-3 or -a missing, show an error message that explains this.
Change-Id: I76732b28d7a553a6293d1707fe398d28b5ef4886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calculating a re-sync vector using AUTS, osmo-gen-vec used to print
SQN.MS + 2, the new SQN after vector generation, labeled 'SEQ.MS'.
Firstly, s/SEQ/SQN.
Secondly, print SQN.MS as umts.sqn - 2, which is the actual SQN recovered from
the AUTS. As explained in the comment, SQN.MS + 1 is used to generate the
vector, and then umts.sqn is increased a second time to indicate the next SQN.
With AUTS calculated from SQN.MS == 23, the output was:
AUTS success: SEQ.MS = 25
Output now:
AUTS success: SQN.MS = 23, generated vector with SQN = 24, next SQN = 25
Change-Id: I881bbe8246a5e7d3a5065b4b5b533255723b1a9e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GSUP transmits AUTS for UMTS authentication procedures, and OAP uses the same
procedures to authenticate. osmo-gen-vec is a utility program that passes AUTS
to our osmo_auth_gen_vec_auts() API.
According to 3GPP 33.102 6.3.3, AUTS = SQN^AK || MAC-S, which are 6 || 8 == 14
bytes. This is confirmed by 24.008 9.2.3a where the TLV has 16 bytes, TL = 2
and AUTS being the V = 14.
It is not harmful for milenage_gen_vec_auts() to pass two more AUTS bytes. But
writing 16 bytes to a GSUP struct is a potential problem when passing in a 14
byte long AUTS buffer to the GSUP API, which then reads past the AUTS buffer.
The API implies the length, so far to be 16, so passing in a 14 byte buffer to
GSUP would require copying to a larger buffer first.
Fix this by using a length of 14 for AUTS everywhere instead.
This constitues an ABI breakage, we may handle it as a "fix before an official
release", otherwise we need a version bump.
The OAP protocol document has also been updated, needs an update in the
osmo-gsm-manuals as well.
Change-Id: If25b173d9ec57ea4c504d860954912b7d82af455
|
|
|
|
|
|
|
|
|
| |
This change separates the convolutional code definitions from the code
generator logic, allowing us to make further changes in more specific
way. For example, adding some new codes, you change the conv_codes.py
only because such change isn't related to the generator.
Change-Id: I3428561251b7d7a180d1e9b6fcaad50bdbbc37fa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces the memory usage optimization, mentioned
in d2d9760c08f35a231d32f0ebeb73b2927e5573b3. The aim is to make
code generator able to detect, whether the same tables are used
by several convolutional code definitions, and prevent one from
writing these tables multiple times.
For now, the detection process isn't fully automatic, so all
shared polynomials should be placed inside the 'shared_polys'
dictionary, for example:
shared_polys = {
"xcch" : [
( G0, 1 ),
( G1, 1 ),
],
"mcs" : [
( G4, 1 ),
( G7, 1 ),
( G5, 1 ),
],
}
Change-Id: I84760f5cdfdaece376b801d2e6cb2954ee875a3b
|
|
|
|
|
|
|
|
| |
we wanted to check for !rmsg, but used to check for !msg, missing error
returns from read_record_nr().
Change-Id: I79b6a94b1aa947c8329317b0626865c3cd4159c1
Fixes: Coverity CID 57672
|
|
|
|
|
|
|
|
|