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
Change-Id: I93a82064c95027c7c63cb30baf8482ecddcbd09d
1. Dump both upstream and downstream rules.
2. Also dump rule last used time.
Test: manual
Bug: 190783768
Change-Id: I3fffbf4a5dea68e61349de8b41bea49b8a319f86
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
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
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
Change-Id: I944f4c6ad36206bdccd85a6ea7ef71324a29c685
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
Merged-In: I91bcccd676d109c1b974497ac29bd366a41b8899
Change-Id: I91bcccd676d109c1b974497ac29bd366a41b8899
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
Change-Id: I5505655f52da9fdca2fd43a58e043a9ab727741d
Replace the isFeatureEnabled function which is check with apex version.
Bug: 187946226
Test: Set device config flag and check the result
Change-Id: Iba44a01e2fdd0698dcb338ea4a8fe8147cbaa7dd
While the actual part that track default request is inside
UpstreamNetworkMonitor, instead of passing it from Tethering,
move it into counter-part CL and use it from
UpstreamNetworkMonitor.
Since the current code is replaced by registerSystemDefaultCallback
in Android S, implement it inside the api30 shim implementation
to provide an unified interface to tethering.
Test: atest TetheringCoverageTests
Bug: 185952829
Change-Id: Iaf21b6b662aa6aba79c2b75379128b8523f81f02
This is no longer necessary as all the methods that take it are
running on on the handler thread, either in Tethering itself or
on the state machine thread in IpServer, which runs on the same
thread as Tethering.
Specifically:
- interfaceStatusChanged, interfaceAdded, interfaceRemoved,
interfaceLinkStateChanged: run from mNetdCallback, which always
posts them to mHandler.
- setWifiTethering: only called by enableTetheringInternal, which
is called by the following:
- startTethering, stopTethering: via lambda posted to mHandler
- IpServerCallback#requestEnableTethering: called by IpServer
while processing a command.
- setEthernetTethering: only called by enableTetheringInternal.
- EthernetCallback: runs on mExecutor, which posts to mHandler.
- getLastTetherError: only used by the test. Renamed to
getLastErrorForTest to ensure no other callers.
- sendTetherStateChangedBroadcast: called only by
notifyInterfaceStateChange, which is called only by
- IpServerCallback#updateInterfaceState, which is called only
by sendInterfaceState, which is called by various IpServer
state enter methods.
- notifyLinkPropertiesChanged: called only by
IpServerCallback#updateLinkProperties, which is only called by
IpServer#sendLinkProperties, which is only called by:
- Code that processes CMD_IPV6_TETHER_UPDATE
- IpServer#handleNewPrefixRequest: only called when processing
CMD_NEW_PREFIX_REQUEST.
- IpServer#sendInterfaceState (see above)
- handleWifiApAction, handleWifiP2pAction: only called by
mStateReceiver, which runs on the handler thread
- tether(String, int): called by:
- tether(String, IIntResultListener): posted to mHandler
- changeInterfaceState: called by:
- EthernetCallback (see above)
- enableWifiIpServingLocked: called by handleWifiApAction and
handleWifiP2pAction (see above)
- tetherMatchingInterfaces: only called by handleUsbAction,
which is run from mStateReceiver on the handler thread.
- untether(String): called by:
- untether(String, IIntResultListener): posted to mHandler
- changeInterfaceState (see above)
- setUsbTethering: called by:
- setUsbTethering(boolean, IIntResultListener): posted to mHandler
- enableTetheringInternal (see above)
- setNcmTethering: called by enableTetheringInternal (see above)
- getTetheredIfaces: called only by TetheringTest. Renamed to
getTetheredIfacesForTest to ensure no other callers.
- getErroredIfaces: unused, deleted in this CL
- getTetheredIfaces: called by:
- isTetheringActive: called by onUserRestrictionsChanged, which
is only called by mStateReceiver
- TetheringTest
- dump(): changed to run on handler thread
- upstreamWanted: called by
- TetherModeAliveState#enter
- TetherModeAliveState#updateUpstreamWanted, which is called
only by TetherModeAliveState#processMessage.
Test: atest TetheringCoverageTests
Test: enabled/disabled hotspot, USB tethering
Change-Id: Id49d33f027b8df4c97fda480ff239c0ba90bb96a
This is in preparation for removing mPublicSync.
Test: m
Test: adb shell dumpsys tethering
Test: atest TetheringTests TetheringIntegrationTests
Change-Id: Ib2c9d0bff23614f76c8e075d32cb03412d3d21f7
Some OEM may have special mobile data icon show up when non-default
(e.g. DUN) mobile connection connected even wifi is also connected.
So always connected DUN may let user hard to distinguish tethering
upstream in those OEM's devices. Also release unused mobile connection
may safe power.
This CL removes unnecessary code from selectPreferredUpstreamType.
In particular:
- When a DUN or HIPRI upstream is selected, calling
registerMobileNetworkRequest is unnecessary. A mobile
NetworkRequest is always registered unless a non-mobile upstream
is selected.
- When a non-mobile upstream is found, releasing the mobile
NetworkRequest is unnecessary in selectPreferredUpstreamType
because it will be done by chooseUpstreamType immediately after
selectPreferredUpstreamType returns.
- When no upstream is found and cellular upstream is not permitted,
it is not necessary to release the mobile NetworkRequest. When
cellular is not permitted, no such NetworkRequest will be filed
because registerMobileNetworkRequest checks with EntitlementManager
before actually requesting the network. If cellular becomes the
upstream and then later becomes not permitted because of an
entitlement failure, all tethering will be stopped by Settings.
Note: currently legacy upstream selection has two known bugs:
1. If mobile has higher priority than non-mobile network, mobile request
should never be released and always prefer use mobile. But in practice,
mobile request would be released when tethering select non-mobile network
as upstream.
2. If mobile has higher priority than wifi network and default network
is wifi but mobile is still connected, tethering would choose mobile as
upstream because it has higher priority. Mobile disconnecting may not
trigger tethering to switch its upstream to wifi because currnetly
tethering rely on CONNECTIVITY_ACTION broadcast to handle upstream
disconnect.
Bug: 173068192
Test: atest TetheringTests
Change-Id: Id5df58af830cc534ecd79041ddf8a04171047e9b
This is useful for OEMs that want to use RNDIS or NCM as a
local-only link that is directly connected to some other host.
This can be used to implement USB tethering using NCM, which
currently only supports local-only mode.
Bug: 175090447
Test: TetheringIntegrationTests:EthernetTetheringTest#testLocalOnlyTethering
Change-Id: I0ffaa46e4640e5b235340a15d25909106ceb0c07
When a 464xlat upstream disconnects, onLinkPropertiesChanged is
called after onLost. This breaks an UpstreamNetworkMonitor
assumption that no callback will ever arrive after onLost.
Bug: 173068192
Fix: 185117377
Test: new unit test
Change-Id: I4ff1eca6d5ed1680ff716c71b683891c8a0e5a77
Current upstream selection code suffers from a race where if the
CONNECTIVITY_ACTION broadcast for a given network switch is
received and processed before the NetworkCallbacks for that
network switch, upstream selection just re-selects the same
upstream it had before. The incorrect upstream persists until
another CONNECTIVITY_ACTION is received.
Fix this by defining a new EVENT_DEFAULT_SWITCHED message code
communicated from UpstreamNetworkMonitor to Tethering, and send
that whenever the default network switches.
The message is sent in onLinkPropertiesChanged, because the
tethering code stores all information about networks in an
UpstreamNetworkState structure that contains Network,
LinkProperties and NetworkCapabilities. When a network switch
occurs, onLinkPropertiesChanged always follows onAvailable and
onCapabilitiesChanged, and thus marks the first point in time
when all the information is available.
This CL tries not to change existing codepaths too much, but
it does move the update of mDefaultInternetNetwork from
onCapabilitiesChanged to onLinkPropertiesChanged. This should
not be a problem because the only thing that reads
mDefaultInternetNetwork is getCurrentPreferredUpstream, which,
in the case of a default network switch, will be run by the
onLinkPropertiesChanged which will immediately follow.
Bug: 173068192
Test: changes to existing unit tests show bug is fixed
Change-Id: Ic9196bc92892811b25bda463ffd839ee5c19d294
This is needed for forwarding to work, so it should be dumped.
New output:
Forwarding rules:
29(29) -> 14(rmnet2) 86dd 00:00:00:00:00:00 00:00:00:00:00:00
[ap_br_wlan2]: iif(iface) oif(iface) v6addr srcmac dstmac
14(rmnet2) 29(ap_br_wlan2) 2001:240:2423:13fa:3c21:e35a:6a59:ff8a da:17:fd:70:3d:14 26:5b:b2:ee:bc:ba
IPv4: [inDstMac] iif(iface) src -> nat -> dst
[da:17:fd:70:3d:14] 29(29) 192.168.222.151:39208 -> 14(rmnet2) 100.102.14.231:39208 -> 172.217.175.3:80
[da:17:fd:70:3d:14] 29(29) 192.168.222.151:47386 -> 14(rmnet2) 100.102.14.231:47386 -> 216.58.197.196:443
Also add a call to getHostAddress() to remove the / on IPv6
forwarding rules.
Test: manual
Change-Id: I347ea5a3fd88c51f1fae0c76c75dfa30c68a55ad
Add a unit test to verify that BPF coordinator access downstream4
and upstream4 map while the conntrack event was received.
Verify shim API for IPv4:
- tetherOffloadRuleAdd
- tetherOffloadRuleRemove
- tetherOffloadGetAndClearStats
- tetherOffloadSetInterfaceQuota
- isAnyIpv4RuleOnUpstream
Test: atest TetheringCoverageTests
Change-Id: Ia57f07990d8750fd6ff67d7f4a18aa610336024a
Required because XDP offload needs input interface mac address
to be a part of the key. The mac address is used for checking
packets which are received from exceped input interface.
Test: atest TetheringCoverageTests, TetheringPrivilegedTests
Change-Id: Ied159454b516c0d70efe0a85744d1bb606892f2d
Currently, BpfCoordinator only sets the data limit on a given
upstream whenever the first IPv6 rule is created on that
upstream, and clears it whenever the last rule is deleted on that
upstream. It never does this when adding or removing IPv4 rules.
This makes it impossible to offload traffic on IPv4-only
networks.
Fix this by setting the limit when IPv4 rules are created or
deleted as well.
Test: atest TetheringCoverageTests
Manual tests as the follows
Test {add, clear} limit with IPv6-only network [OK]
Test {add} limit with IPv4-only upstream [OK]
TODO:
Test {clear} limit with IPv4-only network. blocked by aosp/1579873
because the IPv4 rules have never deleted.
Change-Id: I5a29bdd18e564318759f617023163e23fb5a3ed0
Currently, Tethering files NetworkRequests even when
config_tether_upstream_automatic is enabled. This is incorrect:
when the automatic upstream selection is enabled, the tethering
upstream should always follow the default network and there is
no need to file any requests.
These requests are harmful when tethering is not using cellular
as its upstream, because:
- If the device does not use mobile data always on, the request
causes the cellular network to be brought up, causing power
draw.
- Even if the device does use mobile data always on, the request
causes the cellular network to come to the foreground, which
allows all apps to access it, causing potential data usage.
Amend the existing testGetCurrentPreferredUpstream to cover these
changes, by making that test case always set automatic upstream
mode. This does not result in any loss of meaningful test
coverage, because getCurrentPreferredUpstream is only ever called
when chooseUpstreamAutomatically is enabled.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I068a5338699a3ed04f24f97f785ea89ff5890e50
UpstreamNetworkMonitor is the part of tethering that files
NetworkRequests for upstream netwoks, but it currently does not
know all the requirements for upstream selection. For example, it
does not know whether automatic upstream selection is in use.
This forces the upstream selection code to be split between
UpstreamNetworkMonitor and Tethering. This makes it difficult to
follow.
This CL ensures that all information about upstream requirements
(DUN required, automatic upstream selection, tryCell) is passed
to UpstreamNetworkMonitor so it can be aware of it.
This CL also removes the ability for UpstreamNetworkMonitor's
callers to call registerMobileNetworkRequest or
releaseMobileNetworkRequest. In a future CL, this will be
automatically done by UpstreamNetworkMonitor depending on the
upstream requirements.
This CL is a no-op refactoring with no behaviour changes.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I174f765c616e0dbe2aa493c12613e6131cff0666
TrafficStatsConstants.TAG_SYSTEM_NEIGHBOR is moved to
NetworkStackConstants so update the import class name for it.
Bug: 182349970
Test: FrameworksNetTests
NetworkStackTests
TetheringTests
Change-Id: I8fcd2772ed873d318233d3029184e4352245d4cd
Merged-In: I8fcd2772ed873d318233d3029184e4352245d4cd
Starting conntrack event monitor on R devices is unnecessary because
no code uses them.
Bug: 177884581
Test: atest TetheringCoverageTests
Change-Id: I036cb8e29b32a4e220da9a52849b978a6ab821e4
Opening the maps on R devices is unnecessary (because no code
uses them) and unsafe (because the maps might actually be in a
different format than expected by the module).
Always return null when opening the maps, so the code will safely
fall back to using netd for anything.
This only affects dump(). The production code never opens the
maps except via the shim, and only the S shim opens the maps.
Also check isAtLeastS in dumpCounters, because it opens the map
directly.
Bug: 177884581
Test: builds, boots, "dumpsys tethering" shows expected output
Change-Id: I5884490a5cc40fc529a12100ae5baaeae6a18f30
Migrate Maze's BPF program attaching and detaching functions from
system/netd/server/OffloadUtils.{c, h} to tethering module.
Test: atest TetheringCoverageTests
Test case #1:
Enable WiFi hotspot and check tc filters are added or removed on both
wlan1 and rmnet_data#.
$ adb shell tc filter show dev wlan1 ingress
filter protocol ipv6 pref 1 bpf chain 0
filter protocol ipv6 pref 1 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_upstream6_ether:[*fsobj] direct-action
not_in_hw id 2 tag 7cf020cc09a7c982
filter protocol ip pref 2 bpf chain 0
filter protocol ip pref 2 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_upstream4_ether:[*fsobj] direct-action
not_in_hw id 7 tag 2f87d55b636c082c
$ adb shell tc filter show dev rmnet_data2 ingress;
filter protocol ipv6 pref 1 bpf chain 0
filter protocol ipv6 pref 1 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_downstream6_rawip:[*fsobj] direct-action
not_in_hw id 3 tag 8b3885b75bd261de
filter protocol ip pref 2 bpf chain 0
filter protocol ip pref 2 bpf chain 0 handle 0x1
prog_offload_schedcls_tether_downstream4_rawip:[*fsobj] direct-action
not_in_hw id 6 tag b1c9478c91f8df9a
Test case #2:
Enable USB tethering and check tc filters are added or removed on both
rndis0 and rmnet_data#.
Test case #3:
Enable WiFi and USB tethering and check tc filter are added or removed
on rndis0, wlan1 and rmnet_data#.
Change-Id: I3f9a65043271bc8f5bf1b82ae505c471625ca9de
A caller can mostly already do this via forEach(), but having a
specific method is faster (since the code does not need to read
the value) and easier to use.
The semantics of this method (e.g., ignore ENOENT while deleting
a key, but throw on any other error) match those of the native
BpfMap::clear method.
Test: new unit tests
Change-Id: I5cd32efd0f87c823cd2d0a2fa3a95a83093fb6f9
The flag allows overriding the value of config_tether_upstream_automatic
on released R devices, as issues have been found on devices where an
overlay was used to set it to false.
The flag is only usable on R devices, as S devices can either not set
the setting to false, or fix the underlying issues.
Bug: 173068192
Test: atest TetheringCoverageTests
Change-Id: Id99638916e08e596fab21cedd7bfe39906ce2fe5
The tethering module uses JNI in various classes, but only calls
System.loadLibrary in TetheringService#makeTethering. This means
that:
1. Any test that uses a class that uses JNI must load the
library itself.
2. Any code that runs before TetheringService#makeTethering could
potentially crash if it uses JNI. We may never have such code
though.
Instead, make every class that has a native method load the JNI
library itself at static initialization time. This guarantees
that the class will have the JNI code available in any context
(production, test, etc.)
System.loadLibrary is documented not to do anything if called
more than once with the same library name:
https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#loadLibrary(java.lang.String)
and the implementation has a lock so it is safe to call from
multiple threads concurrently.
Test: builds, boots, tethering starts
Test: atest TetheringCoverageTests
Change-Id: I9c0147ae9a28877f416aaff387b426d304ae552d
This CL adds the counters collected by the tethering programs to
the output of "dumpsys tethering bpf". The counter names are
fetched by JNI code at startup and then read by the debugging
code on demand.
Example from my device:
Forwarding errors:
TCP_CONTROL_PACKET: 67
NON_GLOBAL_SRC: 13
NON_GLOBAL_DST: 17
LOCAL_SRC_DST: 7
Test: manual (debug-only code)
Change-Id: I7ec7992612556a4bca5f1b6bb52c655d6d870201
Currently, the dump methods open BpfMap objects and never close
them. This leaks filedescriptors, and if dump is called often
enough, will crash the networkstack process.
Fix this by using try-with-resources statements that
automatically close the map when exiting the try block.
Change the signature of BpfMap#close from "throws Exception" to
"throws ErrnoException" since it does not throw any other type
of checked exceptions.
Test: "lsof | grep network_st" while running "dumpsys tethering bpf" in a loop
Change-Id: I66c407454c2715bf41bf3a2e81bd582f9ea5a905
