Attention is currently required from: laforge, lynxis lazus.
fixeria has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38397?usp=email )
Change subject: SGSN: BSSGP_ConnHdlr: GMM Service Request: handle PMM IDLE UE correct ......................................................................
Patch Set 5: Code-Review-1
(3 comments)
Commit Message:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38397/comment/df49721a_b1e9d... : PS4, Line 9: explicit mention The spec. "explicitly mentions"?
File sgsn/BSSGP_ConnHdlr.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38397/comment/bd742d39_7e251... : PS4, Line 632: explicit Looks more like "implicit". The `tr_GMM_SERVICE_ACC` would be explicit (as the name suggests).
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38397/comment/044de489_b767c... : PS4, Line 640: } else {
Done
So depending on the UE state (IDLE or CONNECTED) we may receive:
* an explicit accept via `tr_GMM_SERVICE_ACC` (if in `CONNECTED`); * an implicit accept via `tr_RANAP_SecurityModeCmd` (if in `IDLE`).
It's only now that I realized that `exp_service_acc` stands for "explicit" and not for "expect"! This is why I previously asked if we should still fail if we get an `tr_GMM_SERVICE_REJ`, I was under impression that it means "expect a service accept".
The only aspect I am still fail to understand is why you're doing the `repeat` if `exp_service_acc` is `false` (meaning the implicit accept). I might be missing something, but IMO we should `repeat` when `exp_service_acc` is `true` instead. This way you would keep waiting for an explicit acceptance even if you complete the security mode control procedure.
The way it works with your patch applied is as follows:
* When `exp_service_acc == true`, we `setverdict(pass)` when either `tr_GMM_SERVICE_ACC` (explicit acceptance) or `tr_RANAP_SecurityModeCmd` (implicit acceptance) is received. So we do not actually enforce the explicit acceptance and let it pass either way. * When `exp_service_acc == false`, we do not expect to receive `tr_GMM_SERVICE_ACC` (and this is correct, though the altstep will get stuck if you receive it from the IUT despite the expectations) and will `repeat` if we receive `tr_RANAP_SecurityModeCmd`, even though it's the implicit acceptance.