From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
This patchset is the first in the series to cleanup redundant code
in ipaccess tools.
They are available in the pablo/cleanups branch in openbsc git tree.
Please, merge it!
Thanks.
Pablo Neira Ayuso (3):
ipaccess-config: exit if no network interface is specified
libcommon: socket: extend make_sock() prototype
ipaccess-proxy: get rid of internal make_sock() implementation
openbsc/include/openbsc/socket.h | 5 ++-
openbsc/src/ipaccess/ipaccess-find.c | 1 +
openbsc/src/ipaccess/ipaccess-proxy.c | 42 ++------------------------------
openbsc/src/libabis/input/hsl.c | 4 +-
openbsc/src/libabis/input/ipaccess.c | 8 +++---
openbsc/src/libcommon/socket.c | 10 ++++---
openbsc/src/libgb/gprs_ns.c | 2 +-
openbsc/src/libgb/gprs_ns_frgre.c | 2 +-
openbsc/src/osmo-bsc_nat/bsc_ussd.c | 2 +-
9 files changed, 22 insertions(+), 54 deletions(-)
--
1.7.2.3
Hi all,
A thread on the asterisk mailing list re-triggerd my memory.
Last november or so i asked if it might be possible to use a
gsm/umts-dongle as a bts. afaicr the general consensus was that it was
not possible because the proximity of TX and RX hardware.
I have been discussing it with my colleges today and wonder where we
were making the obvious thinking-mistake...
1) i know, that certainly at higher powers, the receiver becomes deaf in
the vincinity of a (high powered) transmitter, due to cirtuit overload,
but in our case we only needs a single miliwatt or even less....
2) scanning for multiple devices/frequencies is not needed.
[the idea is to connect to a single hand-held-device, that is only one
meter away, and feed voice through an existing IP-connection]
3) if a dongle is not usable for above reasons as a BTS, why is that
same dongle (more-or-less) capable as working as a handheld? Same
problems should occur as such, not?
http://wiki.e1550.mobi/doku.php
If they can tap in the device for audio/sms-client, it should also be
possible to do it the other way round, as a single-thread bts....
still puzzled, Hans
Hi, list!
I'm trying to understand how the options "nominal power" and
"max_power_red" work...
Last Friday I tried to place 4 BTS in a rectangle of about 100x20 meter
and then I examined the measurement reports of a mobile. They are very
very bad, and oft it cannot see a cell.
Then I tried to change the value of "nominal power" (max_power_red did
not changed) and retry to check the measurement reports.
No changes... :(
Now I'm here in my office with a spectrum analyzer and try to change
these values, but what I see in the spectrum analyzer is always the
same...
I restart OpenBSC after any change, of course!
Could you please help me to understand what these values mean and how
can I boost the signal?
Thanks a lot in advance for your help!
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 23
Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12
_______________________________________________________________________
Impressum:
NETZING Solutions AG - Fröbelstraße 57 - 01159 Dresden
Sitz der Gesellschaft Amtsgericht Dresden HRB 18926
Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz
USt.Id DE211326547 Mail: netzing.ag(a)netzing.de
Hi List
I want to use OpenBSC with Asterisk and LCR.
After a lot of reading I found out that openbsc must start with the
Paramters "-m" and "-P".
But i got a lot error messages like:
<0006> gsm_04_08.c:2960 receive message GSM_TCH_FRAME
<0006> gsm_04_08.c:2992 TCH frame to lchan without RTP connection
So i tried a lot and start only with -P and the RTP-Proxy started. But
LCR and Asterisk sure not involved because the missing "-m". So i need
"-m".
It is a bug or a feature that "-P" will be ignored if I set "-m"?
I´m sitting over the bsc code but until this moment I didnt found
something so I hope somebody here can help.
Ulrich Meckel
Hi, list!
We are trying to connect OpenBSC and Asterisk together (through LCR),
but we have many problems.
We start OpenBSC with the parameters -P -m
--debug=DRLL:DCC:DMM:DRR:DRSL:DMNCC:DMSC:DNM:DLCH:DMUX:DHO
Now, if we try to call a mobile phone from another one, we get many
errors:
<0006> gsm_04_08.c:2960 receive message GSM_TCH_FRAME
<0006> gsm_04_08.c:2992 TCH frame to lchan without RTP connection
Now, if I understand what mncc_tx_to_cc does, I can just think, that
the RTP-Proxy is NOT active, but a part of OpenBSC thinks that it IS
active.
Another interesting problem is, that, although we start OpenBSC to
debug the CC, we do NOT get a message like:
Setting up TCH map between ...
(gsm_04_08.c line 1606)
Could someone confirm me my idea? And, maybe, give me a suggestion to
fix our problem?
We use OpenBSC in the version 0.9.11.375-ca8f.
Thanks a lot in advance for your help
Luca Bertoncello
--
_______________________________________________________________________
Luca Bertoncello
Entwicklung Mail: bertoncello(a)netzing.de
NETZING Solutions AG Tel.: 0351/41381 - 23
Fröbelstr. 57, 01159 Dresden Fax: 0351/41381 - 12
_______________________________________________________________________
Impressum:
NETZING Solutions AG - Fröbelstraße 57 - 01159 Dresden
Sitz der Gesellschaft Amtsgericht Dresden HRB 18926
Vorstand Dieter Schneider - Aufsichtsratsvorsitzender Volker Kanitz
USt.Id DE211326547 Mail: netzing.ag(a)netzing.de
From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
This patchset includes several cleanups previous to another patchset
that will contain the namespace pollution fix (to appear soon).
They're available in the branch pablo/cleanups in libosmocore.
Please merge it.
Pablo Neira Ayuso (4):
bitvec: add bitvec_find_first_bit_pos() from gsm/rxlev_stat.c
write_queue: use full path of includes in osmocom/core/write_queue.h
vty: move vty_out_rate_ctr_group prototype to osmocom/vty/misc.h
utils: move OSMO_SNPRINT_RET() macro definition to
osmocom/core/utils.h
include/osmocom/core/bitvec.h | 2 ++
include/osmocom/core/rate_ctr.h | 3 ---
include/osmocom/core/utils.h | 9 +++++++++
include/osmocom/core/write_queue.h | 4 ++--
include/osmocom/vty/Makefile.am | 2 +-
include/osmocom/vty/misc.h | 10 ++++++++++
src/bitvec.c | 14 ++++++++++++++
src/gsm/rxlev_stat.c | 12 ------------
src/logging.c | 26 ++++++++------------------
9 files changed, 46 insertions(+), 36 deletions(-)
create mode 100644 include/osmocom/vty/misc.h
--
1.7.2.3
From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
This patch is a RFC, I can add the prefix osmocom_ to all functions
in libosmocore to fix with the existing namespace pollution.
This task was proposed by Harald.
Let me know if you are OK with this approach and I'll send a
patchset along this week.
---
include/osmocom/core/backtrace.h | 2 +-
src/backtrace.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/osmocom/core/backtrace.h b/include/osmocom/core/backtrace.h
index bbbb2c2..7c248aa 100644
--- a/include/osmocom/core/backtrace.h
+++ b/include/osmocom/core/backtrace.h
@@ -1,6 +1,6 @@
#ifndef _OSMO_BACKTRACE_H_
#define _OSMO_BACKTRACE_H_
-void generate_backtrace();
+void osmocom_generate_backtrace();
#endif
diff --git a/src/backtrace.c b/src/backtrace.c
index ecd6b9c..5c609bb 100644
--- a/src/backtrace.c
+++ b/src/backtrace.c
@@ -29,7 +29,7 @@
#ifdef HAVE_EXECINFO_H
#include <execinfo.h>
-void generate_backtrace()
+void osmocom_generate_backtrace()
{
int i, nptrs;
void *buffer[100];
--
1.7.2.3
From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
Minor change in openBSC due to new osmocom/vty/misc.h file that was
added in the patchset entitled:
libosmocore: several cleanups
It's available in pablo/cleanups branch in openbsc git tree.
Please, merge it.
Pablo Neira Ayuso (1):
src: include new file osmocom/vty/misc.h for vty_out_rate_ctr_group()
openbsc/src/gprs/sgsn_vty.c | 1 +
openbsc/src/libgb/gprs_bssgp_vty.c | 1 +
openbsc/src/libgb/gprs_ns_vty.c | 1 +
openbsc/src/osmo-bsc_nat/bsc_nat_vty.c | 1 +
4 files changed, 4 insertions(+), 0 deletions(-)
--
1.7.2.3