Attention is currently required from: pespin.

View Change

1 comment:

• File src/osmo-hnbgw/hnbgw_l3.c:

  • Patch Set #3, Line 281: osmo_plmn_from_bcd(ies->lai.pLMNidentity.buf, &local_plmn);

    I didn't write the details because I expected you to know them better 😄 […]

    The two RESET related patches after this patch have been tweaked in the meantime: osmo-hnbgw will output ERROR logs during every RANAP RESET attempt asking the user to add a PLMN to its config file. I think that's loud enough and we don't need to warn on this marginal case.

    FYI, why this is pretty marginal:

    We're not adopting some PLMN for good, this is just relevant to classify a particular incoming message.

    The only effect this has is changing which CN link will pick up the new subscriber.
    When the UE indicates a TMSI that it got from a different PLMN, and if we used the TMSI, we would select a specific CN based on that.
    Instead we should not use the TMSI, and just select any CN by round-robin.
    There is not actually any proper difference, only that there is no way to skip the round robin. The foreign TMSI might even have indicated the same CN that round robin happens to select.

    Any CN that is selected will then first ask the UE for its IMSI anyway; AFAIK it shouldn't even carry a TMSI to another PLMN in the first place?

    This InitialUE message normally contains both the local PLMN a couple times over, as well as the previous PLMN the USIM camped on. So far things worked well by just comparing the PLMNs within one message, to classify the message itself as "has previously been in another PLMN".

    In the meantime, some other reason has shown up to require an actual local PLMN to be configured in the cfg file.

    We could happily continue to classify each individual message by the PLMNs contained in it, we trusted it enough until now. But instead, we now have first-hand info on the PLMN from the user via the cfg file, so rather use that.

    (and ideally also reject messages that indicate a mismatching local PLMN, to help the user find misconfigured HNBs; not implemented yet).

    So it's a pretty marginal aspect and not critical for successful operation.
    The code is here mainly because this is what osmo-bsc does

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