NetworkInterface throws Exceptions every time you look at it askance.
Try to make something we instantiate fully, once, and pass it around.
Partial MacAddress-ification as well, for good measure.
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
- basic IPv6 tethering works
Bug: 32163131
Bug: 62476366
Change-Id: I16c145fddb4e76387370338d792a438eed886d7f
This patch deprecates the ifname field for specific metrics events of
types DhcpClientEvent, DhcpErrorEvent, IpReachabilityEvent and
IpManagerEvent.
Instead ifnames are logged in ConnectivityMetricsEvent, allowing for
link layer inference.
Test: updated unit tests, $ runtest frameworks-net passes
Bug: 34901696
Change-Id: I8bfabcb115bbd5289471d653c153a40bb48f28cd
Network usage is tracked by the kernel at the UID level, which is
granular enough for normal apps, but large components (such as the
system server) are impossible to debug without adding additional
socket tagging to help identify subsystems within a UID.
To help ensure that system components tag all their network traffic,
this change offers a new StrictMode option to detect and report
untagged sockets.
Test: builds, boots, all common traffic tagged
Bug: 30943431, 30414041
Change-Id: I825c7941076054732264690247de2863342638e2
This patch adds lifetime durations of DhcpClient states to
DhcpClientEvents.
To record the duration of a state, the event is now recorded when the
DhcpClient state machine exits that state.
In addition this patch removes event logging of StoppedState,
DhcpState and DhcpHaveLeaseState.
Change-Id: Ibd37b5e3070f35113b6b45942b1e1ff19c27a90b
This patch removes static methods for logging IP connectivity events
defined in android.net.metrics and replaces them with a single log()
instance method defined on IpConnectivityLog. Event constructors are
now public also. Every classes logging such events now create an
instance of IpConnectivityLog for logging event objects directly
instantiated with new.
Removing static dependencies allow straightforward testing of logging.
This patch also removes the base IpConnectivityEvent class which is not
needed any more.
Bug: 29035129
Change-Id: I3de700f93f46deaa48a759f938f7d00e1d8bff98
This ensures that IpManager has a complete copy of DHCP state
before configuring the IPv4 address. That way, when the netlink
notification of the IPv4 address arrives, we are guaranteed to
have all DHCP information (including DNS servers and routes)
available and we will never send the IPv4 address before the DNS
servers.
Bug: 27605330
Change-Id: I732424dfe2408be9e40028563e99d610b541e12d
This patch moves the event logging of DHCP response packet parse errors
to DHCPClient in a single place. It also logs receive IO errors as
DHCPErrors instead of DHCPClientEvents.
BUG=28197345
Change-Id: I7ad666cff4d8b97915880477347fbb3f588fdb2a
DHCP receive thread was spinning on a boolean variable to know when to
stop. That variable had no volatile qualifier, potentially preventing
the thread from stopping at all. Without a volatile qualifier, the reads
and writes in halt() could be reordered in such a way that the running
thread is interrupted before mStopped is set t true. Also, the optimizer
could decide to hoist mStopped in a register inside the running thread,
preventing the loop from exiting.
Change-Id: I5b30c1247808114f0e5b46e230978ee7ea18ab8e
Adds initial support for IP connectivity metrics collection (DHCP
client, IP reachability monitor, network monitor, connectivity
service).
Change-Id: If9a0455f2a34aa9abea90f9c1b38e4d895dc1a72
This class uses reflection to find accessible static integer
members in a specified list of classes and returns a SparseArray
mapping the integers to their names. This will allow us to
replace various 400-line switch statements with a simple
array access.
Change-Id: I3607e6389a423cde0bd83270c00b3c863ae1bb29
1. Entering DhcpBoundState cancels the renew alarm, but at that
point the renew alarm is guaranteed not to have been scheduled.
This is harmless, but results in an "unknown listener" message
in the AlarmManager logs.
2. We don't cancel the renew alarm when exiting DhcpBoundState.
This is also harmless, because that alarm does nothing except
in DhcpBoundState, and we cancel it whenever we enter
DhcpBoundState. But canceling it on exit is more correct.
Change-Id: I60dfcf00f243253b81b8906540e0a6218a7a489c
This is useful when using the new AlarmManager direct callback
interface to wake up the system and request that an object whose
API consists of messages (such as a StateMachine) perform some
action.
In this situation, using AlarmManager.onAlarmListener by itself
will wake up the system to send the message, but does not
guarantee that the system will be awake until the target object
has processed it. This is because as soon as the onAlarmListener
sends the message and returns, the system is free to go to sleep
again.
Bug: 20157436
Bug: 25823676
Change-Id: Idff20029d287f26347441a2523b7fb20eda6a8b0
This violates a MUST in RFC2131, but apparently some
implementations don't know or care.
Bug: 25343517
Change-Id: I80459b58ffe231e7ed64e77bafa157a96b745149
This makes it so that the socket cannot receive datagrams from
anybody except the DHCP server. This does not improve security,
because we never read from the UDP socket anyway, but it does
make ListeningPortsTest pass.
Bug: 23906864
Bug: 23933386
Change-Id: Ib090273a417f7eb2ac1ee3309260249b72fb8345
If socket initialization fails, DhcpState#exit will call
mReceiveThread#stop and crash the system with an NPE. Make sure
we don't do that if mReceiveThread is null, and properly null it
out when exiting.
Bug: 23088314
Change-Id: I4378d8280f9d8588f5eaa8bd7ade61beab1c3ce2
WifiStateMachine expects CMD_START_DHCP to time out after 30-40
seconds. Currently, DhcpClient imposes timeouts on DhcpInitState
and on DhcpRequestState, but not on the time it takes to get to
from CMD_START_DHCP to DhcpBoundState. So in theory the client
could oscillate between DhcpInitState and DhcpRequestState and
never time out.
Fix this by introducing a new oneshot timer that is set when DHCP
starts and is cancelled when it succeeds. CMD_RENEW_DHCP does not
need this because it's implemented using only one state, so the
oneshot timeout can be implemented using the state timeout.
Bug: 19704592
Change-Id: I6a5847a3dee23a2692237b8f3b3b0f8049da5140
Contrary to the expectations of the code, IoUtils.closeQuietly()
does not unblock system calls. So mReceiveThread.halt() was not
actually stopping the receive thread.
This wasn't actually a problem, because after "stopping" the
receive thread, either the interface would go down (interrupting
the previous receive thread with ENETDOWN), or a packet would
arrive to both the old and new receive threads, stopping the
old one. But the lack of a "stopping receive thread" message at
the expected time was confusing.
While I'm at it, also add the string for CMD_TIMEOUT.
Bug: 19704592
Change-Id: I74732429118af780453028898148519b294fa9d3
Currently we treat a lease time larger than 2**31-1 as a negative
value, which causes DhcpClient to attempt to renew its IP address
constantly. Fix this by properly handling large and infinite
lifetimes, and while we're at it, impose a minimum lease time of
60 seconds.
Bug: 21352084
Change-Id: If62c9efeffad6222e2fe0c110f77d0e4c70de96d
- Specify the package name. This provides a bit of security, but
not much since the package is "android".
- Specify the interface name so we can run more than one client
at a time.
Bug: 21395858
Bug: 19704592
Change-Id: I91c9ea15285b36628b6aef0b975c16a0b08d061e
