Project

General

Profile

Actions

Bug #5491

open

MT CSFB calls fail (only) first time after Airplane mode toggle (probably on first attach to EUTRAN too)

Added by keith 11 months ago. Updated 11 months ago.

Status:
New
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
03/19/2022
Due date:
% Done:

0%

Resolution:
Spec Reference:

Description

To reproduce:

With working EUTRAN and GERAN networks, toggle airplane mode. Phone (re)-ATTACHes to LTE network.

Call the phone:

In osmo-msc: (i've attached the entire debug log)

20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=TMSI-0x2F655780 LU-type=NORMAL (gsm_04_
20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 334-07-101 (gsm_04_08.c:407)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Paging Response action (expired) (paging.c:154)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) Paging expired (gsm_04_08_cc.c:339)
20220319023547480 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) tx MNCC_REL_IND (gsm_04_08_cc.c:237)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x0 tid-255) Freeing transaction (transaction.c:230)

After this 1st try, the subsequent try succeeds:

20220319024811027 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) New transaction (transaction.c:218)
20220319024811027 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) rx MNCC_SETUP_REQ (gsm_04_08_cc.c:1979)
20220319024811027 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Starting paging (paging.c:101)
20220319024814102 DMM DEBUG Tx AUTH REQ (rand = 07e7f2e89f5782be2bac726d7d90914a) (gsm_04_08.c:642)
20220319024814102 DMM DEBUG    AUTH REQ (autn = e6ab0ad9e6a7000050ffb868d2a25996) (gsm_04_08.c:644)
20220319024815042 DMM DEBUG msc_a(IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684:GERAN-A-52:PAGING_RESP)[0x55b8e913d250]{MSC_A_ST_AUTH_CIPH}: MM UMTS AUTHENTICATION RESPONSE (res = 6ce1b1df36c7c61f) (gsm_04_08.c:1119)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Paging Response action (success) (paging.c:154)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319024815749 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) Paging succeeded (gsm_04_08_cc.c:316)

There's a difference in show subscriber cache after an ATTACH via SGS as opposed to a complete LUR on GERAN (we have auth data):

show subscriber cache 
  Subscriber #00: 
    MSISDN: 12345174747
    LAC / cell ID: 101 / 100
    RAN type: EUTRAN-SGs
    IMSI: 334070000000968
    TMSI: 1E460BB7
    IMEI: 35729207588080
    IMEISV: 3572920758808001
    Flags: 
      IMSI detached:                  false
      Conf. by radio contact:         true
      Subscr. data conf. by HLR:      true
      Location conf. in HLR:          true
      Subscriber dormant:             false
      Received cancel location:       false
      MS not reachable:               false
      LA allowed:                     true
    A3A8 last tuple (used 1 times): 
      seq # : 4
      RAND  : 17 8a 18 c2 62 8e 85 a5 fe a1 1b 03 c2 51 37 9a 
      SRES  : a0 10 84 9a 
      Kc    : 01 1d 45 1b 6c 47 74 00 
    Expires: never
    Paging: not paging for 0 requests
    SGs-state: SGs-ASSOCIATED
    SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
    Use count total: 1
    Use count: 1 (attached)
show subscriber cache 
  Subscriber #00: 
    MSISDN: 12345174747
    LAC / cell ID: 101 / 0
    RAN type: EUTRAN-SGs
    IMSI: 334070000000968
    TMSI: 2F655780
    Flags: 
      IMSI detached:                  false
      Conf. by radio contact:         true
      Subscr. data conf. by HLR:      true
      Location conf. in HLR:          true
      Subscriber dormant:             false
      Received cancel location:       false
      MS not reachable:               false
      LA allowed:                     true
    Expires: never
    Paging: not paging for 0 requests
    SGs-state: SGs-ASSOCIATED
    SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
    Use count total: 1
    Use count: 1 (attached)

Assigning to myself; I do intend to fix it.

Would appreciate confirmation all the same from anybody else who has a working setup, or even some static analysis by those more familiar with this code.


Files

osmo-msc-csfb.log osmo-msc-csfb.log 117 KB keith, 03/19/2022 02:37 AM
Actions #1

Updated by keith 11 months ago

  • Subject changed from MT CSFB calls fail (only) first time after Airplane mode toggle (probably on first attach to EUTRA N too) to MT CSFB calls fail (only) first time after Airplane mode toggle (probably on first attach to EUTRAN too)
Actions #2

Updated by keith 11 months ago

If I disable encryption/auth on the 2G Network, then this issue does not manifest.

So it's something to do with auth negotiation during the LUR that causes Paging Timeout and then sending a release indication to the MNCC?

Actions #3

Updated by keith 11 months ago

My guess if that at some point something is calling cc_paging_cb() before we have an msc_a, but this is only happening while auth/ciphering is going on.

https://git.osmocom.org/osmo-msc/tree/src/libmsc/gsm_04_08_cc.c#n306

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)