Hi, On Sat, Aug 06, 2011 at 12:58:00AM +0900, Seungju Kim wrote: > Alright, I see. > I just made an ugly hack and applied to my working copy. > So far it seems fine. Now my phone does not lose it's PDP context while > making a phone call. > I'll be working on for some not ugly fix, but all these bits are confusing me > haha.
can you try the attached patch? It should parse it correctly, without the double-byte-swapping of the last patch. -- - Harald Welte <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
>From a69ab7f2ccba679a0e3eb7b55cf514a2dc286bd5 Mon Sep 17 00:00:00 2001 From: Harald Welte <[email protected]> Date: Fri, 5 Aug 2011 21:19:12 +0200 Subject: [PATCH] GPRS: Fix the parsing/interpretation of the PDP CTX status IE The byte ordering is a bit odd: The least significant byte is ahead of the most significant byte, different from everything else in GSM that seems to be big-endian. Thanks to Seungju Kim <[email protected]> for repoerting the bug. --- openbsc/src/gprs/gprs_gmm.c | 24 ++++++++++++++++-------- 1 files changed, 19 insertions(+), 11 deletions(-) diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 098e4c2..c9fe517 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -867,7 +867,7 @@ static int gsm48_tx_gmm_ra_upd_rej(struct msgb *old_msg, uint8_t cause) } static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, - uint16_t pdp_status) + uint8_t *pdp_status) { struct sgsn_pdp_ctx *pdp, *pdp2; /* 24.008 4.7.5.1.3: If the PDP context status information element is @@ -878,11 +878,20 @@ static void process_ms_ctx_status(struct sgsn_mm_ctx *mmctx, * being in state PDP-INACTIVE. */ llist_for_each_entry_safe(pdp, pdp2, &mmctx->pdp_list, list) { - if (!(pdp_status & (1 << pdp->nsapi))) { - LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " - "due to PDP CTX STATUS IE= 0x%04x\n", - pdp->nsapi, pdp_status); - sgsn_delete_pdp_ctx(pdp); + if (pdp->nsapi < 8) { + if (!(pdp_status[0] & (1 << pdp->nsapi))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } + } else { + if (!(pdp_status[1] & (1 << (pdp->nsapi - 8)))) { + LOGP(DMM, LOGL_NOTICE, "Dropping PDP context for NSAPI=%u " + "due to PDP CTX STATUS IE= 0x%02x%02x\n", + pdp->nsapi, pdp_status[1], pdp_status[0]); + sgsn_delete_pdp_ctx(pdp); + } } } } @@ -975,8 +984,7 @@ static int gsm48_rx_gmm_ra_upd_req(struct sgsn_mm_ctx *mmctx, struct msgb *msg, /* Look at PDP Context Status IE and see if MS's view of * activated/deactivated NSAPIs agrees with our view */ if (TLVP_PRESENT(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)) { - uint16_t pdp_status = ntohs(*(uint16_t *) - TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS)); + uint8_t *pdp_status = TLVP_VAL(&tp, GSM48_IE_GMM_PDP_CTX_STATUS); process_ms_ctx_status(mmctx, pdp_status); } -- 1.7.5.4
