There is a new transport type - TRANSPORT_USB(8) in Android S,
so when the test tries to add this new transport type in older
Android version, it cannot pass the transport type validation and
make test fail.
(clean cherry-pick of change in downstream branch history)
Original change ID before project move:
I38816173b04ea198d99f64f45e9271ac2641e4ac
Bug: 184158327
Test: run CtsNetTestCasesLatestSdk on Android R & Q
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ib0368241771d287c09c0e4463f91122533f85a27
Bpf offload do not support VCN network yet, don't start bpf offload
if the interface is ipsec*.
Bug: 191178945
Test: atest TetheringTests
Change-Id: I1ad8cededddec42f45b08aaa31d583c548d105f0
This is fixing post-FIN state (by disabling offload post-FIN).
Once the tcp state enters half-closing tcp state (fin wait,
close wait), delete the offload rules.
From this commit, we have done the short term solution for conntrack
tcp timeout issue. Here is what we have done so far.
- Stop updating tcp timeout to avoid updating wrong tcp state
timeout.
- Update the ESTABLISHED timeout
nf_conntrack_tcp_timeout_established (432000) after adding
bidirectional rules.
- Delete the tcp rules when the tcp state has left
"established".
Here is the long term solution and need to be addressed in follow up
commits.
- Parse the tcp state from netlink conntrack event.
- Build a mapping to trace the tcp state of the tcp conntrack event.
- Update tcp state timeout for {ESTABLISHED (432000), FIN_WAIT (120),
CLOSE_WAIT (60)}.
Bug: 190783768
Bug: 192804833
Test: atest TetheringCoverageTests
Manual test:
1. Browse on tethered device
2. Check conntrack tcp state is established.
$ cat /proc/net/nf_conntrack
ipv4 2 tcp 6 431995 ESTABLISHED src=192.168.207.9
dst=140.112.8.116 sport=50697 dport=443 ..
3. Check offload rules are added via dumpsys.
Upstream:
tcp .. 192.168.207.9:50697 -> 14(rmnet0) 10.224.1.247:50697
-> 140.112.8.116:443 ..
Downstream:
tcp .. 140.112.8.116:443 -> 30(30) 10.224.1.247:50697
-> 192.168.207.9:50697 ..
4. Stop browsing for a few seconds.
5. Check conntrack tcp state is half-closed.
$ cat /proc/net/nf_conntrack
ipv4 2 tcp 6 116 TIME_WAIT src=192.168.207.9
dst=140.112.8.116 sport=50697 dport=443 ..
5. Check offload rules are removed via dumpsys.
Upstream:
(not found)
Downstream:
(not found)
Change-Id: I07e27230bf8952acd7828d1f605167758b3bc490
Needed because a payload data packet may have gone through
non-offload path, before we added offload rules, and that this
may result in in-kernel conntrack state being in ESTABLISHED
but pending ACK (ie. UNACKED) state. But the in-kernel conntrack
might never see the ACK because we just added offload rules.
As such after adding the rules we need to force the timeout back
to the normal ESTABLISHED timeout of 5 days.
Issue: the timeout is set to unacknowledged 300s (countdwon to 298s)
$ adb shell cat /proc/net/nf_conntrack
ipv4 2 tcp 6 298 ESTABLISHED src=192.168.244.128
dst=140.112.8.116 sport=45694 dport=443 ..
Test: atest TetheringCoverageTests
Manual check:
$ adb shell cat /proc/net/nf_conntrack
ipv4 2 tcp 6 431988 ESTABLISHED src=192.168.40.162
dst=140.112.8.116 sport=40774 dport=443 ..
Bug: 190783768
Bug: 192804833
Change-Id: I8c34e85e26c9d976e5e2b85473db75ff46d8abd4
This is a preparation for only update the tcp timeout while
adding rules. Also add slack time for updating UDP timeout
interval.
Bug: 190783768
Bug: 192804833
Test: atest TetheringCoverageTests
Change-Id: I3151b531e6581e257f3cfa39ad2fcf1650358b3d
This ensures classes are used from the service-connectivity jar, instead
of using classes from the system_server bootclasspath when there is a
name conflict.
Any developer adding a future class should do so in a subpackage of
com.android.connectivity (such as com.android.connectivity.server).
Otherwise, jarjar rules need to be added manually until b/180995093 is
fixed.
Also update current jarjar rules so that classes are jarjared to
com.android.connectivity.[original name], making it easier to find the
original source. This is consistent with the wifi module.
Bug: 193086215
Test: atest CtsNetTestCases
dexdump on service-connectivity.jar shows no classes outside of
com.android.connectivity and com.android.server
Change-Id: I2aadeca32751267b74d4fd2fd93bb3e8c62e46c0
Currently netd supports only the default value for VPN but CS
send priorty value 1 to netd. It will break the default routing
for VPN. Thus, update network preference priority value to 0 for
VPN.
Bug: 193245476
Test: atest CtsHostsideNetworkTests:HostsideVpnTests
Change-Id: I197cb358e8e30355fbf675e4c623abebe7abdb7f
- Remove ipv4MappedAddressBytesToIpv4Address because it can be covered
by parseIPv4Address.
- Remove IllegalArgumentException from parseIPv4Address because it has
never happened
- Reverse the order of upstream and downstream timeout refreshing in
refreshAllConntrackTimeouts for readability because both source and
destination of the downstream are opposite direction to the
upstream.
Bug: 190783768
Bug: 192804833
Test: atest TetheringCoverageTests
Change-Id: I6a1e44777a4357dd3847c2e2bb1fc6c3cf01617c
Internal utils are generally jarjared by connectivity jarjar rules, but
ArrayUtils is not actually statically linked into the tests, so this
makes the ConnectivityCoverageTests fail. FrameworksNetTests has been
fine because it does not use jarjar, but does not exercise updated code
because of that.
Remove usage of the hidden utility, as there are reasonable alternatives
with non-hidden APIs that avoid other breakages long-term.
Bug: 187935317
Test: atest ConnectivityCoverageTests:ConnectivityServiceTest
Change-Id: I8ed85b941c3d1028771a5ac33196b1509a95789d
Rename net-module-utils-srcs to connectivity-module-utils-srcs.
This is done as the module utils are made specific to
service-connectivity to contain only classes used by
service-connectivity.
Bug: 192998401
Test: Tests prepared in next change
Change-Id: I354f4b84aa90cc12579c4db5479cf2de1dc9cf5d
registerSystemDefaultNetworkCallback no longer throws
UnsupportedApiLevelException as it has compatibility behavior down to Q,
so remove the catch clause for the checked exception.
The exception would previously not be thrown since the Tethering module
is only running on R+.
Bug: 182961265
Test: atest TetheringTests
Change-Id: I3c58235f3a59294995e5f32502fec6ccd17a3cf0
- Add a new transport type for USB and a new network capability
to support automotive head unit.
- In order to pass DnsManagerTest#testTransportTypesEqual, Android.bp
needs to link to dnsresolver_aidl_interface-V8-java. That test checks
whether the TRANSPORT types defined in NetworkCapabilities are the
same as IDnsResolver.aidl.
(clean cherry-pick of change in downstream branch history, original
change ID before project move:
Iec2df09a776d779108f95098e01b7ffdf6f8867a)
Bug: 181742019
Test: atest FrameworksNetTests
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ie438ec68577ebdaaf990795fa27f1169b0105411
When NetworkRequestInfo#binderDied is called in ConnectivityService,
only pass the NRI to handleRemoveNetworkRequest. This is to prevent a
potential crash when unlinkDeathRecipient is called twice for the same
NRI.
Also, as a cleanup, don't iterate mRequests in the log message on binderDied.
As per the bug, the chain of events leading to a potential crash are:
- `Connectivity.NetworkRequestInfo#binderDied()` is called for an NRI
tracking multiple `NetworkRequest` items. This can happen for a TRACK_DEFAULT
request filed by a UID on a different preference than the default, which
copies the request list.
- This in turn triggers multiple `EVENT_RELEASE_NETWORK_REQUEST` events
for the same NRI, one for reach `NetworkRequest` tracked.
- When handling `EVENT_RELEASE_NETWORK_REQUEST`, each `NetworkRequest`
that is passed in will then be used to look up the parent NRI that originally
sent it to be released.
- Therefore if an NRI was tracking three requests, it would trigger three
release network events, then each request would be used to look up the
same NRI again when handling said release event.
- Finally, `ConnectivityService.NetworkRequestInfo#unlinkDeathRecipient` is
called for the NRI in question. Using the scenario above, that means we could
call `unlinkDeathRecipient` multiple times for the same NRI if it was tracking
multiple network requests causing the associated crash.
- If `unlinkDeathRecipient` is called more than once for the same NRI, it will
cause the crash listed in this bug.
- The fix is to only call handleRemoveNetworkRequest for the NRI once. This
works since when removing the NRI, we iterate over all of its requests to
remove them. By only calling handleRemoveNetworkRequest once, it's ensured
`unlinkDeathRecipient` for this NRI as part of
`Connectivity.NetworkRequestInfo#binderDied()` is only called once and not
potentially multiple times.
Bug: 185541983
Test: atest FrameworksNetTests
Change-Id: I2a2ad4ec6d415423182a1856a898779203658f8b
