The method checkInterfacePresent seems that should return if the
interface is present or not, but it actually return an opposite
result. It may confuse the caller. E.g. The override method in
VpnTest assume it always returns true in the test. It will fail
the vpn start flow due to interface gone.
Bug: 169215213
Test: atest FrameworksNetTess
Change-Id: I3e9a64f0900336b8205674b94db68f090b4e9ff9
The utility classes are useful for mainline modules and their tests, for
example IpClientIntegrationTest.
Bug: 168868607
Test: m && atest NetworkStaticLibTests
Change-Id: If2b1613aa18a7990391e2d31cc2951ca93f1cf3c
This change reduces MTU/MRU values for racoon/pppd from 1400 to 1388 in
an attempt to fix keepalive issues experienced in the field.
Bug: 119076193
Test: Speculative change, original issues were not reproducible.
Change-Id: I7731503260fdc8bcbc6c5fcda6991ead6fb7c52e
This change updates the VPN state when IKEv2 sessions fail, and when
configuration errors occur.
Bug: 162289824
Test: Manual testing with IKEv2/PSK
Change-Id: I2e8c6f421d2898f97b0ac422b2276edf9ef923f1
In current design, crash has been generated when stop function
has been re-entered to catch unexpected behavior. However,
it is possible to re-enter stop function if the network
disconnection occurs after stopping.
Thus, skip stop if keepalive is already in stopping state.
Test: atest ConnectivityServiceTest#testNattSocketKeepalives \
--rerun-until-failure 60000
Bug: 167332570
Change-Id: Ic7068ad3dc990e957c37b8d87d48ebb6469b101f
* changes:
Update language to comply with Android's inclusive language guidance
Update language to comply with Android's inclusive language guidance
Update language to comply with Android's inclusive language guidance
Update language to comply with Android's inclusive language guidance
Update language to comply with Android's inclusive language guidance
Update language to comply with Android's inclusive language guidance
Update language to comply with Android's inclusive language guidance
Update language to comply with Android's inclusive language guidance
Currently, LockdownVpnTracker handles lockdown VPN reset intent.
Which will grab VPN object as a lock, then calls into
ConnectivityService to grab mVpn lock when querying NetworkInfo.
However, the order of grabing locks differs from ConnectivityService
and will causes deadlock if ConnectivityService grabs locks in
the other order.
Thus, make ConnectivityService handles reset intent so the
order of grabing locks can be consistent.
Test: atest FrameworksNetTests
Bug: 147403549
Change-Id: Ia10a3ef6f1e20d092a17313935083a84860961aa
Currently, if SIM is inserted but IMSI is not available, such
as SIM PIN locked state. Information of such SIM will still
be available but IMSI is not. Which makes
NetworkStatsSubscriptionMonitor failed to store IMSI locally
for later RAT type query. Hence, NETWORK_TYPE_UNKNOWN is
always returned for such SIM.
Skip the registration until the IMSI is available. This is safe
since there will be another onSubscriptionsChanged event when
that happens.
Test: enable SIM PIN and manually test
Test: atest NetworkStatsSubscriptionsMonitorTest#testSubscriberIdUnavailable
Test: ./out/host/linux-x86/bin/statsd_testdrive 10082
Bug: 160941101
Merged-In: I408379b3c432d9e62e0837d6b4f6551cc7838e29
Change-Id: I408379b3c432d9e62e0837d6b4f6551cc7838e29
(cherry-picked from ag/12400327)
Currently, the callbacks of stopping were fired when stop procedure
is started, because the upper layer apps only care about the reason
of stopping instead of stopping result. Thus, there is no need to
wait for the result comes back. However, this behavior generates
races if apps want to re-start keepalive immediately since the
resources are not released yet.
Fix: 134891441
Fix: 140305589
Test: atest com.android.server.ConnectivityServiceTest#testPacketKeepalives \
--rerun-until-failure 1000
Change-Id: I987776a9211a50e964c4675b747bc10e203750f1
