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