Bug #5297
closedosmo-pcu: Fix mess in bts_pch_timer where wrong imsi buffer is passed
100%
Description
20211108144833787 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144839344 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144840787 DPCU bts_pch_timer.c:55 PCH paging timeout for IMSI=í²í³í³½ 20211108144842498 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144842514 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144845050 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144845666 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144846100 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144846131 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144847514 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144847515 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144849498 DPCU bts_pch_timer.c:55 PCH paging timeout for IMSI=í²í³í³½ 20211108144849876 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144851452 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144854209 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144854857 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144855925 DRLCMAC gprs_rlcmac.cpp:42 TX: [PCU -> BTS] Paging Request (CCCH) MI=TMSI-0xFD16D292 20211108144856876 DPCU bts_pch_timer.c:55 PCH paging timeout for IMSI=í²í³í³½
So it seems we get a TMSI in "mi", but we end up passing mi->imsi unconditionally to bts_pch_timer_start:
gprs_bssgp_pcu_rx_paging_ps
gprs_rlcmac_paging_request
bts_pch_timer_start(bts, mi->imsi);
I'm still not sure what's the proper fix, but there's 2 options initially:
- Modify bts_pch_timer to contain and match per TMSI as well as IMSI
- In gprs_bssgp_pcu_rx_paging_ps(), the IMSI is mandatory, so we could always pass the mi_imsi to gprs_rlcmac_paging_request() and then to bts_pch_timer_start()
Updated by pespin over 2 years ago
The issue can be observed in gsmtap_log of TC_paging_ps_from_sgsn_sign_ptmsi.
Updated by pespin over 2 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 80
I submitted following patches to address the issue:
https://gerrit.osmocom.org/c/osmo-pcu/+/26166 bts_pch_timer: Fix timer working only for MI type IMSI [NEW]
https://gerrit.osmocom.org/c/osmo-pcu/+/26167 tests/alloc: Extend test_bts_pch_timer() to validate MI type TMSI [NEW]
However, current code around bts_pch_timer.c/h seems to be in practice doing nothing more than logging stuff and incrementing CTR_PCH_REQUESTS_TIMEDOUT if a timeout is found (T3113), but no real action is done if there's a timeout.
Not sure if we are missing any sort of logic there, I have a difficult time finding detailed information in TS 44.060 and TS 44.018. For instance,
T3113: This timer is started when the network has sent a PAGING REQUEST message and is stopped when the network has received the PAGING RESPONSE message.
but it doesn't state what's the real use for this timer....
Updated by pespin over 2 years ago
I also submitted following patch to avoid scheduling more Paging Request than necessary over the air interface:
https://gerrit.osmocom.org/c/osmo-pcu/+/26168 bts_pch_timer: Avoid resend Paging Request over PCUIF if T3113 is armed
Updated by pespin over 2 years ago
- Status changed from Feedback to Resolved
- % Done changed from 80 to 100
All merged, closing.
