Reply ipv4only.arpa AAAA query with Pref64::WKA for applying test
prefix64 to LinkProperties of test network.
See Nat464Xlat#setNat64PrefixFromDns.
Currently, the test prefix64 is applied directly in test network
initialization. In order to increase the NAT64 test coverage,
the integration test starts to reply prefix64 discovery DNS query
for testing the RFC 7050 prefix discovery.
These clat related tests are still expected to pass since this
prefix64 source change:
- testTetherClatIcmp
- testTetherClatUdp
- testTetherClatTcp
Bug: 259888307
Test: atest EthernetTetheringTest
Change-Id: Ic94ce997dd0b1d718a1074850c01ea90298cc1c3
Move all EthernetTetheringTest buildXXXPacket util into TetheringTester
and make them static public.
Bug: 259888307
Test: atest EthernetTetheringTest
Change-Id: Ice5252c1adfdb98dfaf815f48ac4603711317f65
Different network objects with the same network ID should be
treated as the same network.
chooseUpstreamType compares the current upstream and new upstream
by object (comparison operator) instead of network id
(Network#equals). This implies that different objects with the
same network id still trigger upstream changed report.
Since this commit, reportUpstreamChanged is only called when upsteam
has really changed (connected, switched or disconnected) in
chooseUpstreamType. In previous code, reportUpstreamChanged is also
called if EVENT_ON_CAPABILITIES is called when the upstream is the
same but its capabilities changed.
The NotificationUpdater#onUpstreamCapabilitiesChanged method only
needs to be called by chooseUpstreamType when it chooses a new
upstream. If the upstream remains the same but its capabilities
change, the EVENT_ON_CAPABILITIES will call
onUpstreamCapabilitiesChanged.
Bug: 243516306
Test: atest TetheringTest
Change-Id: I009383a61a5fabd249ba78fcffd524a5bbe4602e
A test to verify that SAP and LOHS can use different IPv4
addresses if they are both enabled.
Bug: 233175023
Test: atest TetheringTest
Change-Id: I40f0f35221a76e6593cc8d04e9f2b25df8c27c87
A test to confirm that connected clients are updated when SAP
and LOHS are enabled simultaneously.
Bug: 233175023
Test: atest TetheringTest
Change-Id: I920f02e5b2ad137af529776141d51b6c83b8ea5b
EthernetTetheringTest#testTetherZeroLengthDhcpPacket requires the latest
NetworkStack module, otherwise, the test will fail due to the loss of
the fix. Apply @NetworkStackModuleTest to exclude this testcase from
target test suite CtsTetheringTestLatestSdk.
Bug: 283200648
Test: atest CtsTetheringTestLatestSdk
Change-Id: Iebfb043e2b71427a6feaf90788fe79b6ab6b678d
This allows better overriding of it in the variants of this apex
that have a different package name.
Bug: 242509786
Test: build google tethering, diff before & after
Change-Id: I84c53458686f70408ec759df854f5fcdee9cdaed
It leads to complexity when Tethering is overridden, because the
required attribute must be duplicated for all the variants.
Require NetworkStack be explicitly installed instead.
Bug: 242509786
Test: m
Change-Id: Ideaecf88418901e2c86271166be24f6b7e498a20
Use type + scope as key to build cached address map so that
SAP (key: TETHERING_WIFI + INTERNET) and LOHS
(key: TETHERING_WIFI + LOCAL) can use different address.
Bug: 233175023
Test: atest TetheringTests
Change-Id: I46a4b3ee919628092b7540202a43d79f407b09b6
This change store localOnly wifi clients in its own field so that
tethered and localOnly hotspot clients can exist at the same time.
Currently, there are no tethered and localOnly hotspot clients at
the same time because PrivateAddressCoordinator does not support
SAP + LOHS. A follow-up change will be made to allow this.
When both SAP and LOHS are enabled, the SAP and LOHS clients from
TetheringEventCallback#onClientsChanged are all TETHERING_WIFI.
Currently, there is no way for the listeners to distinguish between
SAP and LOHS clients.
Bug: 233175023
Test: atest TetheringTests
Change-Id: I01b0a6abb084f7135f7825e0c5303e49c16a4c39
As the suggestion from:
https://android-review.git.corp.google.com/c/platform/packages/modules/Connectivity/+/2489359/9/Tethering/src/android/net/ip/IpServer.java#b1176
Make BaseServingState an abstract class to prevent it from being used
directly. Additionally, move the handleNewPrefixRequest method into
BaseServingState because it is the only class that uses it.
To avoid TetheredState and LocalHotspotState from having to implement
their own enter function, add the mDesiredInterfaceState field to
BaseServingState.
Bug: 233175023
Test: atest TetheringTests
Change-Id: I03269c37e666345efb0c61039a2bb213f223a5a2
Starting with U, only explicit intents will be allowed to
launch non-exported internal components. Set package name
to entitlement recheck intent so that the intent could be
delivered to tethering itself successfully.
Bug: 278482046
Test: atest TetheringTests
manual verify entitlement recheck work in U
Change-Id: Ife30eee13fe39509ccb5786d2a76fbb7baa022a8
The logic dealing with in vs out-of-process tethering flags
was added in aosp/master once it was already not merging to tm-dev,
thus ending up only in udc-dev, it was later removed in aosp/master,
and then cherrypicked to udc-dev.
As such there is no shipping version of the bpfloader
(besides early U developer previews and betas)
with this requirement.
This will make September+ releases of the tethering apex incompatible
with U developer previews and betas 1 and 2.
(ie. any U build not including https://googleplex-android-review.git.corp.google.com/c/platform/system/bpf/+/23214402
which was merged into udc-dev on May 14th @ 18:00)
This change has a dependency on
https://googleplex-android-review.git.corp.google.com/c/platform/vendor/google/modules/TetheringGoogle/+/23243439
Test: TreeHugger
Bug: 279942846
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I52d0ea706a8e2cb5c37874ed54f199035c14966c
DHCP packet listener doesn't close socket any more upon receiving a
zero-length DHCP packet with a fix, instead, just ignore the zero-length
packet and continue reading. Also update the integration test logic to
verify the new behavior, i.e. we can send DHCPDISCOVER from a second device
with different mac address to verify the upstream DHCP server doesn't close
the listening socket, and then we will receive the response from server e.g.
DHCPOFFER packet.
Bug: 269692093
Test: atest TetheringIntegrationTests
Change-Id: I183da43ce5a6511714d293318fe6c60ea55999c0
With the release cut of the July train and the recent automerger
cutover, tm-mainline-prod is now officially an abandoned branch.
This change deletes (most) infrastructure that was put in place to
disable cronet on tm-mainline-prod.
Test: builds
Change-Id: I078f2114b736a634f08d8f704c19beb2224ef645
