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]
_______________________
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...
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.
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)
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.
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
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.
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!
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
Dear All,
I have a question regarding the SLS in M3UA, is the sls number mapped to the sctp stream id?
for example, lets consider that i have sctp association with two stream id, 1 and 2, can i send m3ua message with sls 0 mapped to sctp stread id 1, and another m3ua message with sls1 mapped to sctp stream id 2. is this correct? if not can you please help digest this issue :).
Appreciate your help,
Ammar
