Attention is currently required from: laforge, lynxis lazus.

Patch set 5:Code-Review -1

View Change

3 comments:

• Commit Message:

  • Patch Set #4, Line 9: explicit mention

    The spec. "explicitly mentions"?

• File sgsn/BSSGP_ConnHdlr.ttcn:

  • Patch Set #4, Line 632: explicit

    Looks more like "implicit". The `tr_GMM_SERVICE_ACC` would be explicit (as the name suggests).

  • Patch Set #4, 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 change 38397. To unsubscribe, or for help writing mail filters, visit settings.