Re: behaviour of TIMEOUT on version 7.0.0
Shyamlee Badole
Thu Aug 20 18:17:49 2020
Hey,
Thank You for sending the patch.
I've tested this patch (version 7.0.0), but the issue is still reproducible.
The option that is given in dhcpcd.conf is lastlease and not
lastleaseextend.
Could this be the cause since in dhcp_expire() we are checking for the
latter as follows:
if (ifp->options->options & DHCPCD_LASTLEASE_EXTEND)
Thanks,
Shyamlee
On Thu, Aug 20, 2020 at 9:48 PM Roy Marples <roy@xxxxxxxxxxxx> wrote:
> I don't maintain dhcpcd-7 anymore - many bugs have been fixed since.
> Anyway the attached patch should work - let me know.
>
> Roy
>
> On 20/08/2020 17:10, Shyamlee Badole wrote:
> > Hi,
> >
> > Thank You for sending the patch.
> > Since we are using dhcpcd 7.0.0 if you have, can you please share the
> patch for
> > this version?
> >
> > Thanks,
> > Shyamlee
> >
> > On Thu, Aug 20, 2020 at 8:43 PM Roy Marples <roy@xxxxxxxxxxxx
> > <mailto:roy@xxxxxxxxxxxx>> wrote:
> >
> > On 20/08/2020 11:57, Shyamlee Badole wrote:
> > > 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.
> >
> > Thanks, makes it simple to fix I hope!
> > Comitted this to fix:
> >
> https://roy.marples.name/cgit/dhcpcd.git/commit/?id=f021b552b5c53cfa785bc5f8df1c97fa8ffa9b86
> >
> > Can you test it please?
> >
> > Roy
> >
>
Archive administrator: postmaster@marples.name