Hello Sylvain,
On Sun, 1 Nov 2009 11:05:31 +0100, "Sylvain Munaut" 246tnt@gmail.com wrote:
I searched for what could be wrong but I didn't see anything obvious. Could you provide a trace of a working startup so I can compare ?
Maybe my trace is usefull too, I modified the two IP addresses and set "timeslot 7" to "phys_chan_config TCH/F_PDCH". I only noticed that it did not work immediately after the nanoBTS has been powered on, I had to start bsc_hack a second time (not sure if this can be reproduced). The trace is in the attached ZIP file, its from a Cygwin system.
Best regards, Dieter
Dieter Spaar, Germany spaar@mirider.augusta.de
Hi Dieter,
Thanks for the trace, I'll have a look now.
In the mean time I made some progress:
- I have to remove the NM_ATT_IPACC_RLC_CFG_3 tag and config from nanobts_attr_cell. If I don't the GPRS CELL NACKs the attributes and never activate. The message sent back by the bts is "new value for attribute RLC Configuration 3 not supported"
- 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.
- Now, I get this :
<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 ...
Sylvain