OpenBSC

openbsc@lists.osmocom.org

1 participants
4154 discussions

by Dieter Spaar

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

15 years, 8 months

lots of new BS11 internals pictures

by Bjoern Heller

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

15 years, 8 months

Re: GPRS branch status updates

by Dieter Spaar

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

15 years, 8 months

GPRS branch status updates

by Harald Welte

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)

15 years, 8 months

AW: OpenBSC RTP / MNCC integration

by Andreas.Eversberg

hi harald, > sorry for not getting back earlier. I honestly did not realize that there > was a second attachment to your mail. We typically use inline patches, and one > patch per mail on this list. Once again, sorry for the delay. next time i will send the patches inline... > I'm now looking at the code in detail, I shall be getting back to you at some > point during the next days. in order to remove md5 code, you can use a simple XOR to mix the input data. i think it is good enough to not select the same random number as the base station. regards, andreas

15 years, 8 months

OpenBSC unsubscribe notification

by mailman-bounces＠lists.gnumonks.org

xavier.carcelle(a)openpattern.org has been removed from OpenBSC.

15 years, 8 months

(no subject)

by Andreas.Eversberg

hi there, i found the problem with the delayed audio between application and the nanoBTS. the reason was the timestamp. a delay in openbsc causes packets to be delayed 1/2 seconds, so many packet of 1/2 seconds arrived at nanoBTS after the delay at once, nanoBTS buffers them. the reason for the delay was the "usleep(100000)" hack inside input/ipaccess.c. the patch will use the tx_timer instead, so openbsc and application will not stall. this timer was already used with BS11 messages. (there it uses 50 miliseconds instead of 100 miliseconds.) sending 10 messages to nanoBTS will take almost one second. can we decrease the tx_timer value for nanoBTS? how many packets can handle nanoBTS per second? also i fixed some bugs in the rtp patch. use rtp_2.patch for commission/discussion instead. regards, andreas

15 years, 8 months

UMTS BTS for sale on ebay

by Marc Juul

Hi. Just wanted to let you know about a $500 UMTS BTS for sale on ebay: http://cgi.ebay.com/ALCATEL-LUCENT-ANDREW-UMTS-BTS-1120-BASE-STATION_W0QQit… In case you were looking for one. -- Juul juul(a)labitat.dk

15 years, 8 months

[PATCH] ip.access: Header has a 16bit length in network byte order

by Sylvain Munaut

From: Sylvain Munaut <tnt(a)246tNt.com> This is confirmed by looking at the source of their dissector. The length can go up to 273 bytes apparently (again, according to the source of their dissector). Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com> --- openbsc/include/openbsc/ipaccess.h | 3 +-- openbsc/src/input/ipaccess.c | 10 +++++----- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/openbsc/include/openbsc/ipaccess.h b/openbsc/include/openbsc/ipaccess.h index eb17167..3956877 100644 --- a/openbsc/include/openbsc/ipaccess.h +++ b/openbsc/include/openbsc/ipaccess.h @@ -4,8 +4,7 @@ #include "e1_input.h" struct ipaccess_head { - u_int8_t zero; - u_int8_t len; + u_int16_t len; /* network byte order */ u_int8_t proto; u_int8_t data[0]; } __attribute__ ((packed)); diff --git a/openbsc/src/input/ipaccess.c b/openbsc/src/input/ipaccess.c index 1265982..ea44f1e 100644 --- a/openbsc/src/input/ipaccess.c +++ b/openbsc/src/input/ipaccess.c @@ -259,7 +259,7 @@ struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error) { struct msgb *msg = msgb_alloc(TS1_ALLOC_SIZE, "Abis/IP"); struct ipaccess_head *hh; - int ret = 0; + int len, ret = 0; if (!msg) { *error = -ENOMEM; @@ -284,8 +284,9 @@ struct msgb *ipaccess_read_msg(struct bsc_fd *bfd, int *error) /* then read te length as specified in header */ msg->l2h = msg->data + sizeof(*hh); - ret = recv(bfd->fd, msg->l2h, hh->len, 0); - if (ret < hh->len) { + len = ntohs(hh->len); + ret = recv(bfd->fd, msg->l2h, len, 0); + if (ret < len) { fprintf(stderr, "short read!\n"); msgb_free(msg); *error = -EIO; @@ -374,8 +375,7 @@ void ipaccess_prepend_header(struct msgb *msg, int proto) /* prepend the ip.access header */ hh = (struct ipaccess_head *) msgb_push(msg, sizeof(*hh)); - hh->zero = 0; - hh->len = msg->len - sizeof(*hh); + hh->len = htons(msg->len - sizeof(*hh)); hh->proto = proto; } -- 1.6.5.1

15 years, 8 months

AW: [RFC] Subscriber Reference Counting

by Andreas.Eversberg

> Currently the branch is doing: > - Stops borrowing the gsm_subscriber to the lchan > - Fixes leaks in the vty_interface_layer3.c code for subscriber action > - Fixes a subscriber leak (actually two) in mncc_send. > > if wanted I can attach the patches to this mail to ease reviewing. what branch is it? do i need additional patches? i use the master with the RTP patch applied.

15 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC