[Dnsmasq-discuss] android client does not check ip address with DHCPREQUEST

[Simon Kelley]

RFC1531 is twice obsoleted. The current definition of DHCP is RFC2131,
which says, in para 3.2.


      The client times out and retransmits the DHCPREQUEST message if
      the client receives neither a DHCPACK nor a DHCPNAK message.  The
      client retransmits the DHCPREQUEST according to the retransmission
      algorithm in section 4.1.  The client should choose to retransmit
      the DHCPREQUEST enough times to give adequate probability of
      contacting the server without causing the client (and the user of
      that client) to wait overly long before giving up; e.g., a client
      retransmitting as described in section 4.1 might retransmit the
      DHCPREQUEST message four times, for a total delay of 60 seconds,
      before restarting the initialization procedure.  If the client
      receives neither a DHCPACK or a DHCPNAK message after employing
      the retransmission algorithm, the client MAY choose to use the
      previously allocated network address and configuration parameters
      for the remainder of the unexpired lease.  This corresponds to
      moving to BOUND state in the client state transition diagram shown
      in figure 5.


If the Android client took out DHCP lease of length (say) one hour, it's
entitled to use that address for one hour, without ever talking to the
DHCP server again. By editing the lease database, you've misconfigured
dnsmasq and caused it to lease an address to another machine which it
has already leased to the Android phone. If you want to play such games,
you need to use short leases and include delays before reusing the address.


Cheers,

Simon.


On 09/01/2019 15:48, Inigo de la Fuente wrote:
> Hi All,
> 
>  
> 
> I have performed several test and already have opened one thread about
> this issue. I have seen unexpected behavior on android when DHCPv4
> client tries to reuse a previously allocated network address and this
> address is unavailable on the server.
> 
>  
> 
> The test steps are the following:
> 
>  1. Set the range of DHCP leases to only 1. Until now, DHCP can only
>     lease one address.
>  2. Connect a device and get the only IPv4 address lease available then
>     disconnect.
>  3. On the server dnsmasq leases file, replace the IPv4 lease and give
>     the address to other machine.
>  4. Reconnect the device on point 1.
> 
>  
> 
> Basically on windows and IOS I can see that the first message on the
> DHCP client-server communication is a DHCPREQUEST sent by the client
> with the IPV4 address that wants to reuse. Then, the server respond with
> a DHCPNAK indicating the lease is not available anymore on the server.
> After that the client tries to get a new IPV4 but is not possible
> because no IPV4 range is available. (the only available address is
> assigned).
> 
> This is the correct behavior indicated on RFC1531
> 
>  
> 
> However, on Android the DHCPv4 client does not use DHCPREQUEST and then
> it reuses the address even when that address has been reassigned to
> other machine.
> 
>  
> 
> Did someone experience that?
> 
>  
> 
> Regards and thanks in advance
> 
>  
> 
> 
> 
> -------- Disclaimer --------
> This email and any files transmitted may contain proprietary and
> confidential information of ICT Group N.V. or any of its subsidiaries
> (“ICT”) and is intended only for the (use of the) named recipient(s)
> above. If you have received this message in error or are not the
> intended or named recipient(s) of this message, please immediately
> notify the sender by return and delete this email message from your
> computer. Any views or opinions presented are solely those of its author
> and do not necessarily represent those of ICT. You are hereby notified
> that unauthorized disclosure, use, dissemination, forwarding, printing
> or copying of this e-mail and its attachments either whole or partial of
> its contents is strictly prohibited. ICT cannot guarantee that email
> communications are secured and error-free and does not accept any
> liability for damages resulting from the use of email. The general terms
> and conditions of purchase respectively sale and delivery of ICT are
> applicable to all transactions and undertakings resulting therefrom.
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>