in46a_from_eua() API documentation clearly states an array of 2 items
should be passed as pointer, but show_one_pdp() was passing only one,
which would end up in out-of-bounds writes on v4v6 EUAs.
Let's better use ippool to print allocated ip addresses instead of
parsing EUAs we sent some point in the past.
Change-Id: I7e164f40f50de43027bcd4464aa879450d2fb10e
It's clearer having size-related checks in one place for a data structure
in46_addr, instead of spread around the code.
Change-Id: Idc94bf0c8c01bb5a30e36d3c284b99f66b972abb
All addresses in struct tun_t were stored as an in_addr.
But IPv6 addresses need an in6_addr, so switch tun_t addresses
to the in64_addr wrapper struct.
This is an ABI break, as documented in TODO-RELEASE.
Fixes an out of bounds memcpy() identified by Coverity.
Change-Id: Idd2431ad25d7fa182e52e2bd5231ceb04d427c34
Related: CID#174278
The variable this->listsize is an unsigned int, but the format
string assumed ptrdiff_t. Found by Coverity.
Change-Id: Ib2a55907adae98f8aa7b079f1c9a3b4fc5f67fc5
Related: CID#188879
Coverity points out that addr.len was potentially being used
uninitialized, via calls to in46a_inc(&addr).
Change-Id: Idb67394e5f4c2072380a33f46c848d92c4317245
Related: CID#174189
When copying an address to a reused static hash table member
with memcpy(), this code mistakenly passed the size of a
pointer as the amount of bytes to be copied, rather than
the actual size of the address.
This means the IP pool could contain bogus IP addresses because
only addr->len (a uint8_t) and 3 further bytes of the address
were actually copied on 32 bit platforms. On 64 bit platforms,
a sufficient amount of bytes were copied for IPv4 to work
correctly, but too few bytes were copied for IPv6.
This problem was found by Coverity.
Replace the bogus memcpy() call with direct assignments to the
appropriate struct in64addr union members, and assert that the
length recorded for the address actually corresponds to the
length used by the address family (IP4, IPv6).
Change-Id: Ic21560f7519e776107485a8779702fb1279d065c
Related: CID#57921
The calloc() call in ippool_new() had two problems.
The first problem is benign: The order of arguments were reversed.
Pass the number of elements in the array first, then the size of
each element, as calloc() expects.
This problem was found by me. There are more instances of this
problem in this file, which I'll address in follow-up patches.
The second problem is that the requested allocation was larger than
necessary: The hash table is an array of pointers to ippoolm_t, not
an array of struct ippoolm_t. Fix the required size passed to calloc().
This problem was found by Coverity.
Change-Id: I93fa5bc539771ca19714f6a665558c9140e2ce07
Related: CID#57920
Coverity complains about a missing ioctl() return value check.
Check for failure of the TUNSETNOCSUM ioctl and log a warning
if it fails.
Change-Id: I88da2164d975d7a232619b8d31c5eadeef0f3a80
Related: CID#57661
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
There's nothing really tun-specific about the adding and removing of
addresses to network devices. Let's generalize the related code.
Change-Id: I139a950dd81a4b1199953be1608cd109a060f562
sgsnemu (the only user of this API so far) has been modified to use the
new API with in46_addr.
FreeBSD code for IPv6 has not been tested.
Change-Id: Ie36afe6eaf393855a4a708000ef4ad0192bf4767
First of all, dstaddr can be NULL, avoid copying it in that case.
Second, we want to copy the addr data, not the pointer. I tested it and
the IP was not added (not shown in ip addr) until I copied the content
instead of the address.
Change-Id: I8da637b155f0e913cab6c5b0dde355c9f33375b5
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
In any case, if we add support for ipv6 in tun_addaddr we will need
tun_setaddr (and also change the API of tun_addaddr to use in46_addr).
Change-Id: Iadf51379455174a642b477040ec96f28022c24c7
netdev_ip_local_get() is a generalized version of tun_ip_local_get()
which supports the net device as argument, rather than a tun_t.
Change-Id: I072aa1a55e7bf110706e9207021b776d9b977fb6
* we have to use stataddr, not addr (dynamic)
* we have to multiply the length of the address by 8 to get its bit length
* we can simplify the -1 +1 logic (like dynamic)
Change-Id: I174102051bef95f7df34b7d7c480a00ae408be7d
Fixes: Coverity CID#174189
The 'struct tun' curently only has an in_addr (v4-only) member to
store the address of the tun device, so let's not attempt to store
an IPv6 address in it.
FIXME: This entire code needs an overhaul. The assumption that there's
only one address, and only either v6 or v4 is broken to begin with.
Change-Id: If0b626d688841d6e0a3867834f4cb1b70084050e
Fixes: Coverity CID#174278
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
Take the chance this commit is changing test output to also remove use
of IPPOOL_NOGATEWAY which is going to be removed soon, and instead test
IPPOOL_NOBROADCAST.
Change-Id: I95c24bc690490155bec9e3933d678e4668d7745f
From getifaddrs(3) man:
"The data returned by getifaddrs() is dynamically allocated and should
be freed using freeifaddrs() when no longer needed"
Change-Id: If6300d1c8d36fcafef294a4c11bbda31a158bb9c
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
We haven nobody maintaining this platform, let's remove it.
In fact, only Linux and FreeBSD are part of the jenkins build tests,
so even Apple/MacOS is up for disposal. However, as it's more
popular, let's keep the code.
Change-Id: Id6b8179259bacade52c39f96e688f828eff164ac
This allows the application to attach some private state to the tun
device, such as the context from which it was created/allocated
Change-Id: Ief43b9b5fab5830fa8e28362c795f88f0b4d353b
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
There's a bit of trickery with the ip_pool and it's "lengty=8" IPv6
prefix handling, let's make sure we don't accidentially call any
support functions with addresses of wrong length.
Change-Id: I444c190bdcd18780344e1f0dad4faf3bcf9da5a5
Pau Espin
Stefan Sperling
Harald Welte