Re: [systemd-devel] [PATCH 00/11] Finalize initial DHCP support
On Fri, 2013-12-20 at 09:47 -0800, Marcel Holtmann wrote: Hi Tom, The first seven patches fix a few issues with the current code. Patch 09 adds DHCP lease renewing support when timer T1 triggers. Using the UDP socket sending implementation in patch 08, the DHCP lease renewal is unicasted to the DHCP server. This means that systemd-network should have applied the acquired IP address and default route to the proper interface before timer T1 triggers. this could become racy and we might end up in funny cases if the lease is really small. I think networkd and the DHCP need some way of communicating a) I set the IP you told me and/or b) we have T1 triggering, have you set the address or should I just redo the DHCP process. Makes sense to me for networkd to call (something like) sd_dhcp_client_address_configured(client, true) whenever it has successfully set the addresses/routes. I.e., I'd go with option (a). Or is there a reason to go with (b) that I'm not seeing? the case I see is that T1 is triggered, but the IP address is not set. Then of course we should not be setting it anymore since it might not stay valid. Leases with lifetime less than 10 seconds are not accepted by the code currently. With the default T1 of half lease time, this gives 5 seconds to react. Now the funny part is that the server can suggest other values for T1 and T2 that the code will use, so yes, the server can try to suggest a 1s T1 expiry time. If the address is not set at the time of T1 expiring, it is treated as a temprorary error and T1 retry is rescheduled with a minimum time of 60 seconds, this from section 4.4.5 in RFC 2131. Thus both T2 and the whole lifetime will expire before that with a short lease 60s. If T2 is reached, the DHCP Request is broadcasted anyway, so if the address is not set even at this point, a new DHCP Request is still sent. The somewhat fuzzy idea was to use T1 from the server if given and to set the next T1 timeout to the minimum 60 seconds proposed by the RFC if the previous reacquisition fails. With this the code should still work nicely with short lease timeouts. But more testing with really short lease times are anyway appropriate. Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/11] Finalize initial DHCP support
On Fri, Dec 20, 2013 at 6:47 PM, Marcel Holtmann mar...@holtmann.org wrote: Hi Tom, The first seven patches fix a few issues with the current code. Patch 09 adds DHCP lease renewing support when timer T1 triggers. Using the UDP socket sending implementation in patch 08, the DHCP lease renewal is unicasted to the DHCP server. This means that systemd-network should have applied the acquired IP address and default route to the proper interface before timer T1 triggers. this could become racy and we might end up in funny cases if the lease is really small. I think networkd and the DHCP need some way of communicating a) I set the IP you told me and/or b) we have T1 triggering, have you set the address or should I just redo the DHCP process. Makes sense to me for networkd to call (something like) sd_dhcp_client_address_configured(client, true) whenever it has successfully set the addresses/routes. I.e., I'd go with option (a). Or is there a reason to go with (b) that I'm not seeing? the case I see is that T1 is triggered, but the IP address is not set. Then of course we should not be setting it anymore since it might not stay valid. However this could be done by DHCP itself just deciding that if client_address_configured is not called by the the time T1 expired, let the DHCP code redo the DHCP discovery. Yeah, that makes sense. For good measure we should have warnings in the code for these unlikely race scenarios and see if someone is actually able to trigger them. With ConnMan, I do not recall we had bug reports of this. However we do not know what funny cases happen with virtualization and containers. Agreed. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/11] Finalize initial DHCP support
On Fri, Dec 20, 2013 at 4:16 PM, Patrik Flykt patrik.fl...@linux.intel.com wrote: The first seven patches fix a few issues with the current code. Patch 09 adds DHCP lease renewing support when timer T1 triggers. Using the UDP socket sending implementation in patch 08, the DHCP lease renewal is unicasted to the DHCP server. This means that systemd-network should have applied the acquired IP address and default route to the proper interface before timer T1 triggers. Common code is factored out in patch 10, which makes patch 11 containing the broadcasting of DHCP Requests at timer T2 trigger quite small. At this point in time support for fetching DNS, NTP, etc options from the DHCP message(s) is still missing, sorry for that. Also Init-Reboot state support is missing; adding that functionality can speed up the address acquisition if the host comes back to a known network where it still has an unexpired lease. Hi Patrik, I applied these patches, with the minor suggestions from Lennart and Zbigniew. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/11] Finalize initial DHCP support
On Fri, Dec 20, 2013 at 4:43 PM, Marcel Holtmann mar...@holtmann.org wrote: Hi Patrik, The first seven patches fix a few issues with the current code. Patch 09 adds DHCP lease renewing support when timer T1 triggers. Using the UDP socket sending implementation in patch 08, the DHCP lease renewal is unicasted to the DHCP server. This means that systemd-network should have applied the acquired IP address and default route to the proper interface before timer T1 triggers. this could become racy and we might end up in funny cases if the lease is really small. I think networkd and the DHCP need some way of communicating a) I set the IP you told me and/or b) we have T1 triggering, have you set the address or should I just redo the DHCP process. Makes sense to me for networkd to call (something like) sd_dhcp_client_address_configured(client, true) whenever it has successfully set the addresses/routes. I.e., I'd go with option (a). Or is there a reason to go with (b) that I'm not seeing? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
