It was left as UNRELEASED but it was actually released (there's a tag on
it). Otherwise osmo-release.mk is fooled.
Change-Id: Iedd8311303274dd3be88a11314a61fbdd511679d
The osmo-release.mk script can be found in libosmocore and it is used in
most osmocom related projects to help create new releases.
LIBVERSION is moved to src/Makefile.am since osmo-release.mk greps for
Makefile.am to find LIBVERSIOn changes. In any case, we don't need in
the global include makefile.
Change-Id: I5d163535c34369c74ece26574c8b1601bc1697b7
This fixes the following kernel error message:
netlink: 'osmo-ggsn': attribute type 1 has an invalid length.
This is due to CTRL_ATTR_FAMILY_ID being defined as a 16bit netlink
attribute, but us encoding it as u32:
netlink/genetlink.c: [CTRL_ATTR_FAMILY_ID] = { .type = NLA_U16 },
let's properly encode it as 16bit and hence resolve the error message.
Change-Id: I41b2719ffc24d7a3420b5980f2a967264e606d91
Closes: OS#3216
They used to be in check_programs, but then this would only build them
during 'make check' which not everyone knows or is using.
Change-Id: Idd2b3a66e5968686e6bbff59dbc89b7673def8dd
Inspired-by: Thomas Boros <tomas.boros92@gmail.com>
When deleting a PDP context via "gtp-tunnel delete", we specify only
the gtp netdevice, the gtp version and the TID/TEI. However, the
gtp_build_payload() function unconditionally created the netlink
attributes for GTPA_PEER_ADDRESS and GTPA_MS_ADDRESS, having their
addresses set to zero. The kernel then tried to find a PDP context with
MS and PEER address of 0.0.0.0, and always failed with ENOENT.
The same problem also occurred with OsmoGGSN and OpenGGSN: PDP contexts
could be added but never removed.
The corresponding kernel change that requires this userland change
is the following commit introduced in 4.12-rc1:
commit d9e2dd122637034a0697bf268eed9233701b9dca
Author: Andreas Schultz <aschultz@tpip.net>
Date: Thu Mar 9 17:43:00 2017 +0100
gtp: unify genl_find_pdp and prepare for per socket lookup
Older kernels will work with libgtpnl both before and after this commit,
as they internally will simply disregard any attributes beyond TID/TEI.
Change-Id: Ie2ceb2cd6d2fb009bba01a05b5480c1ad775d619
This aligns with a kernel patch that renames the netlink parameter
to emphasize that it refers to the remote peer which may be either
a GGSN or an SGSN.
The upstream kernel include file retains the legacy name as a define
but we don't need that in our internal library since we are no longer
using it anywhere.
This patch corresponds to a Linux kernel patch extending the kernel GTP
to also cover the SGSN role, not just the GGSN role. In order to keep
the API/behavior compatible, gtp_dev_create() will continue to create
GGSN-side tunnels, while a new gtp_dev_create_sgsn() is introduced to
create SGSN-side tunnels.
Signed-off-by: Harald Welte <laforge@gnumonks.org>
This patch corresponds to a Linux kernel patch extending the kernel GTP
to also cover the SGSN role, not just the GGSN role. In order to keep
the API/behavior compatible, gtp_dev_create() will continue to create
GGSN-side tunnels, while a new gtp_dev_create_sgsn() is introduced to
create SGSN-side tunnels.
Signed-off-by: Harald Welte <laforge@gnumonks.org>
I can't look tei by gtp-tunnel in GTPv1.
I write patch for libgtpnl.
head version
$./tools/gtp-tunnel add hoge v1 65535 65535 10.0.3.2 192.168.0.2
$./tools/gtp-tunnel list
version 1 tei 0/0 ms_addr 10.0.3.2 sgsn_addr 192.168.0.2
fixed version
$./tools/gtp-tunnel add hoge v1 65535 65535 10.0.3.2 192.168.0.2
$./tools/gtp-tunnel list
version 1 tei 65535/65535 ms_addr 10.0.3.2 sgsn_addr 192.168.0.2
This facilitates the use from other projects such as ASL licensed
software. We think there is no point in others having to re-implement
the GTP specific message parsing/encoding on top of libmnl, which is
LGPL anyway.
Please note that the tools are still licensed under GPL, just the
library has been changed.
So we can fully test packet decapsulation without a full blown openggsn
setup by injecting packets and using this simple tool.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Andreas accidentally broke parsing, restore it.
Fixes: ba77a20 ("gtp-rtnl: Split TID handling for GTPv0 and GTPv1")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
gtp_list_tunnel() is exported through the library, so use it instead of
opencode. This is a left-over from the early stage of development of
libgtpnl.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
0 is a valid file descriptor and it is the default value after calloc(),
so set this -1 so we don't send it through netlink as used init_netns.
Fixes: 200b2f4 ("gtp-rtnl: and netns support")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
GTPv1 tunnel use separate 32bit Tunnel Endpoint Identifier's for each
direction while GTPv0 uses only one 64bit Tunnel IDentifier.
Signed-off-by: Andreas Schultz <aschultz@tpip.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
With this change, application don't need to pass to the linker -lmnl
which is the right way to make it since they don't directly refer to
mnl_* functions.
We can use this to specify 'gtp0' from openggsn, so we make sure that
it always uses the same tunnel device on creation. If it already exists,
it will return EEXIST. This is used to skip the problem of lacking
NLM_F_ECHO in the rtnetlink link interface that allows us to know the
name of the gtp device that has been dynamically allocated from the
kernel.
And, finally, I don't find any use case for having more than one tunnel
device when integrating this with openggsn.
This patch also adjusts tools/gtp-link-add.c which needs some care, since
it is not yet using any of the library functions. This tools are likely
to be useful for troubleshooting and debugging.
openggsn already sets up the UDP sockets that we need for the control
and user planes of GTP. Since we cannot bind two UDP sockets (one from
userspace and another from the kernel) to the same port, change the
current code to pass the socket descriptors that has been allocated
by openggsn (or whatever daemon which uses the GTP kernel
infrastructure).
Two new attributes are added to set up the tunnel device: IFLA_GTP_FD0
(for GTP0) and IFLA_GTP_FD1 (for GTP1u), which specify the UDP socket
created from userspace. Thus, the GTP kernel code only takes care of
enabling the kernel UDP encapsulation routine.
Pau Espin
Harald Welte
Jonas Bonn