OsmocomBB

• 3GPP TS 24.008:
  • section 4 "Elementary procedures for Mobility Management"
  • section 9.4 "GPRS Mobility Management Messages"
• 3GPP TS 24.007:
  • section 6.6 "Registration Services for GPRS-Services"
  • section 9.4 "Services provided by the LLC entity for GPRS services (GSM only)"
  • section 9.5 "Services provided by the GMM for GPRS services"
• gprs_gmm.{c,h}, gprs_gmm_attach.{c,h}, gprs_gmm_fsm.{c,h}

• 3GPP TS 24.008:
  • section 6 "Support for packet services"
  • section 9.5 "GPRS Session Management Messages"
• 3GPP TS 24.007:
  • section 6.5.1 "Session Management Services for SMREG-SAP"
  • section 9.5 "Services provided by the GMM for GPRS services"
• osmo-sgsn.git gprs_sm.{c,h}

After fixing a bug in libosmo-gprs-rlcmac, I am still not able to complete the attach procedure.

Here is some logging (make sure to apply this patch):

https://gerrit.osmocom.org/c/osmocom-bb/+/32060 layer23: add missing log_info_cat[] entry for DGMM [NEW]

DGMM INFO gmm_prim.c:426 Rx from upper layers: GMMREG-ATTACH.request
DGMM INFO fsm.c:456 GMM_MS[0x561735480e30]{Null}: Allocated
DGMM INFO gmm_ms_fsm.c:293 GMM_MS[0x561735480e30]{Null}: Received Event ENABLE_GPRS_MODE
DGMM INFO gmm_ms_fsm.c:40 GMM_MS[0x561735480e30]{Null}: state_chg to Deregistered
DGMM INFO gmm.c:283 GMME(PTMSI-e1c5d364) Tx GMM ATTACH REQUEST (new P-TMSI=0xe1c5d364)
DLLC INFO llc_prim.c:157 Rx from upper layers: LL-UNITDATA.request
DLLC NOTICE llc_ll.c:228 Rx LL-UNITDATA.request: unknown TLLI 0xe1c5d364, creating LLME on the fly
DLLC DEBUG llc.c:144 modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 01 08 01 04 97 07 00 00 01 0a 00 05 f4 e1 c5 d3 64 00 f0 00 00 00 00 00 fd d1 f4 ]
DRR NOTICE grr.c:94 Sending CHANNEL REQUEST (0x7e)
DGMM INFO gmm_prim.c:351 GMM_MS[0x561735480e30]{Deregistered}: Received Event ATTACH_REQUESTED
DGMM INFO gmm_ms_fsm.c:57 GMM_MS[0x561735480e30]{Deregistered}: state_chg to RegisteredInitiated
DRSL NOTICE grr.c:411 Rx RACH.conf (RA=0x7e, T1=23, T3=37, T2=16)
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=1 (GMM), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=9a8ede
DLLC DEBUG llc.c:610 LLE(ffffffff/e1c5d364,GMM){UNASSIGNED} Rx SAPI=1 (GMM), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=9a8ede
DLLC DEBUG llc.c:100 modem_llc_prim_up_cb(): Rx LL-UNITDATA.indication TLLI=0xe1c5d364 SAPI=GMM l3=[08 15 02 ]
DGMM INFO gmm_prim.c:595 Rx from lower layers: LL-UNITDATA.indication
DGMM DEBUG gmm.c:431 GMME(PTMSI-e1c5d364) Rx GMM IDENTITY REQUEST mi_type=IMEI
DGMM INFO gmm.c:215 GMME(PTMSI-e1c5d364) Tx GMM IDENTITY RESPONSE
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS

fixeria wrote in #note-11:

After fixing a bug in libosmo-gprs-rlcmac, I am still not able to complete the attach procedure.

After a bit more testing, I see that the GMM layer does enqueue GMM Identity Response, but the LLC layer does not seem to get it?

Compare these two logging snippets:

