This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.comHi 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