dhcpcd-discuss

Re: behaviour of TIMEOUT on version 7.0.0

Shyamlee Badole

Thu Aug 20 11:57:18 2020

Hi,

I am attaching the pcap file to give you a better idea of the issue.

As seen from the pcap, when the link is detected on the interface (eth1),
initially the client tried to contact the dhcp server after which it
broadcasted the request asking for previous lease. After that a timeout
occurs (eth1: timed out contacting a DHCP server, using last lease)

After timeout(since that router is down), the client has sent a Broadcast
DISCOVER, to which a dhcp server belonging to another network has offered
an ip. (eth1: offered 192.168.44.6 from 192.168.44.1)
The client is now sending REQUEST to the server(192.168.44.1) using the
previous IP(66.170.65.115).
This REQUEST is sent unicast to the old router gateway and the client is
not able to accept the offered ip and continuously sends the unicast
REQUEST.
Since the client has already entered the Discover phase, it should
broadcast the request instead of unicasting to the old gateway (which is no
longer valid).
If this request to accept the offer was broadcasted, it will be able to
receive the reply from the new server.

Please provide your inputs.

Thanks for the help,
Shyamlee

On Tue, Aug 18, 2020 at 5:46 PM Shyamlee Badole <sherlybadole96@xxxxxxxxx>
wrote:

> Hi Roy,
>
> Thank You for your response.
>
> I've disabled the 'lastlease' option in the dhcpcd.conf file. And it's now
> accepting the ip offered by the server.
> Here instead of a timeout, the previous lease is getting expired.
>
> But we want to keep the last lease.
> There are instances like when the device boots up or when processes
> restarts, the old lease should be used. It should not get a new one.
>
> Is there a way we can achieve this new IP on timeout and keep the last
> lease?
>
> Thanks,
> Shyamlee
>
> On Mon, Aug 17, 2020 at 11:20 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:
>
>> On 17/08/2020 18:07, shamli badole wrote:
>> > Hi Roy,
>> >
>> > Using dhcpcd 7.0.0.
>> >
>> > A router is configured for DHCP on eth1. When the WAN connection is
>> switched
>> > from one network to another, TIMEOUT event is observed after it tries
>> to renew
>> > the currently assigned lease.
>> > After TIMEOUT a DHCP DISCOVER is sent. To which an ip is offered from
>> another
>> > server.
>> > But the router is not able to acquire this lease. It keeps on sending
>> DHCP
>> > REQUEST to the server. Attached logs for reference.
>> >
>> > I observed this behaviour is because the old ip lease is maintained
>> after TIMEOUT.
>> > Since the old ip lease is not cleared, the DHCP REQUEST is sent back to
>> the
>> > previous DHCP Server and not the one which has assigned a new IP
>> Address.
>> >
>> > Can You help in understanding why this behaviour is observed on TIMEOUT
>> when the
>> > dhcp server network is changed?
>> >
>> > I tested by explicitly clearing the old lease by making the s_addr =
>> 0.0.0.0 in
>> > the DHCP DISCOVER. In this case the DHCP DISCOVER and DHCP REQUEST both
>> are
>> > broadcast.
>> > It accepts the ip which is offered by the server.
>> >
>> > Can you please guide on how the TIMEOUT needs to be handled? Does the
>> > application need to reset the interfaces and release the dhcp lease?
>> >
>> > Thank you for your help.
>>
>> The key line from your logs is this:
>> Jul 31 13:58:25 [7450]: eth1: timed out contacting a DHCP server, using
>> last lease
>>
>> Does it work if you disable the non default option you set to use the
>> last lease
>> on timeout?
>>
>> Roy
>>
>

Attachment: bootp.pcapng
Description: application/pcapng


Follow-Ups:
Re: behaviour of TIMEOUT on version 7.0.0Roy Marples
References:
behaviour of TIMEOUT on version 7.0.0shamli badole
Re: behaviour of TIMEOUT on version 7.0.0Roy Marples
Re: behaviour of TIMEOUT on version 7.0.0Shyamlee Badole
Archive administrator: postmaster@marples.name