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_b1e9d796?usp=email
 :
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_7e2513d6?usp=email
 :
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_b767ca98?usp=email
 :
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.



--
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38397?usp=email
To unsubscribe, or for help writing mail filters, visit 
https://gerrit.osmocom.org/settings?usp=email

Gerrit-MessageType: comment
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I29237997e414aea80f254247da54f909410a4b36
Gerrit-Change-Number: 38397
Gerrit-PatchSet: 5
Gerrit-Owner: lynxis lazus <[email protected]>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <[email protected]>
Gerrit-Reviewer: laforge <[email protected]>
Gerrit-Reviewer: pespin <[email protected]>
Gerrit-Attention: laforge <[email protected]>
Gerrit-Attention: lynxis lazus <[email protected]>
Gerrit-Comment-Date: Mon, 25 Nov 2024 19:08:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: laforge <[email protected]>
Comment-In-Reply-To: fixeria <[email protected]>
Comment-In-Reply-To: lynxis lazus <[email protected]>

Reply via email to