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
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
This function is used to compare an IPv6 address against another,
using the smaller of the two prefix lengths.
Change-Id: Ic993d8abdc90897cb55276f01ae3b8a5eadf5a0d
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
Stefan Sperling
Harald Welte
Pau Espin