Here is another set of cosmetic improvements for openggsn
(branch: neels/refactor).
This prints the host address in human readable form and covers two more similar
occurences.
A new error log fix has been added (see 4/4).
A nonstandard curly brace change from the previous patch has been dropped, and
replaced by a blank line to increase readability.
~Neels
Hi,
Some time ago, Pablo Neira Ayuso wrote a GTP-U kernel module and OpenGGSN
support for it. The OpenGGSN side is easily available in the osmocom git [1].
The kernel part is somewhat harder to find, but it's at [2].
It seems that both sides are at 70% completion and only somewhat working.
I have played with the kernel module, changed a couple things and would
like to get some feedback on my changes.
It can be found at: https://github.com/RoadRunnr/osmo-ggsn
Things I've changed:
* requires kernel from net-next (or 4.3)
* convert to use the existing kernel iptunnel infrastructure
* fix GTP-u v1 TEI usage (we need one TEI for RX and another one
for TX)
* use UDP sockets passed from userland for sending (instead of
direct push to network interface)
* fix resource release on GTP-U socket shutdown
* release all resource on module removal
The module currently works with a proof-of-concept GGSN/PGW implemented
in Erlang (will post once the licensing is sorted). OpenGGSN will need
some small changes (will post soon).
Andreas
[1]: http://git.osmocom.org/openggsn/
[2]: http://git.sysmocom.de/osmo-ggsn
Hi all,
a remark / question about GTP, in the context of writing code for
gtphub...
So far I've tried to keep the GTP IP addresses and ports config general --
you never know what weird things one might want to do some day (different
IP addresses for User and Control? Nonstandard port numbers?).
But now I'm at the point where I've got a Control plane message from a
"control peer", and need to figure out the matching peer on the User
plane. How do I do that? By IP address, of course.
Thus it struck me that GTP *depends* on a setup where the User IP address
is identical to the IP of the sender of the Ctrl plane packet.
(view with a monospaced font)
SGSN GGSN (or gtphub)
1.2.3.4 5.6.7.8
Ctrl: 2123 <-------> 2123
User: 2152 <-------> 2152
So trying to stay general with IP addresses is an exercise in futility,
because it plainly doesn't work for GTP: I can't match up a peer's two
message planes unless the above standard is given.
Thinking of a nonstandard situation:
GGSN (or gtphub)
SGSN 5.6.7.8
Ctrl: 1.2.3.4:111 <-------> 2123
User: 4.3.2.1:222 X-------> 2152
The GGSN can record that there's a Ctrl peer at 1.2.3.4:111, from the
incoming GTP packet's sender address. Say it receives a Create PDP Context
Request, in which the nonstandard SGSN sends two TEIs it wants to use, on
the Ctrl *and* User plane. Now, the GGSN cannot possibly know that 4.3.2.1
is the User plane peer for which the TEI from the Create PDP Ctx Req
should be valid. One may think that the SGSN can just contact the GGSN
from 4.3.2.1:222 and send the TEI from the Create PDP, so the GGSN could
know that it's the same peer. But in fact a TEI is scoped *within* a comm
plane with a peer, meaning that any other peer could choose the exact same
TEI at any point, and the means to disambiguate is the peer's IP address.
So my wishful thinking to stay general there is thwarted by design. The
Ctrl and User IP addresses must be identical.
Still, the SGSN's port numbers could theoretically be chosen freely. The
GGSN knows the sender of the Ctrl packet(s), and as soon as a User packet
comes in from the same IP address, it also knows the User plane port. As
long as the IP address is the same and there are no other SGSNs using
different ports on the same IP address, the GGSN could figure out both
nonstandard Ctrl and User ports like this.
BTW, we've also thought about securing the GTP wire towards gtphub with
some kind of authentication (future). With identification sent on both
planes, the limitations discussed here would be void...
So I'll actually keep gtphub's config as general as it is, but will not
invest time, neither in implications of choosing nonstandard setups, nor
in prohibiting them (yet).
The nonstandard ports config capability actually comes in handy for unit
testing, where I can place some netcats and a gtphub on arbitrary port
numbers on the same IP address. (Since implicit creation of 127.0.0.N
interfaces is linux specific, using several local addresses without root
privilege is not portable).
If you spot any thinkos there, please let me know :)
~Neels
Hi all,
though promising GTP implementations are emerging from the shadows, current GTP
Hub development is still using OpenGGSN's kludgy GTP API. I'd love to switch,
but it's not the time for that yet.
To be able to query and manipulate IEs in the OpenGGSN way, I've taken the
liberty to commit below patch on openggsn.git/master, which publishes gtpie.h.
~Neels
commit 6c06d25667f7c46e179bfd1121c512234c98649f
Author: Neels Hofmeyr <nhofmeyr(a)sysmocom.de>
Date: Tue Oct 27 14:57:18 2015 +0100
make install: also install gtpie.h
diff --git a/gtp/Makefile.am b/gtp/Makefile.am
index 4ad9f65..9586dfe 100644
--- a/gtp/Makefile.am
+++ b/gtp/Makefile.am
@@ -1,6 +1,6 @@
lib_LTLIBRARIES = libgtp.la
-include_HEADERS = gtp.h pdp.h
+include_HEADERS = gtp.h pdp.h gtpie.h
AM_CFLAGS = -O2 -fno-builtin -Wall -DSBINDIR='"$(sbindir)"' -ggdb $(LIBOSMOCORE_CFLAGS)
Hey all,
I am having some trouble in initializing osmo-nitb.
When i run osmo-nitb -c /etc/osmocom.openbsc.cfg -l /etc/osmocom.openbsc.cfg
P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNMi am receiving an error
DB: Failed to create connection.
DB: Failed to init database. Please check the option settings.
Can anyone please guide me how to proceed??
I have checked all the drivers required initialze database as per suggested in
http://openbsc.osmocom.org/trac/wiki/osmo-nitb
Still the issue is consistent.
Hi all!
This is the announcement for the re-incarnation of our bi-weekly
Osmocom Berlin Meeting.
Oct 21, 8pm @ CCC Berlin, Marienstr. 11, 10117 Berlin
There is no formal presentation this time, but
* there will be SDR equipment in case more people are interested
to have a look at MPT1327 and/or Tetrapol signals that can be
received in Berlin
* 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)
> > +uint64_t decode_big_endian(const uint8_t *data, size_t data_len)
> > +uint8_t *encode_big_endian(uint64_t value, size_t data_len)
> have you looked at osmo_load64le_ext of libosmocore? I think you don't need
> these routines. and it applies to GSUP too.
Ah, nice. Hadn't seen those yet.
Oh well, I notice that the decode_big_endian() is more elegant to use than
osmo_load64be_ext(), since passing a length of less than 8 bytes to
decode_big_endian() writes the N least significant bytes, and allows this:
uint16_t val;
val = decode_big_endian(buf, sizeof(val));
It has the desired result. However this:
uint16_t val;
val = osmo_load64be_ext(buf, sizeof(val));
will write the bytes bound to the "wrong", most significant end of the
uint64_t, and only zero is written to val. So I would need to explicitly
use osmo_load16be().
Which is less elegant, isn't it? Is it about performance? Would changing
that behavior break anything besides bitrev_test.c? (It checks for exactly
this ordering)
I'd like to change only the osmo_loadXXbe_ext() function, so that it
writes the least significant bytes, like decode_big_endian() does. But
first, does it write the most significant end for a reason?
If it doesn't, we don't actually need to generate functions for each
integer size. Instead we can glorify the decode_big_endian() and
encode_big_endian(), made threadsafe, to become osmo_load/store*().
Right??
Except for bitrev_test.c, all callers I found (in my currently cloned few
source trees) use only the non-"_ext" functions, and would not be affected
by the change at all.
~Neels
P.S.: Holger, after I said to you that osmo_loadXXbe_ext is not less
elegant after all, I re-re-realized that it is indeed still less
elegant...
Dear Harald,
Now that the implementation of the IuH interface is on its way, can you please recommend any femtos which you think can probably be used with this implementation? I think in a previous conversation in this subject someone mentioned that probably Alcatel based units has the highest chance because of certain configuration and/or implementation options.
Anyway, if you can shed some light on this subject, that would be awsome.
Thanks!
Csaba
