GPRS branch status updates

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.org
Mon Nov 2 13:47:18 UTC 2009


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,
-- 
- 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)




More information about the OpenBSC mailing list