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/.
Harald Welte laforge at gnumonks.orgOn 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, -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)