OpenBSC

openbsc@lists.osmocom.org

4315 discussions

RFC extend osmo_signal infrastructure
by Daniel Willmann 07 Oct '11

07 Oct '11

Hello list, I would like to be able to send a TRAP over the control interface for certain signals. For this it would be nice if the signals have a text representation of their name as is the case with the (rate) counters. I want to propose a different API where you register the signals (and maybe even the subsystems) and provide a name for them. The function register_signal would then return the numeric representation of the signal. The performance hit would only be during registering, not during dispatch. The callback function would still be called with the numeric representation in order to avoid resolving the name to the number every time. Inside the callback you would have to resolve the name of the signal to the actual number, but using static variables you'll only have to do it the first time: void signal_cb(unsigned int subsysnum, unsigned int signalnum, void *signal_data, void *handler_data) { static unsigned int foosig, barsig; if (foosig == 0) { foosig = osmo_signal_get_by_name("foo"); } if (barsig == 0) { barsig = osmo_signal_get_by_name("bar"); } switch (signalnum) { case foosig: do_stuff; break; case barsig: do_other_stuff; break; } } The functions that dispatch the signals would have to do something similar. Ideas? Is this too complex? Do we gain enough from registering signals at runtime or should we rather keep the enums and add a value_string for the name/description? Regards, Daniel Willmann

1 0

nanoBTS GPRS question
by Jon Southall 04 Oct '11

04 Oct '11

Hi, I am looking for some help debugging a nanoBTS setup with OpenBSC/SGSN/GGSN as I am struggling getting GPRS to work. I am seeing the following error in the SGSN output: debian4:/opt/openbsc/openbsc/src/gprs# ./osmo-sgsn -c osmo_sgsn.cfg <0011> gprs_ns.c:151 NSVCI=65534 Creating NS-VC <0011> gprs_ns.c:151 NSVCI=65535 Creating NS-VC <0011> gprs_ns.c:738 Creating NS-VC for BSS at 192.168.60.200:23000 <0011> gprs_ns.c:620 NSEI=65535 Rx NS RESET (NSVCI=0, cause=O&M intervention) <0011> gprs_ns.c:488 NSEI=101 Tx NS RESET ACK (NSVCI=101) <0011> gprs_ns.c:797 NSEI=101 Rx NS UNBLOCK <0012> gprs_bssgp.c:246 BSSGP BVCI=0 Rx RESET cause=Transmission capacity modified <0012> gprs_bssgp.c:246 BSSGP BVCI=2 Rx RESET cause=Transmission capacity modified <0012> gprs_bssgp.c:269 Cell 1-1-1-0 CI 0 on BVCI 2 <0012> gprs_bssgp.c:322 BSSGP BVCI=2 Rx BVC-UNBLOCK <0012> gprs_bssgp.c:322 BSSGP BVCI=2 Rx BVC-UNBLOCK <0012> gprs_bssgp.c:462 BSSGP BVCI=2 Rx Flow Control BVC <0012> gprs_bssgp.c:346 BSSGP TLLI=0x7f60277f Rx UPLINK-UNITDATA <0013> gprs_llc.c:428 LLC SAPI=1 C FCS=0x447ea5CMD=UI DATA <0013> gprs_llc.c:700 LLC RX: unknown TLLI 0x7f60277f, creating LLME on the fly I came across this thread http://comments.gmane.org/gmane.comp.mobile.openbsc.general/687 which talks about a similar error but hasn't helped resolve the problem. I have a second hand nanoBTS unit, are there any configuration settings I need to change on the unit itself to make it work with the example configs from OpenBSC? Any help/advice much appreciated Thanks Jon _______________________ Jon Southall Technical Operations Manager E: jon.southall(a)boku.com<mailto:jon.southall@boku.com> M: +14153427958 [cid:image001.png@01CC82AD.3D217E20] _______________________

1 0

VTY hacks for automatic document generation
by Holger Hans Peter Freyther 02 Oct '11

02 Oct '11

