1 Nov
2009
1 Nov
'09
10:29 p.m.
Hello Sylvain,
On Sun, 1 Nov 2009 21:17:26 +0100, "Sylvain Munaut" <246tnt(a)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
--
Dieter Spaar, Germany spaar(a)mirider.augusta.de
2 Nov
2 Nov
1:05 a.m.
New subject: GPRS branch status updates
Hi Dieter,
Yes, I did the same because I couldn't find any way to get a proper
gsm_network at that point in the code ...
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
- 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. 
2:47 p.m.
New subject: GPRS branch status updates
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5711
days inactive
5712
days old
2 comments
3 participants
participants (3)
-
Dieter Spaar -
Harald Welte -
Sylvain Munaut