Hi,Can someone inform us if the VTY configuration commands to change parameters e.g. cell id, location area code, MS power etc. that are run on OpenBSC VTY telnet interface take effect on next restart of the OpenBSC session or during the same session? If former is the case, is there any way to dynamically change Cell ID, LAC, MS TX power etc i.e. without restarting the OpenBSC session?
Regards,
Amber & Sarosh
I can talk all day about atomic commits, but chunks of gtphub have transformed
twice over (that's me figuring out how to map and resolve GTP data elements),
so that half the patches are obsoleted by later ones, in a hard-to-rebase way.
So here is a joint patch of gtphub for review. If anyone requests it, I will
gladly separate it into a handful of patches adding each subsection / family of
API at a time, to better show where each part reaches. Just ask...
Many thanks for any reviews!
~Neels
Neels Hofmeyr (1):
Add GTP hub (code bomb).
openbsc/.gitignore | 2 +
openbsc/configure.ac | 1 +
openbsc/include/openbsc/Makefile.am | 1 +
openbsc/include/openbsc/debug.h | 1 +
openbsc/include/openbsc/gtphub.h | 345 +++++
openbsc/include/openbsc/vty.h | 1 +
openbsc/src/gprs/Makefile.am | 6 +
openbsc/src/gprs/gtphub.c | 1794 +++++++++++++++++++++++
openbsc/src/gprs/gtphub_main.c | 283 ++++
openbsc/src/gprs/gtphub_sep.c | 26 +
openbsc/src/gprs/gtphub_vty.c | 258 ++++
openbsc/tests/Makefile.am | 2 +-
openbsc/tests/gtphub/Makefile.am | 20 +
openbsc/tests/gtphub/gtphub_nc_test.gtphub.conf | 5 +
openbsc/tests/gtphub/gtphub_nc_test.ok | 7 +
openbsc/tests/gtphub/gtphub_nc_test.sh | 85 ++
openbsc/tests/gtphub/gtphub_test.c | 675 +++++++++
openbsc/tests/gtphub/gtphub_test.ok | 3 +
openbsc/tests/gtphub/hex2bin.py | 13 +
openbsc/tests/testsuite.at | 12 +
20 files changed, 3539 insertions(+), 1 deletion(-)
create mode 100644 openbsc/include/openbsc/gtphub.h
create mode 100644 openbsc/src/gprs/gtphub.c
create mode 100644 openbsc/src/gprs/gtphub_main.c
create mode 100644 openbsc/src/gprs/gtphub_sep.c
create mode 100644 openbsc/src/gprs/gtphub_vty.c
create mode 100644 openbsc/tests/gtphub/Makefile.am
create mode 100644 openbsc/tests/gtphub/gtphub_nc_test.gtphub.conf
create mode 100644 openbsc/tests/gtphub/gtphub_nc_test.ok
create mode 100755 openbsc/tests/gtphub/gtphub_nc_test.sh
create mode 100644 openbsc/tests/gtphub/gtphub_test.c
create mode 100644 openbsc/tests/gtphub/gtphub_test.ok
create mode 100755 openbsc/tests/gtphub/hex2bin.py
--
2.1.4
Hi OpenBSC,
I have just merged the gtphub branch to master. The request to do that has
been standing for a while, to let Jenkins run the tests etc., but there
were still quite volatile parts of the code until now.
The last few days, I have successfully tested gtphub in a mock network,
using a web capable phone, a sysmoBTS running an SGSN on-board, and a
gtphub and OpenGGSN on my laptop. It works: I can browse the net!
@Andreas: since our last discussion, I have incorporated all of your
comments. It *does* make sense after all. A peer may request gtphub from
any port, and by sequence number tracking, the response will go back to
that port and IP. Requests with unknown sequence number will be routed
according to the header's TEI, which means that gtphub will send Requests
always to the default port (a proxy with a specific port may be
configured, though). Another thanks for your input!
GGSN resolution by DNS (GRX C ares) is taking a shortcut: hoping that the
peer will try again, after a DNS request has first been fired, gtphub will
simply not respond. Once a GGSN has been resolved and sits in the cache,
Requests are served immediately. In this way, I avoided a mechanism to
queue incoming Requests (until DNS is done, so that other messages are not
blocked in the meantime), which would have been the proper way to do this,
but would add quite a bit of complexity that is really only needed for the
very first resolution of a given GGSN... According to spec, an SGSN will
resend Requests a number of times, so this should actually be sufficient,
I guess.
Some small bits are still outright missing, as you may notice from the
various TODO comments. But all the main parts are implemented and tested.
Probably a number of bugs still need to be found.
Some infrastructural things are also missing. Coming up is the debian
build, and soon to follow: rate control.
Thanks for any reviews!
(I intend to employ proper peer review for gtphub from this point on...)
~Neels
The definition of the APN field format in GTPv1 is hidden in a chain
of documents.
3GPP TS 29.060 (the GTPv1-C specification) Section 7.7.30:
> The Access Point Name contains a logical name (see 3GPP TS 23.060 [4]).
> It is coded as in the value part defined in 3GPP TS 24.008
3GPP TS 24.008 Section 10.5.6.1:
> The value part is defined in 3GPP TS 23.003.
3GPP TS 23.003 Section 9.1:
> The APN consists of one or more labels. Each label is coded as a one
> octet length field followed by that number of octets coded as 8 bit
> ASCII characters
This converts a literal APN (e.g. Label1.Label2.Label3) to a structured
field (e.g. \006Label1\006Label2\006Label3)
Signed-off-by: Andreas Schultz <aschultz(a)tpip.net>
---
sgsnemu/sgsnemu.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/sgsnemu/sgsnemu.c b/sgsnemu/sgsnemu.c
index 5b56751..832bd97 100644
--- a/sgsnemu/sgsnemu.c
+++ b/sgsnemu/sgsnemu.c
@@ -231,6 +231,7 @@ int process_options(int argc, char **argv)
char *type;
char *mcc;
char *mnc;
+ char *tok, *apn;
char *lac;
int lac_d;
char *rest;
@@ -534,10 +535,19 @@ int process_options(int argc, char **argv)
printf("Invalid APN\n");
return -1;
}
- options.apn.l = strlen(args_info.apn_arg);
- strncpy((char *)options.apn.v, args_info.apn_arg,
- sizeof(options.apn.v));
- options.apn.v[sizeof(options.apn.v) - 1] = 0;
+ options.apn.l = strlen(args_info.apn_arg) + 1;
+
+ apn = (char *)options.apn.v;
+ for (tok = strtok(args_info.apn_arg, ".");
+ tok != NULL;
+ tok = strtok(NULL, ".")) {
+ size_t len = strlen(tok);
+
+ *apn++ = (char)len;
+ strncpy(apn, tok, len);
+ apn += len;
+ }
+
printf("Using APN: %s\n", args_info.apn_arg);
/* selmode */
--
2.5.0
I am trying to insert some code to openBSC, and after studying the GSM
network, I decided to test with SMS payload without changing the headers,
the best place for it is in the MSC before the SMS is stored in the SMSC,
can anyone direct me to the source file for it, I've tried to look in
Libsmocore and Openbsc source files but with no success.
Dear all,
as far as I understand, the TCP socket interface between osmo-bts and
OpenBSC only existed in a particular branch/fork of OpenBTS created by
Fairwaves, and it was created at a point where no public release of
OpenBTS included any GPRS support.
As the world has moved on (OpenBTS including their own GRPS code with
something of a unified PCU, SGSN and GGSN; Fairwaves using OsmoBTS), I'm
wondering how much sense it makes to still keep this code in the
osmo-pcu repository.
Particularly, it doesn't seem to make sense to keep it as the compile
default. A default should be applicable to most users / configurations
of a software, shouldn't it?
Any input on thi is appreciated.
My argument would be to drop that code. If not, then at least make it
the non-default case. Or even compile both an osmo-pcu-osmobts and an
osmo-pcu-openbts binary by the default makefile target and do away with
any compile-time switching between the two.
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,
I am working on getting libosmocom package into Fedora, there is
review request in [1].
During the packaging I found following minor issues:
- Incorrect FSF addresses in source code, e.g. there is written in the
sources:
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
But the correct address is (as taken from the
https://www.gnu.org/licenses/gpl-2.0.html):
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
- exit call in the library: /usr/lib64/libosmovty.so.3.0.0 exit(a)GLIBC_2.2.5
libraries shouldn't generally call exit.
thanks & regards
Jaroslav
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1279527
Hi all!
This is the announcement for the re-incarnation of our bi-weekly
Osmocom Berlin Meeting.
Nov 11, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin
There is no formal presentation this time, but
* there will be SDR equipment, antenna and a working/tested setup of a
gnuradio based MPT1327 decoder
* there will be SIMtrace equipment in case somebody wants to play with
it there will be a sysmoBTS with OsmoBTS, OsmoPCU, OsmoNITB, OsmoSGSN
and OpenGGSN if somebody wants to play with it
* there will be Huawei Femtocells to play with
* Harald would like to discuss OpenBSC website / documentation improvements
The meeting is open to anyone interested in mobile communications. You
do not have to be involved with the Osmocom projects in order to attend.
Anyone interested in mobile communications protocols is welcome.
If you are interested to show up, feel free to do so. The meeting is
"free as in free beer", despite no actual free beer being around ;)
More information can be found at
http://openbsc.osmocom.org/trac/wiki/OsmocomMeeting/Berlin
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org>
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)