DGMM INFO gmm.c:283 GMME(PTMSI-e1c5d364) Tx GMM ATTACH REQUEST (new P-TMSI=0xe1c5d364)
DLLC INFO llc_prim.c:157 Rx from upper layers: LL-UNITDATA.request
DLLC NOTICE llc_ll.c:228 Rx LL-UNITDATA.request: unknown TLLI 0xe1c5d364, creating LLME on the fly
...
DGMM INFO gmm_prim.c:595 Rx from lower layers: LL-UNITDATA.indication
DGMM DEBUG gmm.c:431 GMME(PTMSI-e1c5d364) Rx GMM IDENTITY REQUEST mi_type=IMEI
DGMM INFO gmm.c:215 GMME(PTMSI-e1c5d364) Tx GMM IDENTITY RESPONSE
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695980 Rx Pkt DL Dummy Ctrl Block
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695984 Rx Pkt DL Dummy Ctrl Block
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695988 Rx Pkt DL Dummy Ctrl Block
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695993 Rx Pkt DL Dummy Ctrl Block
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1695997 Rx Pkt DL Dummy Ctrl Block
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1696001 Rx Pkt DL Dummy Ctrl Block
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1696006 Rx Pkt DL Dummy Ctrl Block
DRLCMAC INFO rlcmac.c:502 TS=7 FN=1696010 Rx Pkt DL Dummy Ctrl Block

Note that there is no Rx from upper layers: LL-UNITDATA.request in the second case.

fixeria wrote in #note-12:

Note that there is no Rx from upper layers: LL-UNITDATA.request in the second case.

gdb tells me that gprs_gmm_tx_id_resp() returns early because gprs_gmm_build_identity_resp() returns -22 (-EINVAL).
This is happening because osmo_mobile_identity_encode_msgb() fails, most likely because gmme->imei is not populated.

I believe we should have slightly more verbose logging in the enc/dec functions like this one, otherwise debugging stuff takes longer.

fixeria wrote in #note-13:

This is happening because osmo_mobile_identity_encode_msgb() fails, most likely because gmme->imei is not populated.

I hard-coded both IMSI and IMEI in gprs_gmm_build_identity_resp(), and saw osmo-sgsn sending GMM ATTACH ACCEPT:

DLLC NOTICE gprs_llc.c:552 LLME(ffffffff/e1c5d364){UNASSIGNED} LLC RX: unknown TLLI 0xe1c5d364, creating LLME on the fly
DMM INFO gprs_gmm.c:1198 MM(---/ffffffff) -> GMM ATTACH REQUEST 
DLLC NOTICE gprs_llc.c:1079 LLME(ffffffff/e1c5d364){UNASSIGNED} LLGM Assign pre (e1c5d364 => c91ffe37)
DLLC NOTICE gprs_llc.c:1125 LLME(e1c5d364/c91ffe37){ASSIGNED} LLGM Assign post (e1c5d364 => c91ffe37)
DLGSUP INFO gsup_client.c:266 GSUP ping callback (connected, got PONG)
DMM ERROR gprs_gmm.c:114 MM(/c91ffe37) Stopping MM timer 3370 but 0 is running
DMM ERROR gprs_gmm.c:114 MM(/c91ffe37) Stopping MM timer 3370 but 0 is running
DMM INFO sgsn_auth.c:195 MM(901700000034128/c91ffe37) Missing information, requesting subscriber data
DGPRS INFO gprs_subscriber.c:817 SUBSCR(901700000034128) subscriber data is not available
DGPRS INFO gprs_subscriber.c:210 SUBSCR(901700000034128) Sending GSUP, will send: 04 01 08 09 71 00 00 00 43 21 f8 28 01 01 2a 01 01
DGPRS INFO gprs_subscriber.c:722 SUBSCR(901700000034128) Received GSUP message OSMO_GSUP_MSGT_INSERT_DATA_REQUEST
DGPRS INFO gprs_subscriber.c:367 SUBSCR(901700000034128) Will set PDP info, context id = 1, APN = 01 2a
DMM INFO mmctx.c:430 MM(901700000034128/c91ffe37) Subscriber data update
DMM INFO sgsn_auth.c:246 MM(901700000034128/c91ffe37) Got authorization update: state unknown -> accepted
DMM NOTICE gprs_gmm.c:994 MM(901700000034128/c91ffe37) Authorized, continuing procedure, IMSI=901700000034128
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)
DGPRS INFO gprs_subscriber.c:210 SUBSCR(901700000034128) Sending GSUP, will send: 12 01 08 09 71 00 00 00 43 21 f8 28 01 01
DGPRS INFO gprs_subscriber.c:722 SUBSCR(901700000034128) Received GSUP message OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT
DMM INFO mmctx.c:430 MM(901700000034128/c91ffe37) Subscriber data update
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)
DLNSSIGNAL INFO gprs_ns2_message.c:207 NSE(00101)-NSVC(00101) Tx NS-ALIVE
DLNSSIGNAL INFO gprs_ns2.c:1309 NSE(00101)-NSVC(00101) Rx NS-ALIVE
DLNSSIGNAL INFO gprs_ns2_message.c:207 NSE(00101)-NSVC(00101) Tx NS-ALIVE-ACK
DLNSSIGNAL INFO gprs_ns2.c:1309 NSE(00101)-NSVC(00101) Rx NS-ALIVE-ACK
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)
DLGSUP INFO gsup_client.c:266 GSUP ping callback (connected, got PONG)
DMM INFO gprs_gmm.c:294 MM(901700000034128/c91ffe37) <- GMM ATTACH ACCEPT (new P-TMSI=0xc91ffe37)

