Hello Sylvain,
On Sun, 1 Nov 2009 21:17:26 +0100, "Sylvain Munaut" 246tnt@gmail.com wrote:
In gprs_bssgp.c the function bssgp_rx_ul_ud calls :
bts = gsm48_bts_by_ra_id( TLVP_VAL(&tp, BSSGP_IE_CELL_ID), TLVP_LEN(&tp, BSSGP_IE_CELL_ID));
But gsm48_bts_by_ra_id defined in gsm_04_08_gprs.c takes 3 arguments the gsm_network as first one then the buffer and lenght. Since the function was implicitely defined in gprs_bssgp.c, it compiled but of course segfaulted as soon as it got there ... I don't even understand how it worked for you.
At the time I made the trace, I did not yet have connected with a GPRS phone. In the meantime I made a temporary workaround by referencing the global "bsc_gsmnet" and using it for the first parameter.
<0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT
But as soon as the REJECT is sent to the BTS, it reboots ... no error no message nothing ...
I get a "GMM Attach Request" with my phone and the same behaviour afterwards, the nanoBTS reboots.
Best regards, Dieter
Hi Dieter,
- In gprs_bssgp.c the function bssgp_rx_ul_ud calls :
bts = gsm48_bts_by_ra_id( TLVP_VAL(&tp, BSSGP_IE_CELL_ID), TLVP_LEN(&tp, BSSGP_IE_CELL_ID));
But gsm48_bts_by_ra_id defined in gsm_04_08_gprs.c takes 3 arguments the gsm_network as first one then the buffer and lenght. Since the function was implicitely defined in gprs_bssgp.c, it compiled but of course segfaulted as soon as it got there ... I don't even understand how it worked for you.
At the time I made the trace, I did not yet have connected with a GPRS phone. In the meantime I made a temporary workaround by referencing the global "bsc_gsmnet" and using it for the first parameter.
Yes, I did the same because I couldn't find any way to get a proper gsm_network at that point in the code ...
<0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT
But as soon as the REJECT is sent to the BTS, it reboots ... no error no message nothing ...
I get a "GMM Attach Request" with my phone and the same behaviour afterwards, the nanoBTS reboots.
I found out the problem.
In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is incorect. It uses msg->len but at that point it already did a msgb_push to add space for the header so msg->len is already too big. You need to save the size of msg->len before the msgb_push and then use that when encoding the PDU TLV length.
Now, the MS tries to do :
<0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT
repeatedly ... (3 or 4 times before giving up)
BTW, do you sometimes hangout in #openbsc ?
Sylvain
On Mon, Nov 02, 2009 at 01:05:20AM +0100, Sylvain Munaut wrote:
<0004> gsm_04_08_gprs.c:434 GMM RA UPDATE REQUEST type="RA updating" REJECT <0004> gsm_04_08_gprs.c:408 <- ROUTING AREA UPDATE REJECT
This is actually very funny. According to the protocol, a RA update should only be performed if the MS was/is already GPRS ATTACHED to this network before. It clearly wasn't in this case, as the OpenBSC network never offered GPRS support. Still, it tries it. That's why we're rejecting it.
But as soon as the REJECT is sent to the BTS, it reboots ... no error no message nothing ...
I get a "GMM Attach Request" with my phone and the same behaviour afterwards, the nanoBTS reboots.
The ATTACH REQUEST is what the phone should be doing from the very beginning.
The RA update ounds like yet another bug in some GPRS protocol stack[s]...
I found out the problem.
In gprs_bssgp_tx_dl_ud, then length encoded in the PDU TLV is incorect. It uses msg->len but at that point it already did a msgb_push to add space for the header so msg->len is already too big. You need to save the size of msg->len before the msgb_push and then use that when encoding the PDU TLV length.
Thanks, nice spot. I think I've made that mistake before, as it sounds so familiar. I've fixed it now in the gprs brnch.
Cheers,