SYS_ERR is for logging an error from the (operating) system including
the errno value. For general logging, we have DEBUGP/LOGP. Let's
convert the gtp-kernel logging over. This also fixes the related line
ending mess-up as SYS_ERR adds a LF while LOGP/DEBUGP don't.
Change-Id: Idb4069a28227b770e20d62bf306cd294f47146ae
When genl_socket_open() succeeds but genl_lookup_family() fails,
we have to clean up the socket that we just opened.
This requires a new version of libgtpnl :/
Change-Id: I31df046530347f88cb7b16c37a899b456ed1b080
We have to factor out the "run once" code and make sure to really
only run that once, while the per-device code remains in the
gtp_kernel_init() function.
Change-Id: Iba5bd71e4b725eef59fe4f233fbb965e396a06c3
Whether or not GTP kernel support is enabled is the property of a
given APN, and not a global state variable.
Change-Id: Iff3bd8a52bd6c20f9811ee41ff700486d08591f3
The existing kernel GTP support code inherited from OpenGGSN was overly
simplistic and didn't support multiple GTP devices or user-defined GTP
device names. Let's remove that restriction in this patch
Change-Id: I51df223788fd5b7cf8099463b8aa0ca4a4fd1c96
When we branched off osmo-ggsn from the old openggsn code base, the
support for kernel-gtp got temporarily removed. This patch
re-introduces support for handling the GTP-U plane in the Linux kernel
by means of libgtpnl + the kernel GTP-U driver.
This only works for IPv4 at the moment, until the kernel GTP-U code
gains IPv6 support.
Kernel GTP currently also is restricted to a single APN per GSN.
Change-Id: Ieb1bc1bd0d51d41947f0abd6ebbc2e5d102592d6
Rather than taking an explicit in_addr, prefix_length and a
string-formatted prefix, let's pass in an in46_prefix and derive
the other representations from it.
Also, don't refer to a no-longer-existing global 'ipup' variable but
add it as a function argument.
Change-Id: Ife87142c86589b4fa4062d62afe3670467548589
This ensures that in case of error, any caller can still safely
call talloc_free() on the blacklist pointerm as free on NULL
is well-defined. With the code prior to this patch we fear
a double-free.
Change-Id: Idc511cb3f0dfb922920aba8f88ea77df1722ecdc
Commit dda21ed7d4 modified previous calls
to ippool_new() removing the pass of flags to avoid allocating certain
problematic IPs from the pool to MS, such as the network, gateway and
broadcast IPs.
Today I did some unsucessful tests with osmo-ggsn with a pool "ip prefix
dynamic 176.16.222.0/24", and thus IP 176.16.222.0 was being assigned to
the MS. De-capsulated DNS packets were received in the tun interface,
but the Linux system in there was unable to correctly forward the
packets to the gateway interface connected to the Internet. However,
adding a second MS which got 176.16.222.1 had its packets forwarded
correctly.
However, previous implementation relies on flag IPPOOL_NOGATEWAY flag to
blindly blacklist first IP after the network ip (ie, .0 and .1 are
removed), which limits the IP reserved for the tun device to be .1. If a
different IP in the range is assigned, it may cause issues. As a result,
a blacklist is introduced in this commit to dynamically fetch the tun IP
address and exlucde it from the pool of available IPs.
Change-Id: I8e91f7280d60490c858a769dd578c1c8e54e9243
Add support for IPv4 and IPv6 global IPs. Also return the prefix length
of the IP address by using a in46_prefix.
Change-Id: I277af191dc611b6bbcb83479f4ae338083740322
If the EUA in the Create PDP Context Request was not supported by
the given APN (e.g. IPv6 request for a v4-only APN), we crashed.
Avoid this and add proper handling of this error case.
Change-Id: I8d1f7ec727c5d2d4427232015f81ed57d3440dff
Program terminated with signal SIGSEGV, Segmentation fault.
0 create_context_ind (pdp=0xb6b391b0 <pdpa>)
at /usr/src/debug/osmo-ggsn/1.0.0+gitrAUTOINC+ab5e160937-r0/git/ggsn/ggsn.c:453
453 if (!apn->started)
(gdb) bt
0 create_context_ind (pdp=0xb6b391b0 <pdpa>)
at /usr/src/debug/osmo-ggsn/1.0.0+gitrAUTOINC+ab5e160937-r0/git/ggsn/ggsn.c:453
1 0xb6b225e0 in gtp_create_pdp_ind (gsn=gsn@entry=0x74f28, version=version@entry=1, peer=0x0,
peer@entry=0xbee6ead4, fd=-1092167056, fd@entry=8, pack=pack@entry=0xbee6eae4, len=len@entry=179)
at /usr/src/debug/osmo-ggsn/1.0.0+gitrAUTOINC+ab5e160937-r0/git/gtp/gtp.c:1591
2 0xb6b245e4 in gtp_decaps1c (gsn=0x74f28)
at /usr/src/debug/osmo-ggsn/1.0.0+gitrAUTOINC+ab5e160937-r0/git/gtp/gtp.c:2986
3 0x41d770c0 in osmo_select_main () from /usr/lib/libosmocore.so.8
4 0x000121b8 in main (argc=4, argv=0xbee70e54)
at /usr/src/debug/osmo-ggsn/1.0.0+gitrAUTOINC+ab5e160937-r0/git/ggsn/ggsn.c:897
Fixes: dd266066c7, b16c46b4c3
Change-Id: Ie4ec74e87aaf1d067dd1717d986673be56c4d6ed
If the default APN has not been started, it is not eligible to be
used in starting of new PDP contexts.
Change-Id: I93b5c205c033f275824ee8bc8cdcf1428fb086df
Tell the user about possible causes of failure to set the IPv6
address of the tun device, such as general lack of IPv6 support in
the kernel/OS, or the use of /proc/sys/net/ipv6/conf/default/disable_ipv6
Change-Id: I5ff812425ee12b8386bb66521e05c93e825a4506
If we receive a GTP-C CREATE PDP CONTEXT for an APN that we were
unable (or not configured) to start, ignore that APN.
Change-Id: I8011a9ccc1d5effd3779f184c9055af46838ccaf
When there's an interim error (e.g. in resolving the link-local address
or setting up the tun device), apn_start() simply calls apn_stop()
on the not-yet-fully-started apn_ctx.
This only works if apn_stop() doesn't bail out early in case of
a not-started apn_ctx, so let's remove the related check at the
start of the function.
Change-Id: I2917a6258cb73cc12fd9d81296ff0eaa616890b9
It might be useful for any user of libgtp who uses libosmocore so let's
make generalized version of it available as part of installable header.
Change-Id: I79aba10ef989384a28f059c30899e65c771ae5e1
Related: SYS#3610
This per-APN vty option determines if we are transmitting GTP sequence
numbers in downlink G-PDU messages. This behavior is optional as per
GTP spec. The default behavior is "true", like before this change.
Related: OS#2519
Change-Id: Ibf0de261f83951309b01b4feae998b6656c77664
There was a copy+paste mistake that created syntax errors during the
write of a config file that contained IPv6 DNS server settings.
Change-Id: Ida40c32c72dba8155f8294b93484e46e8bd27739
I'm not quite sure how I ended up doing this, but for some strange
reason the code before this commit is sending the ICMPv6 Router
Advertisements from some weird non-standard source address. This is
a violation of RFC4861 which clearly states that the source address
of router advertisements "MUST be the link-local address assigned to the
interface from which this message is sent."
Change-Id: Ib444af70fc8f0b433d371281601fd5a37b29039e
In case the GGSN is behind some kind of DNAT, the public GTP-C and
GTP-U IP addresses as exposed inside the GTP payload information
elements are different from the (internal, behind-nat) IP address
to which it listens/binds.
Change-Id: I548c9011c9abd66d46f963b1def61575f3dabb89
Osmocom has maintained this program since about 7 years now, while
the original author / copyright holder has completely disappeared.
With the introduction of Osmocom-style CTRL and VTY interfaces,
the way how the program is used and configured has substantially
changed. In order to avoid confusion in terms of configuration file
format etc, let's rename it to OsmoGGSN.
Change-Id: I2da30f7d4828e185bfac1a4e2d8414b01cbe4f9d
The control interface handle never belonged into libgtp in the first
place. Commit 727417dd28 should not
have added this to the shared library (used by sgsnemu, osmo-sgsn, ...),
but to some private state of the GGSN.
Introducing a private context pointer at the same location will keep
ABI compatibilty.
Change-Id: I4f17516dae3e04114564828a3e5f6e2ea54212a5
During IPv6 support implementation, helper function pco_contains_proto
was added which contains an error: It is only capable of finding first
protocol correctly, and as a consequence, in my setup DNS servers where not
sent back to the SGSN/MS, resulting in phone being able to connect to
IPs but not to domain names which required DNS resolution.
The condition in the while loop is also changed to match the increment
of the variable inside the loop to make it easier to understand at first
glance.
Fixes: 1ae98777d9
Change-Id: Icc2e6716c33d78d3c3e000f529806228d8aa155e
For some reason Max' commits introducing the CTRL/trap interface
about one year ago didn't convert the IMSI to its actual textual
representation before usign it in the CTRL interface.
Let's clean that up by properly interpreting the IMSI.
Change-Id: I8b20d2e47a29de266d93a7ddd5e6877f7e346a63
As we can now have PDP contexts with IPv6 user IP payload,
it is useful to extend the TUN related code to be able to
configure the tun device IPv6 address + prefix length
Change-Id: I899d21e52d02e0b8384af29ddd489ff19c8f2cf6
In IPv6, DNS server information is not passed along as IPCP6 like
in IPv5 with IPCP. The reason is that IPCP6 (for PPP) doesn't
support passing DNS server information. Rather, the relevant RFCs
indicate DHCPv6 should be used even over point-to-point links.
3GPP decided to avoid DHCPv6 dependency for stateless autoconfiguration
(the only mandatory IPv6 configuration mechanism) and added some new
non-PPP-style PCO information elements ("containers") which can among
other things inform a MS about IPV6 DNS servers.
That same mechanism can also be used to inform the MS about IPv4 DNS
servers, so for IPv4 there are now two competing mechanisms: IPCP and
the new "native" PCO container. With this patch, we support both
for IPv4.
Change-Id: I21499afd61def8c925f7838bde76f34d28214b56
The 3GPP specs are quite strange when it comes to how an IPv6 address
or rather prefix is assigned to an IPv6 PDP context. The designated
method for allocating the IPv6 address via the PDP EUA (End User
Address) Information Element in the GTP signalling plane is *not*
used to allocate the address/prefix. Instead, the EUA is used to
allocate an "interface identifier" to the MS, which it the uses
to derive its link-local source address to send a router solicitation.
The GGSN subsequently answers witha router advertisement, advertising
a single/64 prefix, whihcthe MS then uses to generate it's real IPv6
source address for subsequent communication.
Change-Id: Icddf7d30e01d76a4784bcef5787b36f52f703a9f
In IPv6 GPRS, we actually don't want to allocate an individual v6
address (like in IPv4), but we want to allocate a prefix. The
standard prefix lengh is 8 bytes, i.e. a /64 prefix. This patch
extends the pool to be able to work with such v6 prefixes.
Change-Id: I0cf700b6baf195a2e5fbea000531f801acaaa443
When we receive PDP context requests for unknown PDP types or if
we run out of dynamic addresses, we need to inform the SGSN that
PDP context creation failed.
Change-Id: Ibf199c1726130d27c8f80230b30ee51101c93b06
This patch enables the use of IPv6 PDP contexts. The phone will
have to request an IPv6 End-user-Address, and the GGSN will have
to be configured for an IPv6 pool.
The outer transport-layer IP between SGSN and GGSN must still be
IPv4, it is not modified by this patch
Change-Id: I22c3bf32a98e5daf99d6eaeac8c9f95cc7574774
Extend the IP pool implementation to be able to manage both pools
of 32bit addresses (IPv4) as well as pools of 128bit addresses (IPv6)
Change-Id: Ib98cc4bf634d6be9a7bf8c03a24e629455fcafc8
An EUA length of *2* octets indicates dynamic IP address, while
an EUA length of 0 is invalid. Let's fix this hack (which needs
to finally be removed anyway).
Change-Id: Ib1b57eb0654327882044d6862d955f4b32aa6bcd
When Linux Kernel GTP-U support is enabled, OpenGGSN so far only worked
with GTPv0,but not with GTPv1, as the TEI values were not correctly
configured. This patch fixes the initialzation of the local and remote
TEI before using libgtpnl to create a tunnel context in the kernel.
Change-Id: I3e953ff5b4ab44c26dbbe20d18b61038fa57ff32
Do not attempt to send TRAP message on PDP context deletion if peer is
unknown.
Change-Id: I5e02c1d42bb7aaf1ef81a9824aab7b12047cdd3e
Fixes: Coverity CID 150135
Only generation of TRAP messages over Control Interface is supported so
far.
Note: requires corresponding version of libosmoctrl.
Change-Id: Ia76f841d2c9cd14394e9316fcd39f4060e23c898
Related: OS#1646