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
Currently we send it only in request packets, but not in discover
packets. This might confuse servers because they might think that
the discover and the request come from different clients.
Also reorder the options in the request packet to match the order
used by the legacy DHCP client.
While I'm at it, fix the generation code for inform and decline
packets, which we do not use.
Bug: 19704592
Bug: 20335221
Change-Id: I1d45306e76dbd5da9cc4611e6df84a9f67346b2c
We mostly follow RFC 2131, which says that secs is the number of
seconds "since client began address acquisition or renewal
process", and thus set secs to zero on renew. This is different
from our current behaviour, which keeps on counting without
resetting secs to zero on renew.
Bug: 19704592
Change-Id: Ifbb7644094c579be626ffb698eee87047425dbf0
This currently truncates all strings at the first NULL character,
except for vendorInfo, which is an opaque string.
Bug: 19985674
Change-Id: Ie53b2c55eb8a5204d7b2c7e2d8587743d923647a
This currently truncates all strings at the first NULL character,
except for vendorInfo, which is an opaque string.
Bug: 19985674
Change-Id: Ie53b2c55eb8a5204d7b2c7e2d8587743d923647a
1. Check the length of the fixed-length portions of the packet.
2. Catch BufferUnderflowException while parsing options.
Change-Id: If907f49f02a04a4a3360f46a3192e94ab099af0e
The behaviour of the client is intended to mirror the behaviour
of the current DhcpStateMachine + dhcpcd combination, except it
does not store leases across network changes.
Bug: 19704592
Change-Id: I110b58003da2d8293059d48a0181e16f7f7f145c
1. Define and add parsing code for MTU, max message size, T1, T2.
2. Add common TLVs (message size, hostname, vendor ID) to all
packets sent by the client.
3. Don't include requested IP and server ID in renew messages,
since the RFC says MUST NOT.
4. Don't hardcode the broadcast flag to true in DISCOVER packets,
use what the caller passed in.
5. Make some methods static.
Bug: 19704592
Change-Id: I42a0997e468b12e19cad9b403b98fe266e6cea73
1. Add a method to make a DhcpResults object from a DHCP packet.
2. Add a method to fetch the client MAC from the packet. This is
needed to check that the message is for us (lots of DHCP
messages are broadcast).
3. Add a length argument to the method that parses DHCP packets,
so the caller can use the same MTU-sized array all the time
instead of having to pass in a new array for every packet.
Bug: 19704592
Change-Id: I58223f5ec90fb5c762bc2934649e02f9122018b2
1. Support L2_ENCAP when building packets as well as when parsing.
2. Skip IP options when parsing DHCP packets.
Bug: 19704592
Change-Id: Ic27a45790ed1cf7cf5b82d63b6c0b64c909a570f
1. Delete the DhcpStateMachine, since we don't plan to use it.
2. Make all InetAddresses Inet4Addresses, since that's what they
are. In order to do this, define INADDR_ANY and
INADDR_BROADCAST, constants, since Inet4Address.{ANY,ALL} are
not Inet4Addresses but InetAddresses.
Bug: 19704592
Change-Id: I5a0499be889076992a60aaad0bd8be5ea66bd560
There's no need for it to be in frameworks/base/core, since it
will only be used by services.
Bug: 19704592
Change-Id: I2f5277eca848b7000ca46db575e8602eacb5c8bd
1. Check the length of the fixed-length portions of the packet.
2. Catch BufferUnderflowException while parsing options.
Change-Id: If907f49f02a04a4a3360f46a3192e94ab099af0e
The behaviour of the client is intended to mirror the behaviour
of the current DhcpStateMachine + dhcpcd combination, except it
does not store leases across network changes.
Bug: 19704592
Change-Id: I110b58003da2d8293059d48a0181e16f7f7f145c
1. Define and add parsing code for MTU, max message size, T1, T2.
2. Add common TLVs (message size, hostname, vendor ID) to all
packets sent by the client.
3. Don't include requested IP and server ID in renew messages,
since the RFC says MUST NOT.
4. Don't hardcode the broadcast flag to true in DISCOVER packets,
use what the caller passed in.
5. Make some methods static.
Bug: 19704592
Change-Id: I42a0997e468b12e19cad9b403b98fe266e6cea73
1. Add a method to make a DhcpResults object from a DHCP packet.
2. Add a method to fetch the client MAC from the packet. This is
needed to check that the message is for us (lots of DHCP
messages are broadcast).
3. Add a length argument to the method that parses DHCP packets,
so the caller can use the same MTU-sized array all the time
instead of having to pass in a new array for every packet.
Bug: 19704592
Change-Id: I58223f5ec90fb5c762bc2934649e02f9122018b2
1. Support L2_ENCAP when building packets as well as when parsing.
2. Skip IP options when parsing DHCP packets.
Bug: 19704592
Change-Id: Ic27a45790ed1cf7cf5b82d63b6c0b64c909a570f
1. Delete the DhcpStateMachine, since we don't plan to use it.
2. Make all InetAddresses Inet4Addresses, since that's what they
are. In order to do this, define INADDR_ANY and
INADDR_BROADCAST, constants, since Inet4Address.{ANY,ALL} are
not Inet4Addresses but InetAddresses.
Bug: 19704592
Change-Id: I5a0499be889076992a60aaad0bd8be5ea66bd560
There's no need for it to be in frameworks/base/core, since it
will only be used by services.
Bug: 19704592
Change-Id: I2f5277eca848b7000ca46db575e8602eacb5c8bd
