15 Mar
2017
15 Mar
'17
1:46 p.m.
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "An utility library for Open Source Mobile Communications".
The branch, master has been updated
via 45e778d397a525956e377567d5f9af6318a5343e (commit)
via bb6f7b7becb138da78c0f677d6340065f91d0067 (commit)
via 82c9a0ec198d83452a4232f288e230b59fa1eaf8 (commit)
via 5fe3d1b0f7d40bd80733b23575e40b9544652fc4 (commit)
via d3b58730d5c86db96ee51e458ad35596617bebe9 (commit)
via 8e1b598c8ae408f0dd15a4460920a4d82eb05a27 (commit)
from c733d1421aff288e4ede3a532085104217c27370 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
http://cgit.osmocom.org/libosmocore/commit/?id=45e778d397a525956e377567d5f9…
commit 45e778d397a525956e377567d5f9af6318a5343e
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Tue Mar 14 02:53:56 2017 +0100
milenage_test: enhance to verify new SQN increments
After the legacy mode incrementing with ind_bitlen == 0 is through, do another
AUTS run with sensible ind_bitlen and ind, and then two more normal vector
generations to verify proper SQN increments.
Related: OS#1968
Change-Id: Id6947899ff7b1c82b939f969e163e51ce282bce2
http://cgit.osmocom.org/libosmocore/commit/?id=bb6f7b7becb138da78c0f677d634…
commit bb6f7b7becb138da78c0f677d6340065f91d0067
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Mon Mar 13 17:27:17 2017 +0100
osmo_auth_gen_vec: UMTS auth: fix SQN as SEQ || IND
So far we incremented SQN by 1, which doesn't match the procedures described in
3GPP TS 33.102. An IND (index) denotes a non-significant part of SQN, and the
significant SEQ part needs to be incremented.
In OsmoHLR we furthermore want to use the "exception" suggested in annex
C.3.4,
so that each HLR's client has a fixed IND index. In other words, we will not
assign IND cyclically, but keep IND unchanged per auth vector consumer.
Add 'ind_bitlen' and 'ind' to the osmo_sub_auth_data.u.umts structure
and
increment SQN accordingly.
Add a comment explaining the details.
Because 'ind_bitlen' is still passed as zero, the milenage_test does not
change
its behavior, which is a feature I want to clearly show in this patch. The test
will be expanded for the newly implemented SQN scheme in a subsequent patch.
Adjust osmo-auc-gen.c to still show the right SQN and SQN.MS -- because it is
passing ind_bitlen == 0, osmo-auc-gen can rely on single increments and know
SQN.MS is sqn - 1. Note that osmo-auc-gen_test output remains unchanged.
Related: OS#1968
Change-Id: Ibc97e1736a797ffcbf8c1f7d41c5c4518f4e41bf
http://cgit.osmocom.org/libosmocore/commit/?id=82c9a0ec198d83452a4232f288e2…
commit 82c9a0ec198d83452a4232f288e230b59fa1eaf8
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Mon Mar 13 17:36:17 2017 +0100
osmo_auth_gen_vec: UMTS auth: store last used SQN, not next
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
http://cgit.osmocom.org/libosmocore/commit/?id=5fe3d1b0f7d40bd80733b23575e4…
commit 5fe3d1b0f7d40bd80733b23575e40b9544652fc4
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Wed Mar 15 01:16:43 2017 +0100
osmo-auc-gen: clarify SQN output, prepare for SQN changes
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
http://cgit.osmocom.org/libosmocore/commit/?id=d3b58730d5c86db96ee51e458ad3…
commit d3b58730d5c86db96ee51e458ad35596617bebe9
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Wed Mar 15 01:52:58 2017 +0100
add osmo-auc-gen_test
Add test for osmo-auc-gen invocations to ensure stability across upcoming SQN
increment scheme changes.
The test comprises of a shell script that invokes the osmo-auc-gen binary with
various milenage parameters, of which the stdout/stderr are verified.
More osmo-auc-gen invocations could be added, but my main focus is on the SEQ
changes. Instead of manually testing that it still works for each SQN patch, I
want this test to do it for me.
To make sure that osmo-auc-gen is build before the tests are launched, place
'utils' before 'tests' in the root Makefile.am.
Related: OS#1968
Change-Id: Ib4af34201cd2e7d76037bcd31dd89ef18c1a9aec
http://cgit.osmocom.org/libosmocore/commit/?id=8e1b598c8ae408f0dd15a4460920…
commit 8e1b598c8ae408f0dd15a4460920a4d82eb05a27
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Mon Mar 13 17:36:36 2017 +0100
milenage_test: cosmetic fix: shown value is not SEQ.MS
In the milenage_test, the console output printed "SEQ.MS = 33", but 33 is
a) the SQN, not SEQ;
b) the SQN *after* the next auth generation, i.e. SQN.MS would have been 31.
While at it also use the proper PRIu64 from inttypes.h to output the sqn value.
This prepares for upcoming sparation of SQN incrementing by SEQ and IND,
particularly to clearly show where the changes in auth/milenage_test's
expectations originate.
Related: OS#1968
Change-Id: Ie83201f1362f3d793ada774f3fc5f89cc0b3fbb7
-----------------------------------------------------------------------
Summary of changes:
Makefile.am | 2 +-
include/osmocom/crypt/auth.h | 2 +
src/gsm/auth_milenage.c | 77 ++++++++++++++++-
tests/Makefile.am | 5 +-
tests/auth/milenage_test.c | 40 ++++++++-
tests/auth/milenage_test.ok | 5 +-
.../osmo-auc-gen/osmo-auc-gen_test.err | 0
tests/osmo-auc-gen/osmo-auc-gen_test.ok | 99 ++++++++++++++++++++++
tests/osmo-auc-gen/osmo-auc-gen_test.sh | 30 +++++++
tests/testsuite.at | 7 ++
utils/osmo-auc-gen.c | 27 +++---
11 files changed, 271 insertions(+), 23 deletions(-)
copy debian/libosmocore.install => tests/osmo-auc-gen/osmo-auc-gen_test.err (100%)
create mode 100644 tests/osmo-auc-gen/osmo-auc-gen_test.ok
create mode 100755 tests/osmo-auc-gen/osmo-auc-gen_test.sh
hooks/post-receive
--
An utility library for Open Source Mobile Communications