libosmogsm has recently introdcued a 'struct osmo_sub_auth_data2' as
successor to 'struct osmo_sub_auth_data', together with updated
osmo_auth_gen_vec2/osmo_auth_gen_vec_auts2 API.
The rationale of this new API is to enable
* support for AKA algorithms which use K and/or OP[c] values of 256bit
(instead of the classic 128bit)
* support for RES length sizes of 4 and 16 bytes (instead of the classic
8 bytes)
This commit just jumps over to the new API without adding any related
functionality to osmo-hlr. The latter is left for subsequent commits.
Change-Id: I3207c7bfb73e9ff5471e5c26b66639549e4d48a2
Depends: libosmocore.git Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
This templates is used for generating C code, so it should use our
normal tab-based code indenting.
Change-Id: I0be7eb2d7b551d7eaaee15994ef37262694819f6
So far we supported a "xor" algorithm in osmo-hlr, without specifying
whether it's the XOR-3G or the (different) XOR-2G algorithm.
Furthermore, it was buggy in the sense that it permitted the XOR[-3G]
for 2G authentication data in the database.
This patch
* renames existing "xor" to "xor-3g"
* disallows "xor-3g" usage with 2G authentication data
* introduces support for XOR-2G as "xor-2g" in the VTY
Change-Id: I039a1f84fda54a908a82fe621e7fd078cb85e4c6
Depends: libosmocore.git I0ee0565382c1e4515d44ff9b1752685c0a66ae39
Unfortunately "-std=c99" is not sufficient to make gcc ignore code that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: I861be39275b40c522c02f553074c5a4489e87127
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: I70cf75b3cb6ae59c92248cc529546750fb0da07b
log_set_print_category_hex(0) is added in some places since the old API
used to set that internally to keep backward compatiblity.
Change-Id: I3cf46b7c24452254319d5c3eacceff418211bcf7
Test USIMs as specified by 3GPP use the XOR algorithm not only for 2G
but also for 3G. libosmocore includes the XOR-3G support since v1.3.0,
but osmo-hlr somehow never made use of it.
Change-Id: I3a452af9c18cd90d00ab4766d6bd1679456bc1a2
Closes: OS#4924
Change the interpreter of the python script back to python3, as it was
when the script was initially added in
Idff9d757ab956179aa41ada2a223fd9f439aafbd. In the meantime, it had been
changed to python2 to make it work with build slaves that were missing
python3, but this is not necessary anymore.
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: Ifbb8f8f5428657a1c2d4d6d1217f8e374be43aba
Apply the same headers structure that we keep in most Osmocom source trees:
Keep noinst_HEADERS in include/osmocom/hlr and include them using
#include <osmocom/hlr/*.h>
The only header kept in src/ is db_bootstrap.h, because it is generated during
build time. If it was built in include/osmocom/hlr, we would need db.o to
depend on db_bootstrap.h in a different subdir, which automake can't do well.
Change-Id: Ic912fe27f545b85443c5fb713d8c3c8aac23c9ad
This ensures that the rpath of the generated binaries is set to use only
the just-compiled so-files and not any system-wide installed libraries
while avoiding the ugly shell script wrapper.
Change-Id: I927561289b17b313d52fb5c1da55e237fc1d33be
Don't log "deriving 2G from 3G" when we're actually calculating separately; log
it when we're actually deriving from 3G.
Add log "calculating 2G separately" in the right place.
The test output changes show that each test said "separate 2G" at the top while
logging "deriving 2G from 3G" further down, which was obviously wrong.
Change-Id: I6679d7ef8fdcae39a0c2aff7ac638e63dddb10dc
Tweak unit test binaries to still used DEBUG loglevels, so that their expected
outputs remain unchanged (and nicely verbose).
Adjust test_nodes.vty, now expecting the 'notice' log levels upon
'show running-config'.
Change-Id: Ic061e61c9625b49cef8bc2a2c0b936e262c22268
The previous efforts have failed: python3 does not supply
/usr/bin/python symlink. Let's use python-minimal dependency.
Change-Id: If9e3f31622efae132b25683c54ce09c83ce43415
After recent switch to legacy python2 .deb fails on OBS. Let's put
known-to-work python3 dependency back but keep the script itself on
python without version specifier as it seems to work fine with both
versions.
This, in turn, causes tests to fail on FreeBSD so disable them for now.
Change-Id: I4a87252d411d840fca7362736a8c7877efa6ff52
Related: SYS#3322
We can no longer accurately print the SQN from AUTS resync, since the SQN is
incremented after AUTS. Instead, always print the SQN from the generated tuple,
i.e. exactly the one left in auth data *after* the tuple was generated.
This change was forgotten in recent adjustments to the new SQN incrementing
scheme from libosmocore, in change-id I4ec5a578537acb1d9e1ebfe00a72417fc3ca5894
for libosmocore change-id Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3.
It should have been obvious that something was missing in the previous patch
from the auc_test output: the SQN in the output changed while the AUTN remained
the same. That slipped by without being noticed :/
Change-Id: I0e1e828da931a3d22c75306c55bdb7f44df6512f
In change-id Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3, libosmocore changes
from incrementing SQN after tuple generation to incrementing SQN before tuple
generation. Thus we now need to pass desired_sqn - 1 to get the same tuples.
Adjust all regression tests, showing that the tuples as well as the SQNs used
to generate the tuples remain unchanged, and only the SQN before and after
generating reflect different values.
Related: OS#1968 OS#1969
Change-Id: I4ec5a578537acb1d9e1ebfe00a72417fc3ca5894
The current auc tests test a lot with SQN == 0. An upcoming change in the SQN
algorithms from libosmocore [1] will require us to pass desired_sqn - 1,
because the tuple generation will increment the SQN before calculating. Later
on [2] we will also want to employ ind_bits and ind in the test. In order to
have some room in the number range, cosmetically adjust the current SQN tested
for from 0 to 32, changing the generated AUTN. The upcoming adjustment to the
new situation will then be able to show that only the SQN values before and
after vector generation change while the auth tuples as well as the SQNs used
for generation remain the same (without having to trick around with wrapping
SQN past its maximum value).
Note that the TS 55.205 test sets include neither SQN nor AUTN. While AUTN
changes with changing SQN, all the other values are invariant of the SQN used.
So we can simply choose a different SQN and ignore the difference in the AUTN.
[1] change-id Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3 "store last sqn"
[2] change-id Ibc97e1736a797ffcbf8c1f7d41c5c4518f4e41bf "fix SQN increment"
Related: OS#1969
Change-Id: I45d1866cde1b3e777460df76100af2fe4767c678
In the test failure mismatch printf, better indicate the place of first
mismatch. Helpful if some byte within a hexdump differs, the case when
debugging AUTS.
Copy some optarg code from openbsc's msc_vlr tests to provide verbose mode that
prints log statements' source file and line.
Change-Id: I1b23da055b5edacba09310411caf43c4cd1c29bc
Fix bug where AUTS was fed to each vector generation and thus each vector was
generated with the same SQN. In auc_3g_test, adjust the bug indicating test
expectations to now expect the proper results.
Depends: libosmocore change-id If943731a78089f0aac3d55245de80596d01314a4
Change-Id: I425a1d92c85896227341f565f5361c0d830ce866
Make the generation logic easier to understand (hopefully).
Massively extend debug logging, which serves to illustrate the current AUTS
failure shown by auc_3g_test.
Since DAUC now logs the vectors, there is no need to print the vectors in
VEC_IS() in auc_3g_test and auc_ts_55_205_test_sets anymore. Adjust testlog
expectations accordingly.
Change-Id: Ifb36d010a4ac64c765517e15b9074424ec19cc60
Add test that shows how passing AUTS to auc_compute_vectors performs an AUTS
sync on each vector and hence produces the same SQN each time. This will
generate one working vector as resync result, and then N-1 more with the wrong
SQN as far as the USIM is concerned. This causes a resync to be necessary on
every authentication.
Depends: libosmocore change-id If943731a78089f0aac3d55245de80596d01314a4
Change-Id: I246c9edfb009b593f834bb5b0577b65bfde7083c
Preparing for upcoming unit test, in a separate commit for cosmetic reasons
(setting the flag to false across the code).
Change-Id: I6b9899cd898eecc95b244432f416041b194a7187
In auc_gen_vectors(), add various checks that the auth data arguments passed
make sense, and add unit test to verify that they work. (Caught a segfault due
to NULL dereference with this.)
Change-Id: I775652b6a91d382707ce32176a3fe4ef547cbca7
Used this to catch a bug where the AUTS process failed to copy RAND to the auth
vector (libosmocore).
Depends: libosmocore change-id If943731a78089f0aac3d55245de80596d01314a4
Change-Id: I06dd8671aa515139bdc3f08883f08276662cf25f
Put to-text conversion of the 3GPP TS 55.205 PDF's section defining the test
vectors in tests/auc/gen_ts_55_205_test_sets/ts55_205_test_sets.txt and add
python script to generate auc_ts_55_205_test_sets.c from that at build time.
The generated auc_ts_55_205_test_sets.c runs through all 19 test sets,
verifying that our gsm_milenage() matches the reference data.
Change-Id: Idff9d757ab956179aa41ada2a223fd9f439aafbd
Harald Welte
Vadim Yanitskiy
Pau Espin
Oliver Smith
Neels Hofmeyr
Daniel Willmann
Neels Hofmeyr