Hi, my goal is to generate our wiki pages (or docbook, or...) for the config formats from the VTY commands directly. We might also want/need to add additional docs inside the command. My current hack is this: diff --git a/src/vty/command.c b/src/vty/command.c index ab1eaca..bcf72d0 100644 --- a/src/vty/command.c +++ b/src/vty/command.c @@ -426,6 +426,20 @@ void install_element(enum node_type ntype, struct cmd_element *cmd) cmd->strvec = cmd_make_descvec(cmd->string, cmd->doc); cmd->cmdsize = cmd_cmdsize(cmd->strvec); + + printf("NODE: %d\n", ntype); + + int j; + for (j = 0; j < vector_count(cmd->strvec); ++j) { + vector descvec = vector_slot(cmd->strvec, j); + int i; + for (i = 0; i < vector_active(descvec); i++) { + struct desc *desc = vector_slot(descvec, i); + if (desc == NULL) + continue; + printf(" %s %s\n", desc->cmd, desc->str); + } + } Output: NODE: 1 show Show running system information version Displays program version NODE: 1 list Print command list NODE: 1 exit Exit current mode and down to previous mode NODE: 1 help Description of the interactive help system NODE: 1 enable Turn on privileged mode command NODE: 1 terminal Set terminal line parameters length Set number of lines on a screen <0-512> Number of lines on screen (0 for no pausing) NODE: 1 Problems: The goal would to have a VTY command to introspect all vty commands, one of the problems is to do it recursively. E.g. we have commands that move to another node but this is via code and can not be seen from the outside. The other problem is we can not get the name from the node number... PS: Can we move VTY to AGPL code, bit by bit? Remove one public function and reimplement to make OpenBSC work again? E.g. the vector in vectors is a bit crazy...

1 0

[RFC] proposal for new library: libosmo-net
by Pablo Neira Ayuso 30 Sep '11

30 Sep '11

Hi, After some private discussion with Harald, I'd like to propose one new library to abstract the network interface that is used to communicate two elements that are part of one GSM network (no matter if it's on the A-bis interface, A interface, ...). This new library, whose proposed name can be "libosmo-net", would initially support: - E1 interfaces. - Ethernet + IPA TCP/IP. - rs232 (as required by bs11 its config interface). This support is included in libosmo-abis, so my idea is to extract this code from it and leave in libosmo-abis only the specific A-bis bits. The libosmo-net library would be extensible, so we can add new interfaces to it (new E1 cards supported, new protocols over BSD sockets, and so on). The interface provided to the client of the library will be homogeneous for all supported interfaces (at least, as much as we can). The new library will provide: * a constructor/destructor to create/release some network interface of * a given supported type. * a call-back for receiving incoming messages that will take the actual msgb. * one function for sending signalling messages. As well as many helper functions in this regard. Therefore, libosmo-abis will require this new libosmo-net library after all is done. For the A interface, I'd propose some hypothetical libosmo-a library that will contain the specific A interface protocols. Let me know what you think.

2 3

comments on jolly/lapd branch
by Harald Welte 25 Sep '11

25 Sep '11

Hi Andreas, I've done a quick read through your jolly/lapd branches, and I have the following comments: 1) great work, thanks :) 2) lapd_profile I would like to use a 'struct lapd_profile' instead of a simple enum. Why? Because this puts all the values/parameters (like k, n201, short_address, use_sabme, t200, etc.) into the control of the caller, instead of the library. so basically we would have struct lapd_profile { uint8_t k; unsigned int n201; ... }; and then some library-pre-defined ones: const struct lapd_profile lapd_profile_isdn = { ... }; const struct lapd_profile lapd_profile_abis = { ... }; but this way an application could define their own profile with slightly different timers, without having to modify the library codebase. The actual lapd_datalink then just would have a const struct lapd_profile *profile; member that is assigned during lapd_dl_init(). 3) the msgb_free() changes in input/dahdi.c, src/e1_input.c, etc. should be a separate patch, as they are actual bugfixes of the old code, as far as I understand. That bugfix patch should be first, then the actual LAPD restructuring on top of it. 4) regarding the two-dimensional switch() statements, I suggest introducing the following macros to include/osmocom/core/osmo_prim.h: #define OSMO_PRIM(prim, op) (prim << 8 | op & 0xFF) #define OSMO_PRIM_HDR(oph) OSMO_PRIM(oph->primitive, oph->operation) then you can do something like this in the lapd code: switch (OSMO_PRIM_HDR(oph)) { case OSMO_PRIM(PRIM_DL_EST, PRIM_OP_REQUEST): ... } 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)

1 0

New open hardware for OpenBTS
by Alexander Chemeris 21 Sep '11

21 Sep '11

