OpenBSC August 2011

openbsc@lists.osmocom.org

13 participants
30 discussions

GPRS - local and foreign TLLIs
by Luca Melette 18 Nov '25

18 Nov '25

Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM

4 5

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

Several questions
by jason mercury 06 Dec '12

06 Dec '12

I have some questions: 1) When I start bsc_hack bsc_init.c first establishes OML link and initializes the bts then it establishes RSL link and bts starts broadcasting. However, it takes so much time to start the bts. Instead of this I want to do the following: it establishes OML link at the beginning and only once, then when i want to start broadcasting it establishes just the RSL link and bts will start faster since i don't have to wait for OML link. What should be done for this? 2) If i send one or two word messages from telnet interface it is okay. But if i send a longer message the phone could't receive the end of the message correctly(last words may be incomplete). Did any one encounter with this problem? What is wrong with me? 3) Could I send SMS in which extension of the sender is text not integer. For example, i want to send an information SMS that this is a test network. For this purpose i want to send an SMS from 'OpenBSC'. I set the extension of the first subscriber in database as text and tried to send the SMS but SMS wasn't delivered. What should i do? 4) Can i add SMS externally to SMS table of database? Thanks. Jason

4 3

[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, Harald prefers that this case is internally handled by the ipaccess and hsl drivers by means of the driver_data field in the e1inp_line structure. Reported-by: Gus Bourg <gus(a)bourg.net> --- src/e1_input.c | 4 ---- src/input/hsl.c | 20 ++++++++++++++++++++ src/input/ipaccess.c | 20 ++++++++++++++++++++ 3 files changed, 40 insertions(+), 4 deletions(-) diff --git a/src/e1_input.c b/src/e1_input.c index a549ba4..ad0778a 100644 --- a/src/e1_input.c +++ b/src/e1_input.c @@ -676,10 +676,6 @@ int e1inp_line_update(struct e1inp_line *line) e1inp_line_get(line); - /* This line has been already initialized, skip this. */ - if (line->refcnt > 2) - return 0; - if (line->driver && line->ops && line->driver->line_update) { rc = line->driver->line_update(line); } else diff --git a/src/input/hsl.c b/src/input/hsl.c index dc7532b..60eea17 100644 --- a/src/input/hsl.c +++ b/src/input/hsl.c @@ -456,9 +456,29 @@ static int hsl_bts_connect(struct ipa_client_link *link) return 0; } +struct hsl_line { + int line_already_initialized; +}; + static int hsl_line_update(struct e1inp_line *line) { int ret = -ENOENT; + struct hsl_line *hl; + + if (!line->driver_data) + line->driver_data = talloc_zero(line, struct hsl_line); + + if (!line->driver_data) { + LOGP(DLINP, LOGL_NOTICE, "hsl: OOM in line update\n"); + return -ENOMEM; + } + hl = line->driver_data; + + /* We only initialize this line once. */ + if (hl->line_already_initialized) + return 0; + + hl->line_already_initialized = 1; switch(line->ops->cfg.ipa.role) { case E1INP_LINE_R_BSC: diff --git a/src/input/ipaccess.c b/src/input/ipaccess.c index b7391b3..ea04e8d 100644 --- a/src/input/ipaccess.c +++ b/src/input/ipaccess.c @@ -813,9 +813,29 @@ static int ipaccess_bts_cb(struct ipa_client_link *link, struct msgb *msg) return 0; } +struct ipaccess_line { + int line_already_initialized; +}; + static int ipaccess_line_update(struct e1inp_line *line) { int ret = -ENOENT; + struct ipaccess_line *il; + + if (!line->driver_data) + line->driver_data = talloc_zero(line, struct ipaccess_line); + + if (!line->driver_data) { + LOGP(DLINP, LOGL_ERROR, "ipaccess: OOM in line update\n"); + return -ENOMEM; + } + il = line->driver_data; + + /* We only initialize this line once. */ + if (il->line_already_initialized) + return 0; + + il->line_already_initialized = 1; switch(line->ops->cfg.ipa.role) { case E1INP_LINE_R_BSC: { -- 1.7.2.5

3 2

Missing libosmoabis-library
by Dennis Wehrle 31 Aug '11

31 Aug '11

Hi I just tried to use the newest versions of libosmocore, openbsc and lcr. But i can't configure openbsc (the master branch). It complains about missing libosmoabis. Where can i find this library? This happens even if i use the pablo/libosmo-abis branch from libosmocore. Best regards Dennis

2 2

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

30 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 30 Aug '11

30 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC August 2011