commit | 2fd69e15d36d5a8e87029741ad66632c57d24cd4 | [log] [tgz] |
---|---|---|
author | Neels Hofmeyr <nhofmeyr@sysmocom.de> | Tue Mar 26 00:50:04 2024 +0100 |
committer | Neels Hofmeyr <nhofmeyr@sysmocom.de> | Thu Mar 28 04:06:58 2024 +0100 |
tree | 8cab8b7a6ac0e08746af4847278eb56388400dec | |
parent | 72ef7d8bb07bc4e938a242bfdd9d0e45f77fc917 [diff] |
fix VLR evil twin on LU with unknown TMSI When a subscriber first attaches by TMSI only, and later tells the IMSI via ID Response, it may turn out that this IMSI already exists in the VLR database. If this happens, the TMSI that the subscriber issued was not known in the existing VLR entry, indicating that the subscriber has in the meantime camped on a different core. Which means we can assume that there cannot be any active connections, and the old subscriber can be discarded, for the benefit of the new one. (We could also discard the new one, but it is more complex to reparent the ongoing FSMs for Compl L3 than to copy some dormant VLR state.) In vlr_subscr_set_imsi(), check for an existing IMSI entry in the VLR. If such exists, copy any pending Paging and auth tuple state to the new subscriber, and discard the old one from the VLR. In order to safely discard a vlr subscriber by force, add a new vlr_ops function: subscr_inval(), to tell the MSC that a vlr_subscr is no longer valid. Upcoming patch I583682d1a35a70b008d7bb2d89ba7c3109a60b21 better clears TMSI state from the VLR, making it more likely to hit the evil twin situation this patch fixes; hence this is, sort of, preparation. Related: SYS#6860 OS#4721 Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd
This repository contains a C-language implementation of a GSM Mobile Switching Centre (MSC) for 2G (GSM) and 3G (UMTS). It is part of the Osmocom Open Source Mobile Communications project.
OsmoMSC exposes
OsmoMSC implements
You can find the OsmoMSC home page and wiki online at https://osmocom.org/projects/osmomsc/wiki.
You can clone from the official osmo-msc.git repository using
git clone https://gitea.osmocom.org/cellular-infrastructure/osmo-msc
There is a web interface at https://gitea.osmocom.org/cellular-infrastructure/osmo-msc
User Manuals and VTY reference manuals are [optionally] built in PDF form as part of the build process.
Pre-rendered PDF version of the current "master" can be found at User Manual as well as the VTY Reference Manual
We welcome any osmo-msc related discussions in the Cellular Network Infrastructure -> 2G/3G CN section of the osmocom discourse (web based Forum).
Discussions related to osmo-msc are happening on the openbsc@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/openbsc for subscription options and the list archive.
Please observe the Osmocom Mailing List Rules when posting.
We use the issue tracker of the osmo-msc project on osmocom.org for tracking the state of bug reports and feature requests. Feel free to submit any issues you may find, or help us out by resolving existing issues.
Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards
We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details
The current patch queue for osmo-msc can be seen at https://gerrit.osmocom.org/#/q/project:osmo-msc+status:open
OsmoMSC originated from the OsmoNITB project, which started as a minimalistic all-in-one implementation of the GSM Network. In 2017, OsmoNITB had reached maturity and diversity (including M3UA SIGTRAN and 3G support in the form of IuCS and IuPS interfaces) that naturally lead to a separation of the all-in-one approach to fully independent separate programs as in typical GSM networks.
OsmoMSC was one of the parts split off from the old openbsc.git.