- netlink from core to services/net/netlink
- IpReachabilityMonitor from core to services/net/ip
Cherry-picked from 02cc5a030a6f132e776b754dd5684ae632009f76
Change-Id: I45ac3f591bade45dd5ec441111b02b621234c0e4
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
* commit '3d3f766c8b37dcf495235ca4a500494498712eed':
Support DHCP replies with multiple default gateways.
Accept DHCP responses from non-67 server source ports
Improve logging of DHCP parse errors using exceptions.
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
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: I82fe9d6c6c520536ffd6422bcc60fab664999e6f
It's not terribly interesting to see logged exceptions about reads
on sockets that were deliberately closed due to normal tear down.
Change-Id: Ib6834a98b6f086fc40ce19db60c161414459d758
These would cause us to crash with a NegativeArraySizeException
when trying to create the clientMac array. Instead, if the length
is > 16 (invalid, because the field is only 16 bytes long), fudge
it to 6 (Ethernet / wifi). This is a bit less liberal than the
legacy client, which doesn't check the length at all.
Bug: 23725795
Change-Id: I83f47bfc400ffa8ce85dd9d1b8eb96be5afe51a5
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
1. We don't parse PAD options properly, leading in failure to
parse packets sent by DHCP servers that put the end of options
marker after pad options and at an odd offset.
2. We get the DhcpResults vendorInfo from the wrong option type
(60 instead of 43).
Fix these and add unit tests for the offer packets sent by a few
different DHCP servers.
Bug: 21955617
Bug: 22281295
Change-Id: I5d13f1a6a3ff0b53112f18f3db8792fa32ad2da3
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
The initial implementation of toDhcpResults attempted to get the
leased IP address from ciaddr if yiaddr was 0.0.0.0, but it never
actually did so because a) it used == instead of equals(), and b)
the parsing code never populated mClientIp for a DhcpOfferPacket
or DhcpAckPacket.
Fix this and add a test for it.. Technically DHCP does not use
ciaddr (only bootp uses it), but in 5.0 we would use ciaddr if
yiaddr was 0.0.0.0 and a bit more compatibility shouldn't hurt.
Bug: 19704592
Change-Id: I1f58555f0c10b9c576995a6edb759a83d8938ea0
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
