This change simply ignores resetting of country code by cellular
networks to avoid disconnecting existing wifi connections. It also
defers setting newly found country code until after existing Wifi
connection is torn down.
Also removes some dead code related to resetting of country codes.
Bug: 13894807
Change-Id: Ie2fcfdd4b3be8ba94542772c132fb1acb6a2c683
This helps in reducing overt scans when cell network is unavailable; and
in turn helps alleviate some regulatory concerns.
BUG: 11062898
Change-Id: I2d860f2d1acfdafba427504247a54b81482b0f5b
We're getting signals from the radio and it sometimes drops out for
a while. This change will delay applying an empty country code
for 15sec but apply non-empty country codes immediately. It uses a
sequence number so we only apply the most recent change, even if
it's delayed.
Also secures the wifi call to set the country code as we can't
allow apps to set it willy-nilly.
bug:11062898
Change-Id: I610039a833e26d4c5c8b7b9ac1b7546f3c83446a
This is necessary so that the framework can know whether an IPv6
address is likely to be usable (i.e., if it's global scope and
preferred). Also, it will simplify the address notification
methods in INetworkManagementEventObserver, which currently take
the address, the flags, and the scope as separate arguments.
1. Add flags and scope to the class and update the unit test.
Use the IFA_F_* and RT_SCOPE_* constants defined by libcore.
Since most callers don't know about flags and scope, provide
constructors that default the flags to zero and determine the
scope from the address. Addresses notified by the kernel will
have these properly set. Make multicast addresses invalid.
Update the class documentation.
2. Provide an isSameAddressAs() method that compares only the
address and prefix information between two LinkAddress
objects. This is necessary because an interface can't have
two addresses with the same address/prefix but different
flags.
3. Update LinkProperties's addLinkAddress and removeLinkAddress
to identify existing addresses to add/remove using
isSameAddressAs instead of implicit equals(). Specifically:
- If addLinkAddress is called with an address that is already
present, the existing address's flags and scope are updated.
This allows, for example, an address on an interface to go
from preferred to deprecated when it expires, without it
having to be removed and re-added.
- If removeLinkAddress is called with an address that is
present but with different flags, it deletes that address
instead of failing to find a match.
4. Update the INetworkManagementEventObserver address
notification methods to take just a LinkAddress instead of
LinkAddress, flags, and scope. While I'm at it, change the
order of the arguments for consistency with the other
functions in the interface.
Change-Id: Id8fe0f09a7e8f6bee1ea3b52102178b689a9336e
Currently address{Updated,Removed} pass in the address as a
string such as "fe80::1/64". Use LinkAddresses instead, since
that's what it is.
This makes the code more robust in the unlikely case that netd
passes in an invalid string. In the future we can move flags and
scope into the LinkAddress itself and simplify the code further.
Bug: 9180552
Change-Id: I66599f9529cf421caa7676fdd0141bb110b8589e
This change modifies a framework optimization. The framework optimization
disables a network when an access point repeatedly rejects requests
to associate with it. This change has some problems; one being that
it counts the rejects for all networks, and not for a specific network.
This incorrectly penalizes last networks at times; and since the current
threshold is 4 rejects, the probability of penalizing wrong networks
is high. This change ups that number to 16 to reduce that probability.
Bug: 11654725
Change-Id: I7150a9ccbb54bac44f2c2ba100fb6617ded33616
Setting the same code is redundant, and may cause supplicant to drop
currently connected connection.
Bug: 11303252
Change-Id: I1af57b3af2d0b8cc51939a8b9872fb3fe0105a91
We were ending up with 1 reference to every char array
in which a new AP was discovered. In a busy env this could
cost several hundred K from the dalvik heap.
bug:11087956
Change-Id: I3b14c39fd0c98e4aea08a406e80bcf6af40d0664
Networks should be unconditionally disabled when going to
scan only state or we risk connecting when we don't want to.
bug:11062188
Change-Id: If89621ca07d86673a661d2e5fe4ce89286f8835e
The transition from driver-started to scan-only state was incorrectly
always marking wifi disabled, but transitioning back only marked it
enabled if we were exiting due to leaving the scan-only-with-wifi-off
mode.
bug:11062188
Change-Id: I44fe64fd8dac8f36f4e22cb1c16b9d7a06bdbac0
After a L2ConnectedState to WpsRunningState transition, network is disconnected.
However, the disconnected message is ignored by WpsRunningState, leaving DHCP
still running. When entering L2ConnectedState again, WifiStateMachine gets stuck
on waiting for DhcpStateMachine, because DHCP is already running and the command
CMD_START_DHCP is ignored. Calling handleNetworkDisconnect() when exiting
L2ConnectedState fixes this problem, plus it handles disconnection correctly.
Bug: 10900241
Change-Id: Id29e4989b29db7e64719940cf93eba1f1a90912a
After a reboot, KeyStore is locked, and certificates encrypted with user
PIN are not accessible. So statemachines are not able to connect to
EAP-TLS networks. This change makes the problem less severe by
1. Not signing certificates with user PIN on devices with hardware backed
KeyStore.
2. Issuing a reconnect upon first USER_PRESENT event.
This means HH (which has a hardware backed keystore) can connect to
EAP-TLS networks without requiring user intervention and other devices
will automatically connect to those networks after user punches PIN.
Bug: 10325089
Change-Id: I023d60e58d8214152f051bd9ec84b85b702d829a
This ignores any previous setting and instead uses
a value set at build time. This does not preclude
us from using some other signal to determine country
for wifi channel limits.
bug:10513734
Change-Id: Ib82c07285af70fbd82eb0466b7391979ebc8be10
ScanModeState is trying to undo whatever it did in its enter(), in its
exit() function. But doing that is incorrect because it is possible to
transition to multiple states that require different conditions.
In this bug, the state machine transitioned from ScanModeState to
WaitForP2pDisabled state; in response to Stop Supplicant command. Well,
when we are trying to stop supplicant, there is clearly no need to
enable P2P or load all networks. But since this code exists in exit(),
it is executed nonetheless, causing race conditions accessing the
wpa_supplicant (WifiStateMachine is trying to shut it down, but
P2pStateMachine is trying to bring up the p2p interfaces).
We solve that problem by moving this code to the place where we transition
to DisconnectedState - since that's the state that needs this as a
precondition.
Bug: 10761752
Change-Id: Iaf0ffd8056de8533b5d2bfdf8c440fbb7e406dac
Framework sets allowedKeyManagement to WPA_EAP + WPA_PSK, if
WifiConfiguration didn't supply any value for it. It should probably
change to NONE; but that is post K thing. I am allowing that
combination for now.
Bug: 10843500
Change-Id: Id0c28f4aaf32c6a7e7dca07114a2452ce194a798
Scanning while dhcp is running breaks dhcp, so stop the batched scans
when we need dhcp and start it up again after.
bug:10691401
Change-Id: Ifdeb6f35cfe4509b90fed1e1e694d0c107f24a7e
There used to be some STOPSHIP code in WifiWatchdogStateMachine for debug
purposes. We don't need them for the release.
Bug: 10841961
Change-Id: I501d62e9891ace52317e6c1d399b877175099a3c
Multiple authentication methods are currently considered invalid; but
WPA_EAP and IEEE8021X are set simultaneously. This means we need to
fix code to consider them a valid combination.
Bug: 10325089
Change-Id: I2b4f4d75f21df78bfca66a930e85214c0cd6922e
It was introduced to debug the disappearing APs; now that we think that
we've got to the bottom of it, it is being disabled by default. Set VDBG
to true to get it back.
Bug: 10568538
Change-Id: I226cacf48cccba9671f09164bbb50380adc6b322
ScanResult should have timestamp in uS but we are getting age in ms
from the wifi driver - multiply to have the same units though not
the implied precision.
bug: 10410465
Change-Id: Idf5c5996d69a4793dae3d74edb790d40b9bd3298
java.lang.SecurityException: Operation not allowed
There was a situation I wasn't taking into account -- components
declared by the system has a special ability to run in the processes
of other uids. This means that if that code loaded into another
process tries to do anything needing an app op verification, it will
fail, because it will say it is calling as the system package name but
it is not actually coming from the system uid.
To fix this, we add a new Context.getOpPackageName() to go along-side
getBasePackageName(). This is a special call for use by all app ops
verification, which will be initialized with either the base package
name, the actual package name, or now the default package name of the
process if we are creating a context for system code being loaded into
a non-system process.
I had to update all of the code doing app ops checks to switch to this
method to get the calling package name.
Also improve the security exception throw to have a more descriptive
error message.
Change-Id: Ic04f77b3938585b02fccabbc12d2f0dc62b9ef25
