* changes:
DHCP: Minor cleanups to the packet code.
DHCP: Move the packet code to frameworks/base/services.
DHCP: Add a native method for making a DHCP socket.
DHCP: Add a superclass for DhcpStateMachine.
1. Add a validating method to convert a netmask to a prefix length.
2. Add a function to get the implicit netmask of an IPv4 address.
3. Add a unit test.
Bug: 19704592
Change-Id: Icb9f58d3903ea01df9e3720383c9bd5db6dd8f26
Separate out starting DHCP (DISCOVER) and RENEW operations from fetching
the results. Add NetworkUtils.getDhcpResults(), to enable quick checks
of any available DhcpResults without extraneous interaction with the
DHCP daemon.
Bug: 19422416
Change-Id: I58808e529dda8429737e749f5caef56d923c0809
In K and earlier, we would connect to a network where the gateway
was not covered by the subnet mask of the IP address. This is an
invalid configuration, but it used to work, and other OSes appear
to accept it too, so support it.
Bug: 19067207
Change-Id: I822e1d754b336691b675438eefa959a3d75fd07b
When requests made by ConnectivityManager.startUsingNetworkFeature() are
expired or are canceled via ConnectivityManager.stopUsingNetworkFeature(),
we must remember to clear the binding of DNS requests from the calling
process to the Network satisfying the request.
bug:18778725
Change-Id: I800c808ac6486000241b5d263aa79a1192a9fe9e
1. Send PROXY_CHANGE_ACTION broadcast when any network's proxy changes,
not just the default network.
2. When a process is bound to a particular Network, update the proxy
system properties to those for the bound Network, and keep them
updated when PROXY_CHANGE_ACTION broadcasts are received.
3. Make Network.openConnection() use the proxy for the Network.
bug:17905627
bug:17420465
bug:18144582
(cherry-pick of https://android-review.googlesource.com/#/c/115170)
Change-Id: Ia2819985e6108a8c121e74c683a5646becfd0a97
There are some cases where multiple subscriber identities (IMSI)
should be treated as "merged together" from a data usage
perspective. This is done by extending the template used for
matching purposes to support multiple subscribers.
Then, when we query historical usage or set network policies, we
normalize the matching template to merge to any other identities
that should be included. When normalizing, the "lowest" identity
is always used for equality and storage purposes, which allows
identities to come and go over time.
This change also fixes data usage recording for multi-SIM devices
by passing along the concrete subscriber identity for each network
interface. Also correctly create default policies for multi-SIM
devices. This change also drops setPolicyDataEnable() until it can
be wired up to the right underlying NetworkAgent. (This means we
still bring up the network, and then rely on iptables rules to block
traffic when over the limit, instead of proactively disabling the
connection.)
Bug: 18012787
Change-Id: If6acf32009fdfea2b836f5aff8e2f3e5e0248b4a
Since optimistic addresses are useable upon kernel notification
there is no need for this extra connectivity delay.
---
This functionality was originally submitted in ag/572619. Owing
to issues with bind()ing to optimistic addresses (see b/18609055)
this was reverted in ag/598673.
This reverts the revert. :-)
Bug: 17769720
Change-Id: Ibee490b2af72050693b6bd748193f51e312ca527
This is the revert of ag/572619.
This reverts commit b5ae87a8d0, reversing
changes made to 32b61ab28f54e5b00f472b2166f9b1100375e4ff.
Bug: 18609055
Bug: 17769720
Change-Id: I122eba200f2071d4e5777ec34c1d04fb567345a8
The basic principle is: if an app's traffic could possibly go
over a network without the app using the multinetwork APIs (hence
"by default"), then the status bar should show that network's
connectivity.
In the normal case, app traffic only goes over the system's default
network connection, so that's the only network returned.
With a VPN in force, some app traffic may go into the VPN, and thus over
whatever underlying networks the VPN specifies, while other app traffic
may go over the system default network (e.g.: a split-tunnel VPN, or an
app disallowed by the VPN), so the set of networks returned includes the
VPN's underlying networks and the system default.
Specifically:
1. Add a NETWORK_CAPABILITY_VALIDATED bit to NetworkCapabilities.
2. Add a hidden API to retrieve the NetworkCapabilities of
all default networks for a given macro-user.
3. Modify the status bar code that used getActiveNetworkInfo to
determine which network was active, and make it consider all
validated networks instead.
4. Because the set of active networks depends on which VPN app
the user is running, make the status bar re-evaluate the
networking situation when the active user changes.
Bug: 17460017
Change-Id: Ie4965f35fb5936b088e6060ee06e362c22297ab2
Define and print a compact version of network statistics when dump
is requested with the "--checkin" flag. Defaults to last 24 hours,
but included data can be tweaked with various flags.
Groups together detailed network identities into larger umbrella
terms like "mobile" and "wifi."
Bug: 18415963
Change-Id: I70cf9c828ea5c6e5bb6884837d3608f66fbad2e6
These are used when responding to getActiveNetworkInfo() (and cousins)
when an app is subject to the VPN.
Bug: 17460017
Change-Id: Ief7a840c760777a41d3358aa6b8e4cdd99c29f24
The previous code retrieved information from the legacy tracker multiple
times for each user query, leading to race conditions where the info
could've changed between the calls.
Refactors the handling of legacy data types in ConnectivityService and
unifies call paths so that APIs that deal with legacy data types
(NetworkInfo and int/networkType) and newer types (such as Network) go
through common code paths, using NetworkState to hold all the necessary
data pieces. This enables follow-on bug fixes to getActiveNetworkInfo().
The changes are limited to public "query" APIs (those that retrieve some
network information or the other). More details about the specific
changes and their rationale can be found in the code review thread.
Bug: 17460017
Change-Id: I656ee7eddf2b8cace5627036452bb5748043406c
ConnectivityManager.requestNetwork(NetworkRequest, PendingIntent)
was unhidden and implemented.
Added ConnectivityManager.removePendingIntentRequest(PendingIntent) as
the companion method.
Bug: 17356414
Change-Id: I656a1e149cc1292c443ebfe9e61ee3eb5a80f143
We're starting to get network requests for specific SIMs
and the Legacy Type Inference was broken because the incoming
request included a network specifier while the legacy requests
it was compared with did not. Only compare the things we care
about.
bug:18031008
Change-Id: If107042828c152ede51a2497a3859bc1a6c83694
setDomain() and toLinkProperties() were not setting the domains.
The setDomain() bug affected Wifi and I believe the toLinkProperties()
bug affected Ethernet and Bluetooth reverse-tethering.
bug:18252947
Change-Id: I8764cb944c293e01d99822bb52b55af7e9d77853
Once optimistic addresses become useable upon kernel notification
there will be no need for a connectivity delay.
This change requires kernel changes like:
https://android-review.googlesource.com/#/c/109934
Bug: 17769720
Change-Id: I8510c540aa655aad6a82ee322d591331357ee272
If the kernel sends notification of an optimistic address then
treat is a useable address (isGlobalPreferred()).
Note that addresses flagged as IFA_F_OPTIMISTIC are
simultaneously flagged as IFA_F_TENTATIVE (when the tentative
state has cleared either DAD has succeeded or failed, and both
flags are cleared regardless).
Additionally: do not consider RFC 4193 ULA addresses sufficient
for "global preffered". They are, by definition, of global scope
but not sufficient for global reachability.
Bug: 17769720
Change-Id: I759623b28fd52758f2d4d76d167f3cafd9319d6a
This simplifies callers.
Also remove all "implementations" of addStackedLink and
removeStackedLink except the one in LinkProperties, because they
are unused.
Bug: 12111730
Change-Id: Ie294b855facba4b1436299dcb3211b72d9ba448e
Specifically:
[1] provide a hasIPv4(), and
[2] a hasIPv6()
each of which requires an IP address, a default route, and
address-family-specific DNS servers to evaluate to true.
Additionally:
[3] redefine isProvisioned() to return the logical OR
of [1] and [2] above.
Any external caller can still use any of the has*() methods to
construct its own, different definition of "provisioned".
Bug: 17769720
Change-Id: Ia692fb8508484ff403d3920c94d0e1db4563f807
Most of this logic is simply removed from ConnectivityService.
The captive portal detection is now done by the NetworkMonitor.
The notification logic is still left in ConnectivityService as
it's used by both the NetworkMonitor and telephony's mobile
provisioning logic.
bug:17324098
Change-Id: Ibd1c42b1a75795f90a6483d3d0a5a14f88b193d8
Now that we support unreachable routes, use those to block
address families on VPNs. This is a much more elegant solution.
Also update LinkProperties when IP addresses are added and
removed, fixing a TODO.
Bug: 17462989
Change-Id: Ib749d84710dca70d672350b9f129bb91419ec77e
