OpenBSC

openbsc@lists.osmocom.org

1 participants
4319 discussions

Start a nNew thread

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

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

28 Oct '09

hi holger, i would like to test it. but before i can do that, i need to know what ressource are actually counted. for example: a transaction holds one ressource, paging holds one ressource, as well as a channel that is associated to that subscriber's transaction. what about sms? shold an object of "struct gsm_sms" be counted as one ressource, or each sender/receiver within this structure, or all together (one for the sms, one for the sender and one for the receiver)? i need a list of all subscriber ressources for gsm_04_11.c regards, andreas

2 1

OpenBSC system_information branch
by Harald Welte 27 Oct '09

27 Oct '09

Hi! I've updated the system_information branch. The purpose of this branch is to move away from static u_int8_t arrays that are used as templates for the SYSTEM INFORMATION messages. Thise arrays are reminiscent of the old days of bs11_init, where everything had been done this way. The current head of system_information is now managing to actually do that. The full SI1-SI4 on the BCCH as well as the SI5/SI6 on the SACCH are now created from scratch (see code in system_information.c) The content of the SI is "phase 1" content, i.e. before rest octets were introduced I've also written some code to generate the rest octets, as well as a some "rest octet encoding aware" bit vector routines that understand the meaning of 0/1/L/H. However, those rest octet routines are not yet used. They need some careful testing before use. Testing is actually quite hard, as not even wireshark has dissector for the system information messages (anyone interested in contributing on this? It's needed for airprobe, too) One interesting bit that stalled development for quite some time: If you send a SACCH FILLing with length > 18 bytes, then the nanoBTS will actually crash somewhere in the layer 2, sending you long error strings with addresses (stack?) as error reports before rebooting :) Feel free to start testing the system_information branch if you're interested. I'd be happy to hear any "master works for my phone, but system_information branch confuses my phone" kind of reports. 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)

3 3

Status of wireshark patches
by Harald Welte 27 Oct '09

27 Oct '09

Hi! Holger has asked me to send an update on the status of the wireshark patches that we have in git: gsm_a_rr-rrlp.patch and abisip.patch are mainline wireshark, they can be removed from our git tree. abis_oml.patch: * does not yet dissect all the different 12.21 IEs, especially not all of the standard IEs * does not yet differentiate between BTS types. We need a preference where we can select the BTS model in order to really pars all the messages, plus vendor dependent IE tables * might possibly use non-standard C language syntax and thus not be portable to micrsofot compilers on windows. not sure what the wireshark requirements are in that regard rsli-ipaccess.patch: * does not support all of the ip.access RSL extensions yet * no major reason why it should nt be merged to wireshark * additional ip.access RSL extensions can be sent as incremental patches lucent-hmb.patch * this is just a minimal stub, should be completed more before submitting anywhere -- - Harald Welte <laforge(a)gpl-violations.org> http://gpl-violations.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Errors reports by clang --analyze in abis_nm.c
by Holger Freyther 27 Oct '09

27 Oct '09

Hey, the clang C frontend has found some issues in our OpenBSC code. I think we will need to have a table for BS11 and one for ipaccess with the shared/speced elements being in both tables. Here is the list of things I can resolve myself right now: [NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_FIXED, 2 } [NM_ATT_IPACC_FREQ_CTRL] = { TLV_TYPE_TV, }, these vendor specific commands have the same value: [NM_ATT_IPACC_NS_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_BIT_ERR_THESH] = { TLV_TYPE_FIXED, 2 }, [NM_ATT_IPACC_BSSGP_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_BOOT_SW_VERS] = { TLV_TYPE_TLV }, ^~~~~~~~~~~~ [NM_ATT_IPACC_RLC_CFG] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_CCLK_ACCURACY] = { TLV_TYPE_TV }, ^~~~~~~~~~~ [NM_ATT_IPACC_ALM_THRESH_LIST]= { TLV_TYPE_TL16V }, [NM_ATT_BS11_CCLK_TYPE] = { TLV_TYPE_TV }, ^~~~~~~~~~~ [NM_ATT_IPACC_CODING_SCHEMES] = { TLV_TYPE_TL16V }, [0xa8] = { TLV_TYPE_TLV }, [NM_ATT_IPACC_UPTIME] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_L1_PROT_TYPE] = { TLV_TYPE_TV }, [NM_ATT_IPACC_RLC_CFG_3] = { TLV_TYPE_TL16V }, [NM_ATT_BS11_LINE_CFG] = { TLV_TYPE_TV }, [0x85] = { TLV_TYPE_TV }, [NM_ATT_IPACC_STREAM_ID] = { TLV_TYPE_TV, },

2 1

[RFC] Subscriber Reference Counting
by Holger Freyther 27 Oct '09

27 Oct '09

Hi, IIRC Harald et all. were seeing GSM subscriber leakage at HAR2009 and we have not yet explored the cause of this problem. I would like to have no subscriber leaks for the congress and propose the following changes. I have pushed the "holger/subscr-ref-handling" branch to our repository and would be happy if people could give it a spin. My testing here is pretty limited. Currently I have two commits. The second is removing a leak in the vty console for SMS sending and subscriber usage and the other patch is trying to stop borrowing someone else's gsm_subscriber reference. More details below. Currently we do lchan->subscr = new_subscr and then we have two flavors of checking if the channel is already used. I have changed this to use a new assignment function that will do the check consistently and updated call sites. I would establish the following guideline for gsm_subscriber handling: In every method where subscr_get* is called the subscriber must be released at the exit with subscr_put unless the referenced provider is assigned to a struct that is created in the same method, then the subscriber must be released next to the talloc_free. More details: - paging.c seems fine - gsm_subscriber_chan seems fine - gsm_04_08_utils.c seems fine - gsm_04_08.c seems fine now as well. subscr_get/_put should be balanced - gsm_04_11.c if we leak a subscriber we also leak a sms I have not checked all SMS paths to be sure we don't leak there. I would be very happy if people could test this. z,

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC