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
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
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
Neels Hofmeyr
Neels Hofmeyr