Age | Commit message (Collapse) | Author |
|
Bug: 153694684
Test: new test coverage in IpClientIntegrationTest
Change-Id: Ie207940d79abbc0d92dd15becee867e72f171786
|
|
The purpose of processing CMD_UPDATE_L2INFO command in the Stopped
State is just to update the initial l2key and grouphint which are
used when starting DhcpClient (e.g. for INIT-REBOOT). We can get
both of l2key and groupHint from the initial prov configuration
parcelable instead, then be able to delete CMD_UPDATE_L2INFO from
the StoppedState.
Bug: 154441742
Test: atest FrameworksNetTests NetworkStackTests
Test: atest NetworkStackIntegrationTests
Change-Id: I760957017b18975be969a2f519ec09ee4495ebad
|
|
This allows IpClient to parse the pref64 RA option and put it
in the LinkProperties to be sent to ConnectivityService.
IpClientLinkObserver is a natural place for this because it is
the part of IpClient that is already tasked with receiving
netlink events and storing the results in IpClient's
LinkProperties.
Instead of using the path used by most attributes, which are
parsed by NetlinkHandler, converted to a string array, then
re-parsed and sent over binder call to the networkstack, simply
open a netlink socket in the networkstack process and read the
netlink messages from there. In the future, we can build on this
to parse other netlink messages (e.g., IP addresses, routes,
RDNSS, etc.) in the networkstack and entirely remove the
dependency on netd's NetlinkHandler, which is crufty, hard to
extend, and does not support interface indices.
This means that the pref64 attribute will not be ordered with
respect to other netlink events. This is acceptable because the
pref64 attribute does not need to be ordered with any other
information and its presence or absence does not cause
provisioning to succeed or fail. Today the pref64 is learned
through an entirely different codepath (DNS lookups) and that is
not ordered in any way either.
This CL does not change the threading model: the netlink updates
are processed on the handler thread like all the other updates
seen by IpClientLinkObserver, and all access to mLinkProperties
is synchronized (this). This synchronization is no longer
necessary because everything is on the handler thread anyway,
but that will be cleaned up in a future CL.
Because netlink events contain interface indices, but IpClient
and netd deal with interface names, IpClientLinkObserver must be
told what the interface index is. This is done when
startProvisioning is called, because that is when IpClient
fetches the interface parameters including the MAC address and
interface index. It cannot be done when IpClientLinkObserver is
started, because at that time the interface might not exist, or
might exist with a previous interface index. The interface index
is cleared when IpClient enters the stopped state and the
LinkProperties are cleared.
Bug: 153694684
Test: atest NetworkStackNextIntegrationTests:IpClientIntegrationTest#testPref64Option --iterations 100
Change-Id: I3f8d2fbf2e203c6f90029947fa55b5e0b3b06d94
|
|
into rvc-dev
|
|
into rvc-dev
|
|
networks.
Bug: 131797393
Test: atest NetworkStackTests NetworkStackIntegrationTests
Test: atest FrameworksNetTests
Merged-In: I65ebdd142a2bb402035c63cd282bc2574ddf3d8d
Change-Id: I65ebdd142a2bb402035c63cd282bc2574ddf3d8d
|
|
When the DHCP client is given a new IPv4 address which is not its
previous network address to be extended durig RENEWING or REBINDING
state, should roll back to INIT state and restart DHCP configuration.
That's the intended behaviour with this fix (notify provisioning failure
and then exit from receivePacket() immediately, DO NOT accept this renew
lease).
Otherwise, the new given network address will be accepted and noitfy
IpClient to configure this new address on interface, which violates
RFC2131#4.4.5. The incorect call graph will be:
- receiving mismatched renew lease:
- setDhcpLeaseExpiry
- acceptDhcpResults
- notifySuccess
- transitionTo(mDhcpBoundState)
- keep using this new address
Bug: 131797393
Test: atest NetworkStackTests
Merged-In: I6fd37e6af1f6bf3a8ce8de7b9a1ef4731de5db27
Change-Id: I6fd37e6af1f6bf3a8ce8de7b9a1ef4731de5db27
|
|
A new boolean flag (changePrefixOnDecline) to be added in
the DhcpServingParamsParcel, indicating whether or not the DHCP
server should request a new prefix (e.g. a different subnet
prefix) from IpServer when receiving DHCPDECLINE message.
Bug: 130741856
Test: atest NetworkStackTests NetworkStackNextTests
Merged-In: I8cb0f844ef98a5f17d4e07e1812a1abf73aa4c07
Change-Id: I8cb0f844ef98a5f17d4e07e1812a1abf73aa4c07
|
|
Refactor probing class to allow sending probe via thread class
in legacy send parallel probes function and also refactor for
follow up commit to send multiple probes.
Bug: 139034276
Test: atest NetworkStackTests NetworkStackNextTests
Test: manually test with resource configuration
Change-Id: Ia25bfe58b10b0a1a641a2be535ee0d602ffd8cd6
Merged-In: Ia25bfe58b10b0a1a641a2be535ee0d602ffd8cd6
(cherry picked from commit c17b3996f428ac80a2f8b2c4f361b0e18b0b50fa)
|
|
|
|
This addresses comments on the parent change that introduced the
optional feature.
This change also considers IPv6 ULAs as private addresses, corrects some
style and comments.
Bug: 136734947
Test: atest NetworkStackTests:NetworkMonitorTest \
NetworkStackTests:NetworkStackUtilsTest
Change-Id: I1169320f3a5c09631e754518c60acab337faf49b
Merged-In: If4231804b77143b78f26a32c16db53fc4ac44cd8
(cherry picked from commit 0f62e8c6d21afd28280dbae7c3ea216097def466, aosp/1282802)
|
|
If specific config "clientAddr" is set, the DHCP server will only offer
"clientAddr". This is for peer-to-peer use case. If there are multiple
clients for which "clientAddr" is already in use, dhcp server will not
offer other addresses to clients.
Bug: 141256482
Test: manual
atest NetworkStackNextTests
Merged-In: I96bc24a9c30bfc48dff38c3c4456085694fd381c
Change-Id: I96bc24a9c30bfc48dff38c3c4456085694fd381c
|
|
When access points return private IPs (as defined in the NetworkMonitor
constant) in response to DNS probes, do not consider the access point as
behind a portal, but instead indicate that it has no connectivity.
This solves issues with some access points that return private IP
responses to DNS queries when they do not have internet access.
This feature is turned off by default while investigating its impact.
OEMs can force-enable it through a resource overlay:
config_force_dns_probe_private_ip_not_portal. Metrics to evaluate the
feature will be added in a later change.
Bug: 136734947
Test: atest NetworkStackTests
Merged-In: I51975e18f424e3b7265011000f073777f376e597
Change-Id: I51975e18f424e3b7265011000f073777f376e597
|
|
The first tests just verify that provisioning is lost if all IPv4/6 DNS
servers or gateways are lost.
Test: atest NetworkStackTests
Bug: 152819907
Merged-In: I8da6a8f4f237ce963c0a1610432d310160fd3f20
Change-Id: I8da6a8f4f237ce963c0a1610432d310160fd3f20
|
|
This change renames IDhcpLeaseCallbacks, easier to expand in the
future and adds a new method onNewPrefixRequest which will be called
on DHCP server receives DHCPDECLINE message and request a new IPv4
prefix from IpServer.
Bug: 130741856
Test: atest NetworkStackTests NetworkStackNextTests
Merged-In: Ia7b08bb1e7feda08ffe9fbb8885dbc8b7bdd66c9
Change-Id: Ia7b08bb1e7feda08ffe9fbb8885dbc8b7bdd66c9
|
|
* changes:
[MP02] Make multiple probe url configration overlayable
[MP01] Add configuration to support multiple probes
|
|
into rvc-dev
|
|
In case of wifi might stop IpClient and then restart prov immediately
to avoid wifi disconnection especially when roaming happens, this
might cause getting interface params with incorrect interface mtu when
starting provisioning again before interface mtu hasn't been restored.
Moving getting interface params to ClearingIpAddressState#enter ensures
that interface parameters are fetched on the handler thread so they are
properly ordered with other events, such as restoring the interface MTU
on teardown.
Bug: 152169857
Test: atest NetworkStackIntegrationTests NetworkStackTests
Merged-In: Ifd06b8d18ce570b1aa424ad215111c80f094ca97
(cherry picked from commit a6aba532103a3258d09e6931106d6fb05368c130)
Change-Id: I0c8c1ed1646ab12bc30da2b7f8e5819d2d9495ba
|
|
This change adds an new method updateLayer2Information in IIpClient.aidl
to update layer2 info (e.g. bssid, l2key and grouphint) to detect
whether L2 roaming happens or not.
Bug: 131797393
Test: atest NetworkStackTests FrameworksNetTests
Merged-In: I85eabccb6f5d5f322c8e3df556ceef6647616f5a
(cherry picked from commit 3168e392320087c51a677b4d14e783c853ac652d)
Change-Id: Ife93fd162803ae89fa85905b45a4bb1cfb5e7e43
|
|
Add configuration to allow configuring multiple probe.
Bug: 139034276
Test: atest NetworkStackTests NetworkStackNextTests
Merged-In: Ib2c1d16d2088ef043cdc6f9cb323a9df552beefb
Change-Id: Ib2c1d16d2088ef043cdc6f9cb323a9df552beefb
|
|
This allows tests that emulate DHCP clients to include options.
The values are specified by the RFC and cannot change, so there
is no downside to making them public.
Test: builds
Bug: 150644681
Change-Id: I939bfac5ec14175b74ce3713f5af1362de577839
Merged-In: I939bfac5ec14175b74ce3713f5af1362de577839
(cherry picked from commit f75cd4768124c20c9eda14e21368f83c4963a260)
|
|
IE." into rvc-dev
|
|
Checking a particular IE (vendor specific) in the wifi scan results to
identify upstream hotspot device type, meanwhile also checking if the
ssid matches with the network which the downstream device is attaching to.
Bug: 137835398
Test: atest FrameworksNetTests NetworkStackTests NetworkStackIntegrationTests
Test: 1.attach to upstream hotspot device by selecting the sanned
ssid from wifi settings, then check the OUI, vendor specific
type fileds of IEs from the logcat.
2. build network stack module and install on Q device, verify wifi
works normally.
Merged-In: I8a3212fa066bdc8bf889768f92569891a3cb2408
Merged-In: I57c709c5da984accbbb389ab8d1295eae01328c6
Change-Id: I8b0ea9542775aecc13ed8ceede80abd693002825
|
|
Bug: 130871097
Test: atest FrameworksNetTests NetworkStackTests
Merged-In: Idc2c4303640d4fd3fc29dd0957771088820030ff
(cherry picked from commit f540206076ca0e55d685ef81e3e04da3e9a654cf)
Change-Id: Icd69008635461aa24d976f9b9d2d0ef1d60e23d5
|
|
Bug: 134098566
Test:
lunch arm_aosp-userdebug
make -j32
Change-Id: Ide9610f9b17992eef83e1c42ac71b1b79c179f44
Merged-In: If86a6303671b03bb2ccf98de7e9d77020b013d2f
(cherry picked from commit 10d243214ae933d063affdd2b4f6c1f837279586)
|
|
NetworkMonitor will detect captive portal and may get a redirect
URL from WiFi AP. Redirect URL should able to send to captive
portal app to open the webview instead of detecting again by
captive portal app.
Bug: 134892996
Test: Manually test with captive portal AP
Test: atest NetworkStackTests NetworkStackNextTests
Change-Id: Idf363c79b7243a899121be8a68b32d0541dff14f
Merged-In: Idf363c79b7243a899121be8a68b32d0541dff14f
|
|
Requesting the captive portal option is flagged off by default.
The URL it provides will be used to support the captive portal API; see
RFC7710bis.
Bug: 139269711
Test: atest NetworkStackTests NetworkStackNextTests
Test: atest NetworkStackIntegrationTests NetworkStackNextIntegrationTests
Change-Id: I783466e0e60f364e79cd76af3fe43a7862d35cf2
|
|
The fields are behind a protection method to avoid inadvertently
sending private data to apps. This is going to the system server
which needs those fields.
Test: NetworkStackTests
Change-Id: I7c9a7a82efa364835164622d2e93977e0bcd3d8c
|
|
Test: m
Change-Id: I4ca0c47d62ea90c30f88278b3ebf766be2c5a2e9
|
|
Bug: 149458372
Test: new unit test
Test: tethering no longer crashes
Change-Id: Ic5f709c1ce50d3bb7af26a698dd32adb87012316
|
|
This reverts commit e8fff42022f8c22e84d51bc093189d469bdd9af1.
Bug: 135411507
Test: atest NetworkStackTests
Change-Id: I0609301d7b37309a35c764a7551b0ca93b3faeee
|
|
This reverts commit dc018dd943f0c11e0b9172dee0db0966871af20d.
Reason for revert: crashes tethering: b/149458372
Bug: 149458372
Change-Id: I1fad8528443d8cc133f719aad042cb22d3a8e2a0
|
|
The callbacks will be used by Tethering to provide callbacks when DHCP
leases are updated.
The current design only supports one client as Tethering may want to
send callbacks to multiple callers, but DhcpServer is only owned by
Tethering.
Bug: 135411507
Test: atest NetworkStackTests
Change-Id: I1e44221d6fbd1b1f2d0d0057a29c7445af1cdbcf
|
|
This patch fixes the bug introduced by aosp/1169224 which moves
notifySuccess function to DhcpBoundState#enter. This behavior
is correct for DHCP reacquiring process (e.g. when client renews
or rebinds the previous leased IPv4 address, then enters Bound
state after receiving DHCPACK packet). However, this is incorrect
for DHCP solicit at the first time, since notifying IpClient DHCP
success after configuring interface causes mDhcpResult member is
still empty when handleLinkPropertiesUpdate is triggered by netd
completes configuring interface with new IPv4 address. Hence, new
Link Properties passed to wifi state machine doesn't contain the
available DNS servers received from DHCPACK.
Moving notifySuccess before sending CMD_CONFIGURE_LINKADDRESS cmd
to IpClient ensures mDhcpResult member has been initialize correctly
before assembling new LinkProperties.
Bug:146850745
Test: atest NetworkStackIntegrationTests NetworkStackTests
Change-Id: Ifb990ccc06c1374e616f71038b1811640821e954
|
|
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 136065010
Test: m
Change-Id: Iaf682c850b7cf22980d6fb88d3d60e24c189b74c
Merged-In: Iaf682c850b7cf22980d6fb88d3d60e24c189b74c
|
|
Generally "ByteBuffer packet" has been allocated with a maximum
length of 1500. Calling packet.array() is to return a byte array
of length 1500 but the actual DHCPDISCOVER packet payload is much
less. Return actual DHCP packet byte array instead in this patch,
which allows caller use the payload byte array directly without
extra operation (e.g. calling packet.remaining() to get the correct
length of actual payload).
Bug: 140223017
Test: atest NetworkStackTests NetworkStackIntegrationTests
Change-Id: Ib08f2450fb649ea1ffcdbf8dedc829965f13da86
|
|
|
|
Bug: b/144826001
Test: Build Pass: OK
Test: Power ON/OFF: OK
Test: Verify CPU loading improvement: OK
Change-Id: I412f3db7071672ebc3213dc128bbfc8f8bd2abcc
|
|
|
|
Add a configurable option in the RRO which controls whether or not to
send the hostname set in the Settings->About phone->Device name. The
option in RRO is false by default, that means DHCP Request still not
include any hostname by default. Once the option is overlaid and enabled,
the device name after transliteration will be wrote into hostname option.
Bug: 131783527
Test: atest NetworkStackTests NetworkStackIntegrationTests
Test: manual test, create empty APK to overlay the RRO configuration.
Change-Id: I9af0b0d9e7bb526d3a3c1003bb99d0a3d69b1e9e
|
|
Overload NetworkStackUtils.getDeviceConfigPropertyInt API to check if the
value of property read from DeviceConfig is valid, value in the range
of mininum and maximum would be acceptable, otherwise, return the default
value.
Bug: 128639898
Test: atest NetworkStackTests NetworkStackIntegrationTests
Change-Id: I07e3e9d1e1b7252d852d4665d2ea254f29a1c3eb
|
|
- receiving CMD_TIMEOUT before aborting FILS process.
- receiving CMD_TIMEOUT after aborting FILS process.
- receiving CMD_TIMEOUT before success FILS process.
- receiving CMD_TIMEOUT after success FILS process.
Bug: 140223017
Test: atest NetworkStackTests NetworkStackIntegrationTests
Change-Id: I519bf2fdda38cb9666f769868379a0c044356db0
|
|
Bug:136216415
Test: atest FrameworksNetTests NetworkStackTests
Test: atest NetworkStackIntegrationTests
Test: manual tethering
Change-Id: I0f9483c72374bab271eb18549a1a41812f32f2dd
|
|
Disable this behavior by default, we can enable it with flag rollout
later.
Bug: 128639898
Test: atest NetworkStackTests NetworkStackIntegrationTests
Test: manual test
Change-Id: Ie2133bc5faaba085147519cdb5c8277c563cfbd7
|
|
Bug: 140223017
Test: atest FrameworksNetTests NetworkStackTests
Test: atest NetworkStackIntegrationTests
Test: manual
Change-Id: Ibf200891c9742825a599a21b43f02927869f98ab
|
|
|
|
This simplifies StartedState a bit, and should have no impact on
behaviour.
Test: atest IpClientIntegrationTest
Change-Id: Ie897307925a9af571a622c823d4c641956e607f3
|
|
Address follow up actions and comments
Bug: 130325409
Test: NetworkStackTests NetworkStackNextTests
Change-Id: Ic768f08e5e54667e375c0d486df278773d9c707a
|
|
After introducing IP address conflict detection mechanism, we might get
an duplicated IP address though the DHCP handshake, it's not appropriate
to notify IpClient that DHCP success and configure interface with this IP
address immediately. However, Bound State ensures that we have already
done DAD (if enabled) and IP address has been configured on the interface.
More reasonable to notify IpClient DHCP success when entering Bound state.
This CL does not change the behaviour of a successful transaction.
The call graph is:
- notifySuccess
- acceptDhcpResults
- when receiving an ACK in DhcpReacquiringState
- next action: transition to DhcpBoundState
- called from confirmDhcpLease
- when receiving a rapid commit ACK in DhcpInitState
- next action: ConfiguringInterfaceState
- next action: configure link address, then transition to DhcpBoundState
- when receiving an ACK in DhcpRequestingState
- next action: ConfiguringInterfaceState
- next action: configure link address, then transition to DhcpBoundState
This CL does change the behaviour of failed transactions. For example,
if configuring the IP address or opening the UDP socket fails, after
this CL, the client will no longer notify success. This is more correct.
Bug: 130775067
Test: atest NetworkStackTests NetworkStackIntegrationTests
Change-Id: Ie3b5edd8ddf04aac258b97ecaa291fcb25611bbd
|
|
Allow NetworkStack to send SockDiag netlink request and parse
returned tcp info. Evaluate the internet health from the tcp
information.
Bug: 136162280
Test: atest NetworkStackTests NetworkStackNextTests
Test: Use "adb shell ss" command to check the parsing info
Change-Id: I8df0d11c748c95d3a57115ebb6a4e29d8b50f177
|