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
Hi,
we made lots of pictures of the bs11 pcbs.
Maybe they will help you during disassembly or are interesting
in an technical aspect.
http://www.flickr.com/photos/hellercom/sets/72157619296925571/
regards
Bjoern
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Björn Heller
Jabber: tec(a)jabber.hellercom.de
Hello Sylvain,
On Sun, 1 Nov 2009 11:05:31 +0100, "Sylvain Munaut" <246tnt(a)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(a)mirider.augusta.de
Hi all!
I've pushed the current state of GPRS support into the 'gprs' branch. All the
'core' changes related to GPRS are already in master, so it mainly really adds
the GPRS protocols (gprs_{ns,bssgp,llc}.[ch]) as well as the handling of the
most importnat 04.08 GMM messages (gsm_04_08_gprs.[ch]) as well as the state
management for the SGSN MM context (gprs_sgsn.[ch]).
The status of the code is as follows:
* NS link and BSSGP link are established between OpenBSC and the nanoBTS
* LLC frames from the MS get delivered to the OpenBSC LLC code
* GMM messages sent over LLC are delivered to the GMM code
* The GMM code tries to respond with useful answers, permitting
GPRS attach as well as routing area update
What's missing:
* any kind of GGSN functionality, i.e. gatewaying to PPP daemon for actual
user payloads
* persistant storage of SGSN MM context information, especially the
attach/detach status, routing area and P-TMSI of a subscriber
* PDP context activation/deactivation
* flow control for the BTS as well as for each MS (BSSGP level)
* retransmissions and things like acknowledged mode of LLC
* support for multiple BTS
There's really only one extremely ugly hack in the code right now,
and that is that the IP address of the BTS is hard-coded in the
ipac_gprs_send() function. You will have to enter the IP address
of your BTS there to make packets in the SGSN->BTS direction delivered.
Apart from that, I think the code is at a state where other interested
developers can start playing with it. I am leaving to Korea on a customer
assingment tomorrow and will unlikely have time to work on any GPRS code
throughout the next two weeks.
To get the code going, you should do the following things:
* chceck out the gprs branch
* hard-code your ip address into ipac_gprs_send() as indicated above
* change your openbsc.cfg to use the last timeslot (TS 7) as "TCH/F_PDCH"
instead of just "TCH/F"
Patches / Bug reports / ... welcome
Regards,
Harald
--
- 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)