Hi all, (and sorry to those who receive this twice) At Sept 15th I will speak at the Open Hardware Summit at the breakout session "Open Hardware in Voice Telecommunications" and there I will present Fairwaves project to create an open hardware transceiver for OpenBTS. Someone may recall I proposed similar project about 1.5 years ago, but then abandoned due to lack of interest from the community. Now it was revived on a new level, thanks to financial and motivational support from Jean-Samuel Najnudel of BJT Partners SARL. As an experiment this project will be completely open-sourced in an open-source hardware way. Project is in active development, so just to give you an idea of what we're aiming: * Targeted for rural installations. * CAPEX and OPEX optimized. * 2 TRX per sector. Each TRX connected to its own antenna with its own saturated (=cheap) power amplifier on Tx side. On Rx side both antennas are used to provide diversity receive. * Reference clock synchronized to GPS for accurate timing. * Based on USRP N200, but with Xilinx Spartan 6 and LimeMicro LMS6002D. Which means it's actually design is much more capable then just GSM. More details, web-site, schematics, etc will be available after OHS. First samples of the hardware we hope to have at the end of this year. If you're going to OHS - come to our breakout session to discuss the project and share your ideas! -- Regards, Alexander Chemeris.

4 5

[PATCH/RFC 0/2] libosmo-abis ctrl related fixes
by Daniel Willmann 19 Sep '11

19 Sep '11

Hello, attached are two patches I came across while looking at the pablo/ctrl-updates branch in OpenBSC. The first one is just a bugfix for a resource leak and the second one adds a possibility to register a callback that will notify you if the connection is lost. This is needed for the control interface as we'll need to clean up some ctrlif related things if a connection is lost. Be aware that I haven't tested this with the ctrl-updates branch since this doesn't compile yet. I did test that master still compiles and osmo-bsc/nat don't segfault on start (though openbsc doesn't seem to use ipa_server_conn at the moment). The e1inp_ipa_{bsc,bts}_test worked as well. Regards, Daniel Willmann (2): ipa: Fix resource leak if we encounter an error in ipa_server_conn_read ipa: Add a callback to detect if the server_conn was closed include/osmocom/abis/ipa.h | 3 ++- src/input/ipa.c | 6 +++++- src/ipa_proxy.c | 2 +- 3 files changed, 8 insertions(+), 3 deletions(-) -- 1.7.6.1

4 7

bug in A-bis OML wireshark dissector
by Pablo Neira Ayuso 19 Sep '11

19 Sep '11

Hi! While submitting the A-bis OML wireshark dissector I noticed one bug in it that results in bogus message labeling. The following patch should be applied to osmocom/wireshark.git tree. P.S: I have submitted a patch to wireshark bugzilla that includes this bugfix.

1 0

anyone give me a hint to implement L1 for openbsc
by John Wu 16 Sep '11

16 Sep '11

Hi list, I want to implement a L1 hardware and software for openbsc. But I am not familiar with openbsc framework. I saw there is a project named osmo-nitb which is a standalone application that implement L2 L3 and some other gsm network function. If I can using my L1 software connect to osmo-nitb through abis-overip? Also I notice another project osmo-bts project which implement BTS-side Layer3 and Layer2 protocol. So can I just implement BTS side L1 then combine with osmo-bts which connect to osmo-nitb? Regards!

4 9

[PATCH 0/5] pablo/ctrl-updates related patches
by Daniel Willmann 15 Sep '11

15 Sep '11

Hello Pablo, attached are patches against the current pablo/ctrl-updates branch that fix the compile issues. It needs the closed callback in libosmo-abis to work. As long as the bsc_msc_connection is still using write_queues I have added the old ctrl_cmd_send function again (under a different name) So we can still send commands over that connection. I've tested the communication/timeout/closed_cb handling and nothing problematic showed up. Having two send commands is unfortunate, but I guess it's okay for the time being. I'm guessing that the other connections will be switching to libosmo-abis as well in the foreseeable future and then this issue will resolve itself. Feel free to squash the patches as you see fit in order to get them merged. Regards, Daniel Willmann (5): libctrl: Catch up with API change for ipa_server_conn_create nat: Use libosmo-abis infrastructure in the pending entries libctrl: Add a new function to send commands through an osmo_wqueue osmo-bsc: Use ctrl_cmd_send_wqueue to send cmds over the nat-bsc link nat: Use ctrl_cmd_send_wqueue to send cmds over the nat-bsc link openbsc/include/openbsc/bsc_nat.h | 2 +- openbsc/include/openbsc/control_cmd.h | 1 + openbsc/src/libctrl/control_if.c | 24 +++++++++++++++++++++++- openbsc/src/osmo-bsc/osmo_bsc_msc.c | 4 ++-- openbsc/src/osmo-bsc_nat/bsc_nat.c | 19 ++++++++++--------- 5 files changed, 37 insertions(+), 13 deletions(-) -- 1.7.6.1

2 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC