dhcpcd icon indicating copy to clipboard operation
dhcpcd copied to clipboard

Dhcpcd generating INIT-REBOOT messages during RENEWING/REBINDING when --noconfigure is on

Open acst1223 opened this issue 1 year ago • 6 comments

Hi,

I would like to report that when using dhcpcd with --noconfigure, it generates INIT-REBOOT messages during RENEWING/REBINDING.

According to RFC 2131 4.3.6, when the DHCP client renews or rebinds the lease, the requested-ip must not be set and ciaddr should be the IP address. However I've observed that in the actual dhcpcd packets, the requested-ip is set and ciaddr is zero. This is exactly the behavior of INIT-REBOOT.

After some investigation in the code, I've found that the reason lies in the state->addr property. When sending a DHCPREQUEST, if state->addr is NULL, ciaddr will be zero and the requested-ip will be set. Otherwise if state->addr is not NULL, ciaddr will be set and the requested-ip will not be set. When dhcpcd with --configure binds a lease, ipv4_applyaddr() is called and state->addr is set, so the RENEWING/REBINDING later for the lease works fine. However, when --noconfigure is used, ipv4_applyaddr() is not called in dhcp_bind(), for dhcp_bind() has returned earlier. This leads to state->addr keeping NULL and dhcpcd sending wrong messages during RENEWING/REBINDING.

I believe that although dhcpcd does not configure the system with --noconfigure, since it is still responsible for the DHCP negotiation, it still needs to maintain the correct state for each interface and send correct DHCP messages to the server.

Roy, could you take a look at this? Thanks!

Zikai

acst1223 avatar Aug 26 '24 04:08 acst1223

I'm in two minds about this. Even though dhcpcd isn't configuring the interface, it can detect if something has. I would much rather we detect if something has and then adjust accordingly. If at renew time and nothing has configured the interface then technically we cannot renew as there is no source address to renew from so INIT-REBOOT makes more sense than RENEW anyway.

BTW, just --force your push to your PR rather than creating new ones.

rsmarples avatar Sep 03 '24 09:09 rsmarples

Thanks for the reminder! I now understand that this detection is in dhcp_handleifa(). However, it only sets the address to state if PRIVSEP is used. What's the purpose for this? If we are using --noconfigure without PRIVSEP then we can never get the address set in the state.

I'll close the PR since dhcp_handleifa() now seems to be the issue.

acst1223 avatar Sep 24 '24 07:09 acst1223

Hi @rsmarples , is there any idea on this issue? Do you think we can remove the PRIVSEP here?

acst1223 avatar Oct 15 '24 09:10 acst1223

@acst1223 Ah sorry, time got away and I forgot about this. It was a bit more complicated, but I think the above patch covers it. Needs some testing though. If it fixes your use case or not please let me know!

rsmarples avatar Oct 16 '24 09:10 rsmarples

Thanks for your patch! I've tried it and it fixes this issue perfectly!

acst1223 avatar Oct 18 '24 07:10 acst1223

Need to do some testing myself before I commit, but the feedback is appreciated

rsmarples avatar Oct 18 '24 11:10 rsmarples