Honor deployment.useinsecureprotocols for ProxyDHCP boot - #265
Merged
Conversation
reply_dhcp4 declines to answer a PXE boot request unless deployment.useinsecureprotocols is set to firmware or always, but proxydhcp had no such check. A node left at the default of never was therefore still offered a TFTP bootfile and a plain http boot.ipxe URL whenever the request arrived on port 4011 rather than port 67, so the attribute silently did nothing in ProxyDHCP deployments alongside an independent DHCP server. Apply the same gate, including the UEFI HTTP boot exemption, and log the same remediation hint. The node attributes are now fetched once and passed through to get_deployment_profile instead of being looked up again there. Requests whose architecture could not be determined are ignored rather than falling through to the reply. opts_to_dict stops parsing before the client architecture option whenever the message type is not a request, and such a packet would otherwise reach the iPXE branch and be handed a plain http boot.ipxe URL without ever passing the gate.
The per-MAC 90 second log throttle in proxydhcp has been inert: the `skiplogging = True` reset sat in relay_proxydhcp, where it is a dead local, while the loop in proxydhcp only ever assigns False. Once the first packet is handled the flag stays False for the life of the process, so every retransmitted boot request logs again even though ignoredisco is updated to suppress it. Reset the flag at the top of each loop iteration instead, next to the timestamp check it belongs to, and drop the dead assignment.
reply_dhcp4 logs the insecure mode remediation hint on every DHCP discover it refuses. A node in this state never receives a reply, so it retries for as long as it is powered on and the same message repeats every few seconds. Rate limit it per hardware address the way the neighbouring boot attempt messages already do, reusing the ignoremacs window that check_reply uses for the missing profile hint.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
reply_dhcp4refuses to answer a PXE boot request unlessdeployment.useinsecureprotocolsis set tofirmwareoralways, but the proxyDHCP handler on port 4011 had no such check. A node left at the default ofneverwas stilloffered a TFTP bootfile and a plain http
boot.ipxeURL whenever its request arrived on 4011 rather than 67, so theattribute silently did nothing in ProxyDHCP deployments that run alongside an independent DHCP server.
get_deployment_profileinstead of being looked up twice.bootfileunset or left over from an earlier client.skiploggingper loop iteration. The reset sat inrelay_proxydhcpas a dead local, so the flag stayedFalseafter the first packet and the 90 second per hwaddr window never re-armed.reply_dhcp4through the existingignoremacswindow. A refused node never gets a reply, so it retries for as long as it is powered on and the hint repeated every few seconds.