--gtpnl is now gone, instead you have --gtpkernel that behaves as an on/off
toggle. We full rely on the kernel routing base to select the real device to
transmit.
I have updated ggsn/cmdline.ggo and then run 'gengetopt' to refresh the
automatic code generation for command line options that openggsn uses.
Coverity complains about a 'Dereference before null check' on *queue.
So, push the NULL check further up.
Though I doubt that 'return EOF' is the proper way to handle allocation
failure, this patch is only about the NULL dereference.
Fixes: CID#57918
libgtp cannot understand its own update pdp request (in gtp v1)
Only require the conditional and mandatory fields for gtpv1 and not
others.
Refer to 3GPP TS 29.060 Ch. 7.3.4
pdp_getgtp1(&pdp, get_tei(pack)) works like pdp_getgtp0 for gtp0
connections.
Using get_hlen() for gtpie_decaps is used in other places to decode ies
for both version 0 and 1.
With no pdp parameter gtp_req() will send the packet to TEID 0 which is
not what we want. When trying to modify an established pdp context the
correct TEID of that context must be used.
This patch adds the -g, --gtpnl=device option that allows you to
enable the GTP kernel tunneling mode in openggsn. You have to specify
the real downlink device that will be used to tunnel traffic, eg.
-g=eth0
This means that the gtp0 device will be created and it will use eth0
as the real device to encapsulate packet coming from the Internet that
are addressed to the MS (so the tunnel devuce encapsulates these IP
packets in GTP packets when traveling to the SGSN).
Alternatively, you can also add this to the ggsn.conf configuration file:
gtpnl eth0
The device has to be the real device that can route packets to the SGSN,
if you select the wrong device, the kernel routing code may not find a
way to reach the SSGN, you've been warned.
Therefore, if this option is set, the operational becomes the following:
1) A gtp0 device is created via rtnetlink and configure the socket
encapsulation infrastructure in the kernel.
2) Whenever a PDP context is created, this adds the necessary tunnel
configuration via genetlink GTP interface.
3) Whenever a PDP context is destroyed, this deletes the tunnel via
genetlink GTP interface.
4) Destroy the gtp0 device if ggsn is stopped, including all of the
existing tunnels.
You require the osmo-ggsn.git tree, which contains the kernel module
gtp.ko and the libgtpnl library that you have to compile and install.
Make sure you have loaded the gtp.ko kernel module before launching
the ggsn daemon using the kernel driver mode, otherwise you will get
a nice "operation not supported" error message ;-).
This patch also adds supports for "ipup" configuration option to invoke
an external script after the gtp0 device has been brought up. Typical
command to add the route to reach the MS behind the GGSN is required,
eg. ip route add 10.0.0.0/8 dev gtp0.
The (horrible) ggsn parser has been manually extended to support the
new configuration option. That code doesn't look nice, but it just
mimics what we already have there for consistency, please don't blame
me for that.
If you want to run in debugging mode, I suggest you to use:
sudo ggsn -c ggsn.conf -f -d
Note that you do have to run openggsn as root to bring up the gtp0
device. You have to see this message that announce that the GTP kernel
mode is enabled.
openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25)
This patch also automagically sets up route to reach MS from Internet
just like tun mode does. This is fundamental to get this working,
better don't leave to the admin, he may forget to add this route.
In this patch, I tried to encapsulate this new feature as much as
possible as Harald initially suggested.
To compile this feature, you have to pass --enable-gtp-kernel, ie.
./configire --enable-gtp-kernel
Otherwise, the code to interact with the gtp kernel part is not compiled.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
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@tpip.net>
It would print the memory location of the address buffer. Instead, print the
human readable host address and port.
The current code base supports only IPv4, and thread safety is apparently not
required, hence just use inet_ntoa(). (The IPv6 and thread capable version is 4
times longer and harder to read.)
Return early when socket() returns -1, and check return codes
where indicated by some TODOs. This removes 2 TODOs and fixes
a compiler warning about assignment to a variable which then
isn't used.
Signed-off-by: Michael McTernan <mike.mcternan@wavemobile.com>
The specific log statements are not great yet but at least they
will end up in the log file. In the future everything should be
related to the IMSI or at least the tunnel id.
Pablo Neira Ayuso
Neels Hofmeyr
Daniel Willmann
Harald Welte
Alexander Huemer