Print a dash for the unused "lastUsed" of the rule.
The age should not equal the bootime if the rule has never been
updated the "lastUsed" field.
Format:
[inDstMac] iif(iface) src -> nat -> dst [outDstMac] age
[00:00:00:00:00:00] 14(rmnet0) 140.112.8.116:443
-> 30(30) 10.170.56.233:43720
-> 192.168.45.236:43720 [be:34:40:28:33:5f] -
Bug: 190783768
Test: dumpsys tethering
Original-Change: https://android-review.googlesource.com/1751022
Merged-In: Ie771becd2f72518cf02a86e5ae228315785752a5
Change-Id: Ie771becd2f72518cf02a86e5ae228315785752a5
Allow stop TETHERING_NCM no matter ncm is used for TETHERING_USB or
TETHERING_NCM.
Add a test:
1. NCM is started for TETHERING_NCM
2. The config changes to use NCM for TETHERING_USB.
3. Then the config changes to use RNDIS for TETHERING_USB.
Also let some logs not only print in dumpsys, but also in logcat to
easiler debug unit test.
Bug: 185649441
Test: atest TetheringTests
Original-Change: https://android-review.googlesource.com/1740778
Merged-In: Ia8d76a29646f36941cbb16cd68ae6887100ec8ec
Change-Id: Ia8d76a29646f36941cbb16cd68ae6887100ec8ec
Previously, the hidden API encoding of the tethering boot dex jars,
i.e. those dex jars that tethering contributes to the bootclasspath
were done as part of the monolithic hidden API processing. This change
causes the encoding to be done by the tethering's
bootclasspath_fragment.
This change involves the following:
* Addition of the fragments property to the tethering's
bootclasspath_fragment module to list all the other
bootclasspath_fragment modules on which this depends.
* Addition of the additional_stubs property to add stubs for APIs that
are not provided by another bootclasspath_fragment.
* Moving hidden API flag file entries related to tethering from the
flag files in frameworks/base/boot/hiddenapi directory into the
tethering directory with an appropriate OWNERS file to allow them to
be managed by the Soong and compat team.
* Addition of a PREUPLOAD.cfg hook script to ensure that the flag files
are sorted.
The build automatically checks that the hidden API flags which are
computed by tethering and encoded into its boot dex jars match those
that are generated by the monolithic processing so this is guaranteed
to be safe.
Bug: 179354495
Test: m com.android.tethering
- ensure that the generated APEX is byte-for-byte identical
before and after these changes.
m out/soong/hiddenapi/hiddenapi-flags.csv
- make sure that they are not changed by this.
Change-Id: I4d9621325c7fcea5043cbca4c577ba2ac6125c0c
Ignore-AOSP-First: merge conflicts
The condition for deleting IPv4 forwarding rules.
1. When the tethering client has gone, deletes the client and its
rules.
2. When the upstream has gone, deletes all rules.
3. When the upstream has changed, deletes all rules.
Test: atest TetheringCoverageTests and check IPv4 offload rules
via dumpsys tethering in the following test cases.
Bug: 190783768
Test cases:
a. Loss upstream interface while tethering
1. Enable WIFI tethering
2. Disable upstream interface
3. Check the rules are removed.
b. Loss downstream interfaces while tethering
1. Enable WIFI tethering
2. Enable BT tethering
3. Disable BT tethering
4. Check the BT tether rules are removed.
5. Disable WIFI tethering
6. Check the WIFI tether rules are removed.
c. Switch upstream interface while tethering
1. Enable WIFI tethering
2. Enable BT tethering
3. Switch upstream interface from cellular to wifi.
4. Check all rules are removed.
d. Enable NAT failure (manual)
Log:
The rule deletion in each case.
- IpServer#stopIPv4: case b and case d.
- BpfCoordinator#updateUpstreamNetworkState: case a and case c.
Test case a
06-23 09:58:59.245 [...] Tethering: [BpfCoordinator]
updateUpstreamNetworkState tetherOffloadRule4Clear wlan2
Test case b
06-07 22:17:51.886 [..] Tethering: [bt-pan] cleanupUpstream bt-pan
06-07 22:17:51.888 [..] Tethering: [bt-pan] stopIPv4 bt-pan
06-07 22:18:23.769 [..] Tethering: [wlan2] cleanupUpstream wlan2
06-07 22:18:23.772 [..] Tethering: [wlan2] stopIPv4 wlan2
Test case c
06-08 11:11:48.277 [..] Tethering: [BpfCoordinator]
updateUpstreamNetworkState tetherOffloadRule4Clear bt-pan
06-08 11:11:48.396 [..] Tethering: [BpfCoordinator]
updateUpstreamNetworkState tetherOffloadRule4Clear wlan2
06-08 11:11:48.579 [..] Tethering: [wlan2] cleanupUpstreamInterface
wlan2
06-08 11:11:48.808 [..] Tethering: [bt-pan] cleanupUpstreamInterface
bt-pan
Enabling NAT failure
06-08 13:04:18.117 [..] Tethering: [wlan2] Exception enabling NAT [..]
06-08 13:04:18.234 [..] Tethering: [wlan2] cleanupUpstream wlan2
06-08 13:04:18.246 [..] Tethering: [wlan2] stopIPv4 wlan2
Original-Change: https://android-review.googlesource.com/1579873
Merged-In: Id505a3deb277bbe0f44403234d8ca8bbf01eec80
Change-Id: Id505a3deb277bbe0f44403234d8ca8bbf01eec80
tryCell configuration would not be force disabled UpstreamMonitor stop.
If tethering stop with using mobile upstream and swap with SIM fron no
dun to dun supported, dun request would be filed even tethering is not
active.
Bug: 173068192
Test: atest TetheringTests
Original-Change: https://android-review.googlesource.com/1715791
Merged-In: I5505655f52da9fdca2fd43a58e043a9ab727741d
Change-Id: I5505655f52da9fdca2fd43a58e043a9ab727741d
This is a op CL which prepare for refactor.
Bug: 185649441
Bug: 189410000
Bug: 178116595
Test: atest TetheringTests
Original-Change: https://android-review.googlesource.com/1730548
Merged-In: I270ff43c01736b9d18bd40a8e88e1379e9e4e863
Change-Id: I270ff43c01736b9d18bd40a8e88e1379e9e4e863
Adding the configuration to decide using rndis or ncm for usb tethering.
If ncm is configured for TETHEIRNG_USB, then TETHERING_NCM is not
available.
Bug: 162920185
Test: atest TetheringTests
manul testing usb tethering
Original-Change: https://android-review.googlesource.com/1730541
Merged-In: Ifc7eee2457a950a0e2d1c3cc89a3373a7ad23c9c
Change-Id: Ifc7eee2457a950a0e2d1c3cc89a3373a7ad23c9c
The current code does not print these correctly: it prints the
public address twice and then the NAT address. Fix this to print
the src, nat, and dst addresses.
Also dump the output MAC address.
Example output:
IPv4 Upstream: [inDstMac] iif(iface) src -> nat -> dst [outDstMac] age
[66:f1:6f:d8:66:0a] 31(31) 192.168.146.173:48594 -> 11(rmnet_data1) 100.100.109.185:48594 -> 8.8.8.8:853 [00:00:00:00:00:00] 32305ms
[66:f1:6f:d8:66:0a] 31(31) 192.168.146.173:45806 -> 11(rmnet_data1) 100.100.109.185:45806 -> 8.8.4.4:853 [00:00:00:00:00:00] 32305ms
IPv4 Downstream: [inDstMac] iif(iface) src -> nat -> dst [outDstMac] age
[00:00:00:00:00:00] 11(rmnet_data1) 8.8.8.8:853 -> 31(31) 100.100.109.185:48594 -> 192.168.146.173:48594 [0e:a8:7f:ba:76:48] 32305ms
[00:00:00:00:00:00] 11(rmnet_data1) 8.8.4.4:853 -> 31(31) 100.100.109.185:45806 -> 192.168.146.173:45806 [0e:a8:7f:ba:76:48] 32305ms
Test: manual
Bug: 190783768
Original-Change: https://android-review.googlesource.com/1737399
Merged-In: I93a82064c95027c7c63cb30baf8482ecddcbd09d
Change-Id: I93a82064c95027c7c63cb30baf8482ecddcbd09d
1. Dump both upstream and downstream rules.
2. Also dump rule last used time.
Test: manual
Bug: 190783768
Original-Change: https://android-review.googlesource.com/1737394
Merged-In: I3fffbf4a5dea68e61349de8b41bea49b8a319f86
Change-Id: I3fffbf4a5dea68e61349de8b41bea49b8a319f86
This provides a better way to tell whether traffic is flowing.
Test: manual
Bug: 190783768
Original-Change: https://android-review.googlesource.com/1737393
Merged-In: If557b0a18fc0aea1bf6a65d91547fc1930098ed0
Change-Id: If557b0a18fc0aea1bf6a65d91547fc1930098ed0
Currently, when a network that uses 464xlat is torn down,
NetworkCallbacks will receive onLinkPropertiesChanged after
onLost. This is confusing and incorrect.
The incorrect callback is sent because handleLinkProperties
checks that the netId of the agent still exists, not that the
NetworkAgent is still registered. This is normally correct,
because the NetworkAgent is removed from mNetworkAgentInfos and
the netId are removed from mNetworkForNetId by the same method,
disconnectAndDestroyNetwork.
In this specific case it's not correct, because the call to
handleUpdateLinkProperties is from disconnectAndDestroyNetwork
itself via nai.clatd.update and calls Nat464Xlat#stop.
No other callers of handleUpdateLinkProperties are affected
because:
- EVENT_NETWORK_PROPERTIES_CHANGED is called only by
maybeHandleNetworkAgentMessage, which first checks that the
NetworkAgent is registered.
- handlePrivateDnsSettingsChanged only looks at registered
NetworkAgents (it loops over mNetworkAgentInfos).
- handlePrivateDnsValidationUpdate, handleNat64PrefixEvent and
handleCapportApiDataUpdate call getNetworkAgentInfoForNetId,
which will correctly determine that the agent is no longer
registered, since they run on the handler thread and thus
cannot run at the same time as disconnectAndDestroyNetwork.
The existing code contains a check for the netId being current.
This is intended to ensure that an update from a NetworkAgent
cannot affect another agent with the same Network. This extra
check is not necessary, because code running on the handler
thread can never observe a NetworkAgent in mNetworkAgentInfos
unless mNetworkForNetId maps that NetworkAgent's Network to that
NetworkAgent. This is because mNetworkForNetId is updated by the
same methods as mNetworkAgentInfos, and those updates occur on
the handler thread. So all code on the handler thread will see
those two as consistent.
Bug: 176496580
Test: atest FrameworksNetTests CtsNetTestCases HostsideVpnTests
Original-Change: https://android-review.googlesource.com/1727829
Merged-In: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
Change-Id: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
after this:
diff system/netd/bpf_progs/bpf_net_helpers.h packages/modules/Connectivity/Tethering/bpf_progs/bpf_net_helpers.h
shows no diff, besides a switch to '#pragma once'
as the include guard.
Test: builds, atest, TreeHugger
Bug: 177884581
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Original-Change: https://android-review.googlesource.com/1733033
Merged-In: Ib943321d46254ba64ce206fb9e3b3414d15e4d45
Change-Id: Ib943321d46254ba64ce206fb9e3b3414d15e4d45
The stable connectivity shims are updated to now contain S API, so
tethering tests that assumed that compatibility R behavior was used need
to be updated.
To avoid such failures Tethering tests should have a test target using
updated shims (TetheringNextTests), but this was not done in S
timeframe.
Ignore-AOSP-First: topic needs differences in AOSP
Bug: 189581241
Test: atest TetheringTests
Change-Id: Ibc04e64a1e9d82b67aff10d1a6d77f9e6b1bbdfb
To avoid log flooding, suppress CMD_IPV6_TETHER_UPDATE and
CMD_NEIGHBOR_EVENT message log because they appear frequentlg and
don't have any content which means they are ueseless for debugging.
Also remove logMessage from BaseServingState to fix duplicated
message because all the message already log in TetheredState
and LocalHotspotState which inherit BaseServingState.
Bug: 162920185
Bug: 185649441
Test: atest TetheringCoverageTests
atest MtsTetheringTestLatestSdk
atest CtsTetheringTest
Change-Id: Ib8fe719f3c1c4a65e6b5152df5e5adf33aba2079
Merged-In: Ib8fe719f3c1c4a65e6b5152df5e5adf33aba2079
Since tethering run in single thread without any synchronized lock,
remove "Locked" wording from the methods which the use lock before.
Bug: 162920185
Test: atest TetheringCoverageTest
Change-Id: Ia8c057800cab30cdcbacae4db2d706b6427e9861
Merged-In: Ia8c057800cab30cdcbacae4db2d706b6427e9861
startTrackDefaultNetwork was allowed to called multiple times
before even though there is no one actually do it. However,
in the TetheringTest#verifyDefaultNetworkRequestFiled, a
manual invocation is used to ensure that function supports
multiple entrance.
But with aosp/1697371, startTrackDefaultNetwork is no longer
allowed to be called multiple times, it would lead to log.wtf
and crash system in eng build.
Since the manual invocation of startTrackDefaultNetwork is not
realistic and no longer valid anymore, remove the invocation
that caused the trouble.
Test: atest TetheringCoverageTests
Bug: 188613493
Merged-In: I61f6088783d521fd17ae1e87370842b4239fbe75
Change-Id: I61f6088783d521fd17ae1e87370842b4239fbe75
(cherry-picked from aosp/1711433)
The existing isWifiTetheringSupported only check if tethering side
supports wifi tethering or not but not wifi side. A expected
behavior should include both of them, so add the wifi side check
into the helper function. Also update in the existing caller side
due to a new parameter added.
Bug: 186061922
Test: atest MtsTetheringTestLatestSdk
Megred-In: Id69ac1d30ab2bbf23e870193335b139f54672636
Change-Id: Id69ac1d30ab2bbf23e870193335b139f54672636
Ignore-AOSP-First: cherry-pick
Allows SdkExtensions to inspect its version to decide what the extension
sdk version is on-device.
Bug: 188787081
Test: m com.android.tethering and inspect
Ignore-AOSP-first: internal topic, will cherry-pick after submission
Change-Id: If2d28b02be871594fed1fbb40b7aad284b553afb
Fix memory access violation in com_android_networkstack_tethering_BpfUtils.cpp
caused by invalid format string in com_android_networkstack_tethering_BpfUtils_isEthernet.
If rv is not valid, jniThrowException will format a string using
"Unknown hardware address type %s on interface %s". However, rv is an int but here
"%s" is used in fmt string, thus causing access violation of memory.
Use "%d" instead of "%s" for int.
Bug: 188757793
Original-Change: https://android-review.googlesource.com/1715797
Merged-In: I9d8ec0708efd747e24b3b3ffed5336434d4f64a7
Change-Id: I9d8ec0708efd747e24b3b3ffed5336434d4f64a7
The old callback only report interface list, new callback could provide
the mapping of interface and type. Replace old callback usage in cts
with new callback and check whether old callback could get the correct
interface list by comparing the result between old and new callback.
Bug: 162920185
Bug: 152203943
Test: atest CtsTetheringTest on S
atest CtsTetheringTestLatestSdk on R
atest MtsTetheringTestLatestSdk on S and R
Ignore-AOSP-First: Its dependences CL is not in aosp currently.
Change-Id: I2a0b8c43fb340c3eaed7f0f90464199222a24280
The change aosp/1708088 break tethering unit test in R.
Bug: 187946226
Test: atest TetheringTests in R and S
Change-Id: I4eb4b757f6d7cd3458964c81310dcf0687a4f091
Merged-In: I4eb4b757f6d7cd3458964c81310dcf0687a4f091
Before this change, tethering always report a list of tethered
interfaces and the caller need to use each tethering type's interface
regex to matching tethered list to manual implement the mapping of
tethering type and interface. This change allow caller to get rid of
tethering interface regex.
Bug: 162920185
Bug: 152203943
Test: atest CtsTetheringTest on S
Ignore-AOSP-First: Currently aosp would automerge to mainlne-prod, merge
to sc-dev first to avoid adding new API to mainline-prod
CTS-Coverage-Bug: I already add cts test(ag/14622456), but Lint
still complaint because my cts is under packages/modules/Connectivity/
but it only check whether CL touching platform/cts
Change-Id: I91bcccd676d109c1b974497ac29bd366a41b8899
