smoltcp
smoltcp copied to clipboard
Reuse server DHCPOFFER transaction id in DHCPREQUEST
Hello! From my understanding of the DHCP specification rfc2131 smoltcp currently does not follow the specification when it comes to the transaction id used for DHCPREQUEST messages. I initially saw this mentioned in a discussion here https://github.com/esp-rs/esp-hal/discussions/2345#discussioncomment-11179188.
If I understand the spec. correctly, when a DHCPOFFER is received from a server, the follow-up DHCPREQUEST should reuse the transaction id from the DHCPOFFER message. Currently a new random transaction idis used for the request instead.
The relevant parts of the RFC is Table 5 and the text just after it (page 36-37).
I have only been able to test this on my home setup so far but it seems to work as expected there at least. I'm not sure how to add a proper test for this or if the change might interact with retries in some way that needs additional handling.
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 80.33%. Comparing base (e2b75e3) to head (48d10eb).
:warning: Report is 18 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #1061 +/- ##
==========================================
- Coverage 81.17% 80.33% -0.84%
==========================================
Files 81 81
Lines 28955 24341 -4614
==========================================
- Hits 23503 19554 -3949
+ Misses 5452 4787 -665
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Thanks for the review! Is there anything I should do before this can be merged? I see that some checks are marked as failed.
This seems to work as well - I see that the DHCP Discover and Request use the same transaction id.
looks good. I got a few more questions tho:
- Should the xid of the DHCPREQUEST in renew/rebind also match the original xid of the DHCPOFFER? The current code is generating them randomly. I've read through the RFC but I don't see an obvious answer.
- The code is always calling
random_transaction_idbut then overwriting it in the Requesting branch. Maybe it'd be better to only callrandom_transaction_idin the branches where it's actually needed to avoid unnecessary RNG calls.
I can't find a clear answer regarding DHCPREQUEST xid:s at renew/rebind in the RFC. However, both Windows ipconfig /renew, and linux dhclient enp1s0 seem to use new xid:s in the DHCPREQUEST when renewing.