Parse multiple IPCP IEs embedded in Protocol Configuration Options,
and return IPCP responses for all of them. Makes the associated
TTCN3 GGSN test pass.
Depends: Ia1410abb216831864042f95679330f4508e1af3d
Change-Id: I51ecab4e35f3ee638e68ca773b0da90cc0294ab0
Related: OS#3319
IPCP data can begin at any byte location in the pco_req->v array.
Casting to a 'struct ipcp_hdr' pointer could lead to unaligned access.
Parse IPCP data with u_int8_t pointers instead to avoid this problem.
Add some length checks while here.
pco_contains_proto() and ipcp_contains_option() now receive the minimum
size of the data the caller is looking for, and only return pointers
to items of sufficient size.
Also fix an inifinite loop in ipcp_contains_option() by refusing
IPCP options with length small than 2. Previously, a zero length
option would trigger an infinite loop in the parser.
Change-Id: Ia1410abb216831864042f95679330f4508e1af3d
Related: OS#3194
struct ipcp_option_hdr and struct ipcp_hdr are not declared as
packed explicitly, but they are used to parse memory blobs by
casting pointers. Add __attribute__((packed)) to ensure that
those structs are stored packed.
Change-Id: I14e10bb3ce482347b3f0c4d3a75168a55df15f20
Related: OS#3288
The abort condition of the while loop in ipcp_contains_option()
is accessing ipcp->len directly. Unfortunately this field is an
uint16_t which as to be interpreted as little endian value. If
it is used without prior conversion the value may appear larger
than actually intended and the loop will then not stop at the
end of end of the buffer.
This can cause unpredictable results when the value given with
the parameter enum ipcp_options opt is not found.
The loop will then eventually cause a segmentation fauld or
is likely to hang as soon as cur_opt->len points to a zero
byte in memory.
- Make sure that ipcp->len interpreted correctly by accessing
it through ntohs()
Change-Id: Icffde89f9bc5d8fcadf6e2dd6c0b4de03440edd5
Related: OS#3288
There are some configuration nodes, which are handled by extenral
libraries, such as libosmoctrl. So, when switching back to the
parent node, this should be kept in mind.
Change-Id: I65be7910dc46166caa34a0984a6763e1477dec99
This way, the IP address / route handling between TUN devices and kernel
GTP can be shared, which will provide not only a unified codebase but
also a more consistent behavior.
This also paves the road for to use kernel GTP from sgsnemu in the future.
Related: OS#3214
Change-Id: Ic53a971136edd0d8871fbd6746d7b0090ce3a188
tun_addaddr() internally contains a fallback to tun_setaddr() for the
first address, so we can unify the API usage a bit and use tun_addaddr()
from all call sites
Change-Id: I34de003a1a040254bd38b29e48caea34cb0c88d2
There's a problem during the initial start-up of osmo-ggsn in case
of kernel gtp-u: apn->ggsn->gsn is not yet set while parsing the
'apn' nodes from the config file. This member is only set after
the last 'apn' node has been parsed at the end of the 'ggsn' node.
Closes: OS#3217
Change-Id: I022a5e5ebc1f155e8f94938856d310462f79bbe8
Improvements include:
- Use Identifier received from request instead of using hardcoded id=0.
- Don't add DNS to response if they were not included in request.
Change-Id: Ic8aa5d634e526683b2ad8ed5d14088e171c41c98
Check (before forwarding received GTP packets into the tun) if the pdp ctx
associated with the packet requested was assigned an EUA of the given IP version.
This way we avoid for instance forwarding an IPv6 packet (or sending
back a response to a Router Solicitation packet) in case the APN was
configured without IPv6 support or if the MS/SGSN didn't ask for an IPv6
while requesting an EUA.
As a side effect, this commit fixes an OSMO_ASSERT hit introduced in handle_router_mcast
in 2d6a69e69a due to a deffective MS
sending an icmpv6 Router Solicitation over IPv6 after having been
requesting and assigned an IPv4 EUA (so no IPv6 packets expected).
Before that commit, there was no crash but the message was being wrongly
answered and used an uninitialized .v6 addr field from the peer struct.
Fixes: OS#2843
Change-Id: Ib6d18a64c2b71f3bcf6cb7e3a978d2d3f9c7a79b
The error is:
CC gtp-kernel.o
gtp-kernel.c:19:26: fatal error: libgtpnl/gtp.h: No such file or directory
#include <libgtpnl/gtp.h>
^
compilation terminated.
Fix it by using proper CFLAGS/LIBS for libgtpnl.
Change-Id: I5a24076778ea3ce263ac27211a6f45f935155b33
Previous commit added the ipv6 link-local vty cmd but forgot to add code
to print its value in config_write_apn.
Fixes: 37c45e3998
Change-Id: I08aeaa98d6dc318b7e9740d837ba4ac48cd7051c
This vty cmd let's you set up a new link-local IP for a specific APN to
be used during ICMPv6 Router Advertisement procedure.
osmo-ggsn hence requires a link-local IPv6 address to be added to the
tun interface, otherwise the apn will not be configured correctly and it
won't be able to allocate addresses from the ipv6 pool later on.
This feature is useful in case your OS doesn't support autoconfiguring
link-local IPs when the interface is brought up (some linux versions are
known to fail at this) or in case you configured your OS specifically to
avoid automatic set up (sysctl net.ipv6.conf.*.autoconf).
If "no ipv6 link-local" is provided (default), osmo-ggsn will rely on the
OS or the ipup-script setting up the link-local IP for the tun
interface at creation time, then fetching it after ipup-script time and
using the first link-local ip found. On the other hand, if the "ipv6
link-local" cmd is provided, osmo-ggsn will add the link-local IP to the
interface manually and use that one for later Router Advertisement
procedures.
Change-Id: I09ef27f54940d4c47150e5f9016d1cd4298c16b5
Before this commit, when an MS requested an ipv4v6 context osmo-ggsn
returned an error stating the type was unknown, and this text was
printed in the log:
Processing create PDP context request for APN 'ims'
Cannot decode EUA from MS/SGSN: f1 8d
This patch has been tested with an MS running the 3 types of addresses:
- IPv4 and IPv6: no regressions observed, the context is activated and
packets are sent to the ggsn.
- IPv4v6: Wireshark correctly parses request and reponse, and then
ICMPv6 traffic from both sides. Finally I see the MS using the IPv4 and
IPv6 DNS addresses advertised and TCP traffic over IPv4 (because
probably my IPv6 network setup is not correct). I also checked I can
disable/enable data (pdp ctx delete and activate) several times without
any issue.
Change-Id: Ic820759167fd3bdf329cb11d4b942e903fe50af5
The existing code would abort iterating over the list of PCO TLVs
if a TLV of length zero was encountered. However, there's nothing
in the spec that would make a zero-length PCO invalid, so we should
continue to iterate over any PCO TLVs after the zero-length one.
This issue was discovered while writing test cases in
osmo-ttcn3-hacks.git
Change-Id: I36660566a8ee2ca80ae6ee99c86e167e7c208df2
... this probably didn't show up as 8.8.8.8 is dual-endian. doh!
The address was already in network byte order, but msgb_put_u32 "of
course" expects host byte order, ending up the wrong way in the actual
packets :/
Change-Id: Ia4bcac5fcebfc24760432eb66be258a01d78f65f
Closes: OS#2685
Changes made as requested by the deprecation text.
Fixes warning below:
warning: ‘vty_install_default’ is deprecated: Now happens implicitly with install_node() [-Wdeprecat
ed-declarations]
vty_install_default(GGSN_NODE);
^~~~~~~~~~~~~~~~~~~
Change-Id: I5c6197129e0c251a4e8dd174027b011c8f6476c6
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
Stefan Sperling
Pau Espin
Philipp Maier
Harald Welte