aboutsummaryrefslogtreecommitdiffstats
path: root/utils
AgeCommit message (Collapse)AuthorFilesLines
2019-12-09sim: allow opening reader# > 0Eric Wild1-1/+49
Change-Id: I4b1abc8d8aae4bd9a32f927269d7ebfef902d7c5
2019-12-03utils: exit(2) on unsupported positional arguments on command lineHarald Welte2-0/+10
Change-Id: Icc76cae2225ec4e664b950176dd861fa15712f59
2019-12-03osmo-arfcn: Fix '-h' optionHarald Welte1-1/+1
Change-Id: I13decca25dcdb75191c1e78058704ae8efa69b33
2019-10-09logging: Introduce mutex API to manage log_target in multi-thread envsPau Espin Pedrol1-2/+2
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
2019-06-04utils: add gsmtap_logread.py a gsmtap log readerAlexander Couzens2-0/+167
Receive gsmtap logs and feeds it into the python logging framework. Allows to use generic logging features and further utilities. Change-Id: I24478d8e16066c6118e867bdba54c6418c15e170
2019-02-22Add multipatch capability to osmo-config-mergeMax1-21/+45
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
2018-11-20gsm: Deprecate buggy gsm_arfcn2band API and introduce gsm_arfcn2band_rcPau Espin Pedrol1-1/+7
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
2018-10-21osmo-config-merge: fclose() what we fopen()Harald Welte1-0/+2
Change-Id: Ib44f902e5bca2277f1b340d34fabbd2a298d683e Fixes: Coverity CID#188851
2018-09-28osmo-config-merge: Fix some small issuesDaniel Willmann1-4/+15
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
2018-09-27utils/osmo-config-merge: explicitly return from main()Vadim Yanitskiy1-0/+2
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
2018-09-25osmo-config-merge: Don't use C99 'for' loop initial declarationsHarald Welte1-2/+4
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
2018-09-25Add new osmo-config-merge utilityHarald Welte2-1/+271
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
2018-07-27cosmetic: osmo-sim-test.c: use memcpy instead of strncpyNeels Hofmeyr1-1/+2
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
2018-07-02Don't enforce Python 2 for utilitiesVadim Yanitskiy2-2/+3
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
2018-02-09Revert "Use python 3 for utilities"Harald Welte2-2/+2
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
2018-02-08Use python 3 for utilitiesMax2-2/+2
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
2017-12-11Add functions for extended RACH codingMax1-1/+10
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
2017-11-16utils: Fix false positive in compiler warningPau Espin Pedrol1-1/+1
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
2017-10-30utils: move linked libraries into common variableMax1-3/+2
Change-Id: I54f4e439cc232d926b42ddba9648d4f5e7487c3e
2017-10-09Add function to generate random identifierMax1-8/+6
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
2017-09-12osmo-auc-gen.c: squelch compiler warnings, move local varNeels Hofmeyr1-4/+3
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
2017-08-29umts aka: add sqn_ms out-param, print SQN.MS in osmo-auc-genNeels Hofmeyr1-0/+2
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
2017-08-29osmo-auc-gen: umts: print out the IND of the SQN usedNeels Hofmeyr1-3/+7
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
2017-08-29osmo-auc-gen: umts: add --ind-len argNeels Hofmeyr1-1/+10
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
2017-08-29osmo-auc-gen: umts: add --ind argNeels Hofmeyr1-1/+29
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
2017-08-29osmo-auc-gen: umts: use default of ind_bitlen = 5 instead of 0Neels Hofmeyr1-0/+1
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
2017-08-29osmo-auc-gen: umts: properly request --sqnNeels Hofmeyr1-5/+17
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
2017-08-29osmo-auc-gen: umts: remove erratic SQN.MS printoutNeels Hofmeyr1-6/+0
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
2017-06-23doxygen: unify use of \file across the boardNeels Hofmeyr2-4/+6
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
2017-06-23doxygen: enable AUTOBRIEF, drop \briefNeels Hofmeyr1-2/+1
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
2017-06-22osmo-sim-test.c: Remove unused functionsPau Espin Pedrol1-37/+0
Change-Id: I3060cfee8ece86c4c89a65f93c9f5424df0c410b
2017-05-17utils/osmo-sim-test.c: strip unused variablesVadim Yanitskiy1-5/+1
Change-Id: Id577d9df5a814ad5aa00e1d04c4790d75d17ad7e
2017-03-20build: fix distcheck: include gen scripts in EXTRA_DISTNeels Hofmeyr1-0/+2
Change-Id: Id94d2fe83f080a18a2a686206bd21cf5fafe2fa7
2017-03-20build: conv_gen.py: ensure parent dirs of written files existNeels Hofmeyr1-3/+9
Previously, this would fail when generating to $builddir if that subtree did not exist yet in $builddir. Change-Id: Ia4fba96dcf74a25cf3e515eb3e4f970e0c3cdd54
2017-03-20osmo-auc-gen: fix --sqn limit on 32bit systems, fixing buildNeels Hofmeyr1-3/+1
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
2017-03-15osmo_auth_gen_vec: UMTS auth: store last used SQN, not nextNeels Hofmeyr1-5/+7
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
2017-03-15osmo-auc-gen: clarify SQN output, prepare for SQN changesNeels Hofmeyr1-15/+10
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
2017-03-07libosmocoding: migrate transcoding routines from OsmoBTSVadim Yanitskiy1-0/+24
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
2017-03-06utils/conv_gen.py: add header generation featureVadim Yanitskiy1-5/+44
Change-Id: Iae830d716f01810972edbef14fc5383ac647d0ea
2017-03-06utils/conv_gen.py: add test vectors generation featureVadim Yanitskiy1-2/+76
Change-Id: Ie10c47ee952f253b1ba77ecf6e79f2c033545bc1
2017-02-09utils/conv_gen.py: improve application flexibilityVadim Yanitskiy1-8/+38
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
2017-02-08fix various compiler warnings (on FreeBSD-11.0)Harald Welte1-3/+3
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
2017-02-06osmo-auc-gen: cmdline help: list algorithms; error messagesNeels Hofmeyr1-1/+10
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
2017-02-04osmo-auc-gen: cosmetic: clarify output upon AUTSNeels Hofmeyr1-1/+14
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
2017-02-02GSUP, OAP, osmo-gen-vec: fix AUTS length to 14, not 16Neels Hofmeyr1-1/+1
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
2016-12-24utils/conv_gen.py: separate code definitionsVadim Yanitskiy2-714/+728
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
2016-12-24utils/conv_gen.py: use shared tables if possibleVadim Yanitskiy1-37/+61
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
2016-11-26osmo-sim-test.c: Fix rmsg checkHarald Welte1-1/+1
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
2016-11-02utils/conv_gen.py: explicitly import reduce()Vadim Yanitskiy1-0/+1
This change finally makes the script able to be executed in Python 3 environment. Due to new Python 3 restrictions, the reduce() should be imported explicitly. Change-Id: Icbc81c29f1a226aeed2c1245a5d60809fe124005
2016-11-02utils/conv_gen.py: don't mix print and write()Vadim Yanitskiy1-32/+34
This is mostly a code style change, but it also increases the compatibility with Python 3. Change-Id: I5c8271d973f766aeb9cbcab30c4eddfdab54fcbb
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 00:30:50 +0000