OpenBSC

openbsc@lists.osmocom.org

11 participants
4278 discussions

[PATCH] input: fix multiple BTS attached to single line scenario
by pablo＠gnumonks.org 31 Aug '11

31 Aug '11

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> With multiple BTS attached to a single line, we have to call ->line_update() multiple times. I broke this myself while avoiding that A-bis over IP drivers bind to the socket several times. To fix this situation, this patch adds the E1INP_DRV_F_LINE_ETHER flag which allows us to skip multiple invocation of ->line_update() only in case that this is an A-bis over IP driver. Reported-by: Gus Bourg <gus(a)bourg.net> --- include/osmocom/abis/e1_input.h | 5 +++++ src/e1_input.c | 4 ++-- src/input/hsl.c | 1 + src/input/ipaccess.c | 1 + 4 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/osmocom/abis/e1_input.h b/include/osmocom/abis/e1_input.h index 42b1758..bbbbf29 100644 --- a/include/osmocom/abis/e1_input.h +++ b/include/osmocom/abis/e1_input.h @@ -124,9 +124,14 @@ enum e1inp_line_role { E1INP_LINE_R_MAX }; +enum { + E1INP_DRV_F_LINE_ETHER = (1 << 0), /* Driver uses ethernet line. */ +}; + struct e1inp_driver { struct llist_head list; const char *name; + unsigned int flags; int (*want_write)(struct e1inp_ts *ts); int (*line_update)(struct e1inp_line *line); void (*close)(struct e1inp_sign_link *link); diff --git a/src/e1_input.c b/src/e1_input.c index a549ba4..3c5ac7d 100644 --- a/src/e1_input.c +++ b/src/e1_input.c @@ -676,8 +676,8 @@ int e1inp_line_update(struct e1inp_line *line) e1inp_line_get(line); - /* This line has been already initialized, skip this. */ - if (line->refcnt > 2) + /* This ethernet line has been already initialized, skip this. */ + if ((line->driver->flags & E1INP_DRV_F_LINE_ETHER) && line->refcnt > 2) return 0; if (line->driver && line->ops && line->driver->line_update) { diff --git a/src/input/hsl.c b/src/input/hsl.c index dc7532b..fe9e70c 100644 --- a/src/input/hsl.c +++ b/src/input/hsl.c @@ -322,6 +322,7 @@ static int hsl_line_update(struct e1inp_line *line); struct e1inp_driver hsl_driver = { .name = "hsl", + .flags = E1INP_DRV_F_LINE_ETHER, .want_write = ts_want_write, .line_update = hsl_line_update, .close = hsl_close, diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c index b7391b3..b12383b 100644 --- a/src/input/ipaccess.c +++ b/src/input/ipaccess.c @@ -555,6 +555,7 @@ static int ipaccess_line_update(struct e1inp_line *line); struct e1inp_driver ipaccess_driver = { .name = "ipa", + .flags = E1INP_DRV_F_LINE_ETHER, .want_write = ts_want_write, .line_update = ipaccess_line_update, .close = ipaccess_close, -- 1.7.2.5

2 1

[PATCH] vty: bail out if we cannot enable logging from VTY
by pablo＠gnumonks.org 31 Aug '11

31 Aug '11

From: Pablo Neira Ayuso <pablo(a)gnumonks.org> --- src/vty/logging_vty.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/vty/logging_vty.c b/src/vty/logging_vty.c index b037a5b..b4ab748 100644 --- a/src/vty/logging_vty.c +++ b/src/vty/logging_vty.c @@ -78,8 +78,10 @@ DEFUN(enable_logging, } conn->dbg = log_target_create_vty(vty); - if (!conn->dbg) + if (!conn->dbg) { + vty_out(vty, "Cannot enable logging to this VTY.%s", VTY_NEWLINE); return CMD_WARNING; + } log_add_target(conn->dbg); return CMD_SUCCESS; -- 1.7.2.5

1 0

Core dump in trunk
by Gus Bourg 30 Aug '11

30 Aug '11

I've pulled everything fresh from trunk in my quest to get multiple BTS's working on one E1 card. :) However, I'm seeing a core dump when I start osmo-nitb in the box now. A BT is available here: http://pastebin.com/KAaxt5d3 This is in a configuration where I only have one BTS configured. Though I get the same issue if I have more than one configured too. Thanks, Gus

3 9

Multiple BTS's on one one E1?
by Gus Bourg 25 Aug '11

25 Aug '11

Hello all, I'm attempting to connect multiple BTS's to one E1 card. Each BTS is a single TRX and I'm using a dahdi card plugged into a DCS. The DCS maps the channels as follows: Name Src Dest Speed Type -------------------------------------------------------------------------------- bscnok1 01.T1E1-A.02.01 01.T1E1-A.03.01 0256k D FDX bscnok2 01.T1E1-A.02.05 01.T1E1-A.04.01 0256k D FDX bscnok3 01.T1E1-A.01.09 01.T1E1-B.01.01 0256k D FDX So essentially: TS 1,2,3,4 from OpenBSC (T1E1-A-02) are mapped to nok1 1,2,3,4 (T1E1-A-03) TS 5,6,7,8 from OpenBSC (T1E1-A-02) are mapped to nok2 1,2,3,4 (T1E1-A-04) TS 9,10,11,12 from OpenBSC (T1E1-A-02) are mapped to nok3 1,2,3,4 (T1E1-B-01) This all works fine. The BTS operates on TS1,2,3,4 on any of the ports I have configured. I just swap timeslots in openbsc.cfg from 1,2,3,4 to 5,6,7,8 or 9,10,11,12 and everything is happy. Where I run into a problem is when I try to actually run multiple BTS's at once. So I take everything defined in "bts 0" and duplicate it as "bts 1". I change the time slots for oml, rsl, and traffic channels to match the appropriate channels for bts 1/2. But when I go to start osmo-nitb I get an error that it can't open /dev/dahdi/1 because it's already in use. It appears for some reason that it's attempting to open /dev/dahdi/1 for both BTS's even though only bts 0 uses /dev/dahdi/1 for OML - bts 1 should use /dev/dahdi/5 and bts 2 should use /dev/dahdi/9. My /etc/dahdi/system.conf is defined as: span=1,1,0,ccs,hdb3,crc4 bchan=2-4,6-8,10-12 dchan=1,5,9 I'm at a loss. Has anyone tried to run multiple BTS's with dahdi on a single E1 or T1 span? Is there something special I need to specify so that OpenBSC doesn't grab the first dchan for each BTS? Thanks, Gus

3 3

Re: Multiple BTS's on one one E1?
by Harald Welte 25 Aug '11

25 Aug '11

_please_ use the mailing list! On Wed, Aug 24, 2011 at 11:39:53AM -0700, Gus Bourg wrote: > It looks like e1inp_ts needs to have a member lapd: > > input/dahdi.c:471:14: error: ‘struct e1inp_ts’ has no member named ‘lapd’ you are probably using a non-current version of openbsc.git and libosmo-abis.git > Problem is that we go into a bootstrap loop: Well, that should be relatively easy to workaround with a small hack like a static variable that checks whether the BTS has been bootstrapped before. That's of course not a proper solution... I currently don't have time to debug this further, and I am far away from any of my E1 equipment for testing. -- - 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)

1 0

open bts project
by Andre Egington 24 Aug '11

24 Aug '11

Dear Group > > > > I have been for the past few months Following your project very > closely and have to say how amazed I am at this project. I would love > to do something like this here in the uk but finding hardware to do it > is just impossible I would like to get my hands on a Simens BS-11 but > cant source any. I will continue to watch this project but felt I > should email you to ask if you know of anywhere that I can purchase > hardware that able to work with your open bts software if there is any advice you can give that would be great. > Regards Andre

1 0

[PATCH 2/2] DAHDI: Make sure dahdi_e1_setup() can be called multiple times
by Harald Welte 24 Aug '11

24 Aug '11

In case we have multiple BTS attached to the same E1 line, the e1inp_driver::line_update() function will be called multiple times, and we need to make sure this is handled gracefully. --- src/input/dahdi.c | 27 ++++++++++++++++++++++++--- 1 files changed, 24 insertions(+), 3 deletions(-) diff --git a/src/input/dahdi.c b/src/input/dahdi.c index a4dbd03..66bf53f 100644 --- a/src/input/dahdi.c +++ b/src/input/dahdi.c @@ -393,6 +393,10 @@ static int dahdi_e1_setup(struct e1inp_line *line) struct osmo_fd *bfd = &e1i_ts->driver.dahdi.fd; int dev_nr; + /* unregister FD if it was already registered */ + if (bfd->list.next && bfd->list.next != LLIST_POISON1) + osmo_fd_unregister(bfd); + /* DAHDI device names/numbers just keep incrementing * even over multiple boards. So TS1 of the second * board will be 32 */ @@ -405,10 +409,20 @@ static int dahdi_e1_setup(struct e1inp_line *line) switch (e1i_ts->type) { case E1INP_TS_TYPE_NONE: + /* close/release LAPD instance, if any */ + if (e1i_ts->lapd) { + lapd_instance_free(e1i_ts->lapd); + e1i_ts->lapd = NULL; + } + if (bfd->fd) { + close(bfd->fd); + bfd->fd = 0; + } continue; break; case E1INP_TS_TYPE_SIGN: - bfd->fd = open(openstr, O_RDWR | O_NONBLOCK); + if (!bfd->fd) + bfd->fd = open(openstr, O_RDWR | O_NONBLOCK); if (bfd->fd == -1) { fprintf(stderr, "%s could not open %s %s\n", __func__, openstr, strerror(errno)); @@ -416,10 +430,17 @@ static int dahdi_e1_setup(struct e1inp_line *line) } bfd->when = BSC_FD_READ | BSC_FD_EXCEPT; dahdi_set_bufinfo(bfd->fd, 1); - e1i_ts->lapd = lapd_instance_alloc(1, dahdi_write_msg, bfd); + if (!e1i_ts->lapd) + e1i_ts->lapd = lapd_instance_alloc(1, dahdi_write_msg, bfd); break; case E1INP_TS_TYPE_TRAU: - bfd->fd = open(openstr, O_RDWR | O_NONBLOCK); + /* close/release LAPD instance, if any */ + if (e1i_ts->lapd) { + lapd_instance_free(e1i_ts->lapd); + e1i_ts->lapd = NULL; + } + if (!bfd->fd) + bfd->fd = open(openstr, O_RDWR | O_NONBLOCK); if (bfd->fd == -1) { fprintf(stderr, "%s could not open %s %s\n", __func__, openstr, strerror(errno)); -- 1.7.5.4 --oJ71EGRlYNjSvfq7--

1 0

[PATCH 1/2] LAPD: Add function to release/free a LAPD instance
by Harald Welte 24 Aug '11

24 Aug '11

--- include/osmocom/abis/lapd.h | 1 + src/input/lapd.c | 7 +++++++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/include/osmocom/abis/lapd.h b/include/osmocom/abis/lapd.h index dd22028..92dc2c3 100644 --- a/include/osmocom/abis/lapd.h +++ b/include/osmocom/abis/lapd.h @@ -48,6 +48,7 @@ struct lapd_instance *lapd_instance_alloc(int network_side, void (*tx_cb)(uint8_t *data, int len, void *cbdata), void *cbdata); +void lapd_instance_free(struct lapd_instance *li); /* Start a (user-side) SAP for the specified TEI/SAPI on the LAPD instance */ int lapd_sap_start(struct lapd_instance *li, uint8_t tei, uint8_t sapi); diff --git a/src/input/lapd.c b/src/input/lapd.c index 0287e14..d94af58 100644 --- a/src/input/lapd.c +++ b/src/input/lapd.c @@ -730,3 +730,10 @@ struct lapd_instance *lapd_instance_alloc(int network_side, return li; } + +void lapd_instance_free(struct lapd_instance *li) +{ + /* tei and sapis are allocated hierarchically of the lapd + * instance, so one free is sufficient here */ + talloc_free(li); +} -- 1.7.5.4 --oJ71EGRlYNjSvfq7 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-DAHDI-Make-sure-dahdi_e1_setup-can-be-called-multipl.patch"

1 0

How to fake Roaming?
by Peter Hasse 23 Aug '11

23 Aug '11

Hi We are planing to combine OpenBSC with our wifi mesh implementation in a static setup as a demo / testbed. We would like to implement a roaming like behavior and have actually two approaches 1. Configuring a call forward on the phone so that it the "real" provider forwards the call to a number that we can route into the openBSC based network if the phone is not connected to its network. This would allow people to call "me" eager if i connected to the "real" network or the OpenBSC network. Disadvantage would be that if I call somebody from the OpenBSC network the called party would not see the number from the "real" network. 2. Use a service like sipgate one. It would also allow a unified number for both "real" and OpenBSC network but if you call from the "real" network it has a different number. Besides the unlikely way of real roaming with an carrier another option would be to fake the outgoing number. Does anybody know a service that could be used for that (i would need to fake a german GSM number). Does anybody know how this is handled on oil rigs or ships? Do they have a roaming agreement ? thanks mfg Peter

2 1

OpenBSC and MMS
by Simon Barnett 16 Aug '11

16 Aug '11

Hi all, I would like to test sending MMS messages to mobile devices. Out of the box I know OpenBSC supports SMS, which I have been able to use, however, I feel that MMS will be more tricky. My initial thoughts are to set up OpenBSC with GPRS using this: - http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS And then try to bolt some kind of MMS support on top. Before I get started though, I was wondering if anyone had done this before and/or had any ideas as to how I might go about implementing this. I really would appreciate any guidance anyone could offer me. Thanks in advance, Simon

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC