keep acquisition timestamp when route isn't updated

[Freax13]

RFC 4861 specifies that router advertisements should be sent no more than once every MIN_DELAY_BETWEEN_RAS (3 seconds). In practice though, there are several ISPs (Comcast, Spectrum, Vodafone) that send out router advertisements at higher rates.

Previously this caused dhcpcd to never update the route until it eventually expired and was removed by the kernel.

This happened because the rt_acquired timestamp was out of sync with the kernel expiry tracking. rt_acquired was updated every time a router advertisement was processed even when the route wasn't updated in the kernel. When router advertisements were sent out frequently, rt_acquired was updated frequently, the difference between the old and new rt_acquired values never became great enough for rt_cmp_lifetime to return 1 and the kernel's routing table was never updated.

To fix this, keep the old rt_acquired value iff the kernel's routing table wasn't updated. This ensures that rt_acquired stays in sync with the expiry value in the kernel's routing table.

Closes #681
Cc @squarooticus

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 802c5fb0-028c-44b5-a2d4-5cea4761981d

📥 Commits

Reviewing files that changed from the base of the PR and between 8b31291 and ed30cd8.

📒 Files selected for processing (4)

• src/if-linux.c
• src/ipv6.c
• src/route.c
• src/route.h

---

Walkthrough

The route acquisition timestamp field is renamed from rt_aquired to rt_acquired. Route lifetime calculations, route replacement, Linux expiration handling, and IPv6 RA/DHCP route construction now use the corrected field.

Changes

Route lifetime handling

Layer / File(s)	Summary
Route timestamp field src/route.h	Renames the acquisition timestamp field to rt_acquired and corrects its comment.
Route lifetime preservation src/route.c, src/if-linux.c	Updates lifetime comparisons, preserves the timestamp during unchanged route replacement, and uses the corrected field for expiration.
IPv6 route timestamp sources src/ipv6.c	Uses rt_acquired when constructing RA prefix, subnet, default, and DHCP routes.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: rsmarples

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes preserving the route acquisition timestamp when the route is not updated.
Description check	✅ Passed	The description directly explains the frequent router advertisement issue and the timestamp synchronization fix.
Linked Issues check	✅ Passed	The changes address issue #681 by preserving route timestamps when kernel routes are unchanged, enabling renewal under frequent router advertisements.
Out of Scope Changes check	✅ Passed	All changes support the route timestamp fix, including correcting the field name and updating its references.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[squarooticus]

It's very hard to follow the logic of how this code is supposed to work. It looks like:

• When rt_doroute() returns true, rt_build() replaces the original route (i.e., the one in dhcpcd's internal tables) with the one it acquired from the network (e.g., via DHCP or RA)
• rt_doroute() returns true when it indicates either (a) some change in the route (makes sense) and is successful in making that change or (b) no change (???).

I'm struggling to figure out why (b). The reason I'm trying to puzzle this out is that I'm not sure that modifying the newly-acquired route to match the original one is the right solution. I think it'll work, but AFAICT it's the only place where the newly-acquired route is synthetically modified, which feels like the wrong solution here.

It seems like the right class of solution here is to leave the original route in place when doroute thinks nothing has changed, whereupon eventually the acquisition time difference will exceed DEV_MAX, and the route will be replaced, both in the internal tables and the kernel. But to be confident about this, I first need to understand why (b) above. Can any of the core devs for dhcpcd explain that logic?