However, the modem app crashed:

DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=3 (SNDCP3), UI func=UI C/R=1 PM=1 E=0 IP=0 N(U)=0 FCS=2b2b2b
DLLC INFO llc.c:740 LLE(ffffffff/e1c5d364,SNDCP3){UNASSIGNED} Dropping frame with invalid FCS
DLLC INFO llc_prim.c:199 Rx from lower layers: GRR-UNITDATA.indication
DLLC DEBUG llc_grr.c:97 Rx GRR-UNITDATA.indication: SAPI=1 (GMM), UI func=UI C/R=0 PM=1 E=0 IP=0 N(U)=3 FCS=9ebca5
DLLC DEBUG llc.c:610 LLE(ffffffff/e1c5d364,GMM){UNASSIGNED} Rx SAPI=1 (GMM), UI func=UI C/R=0 PM=1 E=0 IP=0 N(U)=3 FCS=9ebca5
DLLC DEBUG llc.c:100 modem_llc_prim_up_cb(): Rx LL-UNITDATA.indication TLLI=0xe1c5d364 SAPI=GMM l3=[08 02 01 2a 44 09 f1 07 00 01 00 17 16 18 05 f4 c9 1f fe 37 ]
DGMM INFO gmm_prim.c:595 Rx from lower layers: LL-UNITDATA.indication
DGMM DEBUG gmm.c:354 GMME(PTMSI-e1c5d364) Rx GMM ATTACH ACCEPT
DGMM ERROR gmm.c:58 modem_gmm_prim_up_cb(): Rx GMMREG-ATTACH.confirm UNIMPLEMENTED
DLLC INFO llc_prim.c:157 Rx from upper layers: LLGM-ASSIGN.request
DLLC NOTICE llc_llgmm.c:141 LLME(ffffffff/e1c5d364){UNASSIGNED} LLGM Assign pre (e1c5d364 => c91ffe37)
DLLC NOTICE llc_llgmm.c:185 LLME(e1c5d364/c91ffe37){ASSIGNED} LLGM Assign post (e1c5d364 => c91ffe37)
DGMM ERROR gmm.c:78 modem_gmm_prim_down_cb(): Unexpected Rx GMRR-ASSIGN.request
Assert failed 0 gmm.c:79

fixeria wrote in #note-14:

fixeria wrote in #note-13:

This is happening because osmo_mobile_identity_encode_msgb() fails, most likely because gmme->imei is not populated.

I hard-coded both IMSI and IMEI in gprs_gmm_build_identity_resp(), and saw osmo-sgsn sending GMM ATTACH ACCEPT:

Yes, that's probably because we are not filing the "imei", "imsi", etc. fields in the GMM-ASSIGN.req primitive in the modem app. I guess we can hardcode those in the modem app for now, and later fill them using some stuff already available in the "mobile" app by moving it to common/

DGMM ERROR gmm.c:78 modem_gmm_prim_down_cb(): Unexpected Rx GMRR-ASSIGN.request

We are missing forwarding GMMRR primitives to rlcmac stack in the modem app.

pespin wrote in #note-15:

fixeria wrote in #note-14:

