October 2009 - OpenBSC - lists.osmocom.org

[PATCH 0/1] Add bport0/1 support for bs11_config
by Daniel Willmann 14 Dec '10

14 Dec '10

Hello, second try to add support to bs11_config for bport0/1 configuration. This time with enum abis_bs11_line_cfg. It seems sometimes creating bport1 fails, even LMT shows create obj greyed out. Don't know why yet. Regards, Daniel Willmann Daniel Willmann (1): Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config openbsc/include/openbsc/abis_nm.h | 10 +++++++++- openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++-- openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 3 deletions(-)

4 5

RFC: Establishing logging standards
by Holger Freyther 11 Nov '09

11 Nov '09

Hey, I think in the next days I will go around the sourcecode and change a couple of logging messages. My two primary goals are increase the usefulness to figure out what was going wrong and the second to be able to put some of these into the syslog. Should we use DEBUG* to also log to syslog or introduce a new set of macros? Log Levels: I think Harald has expressed the wish to introduce log levels. Should we follow the log levels of syslog(3)? Messages: I would like to collect formats for various actions. Currently I'm thinking of the following but would like to have more input. subscriber: When talking about a subscriber use TMSI, IMSI and Extension. lchan: Include refcount, channel type, link_id, subscriber sccp: Talk about SCCP source local reference and pointer transaction: Print the transaction? gsm0408: Print the lchan which prints the subscriber? comments? holger

3 8

[PATCH] implemented GSM340_TP_VPF_ABSOLUTE
by Steffen 'stefreak' Neubauer 11 Nov '09

11 Nov '09

From: Steffen Neubauer <stefreak(a)stefreak.de> - Added function "gsm340_scts" to decode the service center time stamp into a UTC/GMT timestamp - in function gsm340_validity_period: can now decode validity period format absolute. I hope it's good ;) Greetings, Steffen

2 4

GPRS branch status updates
by Harald Welte 01 Nov '09

01 Nov '09

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)

2 4

AW: OpenBSC RTP / MNCC integration
by Andreas.Eversberg 31 Oct '09

31 Oct '09

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

2 1

OpenBSC unsubscribe notification
by mailman-bounces＠lists.gnumonks.org 31 Oct '09

31 Oct '09

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

1 0

(no subject)
by Andreas.Eversberg 30 Oct '09

30 Oct '09

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

2 1

UMTS BTS for sale on ebay
by Marc Juul 30 Oct '09

30 Oct '09

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

2 1

[PATCH] ip.access: Header has a 16bit length in network byte order
by Sylvain Munaut 29 Oct '09

29 Oct '09

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

2 1

AW: [RFC] Subscriber Reference Counting
by Andreas.Eversberg 28 Oct '09

28 Oct '09

> 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.

2 1