-
-
Notifications
You must be signed in to change notification settings - Fork 699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[MME/Gn] SGSN Context Request contains mangled TMSI #3021
Comments
Test validating similar scenario can be found in MME_Tests.TC_ue_cell_reselect_geran_to_eutran in https://gitea.osmocom.org/ttcn3/osmo-ttcn3-hacks/src/branch/master/mme/MME_Tests.ttcn#L1545 Related test generated pcap: https://jenkins.osmocom.org/jenkins/job/ttcn3-mme-test-ogs/236/artifact/logs/mme-tester/MME_Tests.TC_ue_cell_reselect_geran_to_eutran.pcap.gz |
@asdfuser check function guti_to_rai_ptmsi() in open5gs.git |
I'm not totally sure, but I think the mapping in open5gs is the other way round. In mme_gn_build_sgsn_context_request() you call guti_to_rai_ptmsi() which according to 3GPP TS 23.003 Ch.2.8.2.1.1 is the mapping used "when a UE moves from an MME to an SGSN. The SGSN may be either an S4 SGSN or a Gn/Gp SGSN." However in the case where the MME requests an SGSN context the reverse is happening (2G->4G) so you'd need to apply the mapping from Ch. 2.8.2.2.3 (Mapping in the new MME) which is the reverse from Ch. 2.8.2.2.2. I started modifying the mapping functions, will test them tomorrow: /* 3GPP TS 23.003 2.8.2.1 Mapping GUTI from RAI, P-TMSI and P-TMSI signature (in the MME) */
void guti_from_rai_ptmsi(ogs_nas_eps_guti_t *nas_guti, const ogs_nas_rai_t *rai, mme_p_tmsi_t ptmsi, uint32_t ptmsi_sig)
{
nas_guti->nas_plmn_id = rai->lai.nas_plmn_id;
nas_guti->mme_gid = rai->lai.lac;
nas_guti->mme_code = rai->rac;
nas_guti->m_tmsi = 0xC0000000 | (ptmsi & 0x3f00ffff) | (ptmsi_sig & 0x00ff0000);
}
/* 3GPP TS 23.003 2.8.2.2 Mapping RAI and P-TMSI from GUTI (in the MME) */
void rai_ptmsi_from_guti(ogs_nas_rai_t *rai, mme_p_tmsi_t *ptmsi, const ogs_nas_eps_guti_t *nas_guti)
{
rai->lai.nas_plmn_id = nas_guti->nas_plmn_id;
rai->lai.lac = nas_guti->mme_gid;
rai->rac = (nas_guti->m_tmsi >> 16) & 0xff;
if (ptmsi)
*ptmsi = (nas_guti->mme_code << 16) | (nas_guti->m_tmsi & 0x3f00ffff);
} |
This issue has been marked as stale because there has been no recent activity on it. If there is no further activity, it will be closed. The Open5GS team is a small but dedicated team with limited resources and may not be able to address every issue directly. Do not attempt to circumvent this by 'bumping' the issue; doing so will result in it's immediate closure and possibly your exclusion from participating in any future discussions. |
This issue has been closed automatically due to lack of activity. This has been done to try and reduce the amount of noise. Please do not comment any further. The Open5GS Team may choose to re-open this issue if necessary. |
See gn-tmsi.pcapng.zip for a trace of the messages.
no.1 has the Attach Accept with TMSI 0xe99fc497
no.4 contains the TAU with the old GUTI
no.2 has the SGSN Context Request with P-TMSI: 0x97c49fe9
In this case it seems like wrong endianess, but I'm not sure that is the whole story since the MME needs to use the GUTI in packet no.4 and @pespin mentioned that deriving the TMSI from it is quite complex.
The text was updated successfully, but these errors were encountered: