Closed borkra closed 3 years ago
ido
commented
3 years ago If I understood correctly, the problem will be solved by either not using dnsmasq, or waiting until dnsmasq does another release...
I would prefer to avoid introducing additional complexity to dhcpcd for a temporary workaround.
borkra
commented
3 years ago The problem is that dnsmasq has large installation footprint. I am not in control of network device is on, or what customers are using for DHCP server.
So the fact that dnsmasq is fixed will have little bearing on the problem in years to come, until everybody updates.
And large IT organizations are very conservative in changing network hardware/software. The only grace, I hope though majority customers will use Cisco routers as DHCP server.
I hope this issue could be fixed.
ido
commented
3 years ago Can you point me to the dnsmasq commit that resolves the bug and any other documentation or discussion you have on it? I’ll do some reading, but my current inclination is to close as wontfix because this is a slippery slope as far as complexity goes.
On Wed, Apr 28, 2021 at 11:40 Boris Krasnovskiy @.***> wrote:
The problem is that dnsmasq has large installation footprint. I am not in control of network device is on, or what customers are using for DHCP server.
So the fact that dnsmasq is fixed will have little bearing on the problem in years to come, until everybody updates.
And large IT organizations are very conservative in changing network hardware. The only grace, I hope though majority customers will use Cisco routers as DHCP server.
I hope this issue could be fixed.
— You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/NetworkConfiguration/dhcpcd/issues/35#issuecomment-828690163, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAU4RXQYBUIIRLYVFDRQE3TLBJBZANCNFSM43XCVJBA .
borkra
commented
3 years ago borkra
commented
3 years ago The original problem was when device went through reboot without releasing DHCPv6 address, when it comes back up IPv6 not received.
I have conversation with Roy on the mailing list, why IPv6 is not released from DHCPv6 server, and Roy helped me with adding release flag to the conf file. Unfortunately, release fixes the problem on graceful shutdown, but not on ungraceful one, like yanking power cord. The other part of the issue, why dhcpcd could not get IPv6 address back after reboot. My understanding that was due to rebind message problem with dnsmasq.
My hope is you could add something like if REBIND message timed out (not acked withing certain time send RENEW or something like it)
ido
commented
3 years ago On Wed, Apr 28, 2021 at 2:03 PM Boris Krasnovskiy @.***> wrote:
The original problem was when device went through reboot without releasing DHCPv6 address, when it comes back up IPv6 not received.
I have conversation with Roy on the mailing list, why IPv6 is not released from DHCPv6 server, and Roy helped me with adding release flag to the conf file. Unfortunately, release fixes the problem on graceful shutdown, but not on ungraceful one, like yanking power cord. The other part of the issue, why dhcpcd could not get IPv6 address back after reboot. My understanding that was due to rebind message problem with dnsmasq.
My hope is you could add something like if REBIND message timed out (not acked withing certain time send renew or something like it)
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/NetworkConfiguration/dhcpcd/issues/35#issuecomment-828778196, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAU4RVJG6THL35QEAE53M3TLBZYLANCNFSM43XCVJBA .
rsmarples
commented
3 years ago I have conversation with Roy on the mailing list, why IPv6 is not released from DHCPv6 server, and Roy helped me with adding release flag to the conf file. Unfortunately, release fixes the problem on graceful shutdown, but not on ungraceful one, like yanking power cord.
Nothing stops you from manually deleting the lease file before dhcpcd starts or during the PREINIT hook if you want it scripted. That should force a fresh DISCOVER each time dhcpcd starts.
The other part of the issue, why dhcpcd could not get IPv6 address back after reboot. My understanding that was due to rebind message problem with dnsmasq.
My hope is you could add something like if REBIND message timed out (not acked withing certain time send RENEW or something like it)
That is not RFC compliant. REBIND happen after RENEW times out or when a link comes up with lease containing a Prefix Delegation. Sending a RENEW during REBIND might confuse some servers. If REBIND times out then the lease is discarded and we enter the DISCOVER phase.
On carrier up, if we REBIND a DHCPv4 lease then the timeouts are be shortened to the reboot option in dhcpcd.conf, default of 5 seconds. https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/if-options.h#L51
We might want to consider the same for DHCPv6 leases, maybe adding a timeout to dhcp6_startexpire here: https://github.com/NetworkConfiguration/dhcpcd/blob/master/src/dhcp6.c#L2720
The problem is that all currently released versions of dnsmasq do not support dhcpv6 rebind message. It's is fixed already in development tree, but it will be a while before it will be released and propagate through all the installations, I wonder if some workaround could be offered in dhcpcd for this.