[riot-notifications] [RIOT-OS/RIOT] dhcpv6_client: refactor to use `event_timeout` for non-sock timeouts (#16668)

Martine Lenders notifications at github.com
Wed Jul 21 22:23:40 CEST 2021


@miri64 commented on this pull request.



> @@ -494,27 +505,21 @@ static int _preparse_advertise(uint8_t *adv, size_t len, uint8_t **buf)
 static void _schedule_t2(void)
 {
     if (t2 < UINT32_MAX) {
-        uint64_t t2_usec = t2 * US_PER_SEC;
-
-        rebind_time = (xtimer_now_usec64() / US_PER_SEC) + t2;
-        xtimer_remove(&rebind_timer);
-        rebind_timer.callback = _post_rebind;
+        rebind_time = _now_sec() + t2;

This PR aims not to change the logic of the DHCPv6 implementation, but only refactors, so even if it is wrong, that change would belong into a different PR. Hovewer, L. 842 calculates the MRD for a RENEW transmission (please refer to the RFC to figure out what this means exactly, the implementation was a few years ago, I would need to reread it myself, to explain it properly myself; all the more reason why I don't want to change logic in this PR ... ;-)). This line only reschedules the next T2 event which was supplied in a REPLY message by the IA_PD option (or IA_NA option, once #16228 is in), so I don't see how the two operations would be related. I guess in L. 842 we want some kind of offset to T2, as for RENEW the MRD shall be ["Remaining time until earliest T2"](https://datatracker.ietf.org/doc/html/rfc8415#section-18.2.4).

Concerns about things happening at the same time don't make sense, since the client runs in a single thread ;-).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/16668#discussion_r674313480
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20210721/73cc42c5/attachment.htm>


More information about the notifications mailing list