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
From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
Hi!
This patch reworks the timer insfrastructure of libosmocore to
make it more scalable. I remember some discussion with Harald while
I was in Berlin that this can be of interest.
It also reworks the timer torture test, the current list-based
timer seems to have problem with it.
You can find this changes in the pablo/timer branch.
Pablo Neira Ayuso (3):
add rb-tree implementation to libosmocore
timer: add scalable RB-tree based timer infrastructure
tests: add new torture test for timer infrastructure
include/osmocom/core/Makefile.am | 2 +-
include/osmocom/core/linuxrbtree.h | 160 +++++++++++++++
include/osmocom/core/timer.h | 6 +-
src/Makefile.am | 2 +-
src/rbtree.c | 389 ++++++++++++++++++++++++++++++++++++
src/timer.c | 176 +++++++++--------
tests/timer/timer_test.c | 141 ++++++++++---
7 files changed, 757 insertions(+), 119 deletions(-)
create mode 100644 include/osmocom/core/linuxrbtree.h
create mode 100644 src/rbtree.c
--
1.7.2.5
Hello all,
Looking for ideas. I have a NanoBTS Model 140 which doesn't seem to
work with GPRS. It never connects to the SGSN. The openbsc/sgsn
environment is ok - I can swap in another nano and it works fine.
I've taken some log captures:
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