fixeria wrote in #note-13:

This is happening because osmo_mobile_identity_encode_msgb() fails, most likely because gmme->imei is not populated.

I hard-coded both IMSI and IMEI in gprs_gmm_build_identity_resp(), and saw osmo-sgsn sending GMM ATTACH ACCEPT:

Yes, that's probably because we are not filing the "imei", "imsi", etc. fields in the GMM-ASSIGN.req primitive in the modem app. I guess we can hardcode those in the modem app for now, and later fill them using some stuff already available in the "mobile" app by moving it to common/

https://gerrit.osmocom.org/c/osmocom-bb/+/32081 layer23: modem: fill imsi & imei in vty 'test gmm attach'

DGMM ERROR gmm.c:78 modem_gmm_prim_down_cb(): Unexpected Rx GMRR-ASSIGN.request

We are missing forwarding GMMRR primitives to rlcmac stack in the modem app.

Feel free to give it a try with this one applied:
https://gerrit.osmocom.org/c/osmocom-bb/+/32080 layer23: modem: Forward GMMRR primitives between GMM and RLCMAC layers

Still, I think RLC/MAC may be asswerting when reciving that primitive because it's not yet implemented iirc.

I submitted an initial implementation of SM layer in libosmo-gprs-sm and use it through a VTY command in "modem" app:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32154 Introduce libosmo-gprs-sm
https://gerrit.osmocom.org/c/osmocom-bb/+/32155 modem: initial SM layer support through libosmo-gprs-sm

I started implementing some missing bits in the SNSM interface (SM<->SNDCP) which I was skipping so far during PDP Ctx Activiation:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32295 sm: Start using SNSM SAP
https://gerrit.osmocom.org/c/osmocom-bb/+/32296 layer23: modem: Forward SNSM primitives SNDCP<->SM layers

I still need to check whether the SNSM-ACTIVATE.ind/resp are properly implemented in SNDCP (probably they are not).

libosmo-gprs-gmm periodic RAU support implemented here:
https://gerrit.osmocom.org/c/libosmo-gprs/+/32925

I still need to store received/updated RAI/PTMSI/PTMSI_SIG from RAU into the SIMcard LOCIGPRS file. I probably need to add an extra primitive indication in GMMREG to indicate the updates to the MS.

I still need to store received/updated RAI/PTMSI/PTMSI_SIG from RAU into the SIMcard LOCIGPRS file. I probably need to add an extra primitive indication in GMMREG to indicate the updates to the MS.

If RAU fails (rx RAU Reject) we also need to indicate somehow to the app/SIM, so that it can erase LOCIGPRS and change GU state, eg "GU3 ROAMING NOT ALLOWED".

We basically need some primitive informing the app about states:
- attach updated (RAI, PTMSI, etc. are updated during RAU ACC)
- attach failed (RAU REJ)
- detach initiated by network (GMMREG-DETACH.ind, this already exists specified, so no problem here).

One solution would to be submit GMMREG-ATTACH.cnf_acc each time there's a RAU ACC, and submit a GMMREG-ATTACH.cnf_rej each time there's a RAU REJ, even if there was no GMMREG-ATTACH.req or it was already answered during ATTACH ACC.
Another solution would be to add a new GMM-ATTACH.ind with also acc/rej similar to GMMREG-ATTACH.cnf.

TS 24.007 6.6.1.6 GMMREG-DETACH-IND says: "A network initiated detach has been performed. Or the detach has been performed locally due to expiration of the
standby timer or a failed routing area update". The registration services provided at the service access point GMMREG-SAP are illustrated in the state machine of
figure 6.6 below. Note, that in state registered the MS may be suspended from GPRS mobility management due to an
ongoing CS connection. The registration procedure Routing Area Updating, which is not provided at the GMMREG-
SAP, is not visible within the diagram."

So the above seems to indicate that:
- attach updated (RAI, PTMSI, etc. are updated during RAU ACC) => Add a new GMMREG-ATTACH.ind(cause?, RAI, PTMSI, PTMSI_SIG) (maybe name it GMMREG-RAU.ind?)
- attach failed (RAU REJ) > GMMREG-DETACH.ind(cause)
- detach initiated by network > GMMREG-DETACH.ind(cause)