dhcpcd-discuss

On 5/21/20 8:23 AM, Roy Marples wrote:
> On 21/05/2020 02:36, Jeff Kletsky wrote:
> > Thanks, moved to master
>
> Makes my life easier to support :)
>
> > /usr/local/etc/dhcpcd$ git diff HEAD^
> > diff --git a/dhcpcd.service b/dhcpcd.service
> > index 0b21f99..abc1e6a 100644
> > --- a/dhcpcd.service
> > +++ b/dhcpcd.service
> > @@ -7,6 +7,8 @@ Documentation=man:dhcpcd(8)
> >   Type=forking
> >   ExecStart=/usr/local/sbin/dhcpcd
> >   Restart=always
> > +StandardOutput=null
> > +StandardError=null
> >
> >   [Install]
> >   WantedBy=multi-user.target
>
> https://roy.marples.name/cgit/dhcpcd.git/commit/?id=6ddd035d2d3258e4a14aa352f331997a1054e278 
>
>
> You can now remove the StandardOutput/Error redirect and add -qq as 
> arguments to the ExecStart directive.
>
> > I'd like to say this "proves" that the issue has been resolved 
> > somewhere since 9.0.2, but I'll definitely keep my eyes on both the 
> > packets and the logs.
> >
> > (Yes, I'm willing to make further tests as well)
>
> Glad it's been magically fixed for you!

Thanks for the additional `-qq` -- changes adopted.

As an outsider, I suspect that the logging of stdout/stderr is a 
feature. That way a script as a service can just write to stdout/stderr 
and be "properly" logged (both for syslog and perhaps journalctl) 
without trying to figure out `logger` and however one would write to the 
system journal.



"Magical" always worries me

Reverting to the 9.0.2 didn't exhibit any strange behavior over several 
hours and Request/ACK cycles, nor did additionally reverting to not 
suppressing stdout/stderr.

At this point, I'll just run with the updated `master` and continue to 
capture packets for later examination.


Jeff



For anyone that comes across this in the future, I have seen two classes 
of problems with Comcast (DOCSIS) and DHCP.


The first seems to be a Comcast issue, *not* a dhcpcd issue, where 
packets sent from my router are apparently not seen by the CMTS or 
equipment behind this on the Comcast end. This seems to include 
responses to ARP inquiries sent by the Comcast router, as well as lack 
of response from Comcast equipment (including DHCP requests). While not 
confirmed, it is my recollection that it only seemed to impact IPv4.


The second class is where it appears that a renewal of a lease should 
succeed (ACK from Comcast), but the lease eventually expires. This class 
of issues was the subject of this thread. Some evidence can be seen in 
the logs as "failed to renew DHCP, rebinding", below filtered with 
`fgrep dhcpcd`. As IPv6 seems to be working, this does not appear to be 
a transport-related issue. Other symptoms include dhcpcd repeatedly 
attempting to renew the lease before the timers expire (see earlier in 
this thread).

May 19 20:24:08 dhcpcd[658]: enp0s0f0: REPLY6 received from 
fe80::201:5cff:fe65:bc46 # Comcast equipment
May 19 20:24:08 dhcpcd[658]: enp0s0f0: renew in 3600, rebind in 5760, 
expire in 7200 seconds
May 19 21:05:55 dhcpcd[658]: enp0s0f0: failed to renew DHCP, rebinding
May 19 21:24:08 dhcpcd[658]: enp0s0f0: REPLY6 received from 
fe80::201:5cff:fe65:bc46
May 19 21:24:08 dhcpcd[658]: enp0s0f0: renew in 3600, rebind in 5760, 
expire in 7200 seconds
May 19 22:22:16 dhcpcd[658]: enp0s0f0: failed to renew DHCP, rebinding
May 19 22:24:08 dhcpcd[658]: enp0s0f0: REPLY6 received from 
fe80::201:5cff:fe65:bc46
May 19 22:24:08 dhcpcd[658]: enp0s0f0: renew in 3600, rebind in 5760, 
expire in 7200 seconds
May 19 23:24:08 dhcpcd[658]: enp0s0f0: REPLY6 received from 
fe80::201:5cff:fe65:bc46
May 19 23:24:08 dhcpcd[658]: enp0s0f0: renew in 3600, rebind in 5760, 
expire in 7200 seconds
May 19 23:38:37 dhcpcd[658]: enp0s0f0: failed to renew DHCP, rebinding