dhcpcd-discuss

On 05/05/2020 17:40, Scott Leggett wrote:
> Hi,
>
> I've noticed some interesting behaviour in dhcpcd 9.0.2.
>
> I was investigating a series of log messages like this:
>
>    May 05 20:55:00 gateway dhcpcd[7402]: enp1s0: failed to renew DHCP, rebinding
>    May 05 21:21:15 gateway dhcpcd[7402]: enp1s0: failed to renew DHCP, rebinding
>    May 05 21:47:30 gateway dhcpcd[7402]: enp1s0: failed to renew DHCP, rebinding
>    May 05 22:13:45 gateway dhcpcd[7402]: enp1s0: failed to renew DHCP, rebinding

I have replicated that also with privsep disabled but not with the default of it 
enabled.

Is your dhcpcd setup for privsep?

> A packet capture shows the reason for the renew failure. xx is the
> dhcpcd client and yy is the server:
>
>    Time           Source Port Destination Port Source                Destination           Protocol Length Info
>    45.339308      39          67               xx.xxx.xxx.xxx        yy.yyy.yyy.y          DHCP     357    DHCP Request  - Transaction ID 0x0123456
>    45.350879      67          68               yy.yyy.yyy.y          xx.xxx.xxx.xxx        DHCP     342    DHCP ACK      - Transaction ID 0x0123456
>    87.300454      68          67               xx.xxx.xxx.xxx        255.255.255.255       DHCP     357    DHCP Request  - Transaction ID 0x0123456
>    87.312131      67          68               yy.yyy.yyy.y          xx.xxx.xxx.xxx        DHCP     342    DHCP ACK      - Transaction ID 0x0123456
>
> dhcpcd seems to be using a weird source port for the renew. The response
> comes in to port 68, but it's getting dropped by the stateful firewall
> so dhcpcd never sees it.
> The rebind works because it uses the same source port that the response
> comes in on, so the firewall lets it through.
>
> Is this behaviour intentional?

I cannot replicate this though! In all cases the source port is correct.
I just need to fix the case above later tonight and hopefully you can test it if 
it's the same.

Roy