Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Dear List,
I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit.
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit.
SMS and GPRS seems to be fine.
If someone have any idea, I would love to hear it. :-)
Thanks!
Csaba
Hi all,
This patch set adds to libosmocore an optimized Viterbi decodeer for
architecture specific (Intel SSE) and non-specific cases. The
implementation covers codes with constraint lengths of K=5 and K=7 and
rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup
from the current implementation is in the range of 5 to 20 depending on
the processor and code type. API is unchanged.
Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes
from osmo-bts are included. Further tests for AWGN bit-error-rate
and benchmarks can be found in the following repository.
https://github.com/ttsou/osmo-conv-test
Here are some examples.
Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts.
$ ./conv_test -c 2 -e -r 5 -i 100000
=================================================
[+] Testing: GPRS CS2
[.] Specs: (N=2, K=5, non-recursive, flushed, not punctured)
[.] Input length : ret = 290 exp = 290 -> OK
[.] Output length : ret = 588 exp = 588 -> OK
[.] BER tests:
[..] Testing base:
[..] Input BER.......................... 0.042443
[..] Output BER......................... 0.000006
[..] Output FER......................... 0.001350 (135)
[..] Testing SIMD:
[..] Input BER.......................... 0.042460
[..] Output BER......................... 0.000005
[..] Output FER......................... 0.001240 (124)
Timed AFS benchmark with 8 threads and 100000 bursts per thread.
$ ./conv_test -b -c 10 -j 8 -i 100000
=================================================
[+] Testing: GSM TCH/AFS 6.7
[.] Specs: (N=4, K=5, recursive, flushed, punctured)
[.] Input length : ret = 140 exp = 140 -> OK
[.] Output length : ret = 448 exp = 448 -> OK
[.] Performance benchmark:
[..] Encoding / Decoding 800000 bursts on 8 thread(s):
[..] Testing base:
[..] Elapsed time....................... 4.320001 secs
[..] Rate............................... 25.925920 Mbps
[..] Testing SIMD:
[..] Elapsed time....................... 0.458272 secs
[..] Rate............................... 244.396341 Mbps
[..] Speedup............................ 9.426718
-TT
Dear all,
I suggest to change a stock Redmine theme to something more beautiful,
for example gitmike: https://github.com/makotokw/redmine-theme-gitmike
which used by srlabs.de and looks like pretty. Furthermore, the Osmocom
logo will look better on light background.
Opinions?
С наилучшими пожеланиями,
Яницкий Вадим.
Hi,
Is it possible to have the virtual BTS start a location update at a specific time. In other words, can I add a command that asks all phones to request a location update at any desired time ?
Best regards,
Robert,
Hi list,
I've just seen my first Location Update Accept from our UMTS UE+femtoCell
using osmo-cscn as IuCS network core :D
The Identity Request (IMSI) that the UE used to not answer is now being
answered, and I am getting a successful Location Update Accept from
osmo-cscn after that.
The reason why it didn't work last time isn't entirely clear. All I
changed since is the *test* program that simulates the UE+hNodeB, and I
merely verified that osmo-cscn works (as far as LU is concerned).
A hint is, Daniel told me that the IuPS setup had one day stopped to reply
with a message that used to work before, and has since again started
working. So it might've been a timing issue in the reply towards UE.
Next steps:
Next I will briefly try to run Daniel's 3G SGSN together with CSCN to see
whether the premature Iu Release (?) he sees still happens when CS is
connected successfully.
There is also still a segfault in osmo-hnbgw, triggered by reconnecting a
second time with our hnb-test that simulates an hNodeB. That's next on the
hacking todo list.
According to the specs, proper Authentication is mandatory for UMTS, which
osmo-cscn should initiate. That's not happening yet. It seems our testing
UE is fine with that, so I'll see when I'll get to that.
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi list,
I just thought I had fixed gsm_7bit_decode_n(), since its API doc says
* \param length The length of the input sequence (in octets).
int gsm_7bit_decode_n([...], uint8_t length);
but the implementation is
int gsm_7bit_decode_n([...], uint8_t septet_l)
and indeed the length parameter is handled as septet length. So, logically, I
came up with this patch:
diff --git a/src/gsm/gsm_utils.c b/src/gsm/gsm_utils.c
index e8e452f..a9afc1a 100644
--- a/src/gsm/gsm_utils.c
+++ b/src/gsm/gsm_utils.c
@@ -184,8 +184,9 @@
return text - text_buf_begin;
}
-int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t septet_l)
+int gsm_7bit_decode_n(char *text, size_t n, const uint8_t *user_data, uint8_t octet_l)
{
+ uint8_t septet_l = ((uint16_t)octet_l * 8) / 7;
return gsm_7bit_decode_n_hdr(text, n, user_data, septet_l, 0);
}
(the cast to uint16_t makes 100% sure the calculation isn't truncated to
uint8_t after the *8 multiplication -- I picked this up while hacking on 8bit
microcontrollers. That truncation doesn't really happen on our 32bit/64bit
machines, but if it did, the length would effectively be limited to 255/8 == 31
characters.)
Then I noticed that callers actually do *8/7 before calling the function:
parse_process_uss_req():
num_chars = (uss_req_data[6] * 8) / 7;
/* Prevent a mobile-originated buffer-overrun! */
if (num_chars > MAX_LEN_USSD_STRING)
num_chars = MAX_LEN_USSD_STRING;
gsm_7bit_decode_n_ussd((char *)req->ussd_text,
sizeof(req->ussd_text),
&(uss_req_data[7]), num_chars);
(This is gsm_7bit_decode_n_ussd(), its API doc says "see gsm_7bit_decode_n()")
So we have the API talking about length "in octets" while the implementation
clearly employs septet length.
Fixing the implementation to match the API doc would break binary
compatibility. I should probably fix the API doc to match that weird
implementation, but it nags and hurts a little.
Any opinions?
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi,
I am looking into building a very simple MNCC to SIP bridge to be used with the NITB (and later the CSCN). This will be based on what was learned from adding the RTP bridge which means the audio will not flow through the bridge (eventually later there will be a UDP proxy for NAT traversal)
The primary design points are:
* Being able to select TCH/F or TCH/H
* Decide on the codec very late
* Support for AMR parameters through MNCC
I just look at MO and MT Call establishment from a high-level point of view:
MO-Call:
* NITB will send the SETUP indication
* MNCC GW will do screening and decide if to proceed
* MNCC GW will make TCH/F or TCH/H decision and ask for a source IP, source port
* Based on bearer caps (to be handled by MNCC GW?) and TCH/F, TCH/H MNCC GW can offer a SDP file with multiple codecs to the PBX.
...
* PBX will decide on a codec (ringing or 200 connect)
* MNCC GW will ask NITB to reconfigure and audio will flow
* (TODO: check ringtone, check default, check codec change)
MT-Call:
* MNCC GW will be presented with a list of codecs already
* Depending on that TCH/F or TCH/H can/must be chosen (e.g. for AMR even the codec rate can be in the SDP file that decides which TCH/F or TCH/H to use)
* Can decide bearer caps once paging has succeeded and call is progressing
* Sets audio codec and waits for call to connect
Handover support:
* IP/port (and then SSRC and timestamp in RTP) will change
* MNCC GW could try SIP re-invite with changed parameters
* MMCC GW could hope PBX implements RTP annex and re-learns the connection
Do you have comments or remarks? The above will lead to a version update, probably a dedicated assignment command in MNCC, and separating socket creation and codec change. Anyone wants to have a go at that?
have a nice weekend
holger
Dear all,
IN-Berlin has confirmed the dates in April where we could book the
venue.
Can those eligible + interested in attending please quickly indicate
their preference at http://doodle.com/poll/if263cpxieavsqiq ?
Thanks!
Disclaimer: OsmoDevCon is an invitation-only event for developers with
proven history of contributing to any of the Osmocom projects. The fact
that there is a public poll about the scheduling of the event and/or
your participation in that poll does not mean a particular applicant is
invited.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
Dear all,
I've gone through the high-level list of change areas / projects from
Rel-4 through Rel-14 and collected a list of those parts that seemed
like they could be interesting from an Osmocom point of view.
In case you're curious and enjoy reading 3GPP docs as much as I do,
feel free to check out
http://projects.osmocom.org/projects/cellular-infrastructure/wiki/Interesti…
Some parts were just recently mentioned, like Extended Uplink TBF,
Network Assisted Cell Change, MNCC-SIP interface, Local Call Local
Switch. We also already knew about the "Real" A-over-IP specification
(different from the SCCPlite A interface that OsmoBSC implements), and
A5/4.
There's quite some other interesting bits and pieces, such as for
example the feasibility study on GSM/EDGE BTS power saving, where they
propose (it's not accepted yet) to reduce the transmit power on the
BCCH-carrying TRX at certain points in the time multiplex.
Enjoy,
Harald
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
I'm having a trouble when using pySIM to change the authentication
algorithm in a USIM-SJS1 card. Basically I want disable the 3G authentication
on the card, and only use 2G authentication regardless of the network type.
Anyway, here's my procedure.
In the beginning, I didn't realize there's a zecke/tmp2 branch. So i
modified the the cards.py by myself. I added
data, sw = self._scc.update_binary('6F00', '03')
in the this line
http://cgit.osmocom.org/pysim/tree/pySim/cards.py?h=master#n461
I learned the values '6F00' and '03' from this osmocom webpage
<https://openbsc.osmocom.org/trac/wiki/sysmoUSIM-SJS1>.
One thing to mention that is I also commented out the self._scc.verify_chv()
and update KI/IMSI statements in above. Because it always fails in the
self._scc.verify_chv() step (apdu response 69xx), though I provided the
adm-1 key in the CLI.
After it's done, unfortunately I found that when use ./pySim-read.py to
read SIM again, it fails with apdu response 6b00. Also, the attempt to
updating authentication algorithm didn't work when test in the phone.
Did I already mess up this SIM card at this point?
Then, I found there's a zecke/tmp2 branch. Tried it. Still not working
either in reading (apdu response 6b00); or writing (still ails
in self._scc.verify_chv() with apdu response 6983)
Please give suggestion on what I should do.
Thank you.
Hi all,
several years ago at an OsmoDevCon, we decided to rename the PCU
mailinglist into osmocom-net-grps to expand it to cover all parts of the
GPRS/packet-switched systm, and then continue to discuss
circuit-switched stuff in openbsc.
Over the years it seems the list was more and more forgotten, and all
patches were posted here. I would like to propose to move all GPRS / PS
related discussion to the osmo-net-gprs mailing list again.
Now you can argue that osmo-sgsn, osmo-gbproxy and gtphub are all built
inside the openbsc repository. The presence of osmo-sgsn, osmo-gbproxy
etc. inside one single OpenBSC git reposiory is a historic legacy, and
one that I'm not very proud of. Rather than having more of that
overlap/confusion we should probably aim for less and more separation.
However, let's wait for the Iu-CS / Iu-PS integration and osmo-cscn
(nitb without integrated bsc) first, and then look at how to lay out the
source code repositories.
Meanwhile, let's please aim at discussing GPRS related topics + patches
(particularly PCU bits) on the osmocom-net-gprs list. Thanks for your
attention!
I think there are a lot of people on the openbsc lists who are primarily
interested in OsmoNITB and who are not neccessarily interested in the
low-level-bits of the GPRS/EGPRS RLC/MAC layers ....
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)
This is just to say that all my currently waiting patch sets have been
merged to the respective master branches, after due nitpicking by Holger
in person (thanks!) with various style/simplicity modifications applied.
(The one still open is the int/void* thing, not intended as a patch anyway but
more as a question.)
So the road is clear now for configuring osmo-nitb with its entire set of
own IP addresses, and as a side effect various other osmo-programs also
have configurable telnet-VTY, Ctrl-interface and Abis addresses now.
To summarize the final result:
(1) Abis/IP
e1_input
ipa bind 10.9.8.7
(2) telnet VTY
line vty
bind 10.9.8.7
(3) ctrl interface
ctrl
bind 10.9.8.7
(4) MNCC unix domain socket
-M /path/to/socket/file
(5) SMPP SMSC
smpp
local-tcp-ip 10.9.8.7 2775
Is this worth a Wiki entry?
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi all,
new year, new approaches. In December I was tasked to think about a
real SMSC with SMPP input and SS7 output (or SMPP in the future) and
I wrote down my ideas[1] about data storage, approach, how to achieve
scaling. What is missing fail-over but there are some ideas for this
as well.
The implementation will be done using Pharo and at least the first
data storage will use mongodb >= 3.2. In the past my Pharo work has not
been hosted in git but for this project it will change and maybe it
creates some more visibility, historically documentation and debian
packages were not too visible but that will be different this time
as well.
If you are interested in specification, Smalltalk, testing, load testing,
SS7 or such please join me in the development.
happy hacking
holger
[1] https://github.com/zecke/osmo-smsc/blob/master/README.asciidoc it
will move to git.osmocom.org but I just wanted to have online asciidoc
rendering.
This may seem like overkill for a mere const char * config item, but it makes
the Control interface VTY commands reusable in any main() scope (inspired by
libosmo-abis' VTY config).
Add API functions ctrl_vty_init() and ctrl_vty_get_bind_addr(), in new files
src/ctrl/control_vty.c and include/osmocom/ctrl/control_vty.h, compiled and/or
installed dependent on ENABLE_VTY.
Using these functions allows configuring a static const char* with the VTY
commands
ctrl
bind A.B.C.D
which callers shall subsequently use to bind the Control interface to a
specific local interface address, by passing the return value of
ctrl_vty_get_bind_addr() to control_interface_setup().
Add CTRL_NODE to enum node_type, "eating" RESERVED4_NODE to heed that comment
on avoiding ABI changes.
---
include/Makefile.am | 3 +-
include/osmocom/ctrl/control_vty.h | 9 ++++
include/osmocom/vty/command.h | 3 +-
src/ctrl/Makefile.am | 4 ++
src/ctrl/control_vty.c | 90 ++++++++++++++++++++++++++++++++++++++
5 files changed, 107 insertions(+), 2 deletions(-)
create mode 100644 include/osmocom/ctrl/control_vty.h
create mode 100644 src/ctrl/control_vty.c
diff --git a/include/Makefile.am b/include/Makefile.am
index a965fb9..ac22ee6 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -117,7 +117,8 @@ nobase_include_HEADERS += \
osmocom/vty/telnet_interface.h \
osmocom/vty/vector.h \
osmocom/vty/vty.h \
- osmocom/vty/ports.h
+ osmocom/vty/ports.h \
+ osmocom/ctrl/control_vty.h
endif
noinst_HEADERS = \
diff --git a/include/osmocom/ctrl/control_vty.h b/include/osmocom/ctrl/control_vty.h
new file mode 100644
index 0000000..d0ef69f
--- /dev/null
+++ b/include/osmocom/ctrl/control_vty.h
@@ -0,0 +1,9 @@
+#pragma once
+
+/* Add the 'ctrl' section to VTY, containing the 'bind' command. */
+int ctrl_vty_init(void *ctx);
+
+/* Obtain the IP address configured by the 'ctrl'/'bind A.B.C.D' VTY command.
+ * This should be fed to ctrl_interface_setup() once the configuration has been
+ * read. */
+const char *ctrl_vty_get_bind_addr(void);
diff --git a/include/osmocom/vty/command.h b/include/osmocom/vty/command.h
index 2078e1b..937d2f8 100644
--- a/include/osmocom/vty/command.h
+++ b/include/osmocom/vty/command.h
@@ -84,6 +84,8 @@ enum node_type {
L_NS_NODE, /*!< \brief NS node in libosmo-gb. */
L_BSSGP_NODE, /*!< \brief BSSGP node in libosmo-gb. */
+ CTRL_NODE, /*!< \brief Control interface node. */
+
/*
* When adding new nodes to the libosmocore project, these nodes can be
* used to avoid ABI changes for unrelated projects.
@@ -91,7 +93,6 @@ enum node_type {
RESERVED1_NODE, /*!< \brief Reserved for later extensions */
RESERVED2_NODE, /*!< \brief Reserved for later extensions */
RESERVED3_NODE, /*!< \brief Reserved for later extensions */
- RESERVED4_NODE, /*!< \brief Reserved for later extensions */
_LAST_OSMOVTY_NODE
};
diff --git a/src/ctrl/Makefile.am b/src/ctrl/Makefile.am
index e6ccafb..b4a3da4 100644
--- a/src/ctrl/Makefile.am
+++ b/src/ctrl/Makefile.am
@@ -13,3 +13,7 @@ libosmoctrl_la_LIBADD = \
$(top_builddir)/src/libosmocore.la \
$(top_builddir)/src/gsm/libosmogsm.la \
$(top_builddir)/src/vty/libosmovty.la
+
+if ENABLE_VTY
+libosmoctrl_la_SOURCES += control_vty.c
+endif
diff --git a/src/ctrl/control_vty.c b/src/ctrl/control_vty.c
new file mode 100644
index 0000000..7df53b8
--- /dev/null
+++ b/src/ctrl/control_vty.c
@@ -0,0 +1,90 @@
+/* VTY configuration for Control interface
+ *
+ * (C) 2016 by sysmocom s.m.f.c GmbH <info(a)sysmocom.de>
+ *
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include <stdlib.h>
+#include <talloc.h>
+#include <osmocom/ctrl/control_vty.h>
+#include <osmocom/vty/command.h>
+
+static void *ctrl_vty_ctx = NULL;
+static const char *ctrl_vty_bind_addr = NULL;
+
+DEFUN(cfg_ctrl_bind_addr,
+ cfg_ctrl_bind_addr_cmd,
+ "bind A.B.C.D",
+ "Set bind address to listen for Control connections\n"
+ "Local IP address (default 127.0.0.1)\n")
+{
+ if (ctrl_vty_bind_addr) {
+ talloc_free((void*)ctrl_vty_bind_addr);
+ ctrl_vty_bind_addr = NULL;
+ }
+ ctrl_vty_bind_addr = talloc_strdup(ctrl_vty_ctx, argv[0]);
+ return CMD_SUCCESS;
+}
+
+const char *ctrl_vty_get_bind_addr(void)
+{
+ if (!ctrl_vty_bind_addr)
+ return "127.0.0.1";
+ return ctrl_vty_bind_addr;
+}
+
+struct cmd_node ctrl_node = {
+ CTRL_NODE,
+ "%s(config-ctrl)# ",
+ 1,
+};
+
+DEFUN(cfg_ctrl,
+ cfg_ctrl_cmd,
+ "ctrl", "Configure the Control Interface")
+{
+ vty->index = NULL;
+ vty->node = CTRL_NODE;
+
+ return CMD_SUCCESS;
+}
+
+static int config_write_ctrl(struct vty *vty)
+{
+ /* So far there's only one element. Omit the entire section if the bind
+ * element is omitted. */
+ if (!ctrl_vty_bind_addr)
+ return CMD_SUCCESS;
+
+ vty_out(vty, "ctrl%s", VTY_NEWLINE);
+ vty_out(vty, " bind %s%s", ctrl_vty_bind_addr, VTY_NEWLINE);
+
+ return CMD_SUCCESS;
+}
+
+int ctrl_vty_init(void *ctx)
+{
+ ctrl_vty_ctx = ctx;
+ install_element(CONFIG_NODE, &cfg_ctrl_cmd);
+ install_node(&ctrl_node, config_write_ctrl);
+
+ install_element(CTRL_NODE, &cfg_ctrl_bind_addr_cmd);
+ return 0;
+}
+
--
2.1.4
These patches eradicate some of the easier-to-fix compiler warnings I keep
seeing in almost every dev cycle. I'd be glad to have them on master.
One of them is an actual error, ignoring return values.
Neels Hofmeyr (3):
bsc_nat: fail if VTY telnet port cannot be bound, clarify comment
ipaccess_rcvmsg: fix returncode, add partial write warning
gsm340_rx_tpdu: comment-out two unused vars
openbsc/src/ipaccess/ipaccess-proxy.c | 8 +++++++-
openbsc/src/libmsc/gsm_04_11.c | 7 +++++--
openbsc/src/osmo-bsc_nat/bsc_nat.c | 7 +++++--
3 files changed, 17 insertions(+), 5 deletions(-)
--
2.1.4
This time SMPP is included. Here is the abridged complete overview:
Following the previous patch sets for libosmo-abis and libosmocore, this patch
set allows configuring ALL of osmo-nitb's local IP addresses and makes it
possible to run several osmo-nitb processes alongside each other.
(1) Abis/IP (from the libosmo-abis patch)
In the config file, have:
e1_input
ipa bind 10.9.8.7
(2) telnet VTY (prepared by libosmocore patch set)
In the config file, have:
line vty
bind 10.9.8.7
(3) ctrl interface (prepared by libosmocore patch set)
In the config file, have:
ctrl
bind 10.9.8.7
(4) MNCC socket
In addition to the old -m option with a fixed socket path, you may now
supply a cmdline argument with explicit path:
-M /path/to/socket/file
(5) SMPP SMSC
In the config file, have:
smpp
local-tcp 10.9.8.7 2775
Neels Hofmeyr (6):
enable telnet VTY bind address config for various programs
osmo-nitb: add -M to pass specific MNCC socket path
osmo-nitb: cosmetic: rename to rf_ctrl_path, following mncc_sock_path
osmo-nitb: be strict about cmdline args
enable ctrl bind config for various programs
smpp: refactor initialization, add bind address
openbsc/include/openbsc/bsc_nat.h | 3 +-
openbsc/include/openbsc/ctrl.h | 3 +-
openbsc/include/openbsc/gprs_sgsn.h | 3 +-
openbsc/include/openbsc/mncc.h | 2 +-
openbsc/include/openbsc/smpp.h | 4 +-
openbsc/src/gprs/gb_proxy_main.c | 12 +++--
openbsc/src/gprs/gtphub_main.c | 11 ++--
openbsc/src/gprs/sgsn_ctrl.c | 5 +-
openbsc/src/gprs/sgsn_main.c | 42 ++++++++++-----
openbsc/src/libbsc/bsc_ctrl_lookup.c | 6 ++-
openbsc/src/libbsc/bsc_init.c | 6 ++-
openbsc/src/libmsc/mncc_sock.c | 9 ++--
openbsc/src/libmsc/smpp_openbsc.c | 43 +++++++++------
openbsc/src/libmsc/smpp_smsc.c | 93 ++++++++++++++++++++++++---------
openbsc/src/libmsc/smpp_smsc.h | 7 ++-
openbsc/src/libmsc/smpp_vty.c | 75 +++++++++++++++++++++-----
openbsc/src/osmo-bsc/osmo_bsc_main.c | 10 +++-
openbsc/src/osmo-bsc_mgcp/mgcp_main.c | 6 ++-
openbsc/src/osmo-bsc_nat/bsc_nat.c | 22 ++++++--
openbsc/src/osmo-bsc_nat/bsc_nat_ctrl.c | 5 +-
openbsc/src/osmo-nitb/bsc_hack.c | 43 ++++++++++-----
21 files changed, 298 insertions(+), 112 deletions(-)
--
2.1.4
Following the previous patch sets for libosmo-abis and libosmocore, this patch
set allows configuring almost all of the osmo-nitb IP addresses. The goal is to
allow several osmo-nitb processes to run alongside each other.
(1) Abis/IP (from the libosmo-abis patch)
in the config file, have:
e1_input
ipa bind 10.9.8.7
(2) telnet VTY (prepared by libosmocore patch set)
in the config file, have:
line vty
bind 127.0.0.99
(3) ctrl interface (prepared by libosmocore patch set)
in the config file, have:
ctrl
bind 127.0.0.99
(4) MNCC socket
In addition to the old -m option with a fixed socket path, you may now
supply a cmdline argument with explicit path:
-M /path/to/socket/file
(5) still TODO: SMPP SMSC
libsmpp34 is still listening on 0.0.0.0:2775, requires a change in libsmpp34.
Will follow in a subsequent patch.
Neels Hofmeyr (6):
enable telnet VTY bind address config for various programs
osmo-nitb: add -M to pass specific MNCC socket path
osmo-nitb: cosmetic: rename to rf_ctrl_path, following mncc_sock_path
osmo-nitb: be strict about cmdline args
enable ctrl bind config for various programs
bsc_nat: fail if VTY telnet port cannot be bound
openbsc/include/openbsc/bsc_nat.h | 3 ++-
openbsc/include/openbsc/ctrl.h | 3 ++-
openbsc/include/openbsc/gprs_sgsn.h | 3 ++-
openbsc/include/openbsc/mncc.h | 2 +-
openbsc/src/gprs/gb_proxy_main.c | 12 ++++++----
openbsc/src/gprs/gtphub_main.c | 11 ++++++---
openbsc/src/gprs/sgsn_ctrl.c | 5 ++--
openbsc/src/gprs/sgsn_main.c | 42 ++++++++++++++++++++++-----------
openbsc/src/libbsc/bsc_ctrl_lookup.c | 6 +++--
openbsc/src/libbsc/bsc_init.c | 6 ++++-
openbsc/src/libmsc/mncc_sock.c | 9 +++----
openbsc/src/osmo-bsc/osmo_bsc_main.c | 10 +++++++-
openbsc/src/osmo-bsc_mgcp/mgcp_main.c | 6 ++++-
openbsc/src/osmo-bsc_nat/bsc_nat.c | 21 ++++++++++++++---
openbsc/src/osmo-bsc_nat/bsc_nat_ctrl.c | 5 ++--
openbsc/src/osmo-nitb/bsc_hack.c | 39 ++++++++++++++++++++----------
16 files changed, 130 insertions(+), 53 deletions(-)
--
2.1.4
FYI, Rusty's CCAN contains some interesting option parsing code released
under GPLv2+, i.e. compatible to libosmocore:
Usage is explained in
https://github.com/rustyrussell/ccan/blob/master/ccan/opt/_info
It seems rather small and simple, and permits the subsequent addition of
options, i.e. some shared code can register options, and other parts of
the code can register even more options to it (like our libraries, or
bts-specific code in osmo-bts, ...)
I have more pressing things on my todo list than convert this now, but
as there was some discussion regarding gengetopt here recently, I
thought I might point out an alternative.
We might also look into the LGPL 2.1+ CCAN htable
https://github.com/rustyrussell/ccan/blob/master/ccan/htable/_info
as a possible replacement for those areas where our linear llist
iterations should turn out to be problematic.
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)
Add VTY command
line vty
bind A.B.C.D
The command merely stores the configured IP-address, which can then be used by
the calling main program to set the telnet port of the VTY line. (Commits in
openbsc and osmo-iuh will follow up on this.)
Add function vty_get_bind_addr() to publish the address in the vty.h API.
Add static vty_bind_addr to store.
For allocation/freeing reasons, a NULL address defaults to 127.0.0.1.
BTW, I decided against allowing keywords 'any' and 'localhost' in place of an
actual IP address to make sure a written config is always identical to the
parsed config.
---
include/osmocom/vty/vty.h | 3 +++
src/vty/vty.c | 32 ++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/include/osmocom/vty/vty.h b/include/osmocom/vty/vty.h
index 3684397..43cb0cf 100644
--- a/include/osmocom/vty/vty.h
+++ b/include/osmocom/vty/vty.h
@@ -186,6 +186,9 @@ void *vty_current_index(struct vty *);
int vty_current_node(struct vty *vty);
int vty_go_parent(struct vty *vty);
+/* Return IP address passed to the 'line vty'/'bind' command, or "127.0.0.1" */
+const char *vty_get_bind_addr(void);
+
extern void *tall_vty_ctx;
extern struct cmd_element cfg_description_cmd;
diff --git a/src/vty/vty.c b/src/vty/vty.c
index 5bcbe4a..7e27d7e 100644
--- a/src/vty/vty.c
+++ b/src/vty/vty.c
@@ -75,6 +75,10 @@ vector Vvty_serv_thread;
char *vty_cwd = NULL;
+/* IP address passed to the 'line vty'/'bind' command */
+static const char *vty_bind_addr = NULL;
+#define VTY_BIND_ADDR_DEFAULT "127.0.0.1"
+
/* Configure lock. */
static int vty_config;
@@ -1585,6 +1589,29 @@ DEFUN(no_vty_login,
return CMD_SUCCESS;
}
+/* vty bind */
+DEFUN(vty_bind, vty_bind_cmd, "bind A.B.C.D",
+ "Accept VTY telnet connections on local interface\n"
+ "Local interface IP address (default: " VTY_BIND_ADDR_DEFAULT ")\n")
+{
+ /* Avoid (small) mem leak: initially, vty_bind_addr is NULL. Whenever
+ * this gets called, it is set to a strdup. So whenever it is non-NULL,
+ * free it first. See also vty_get_bind_addr() for the NULL default. */
+ if (vty_bind_addr) {
+ talloc_free((void*)vty_bind_addr);
+ vty_bind_addr = NULL;
+ }
+ vty_bind_addr = talloc_strdup(tall_vty_ctx, argv[0]);
+ return CMD_SUCCESS;
+}
+
+const char *vty_get_bind_addr(void)
+{
+ if (!vty_bind_addr)
+ return VTY_BIND_ADDR_DEFAULT;
+ return vty_bind_addr;
+}
+
DEFUN(service_advanced_vty,
service_advanced_vty_cmd,
"service advanced-vty",
@@ -1654,6 +1681,10 @@ static int vty_config_write(struct vty *vty)
if (!password_check)
vty_out(vty, " no login%s", VTY_NEWLINE);
+ /* bind */
+ if (vty_bind_addr)
+ vty_out(vty, " bind %s%s", vty_bind_addr, VTY_NEWLINE);
+
vty_out(vty, "!%s", VTY_NEWLINE);
return CMD_SUCCESS;
@@ -1757,6 +1788,7 @@ void vty_init(struct vty_app_info *app_info)
vty_install_default(VTY_NODE);
install_element(VTY_NODE, &vty_login_cmd);
install_element(VTY_NODE, &no_vty_login_cmd);
+ install_element(VTY_NODE, &vty_bind_cmd);
}
/*! \brief Read the configuration file using the VTY code
--
2.1.4
Abort upon unknown options and missing option arguments. This came to my
attention while rewiring the -m and -M options: passing -M without argument
would launch nitb with wrong configuration. So, rather exit immediately.
If there are legacy options that should be ignored, they deserve an own 'case:'
in the option switch. There are none that I'm aware of though.
---
openbsc/src/osmo-nitb/bsc_hack.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/openbsc/src/osmo-nitb/bsc_hack.c b/openbsc/src/osmo-nitb/bsc_hack.c
index a89300a..6f8da98 100644
--- a/openbsc/src/osmo-nitb/bsc_hack.c
+++ b/openbsc/src/osmo-nitb/bsc_hack.c
@@ -187,7 +187,9 @@ static void handle_options(int argc, char **argv)
rf_ctrl_path = optarg;
break;
default:
- /* ignore */
+ /* catch unknown options *as well as* missing arguments. */
+ fprintf(stderr, "Error in command line options. Abort.\n");
+ exit(-1);
break;
}
}
--
2.1.4
Following the 'line vty'/'bind A.B.C.D' command added in libosmocore, use the
configured address to set the telnet bind for the VTY line. It is now possible
to publish the VTY on a specific local interface (including 0.0.0.0 aka "any").
Implement in all of:
osmo-gbproxy
osmo-gtphub
osmo-sgsn
osmo-bsc
osmo-bsc_nat
osmo-bsc_mgcp
osmo-nitb
In some of these main programs, move the telnet initialization below the
configuration parsing.
Historically, this was not a good idea for programs using bsc_init.c (aka
bsc_bootstrap_network()), since they expected a gsm_network struct pointer in
((struct telnet_connection*)vty->priv)->priv, so that telnet had to be either
initialized or replaced by a dummy struct. In the meantime, the gsm_network
struct is not actually looked up in a priv pointer but in the static bsc_vty.c
scope (bsc_gsmnet), so this limitation is mere legacy (even though said legacy
is still there in an "#if 0" chunk).
In the other binaries I have briefly looked at the init sequence dependencies
and found no reason to initialize telnet above the config file parsing. In any
case, I have tested every single one of abovementioned binaries to verify that
they still parse the example config successfully and launch, allowing VTY
connections on the configured address(es). I hope this suffices.
In all of the above, log VTY address and port. LOGL_INFO is disabled by default
in some of the logging scopes, and since it is a single log message right at
program launch, I decided for the slightly more aggressive LOGL_NOTICE.
---
openbsc/src/gprs/gb_proxy_main.c | 12 ++++++++----
openbsc/src/gprs/gtphub_main.c | 11 ++++++++---
openbsc/src/gprs/sgsn_main.c | 11 ++++++++---
openbsc/src/libbsc/bsc_init.c | 6 +++++-
openbsc/src/osmo-bsc_mgcp/mgcp_main.c | 6 +++++-
openbsc/src/osmo-bsc_nat/bsc_nat.c | 7 ++++++-
6 files changed, 40 insertions(+), 13 deletions(-)
diff --git a/openbsc/src/gprs/gb_proxy_main.c b/openbsc/src/gprs/gb_proxy_main.c
index f82fb5b..0c3cfbe 100644
--- a/openbsc/src/gprs/gb_proxy_main.c
+++ b/openbsc/src/gprs/gb_proxy_main.c
@@ -252,10 +252,6 @@ int main(int argc, char **argv)
rate_ctr_init(tall_bsc_ctx);
osmo_stats_init(tall_bsc_ctx);
- rc = telnet_init(tall_bsc_ctx, &dummy_network, OSMO_VTY_PORT_GBPROXY);
- if (rc < 0)
- exit(1);
-
bssgp_nsi = gprs_ns_instantiate(&proxy_ns_cb, tall_bsc_ctx);
if (!bssgp_nsi) {
LOGP(DGPRS, LOGL_ERROR, "Unable to instantiate NS\n");
@@ -274,6 +270,14 @@ int main(int argc, char **argv)
exit(2);
}
+ /* start telnet after reading config for vty_get_bind_addr() */
+ LOGP(DGPRS, LOGL_NOTICE, "VTY at %s %d\n",
+ vty_get_bind_addr(), OSMO_VTY_PORT_GBPROXY);
+ rc = telnet_init_dynif(tall_bsc_ctx, &dummy_network,
+ vty_get_bind_addr(), OSMO_VTY_PORT_GBPROXY);
+ if (rc < 0)
+ exit(1);
+
if (!gprs_nsvc_by_nsei(gbcfg.nsi, gbcfg.nsip_sgsn_nsei)) {
LOGP(DGPRS, LOGL_FATAL, "You cannot proxy to NSEI %u "
"without creating that NSEI before\n",
diff --git a/openbsc/src/gprs/gtphub_main.c b/openbsc/src/gprs/gtphub_main.c
index f18710d..89582b1 100644
--- a/openbsc/src/gprs/gtphub_main.c
+++ b/openbsc/src/gprs/gtphub_main.c
@@ -314,9 +314,6 @@ int main(int argc, char **argv)
gtphub_vty_init(hub, cfg);
rate_ctr_init(osmo_gtphub_ctx);
- rc = telnet_init(osmo_gtphub_ctx, 0, OSMO_VTY_PORT_GTPHUB);
- if (rc < 0)
- exit(1);
handle_options(ccfg, argc, argv);
@@ -327,6 +324,14 @@ int main(int argc, char **argv)
exit(2);
}
+ /* start telnet after reading config for vty_get_bind_addr() */
+ LOGP(DGTPHUB, LOGL_NOTICE, "VTY at %s %d\n",
+ vty_get_bind_addr(), OSMO_VTY_PORT_GTPHUB);
+ rc = telnet_init_dynif(osmo_gtphub_ctx, 0, vty_get_bind_addr(),
+ OSMO_VTY_PORT_GTPHUB);
+ if (rc < 0)
+ exit(1);
+
if (gtphub_start(hub, cfg,
next_restart_count(ccfg->restart_counter_file))
!= 0)
diff --git a/openbsc/src/gprs/sgsn_main.c b/openbsc/src/gprs/sgsn_main.c
index 2d3a0e4..b10b0b3 100644
--- a/openbsc/src/gprs/sgsn_main.c
+++ b/openbsc/src/gprs/sgsn_main.c
@@ -315,9 +315,6 @@ int main(int argc, char **argv)
handle_options(argc, argv);
rate_ctr_init(tall_bsc_ctx);
- rc = telnet_init(tall_bsc_ctx, &dummy_network, OSMO_VTY_PORT_SGSN);
- if (rc < 0)
- exit(1);
ctrl = sgsn_controlif_setup(NULL, OSMO_CTRL_PORT_SGSN);
if (!ctrl) {
@@ -357,6 +354,14 @@ int main(int argc, char **argv)
exit(2);
}
+ /* start telnet after reading config for vty_get_bind_addr() */
+ LOGP(DGPRS, LOGL_NOTICE, "VTY at %s %d\n",
+ vty_get_bind_addr(), OSMO_VTY_PORT_SGSN);
+ rc = telnet_init_dynif(tall_bsc_ctx, &dummy_network,
+ vty_get_bind_addr(), OSMO_VTY_PORT_SGSN);
+ if (rc < 0)
+ exit(1);
+
rc = sgsn_gtp_init(&sgsn_inst);
if (rc) {
LOGP(DGPRS, LOGL_FATAL, "Cannot bind/listen on GTP socket\n");
diff --git a/openbsc/src/libbsc/bsc_init.c b/openbsc/src/libbsc/bsc_init.c
index 743f4c1..859d999 100644
--- a/openbsc/src/libbsc/bsc_init.c
+++ b/openbsc/src/libbsc/bsc_init.c
@@ -495,7 +495,11 @@ int bsc_bootstrap_network(int (*mncc_recv)(struct gsm_network *, struct msgb *),
return rc;
}
- rc = telnet_init(tall_bsc_ctx, bsc_gsmnet, OSMO_VTY_PORT_NITB_BSC);
+ /* start telnet after reading config for vty_get_bind_addr() */
+ LOGP(DNM, LOGL_NOTICE, "VTY at %s %d\n",
+ vty_get_bind_addr(), OSMO_VTY_PORT_NITB_BSC);
+ rc = telnet_init_dynif(tall_bsc_ctx, bsc_gsmnet, vty_get_bind_addr(),
+ OSMO_VTY_PORT_NITB_BSC);
if (rc < 0)
return rc;
diff --git a/openbsc/src/osmo-bsc_mgcp/mgcp_main.c b/openbsc/src/osmo-bsc_mgcp/mgcp_main.c
index d755c90..e226b02 100644
--- a/openbsc/src/osmo-bsc_mgcp/mgcp_main.c
+++ b/openbsc/src/osmo-bsc_mgcp/mgcp_main.c
@@ -232,7 +232,11 @@ int main(int argc, char **argv)
if (rc < 0)
return rc;
- rc = telnet_init(tall_bsc_ctx, &dummy_network, OSMO_VTY_PORT_BSC_MGCP);
+ /* start telnet after reading config for vty_get_bind_addr() */
+ LOGP(DMGCP, LOGL_NOTICE, "VTY at %s %d\n",
+ vty_get_bind_addr(), OSMO_VTY_PORT_BSC_MGCP);
+ rc = telnet_init_dynif(tall_bsc_ctx, &dummy_network,
+ vty_get_bind_addr(), OSMO_VTY_PORT_BSC_MGCP);
if (rc < 0)
return rc;
diff --git a/openbsc/src/osmo-bsc_nat/bsc_nat.c b/openbsc/src/osmo-bsc_nat/bsc_nat.c
index 41291d9..e3dc10e 100644
--- a/openbsc/src/osmo-bsc_nat/bsc_nat.c
+++ b/openbsc/src/osmo-bsc_nat/bsc_nat.c
@@ -1628,12 +1628,17 @@ int main(int argc, char **argv)
osmo_stats_init(tall_bsc_ctx);
/* init vty and parse */
- telnet_init(tall_bsc_ctx, NULL, OSMO_VTY_PORT_BSC_NAT);
if (mgcp_parse_config(config_file, nat->mgcp_cfg, MGCP_BSC_NAT) < 0) {
fprintf(stderr, "Failed to parse the config file: '%s'\n", config_file);
return -3;
}
+ /* start telnet after reading config for vty_get_bind_addr() */
+ LOGP(DNAT, LOGL_NOTICE, "VTY at %s %d\n",
+ vty_get_bind_addr(), OSMO_VTY_PORT_BSC_NAT);
+ telnet_init_dynif(tall_bsc_ctx, NULL, vty_get_bind_addr(),
+ OSMO_VTY_PORT_BSC_NAT);
+
/* over rule the VTY config */
if (msc_ip)
bsc_nat_set_msc_ip(nat, msc_ip);
--
2.1.4
I decided to drop the 'any' keyword from the Abis bind address config, to
ensure that the written config is always identical to the parsed config.
Neels Hofmeyr (1):
ipa driver: make bind address vty configurable
include/internal.h | 3 +++
include/osmocom/abis/e1_input.h | 1 +
src/e1_input_vty.c | 20 ++++++++++++++++++++
src/input/ipaccess.c | 28 ++++++++++++++++++++++++++--
4 files changed, 50 insertions(+), 2 deletions(-)
--
2.1.4
I decided to drop the 'any' keyword from the Abis bind address config, to
ensure that the written config is always identical to the parsed config.
Neels Hofmeyr (1):
ipa driver: make bind address vty configurable
include/internal.h | 3 +++
include/osmocom/abis/e1_input.h | 1 +
src/e1_input_vty.c | 20 ++++++++++++++++++++
src/input/ipaccess.c | 28 ++++++++++++++++++++++++++--
4 files changed, 50 insertions(+), 2 deletions(-)
--
2.1.4
This patch allows Abis/IP bind address config for osmo-nitb as well as the
osmo-bscs, without touching openbsc.git.
This is the libosmo-abis part of making osmo-nitb's IP addresses configurable
instead of always listening on 'any'. This will allow running more than one on
the same box. Ctrl interface and vty are to follow, though not in this repo.
I did sink a bit of time until the penny dropped that all I need to do is add a
VTY command in libosmo-abis, but I did find out eventually.
Neels Hofmeyr (1):
ipa driver: make bind address vty configurable
include/internal.h | 3 +++
include/osmocom/abis/e1_input.h | 1 +
src/e1_input_vty.c | 27 +++++++++++++++++++++++++++
src/input/ipaccess.c | 28 ++++++++++++++++++++++++++--
4 files changed, 57 insertions(+), 2 deletions(-)
--
2.1.4
Hi Daniel,
the 'jerlbeck/fixes/sgsn' branch has been merged to master. sysmocom-iu
has some merge conflicts in the SGSN, so I assume it's better if you do
the rebase of sysmocom-iu onto master. Agree? It would also be nice if we
did the merge together ... maybe ping me when you do the rebase and I'll
see if I join you.
I would like to stay as close to master as possible to avoid conflict
build up. If you could do the rebase sooner rather than later, that would
be great. Thanks!
(I could have told you in person but it's good to let the list know, too)
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Hi Harald,
Holger has just refreshed my memory on a conversation we've had on running
multiple NITB instances on the same box: Linux Network Namespaces vs.
making NITB configurable.
Kindly remind me of the immediate plans, should we make osmo-nitb
configurable to bind on only specific IP addresses, like, now?
IIUC that would be a VTY item for osmo-nitb and a parameter into
libosmo-abis. Concerning the VTY, the port could be configurable, or the
IP address, thinking of 127.0.0.42.
I guess relying on `ip netns` would be quicker for now, and I'd have
slightly more time for IuCS.
Is there anyone else out there that would love to configure osmo-nitb to
bind on specific IP addresses only?
Thanks,
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
Moin Daniel :)
(1)
About ebd4d820b3b0d7ba5db3b25a14f407d0c7276044
"libiu: Use custom setupormodifieditemies function"
It seems you forgot to commit the actual function definition of
ranap_decode_rab_setupormodifieditemies_fromlist()
I got the caller of it only and thus can't compile as-is.
(2)
About 38e2f1bca4e43414ed39a938d7c5d8bafe5e8533
"
Revert "iu.c: avoid warning by declaring ranap_free_rab_setupormodifieditemies()"
There should be no need to silence this warning, the ranap_free_*
functions are declared in libranap headers. In any case this will only
obscure any real issue. Maybe osmo-iuh was not rebuilt completely
(including generation of the c files from the python script).
This reverts commit 05ae5b1245f95bf765b42e49af7b2596e013f0a0.
"
I declared ranap_free_rab_setupormodifieditemies() like that because it is
indeed not declared in a header that is installed. Also a grep tells me
that no ranap_free_* is found in any osmo-iuh header file at all.
I also did a 'make regen' in osmo-iuh/src/ to no avail.
By 'libranap headers' I assume you mean libosmo-ranap, or is there a
libranap I'm not aware of yet?
If the ranap_free_* aren't in headers yet, I agree that they should be. I
wanted to silence the warning without being sucked down the rabbit hole of
autogenerated asn1 stuff. Any suggestions: more than welcome.
(3)
In general, I would welcome to see more of your WIP work in publicly
visible private branches, maturing as you go and merged to sysmocom/iu
once ready. For one, having a backup of your work-in-progress in the git
repos makes it harder to lose it due to hardware failure. More important
for me though is that I can see what you're up to, e.g. I could possibly
find the ranap_..._fromlist() function defintion now. It's of course
opening up your "most private" code developments to the outside world,
possibly some stupid commits will be seen by one or two hacker peers, but
I think it's a healthy premise that we all commit mostly bollocks and all
needs refinement anyway... once again: push it! :)
Ah, push it
Push it good
Ah, push it
Pu-Push it real good
-- Salt N Pepa (1987)
As always I'm open to opinions and suggestions...
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
From: Max <msuraev(a)sysmocom.de>
Previously the presence of header and data blocks were communicated
in-band which decreases code readability and makes it unnecessary hard
to add support for new hardware.
Note: OsmoBTS have to be modified to take advantage of extended
ph_data_param structure.
---
TODO-RELEASE | 1 +
include/osmocom/gsm/l1sap.h | 11 +++++++++++
2 files changed, 12 insertions(+)
diff --git a/TODO-RELEASE b/TODO-RELEASE
index edf1099..0939336 100644
--- a/TODO-RELEASE
+++ b/TODO-RELEASE
@@ -1,2 +1,3 @@
#library what description / commit summary line
libosmocore change major external talloc dependency / internal talloc removal
+libosmocore change major size of ph_data_param struct changed / Extend L1SAP PH-DATA with presence information
\ No newline at end of file
diff --git a/include/osmocom/gsm/l1sap.h b/include/osmocom/gsm/l1sap.h
index 9f3fe98..1af8ba8 100644
--- a/include/osmocom/gsm/l1sap.h
+++ b/include/osmocom/gsm/l1sap.h
@@ -25,6 +25,16 @@ enum osmo_mph_info_type {
PRIM_INFO_DEACT_CIPH, /*!< \brief Deactivation of ciphering */
};
+/*! \brief PH-DATA presence information */
+enum osmo_ph_pres_info_type {
+ PRES_INFO_INVALID = 0, /*!< \brief Data is invalid */
+ PRES_INFO_HEADER = 1, /*!< \brief Only header is present and valid */
+ PRES_INFO_FIRST = 3, /*!< \brief First half of data + header are valid (2nd half may be present but invalid) */
+ PRES_INFO_SECOND = 5, /*!< \brief Second half of data + header are valid (1st halfmay be present but invalid) */
+ PRES_INFO_BOTH = 7, /*!< \brief Both parts + header are present and valid */
+ PRES_INFO_UNKNOWN
+};
+
/*! \brief for PH-RANDOM_ACCESS.req */
struct ph_rach_req_param {
uint8_t ra; /*!< \brief Random Access */
@@ -48,6 +58,7 @@ struct ph_data_param {
uint8_t chan_nr; /*!< \brief Channel Number (Like RSL) */
uint32_t fn; /*!< \brief GSM Frame Number */
int8_t rssi; /*!< \brief RSSI of receivedindication */
+ enum osmo_ph_pres_info_type pdch_presence_info; /*!< \brief Info regarding presence/validity of header and data parts */
};
/*! \brief for TCH.{req,ind} | TCH-RTS.ind */
--
2.7.1
Hi all!
Moving all projects to a Redmine is a good way, I think.
In connection with the event I would like to offer my help with
post-processing some old pages (mostly OsmocomBB) and with
improving the new wiki structure.
So, my suggestions:
- Create the main page that will describe all all of the child projects
of Osmocom umbrella including recent news and plans.
- Separate the libosmocore related pages from OsmocomBB
into a new section named "Libraries", for example.
- Separate both SIMTrace and softSIM into a new sections.
It it would be nice to enable Strict-Transport-Security to avoid
some traffic interception attempts. Also what about enabling
SPF and DKIM for mailing lists?
With best regards,
Vadim Yanitskiy.
2016-02-19 4:46 GMT+06:00 <openbsc-request(a)lists.osmocom.org>:
> Send OpenBSC mailing list submissions to
> openbsc(a)lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osmocom.org/mailman/listinfo/openbsc
> or, via email, send a message with subject or body 'help' to
> openbsc-request(a)lists.osmocom.org
>
> You can reach the person managing the list at
> openbsc-owner(a)lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenBSC digest..."
>
>
> Today's Topics:
>
> 1. Re: autoreconf v2.69 with subdir-objects: ./configure creates
> directory 'src/tests/\$(top_srcdir)' (Neels Hofmeyr)
> 2. Re: hnb_cs_lu.msc (Neels Hofmeyr)
> 3. Re: hnb_cs_lu.msc (Harald Welte)
> 4. branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu;
> merging to master (Neels Hofmeyr)
> 5. Re: Moving from trac to a single redmine (Harald Welte)
> 6. Re: Moving from trac to a single redmine (Holger Freyther)
> 7. Re: branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu;
> merging to master (Holger Freyther)
> 8. sysmocom/iu: your commits from today (Neels Hofmeyr)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 17 Feb 2016 15:44:35 +0100
> From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
> To: Eric Blake <eblake(a)redhat.com>
> Cc: bug-autoconf(a)gnu.org, openbsc(a)lists.osmocom.org
> Subject: Re: autoreconf v2.69 with subdir-objects: ./configure creates
> directory 'src/tests/\$(top_srcdir)'
> Message-ID: <20160217144435.GD2106@dub6>
> Content-Type: text/plain; charset="us-ascii"
>
> Eric,
>
> you've clarified just about all of my questions.
> Many thanks for your reply!
>
> ~Neels
>
> > https://lists.gnu.org/archive/html/automake/2015-12/msg00001.html
>
Hi list,
I tend to use vim's :make command so that it takes me to the positions of
warnings and errors automatically. However, when hacking on osmo-iuh, I
sometimes get dozens of these irritating warning chunks:
[[[
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:35:10: warning: ‘struct Member’ declared inside parameter list
struct IE_Extensions *iE_Extensions /* OPTIONAL */;
^
/usr/local/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:31:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct Member {
^
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:35:10: warning: its scope is only this definition or declaration, which is probably not what you want
struct IE_Extensions *iE_Extensions /* OPTIONAL */;
^
/usr/local/include/asn1c/asn_SET_OF.h:17:16: note: in definition of macro ‘A_SET_OF’
void (*free)(type *); \
^
../../include/osmocom/hnbap/CriticalityDiagnostics-IE-List.h:31:2: note: in expansion of macro ‘A_SEQUENCE_OF’
A_SEQUENCE_OF(struct Member {
^
]]]
The cause are numerous instances of code like:
[[[
/* CriticalityDiagnostics-IE-List */
typedef struct CriticalityDiagnostics_IE_List {
A_SEQUENCE_OF(struct Member {
Criticality_t iECriticality;
ProtocolIE_ID_t iE_ID;
TypeOfError_t typeOfError;
struct IE_Extensions *iE_Extensions /* OPTIONAL */;
/*
* This type is extensible,
* possible extensions are below.
*/
/* Context for parsing across buffer boundaries */
asn_struct_ctx_t _asn_ctx;
} ) list;
/* Context for parsing across buffer boundaries */
asn_struct_ctx_t _asn_ctx;
} CriticalityDiagnostics_IE_List_t;
]]]
"...which is probably not what you want".
Turns out it kinda is what I want, I just don't want these warnings :P
Filtering proper error messages from this mess is hard.
Any idea to get rid of these warnings would speed up my dev cycle
dramatically...
Short of refactoring the way these A_SEQUENCE_OF() get generated.
I guess the struct should rather be first declared with a unique name and
then only the type name should be used in A_SEQUENCE_OF(). i.e. not like
osmo-iuh/include/osmocom/rua/RUA_CriticalityDiagnostics-IE-List.h:
A_SEQUENCE_OF(struct Member {...
but like:
osmo-iuh/include/osmocom/rua/RUA_Disconnect.h:
A_SEQUENCE_OF(RUA_IE_t) list;
Doesn't seem to come from the asn1tostruct.py...
Thanks!!
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte