Attention is currently required from: laforge, lynxis lazus, pespin.

Patch set 5:Code-Review -1

View Change

2 comments:

• File sgsn/BSSGP_ConnHdlr.ttcn:

  • Patch Set #4, Line 358: as_gmm_auth

    I don't want to block here, but yet I find this problematic. We end up having two APIs with nearly the same name doing nearly the same thing, though having some difference in their behavior that is not documented anywhere. Oh, it's actually three APIs: `f_gmm_auth_as()`, `as_gmm_auth()`, and `f_gmm_auth()`... But my concern is more about `as_gmm_auth()` vs `f_gmm_auth()`.

    Imagine someone writing a new testcase and trying to use this API.
    Which one to use? The difference is not obvious unless you compare the two closely.

    What would it take to make `as_gmm_auth` more flexible and migrate the users of `f_gmm_auth()` to it? If this is hard and requires a lot of effort, please at least add a comment explaining the difference and probably a TODO for future migration?

    [...] also it fails if you don't have an auth [...]
    f_gmm_auth() requires to have an auth. it can also not used in alt steps.

    I don't understand what you mean here. Looking at the code, I see a big conditional block checking `g_pars.net.expect_auth` and skipping the entire function if it's `false` (actually sleep()ing for one second to catch GMM ID REQ).

  • Patch Set #4, Line 363: Ignoring autn for now

    Done

    Ah, I see now: `f_gmm_auth()` does not check the AUTN in the GMM PDU either.

To view, visit change 38396. To unsubscribe, or for help writing mail filters, visit settings.