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