Closed RealKev79 closed 2 years ago
@RealKev79, hello. Just to ensure, have you enabled DHCP by setting dhcp.enabled
field in the config to true
? Also, which ports are exposed in the AGH's container?
Hi @EugeneOne1 , sorry but this question could you answer by yourself ;-) When the DHCP weren´t enabled then it would not be responding with the "standard" options (51, 53, 54). And also the ports couldn´t be a problem, because the server is responding (and the image is configured with "host"-network ;-))
@RealKev79, hello again and sorry for leaving the issue with no attention, but we've came up with an assumption. The current implementation only overwrites the options that should be in the response (we've also described this in the wiki):
55
;Shortly, I suppose the device doesn't request the parameters, you're trying to rewrite. Could you please request any of those with some manual DHCP client? Thanks.
Hi @EugeneOne1, sorry to bother you, but did I get this topic right that the DHCP in AdGuardHome is only pushing the "standard" option as an offer and all other, in the config entered, options are ignored and only are pushed when the client is directly requesting them?
Is this right or did I get something wrong?
Yes my request is a "simple" dhcp-discover (with a dhcp-test-tool), and as you can see in my screenshots above, that my parallel installed DHCPD-Docker responses there directly with all possible options from the config.
How should I unterstand the milestone? Would you (the whole team ;-)) check it and "corrected" it in that version, so that all options from the config are then provided?
Greetings
@RealKev79, could you please take a look at the RFC 2131 page 29, the paragraph after the table 3. Doesn't it state that only the explicitly requested options (called "parameters" there) should be returned to the client? However, the same list of statements also contains the item:
Parameters with non-default values on the client's subnet.
Perhaps it means exactly the desired feature. @ainar-g, what do you think?
@RealKev79, hello again. We've fixed the DHCP options logic as well as added some new option types for convenient overriding the default ones. You may find the verbose description in the wiki page. The fix is already available in the latest edge build. Could you please check, if the desired options are returned now?
Hi @EugeneOne1, I have tried the "edge-version" and there everything works fine, as you can see:
Fine, then I'll close the issue. Thank you for reporting.
Issue Details
Expected Behavior
Entered DHCPv4-options are sended to the client even when not directly requested (like https://github.com/AdguardTeam/AdGuardHome/issues/4152)
Actual Behavior
None of the entered options in the AdGuardHome.yaml (dhcp/dhcpv4/options) are sended to the client.
Screenshots
Screenshot from the config:
![image](https://user-images.githubusercontent.com/108552488/176965693-b2f0556c-85c5-46a6-8e05-ab0f40ddb629.png)Screenshot from responding answer to a discover packet from AGH
![image](https://user-images.githubusercontent.com/108552488/176965994-23969ba5-0b3e-4c7f-8386-6ae866f0dc35.png)Screenshot from responding answer to a discover packet from parallel installed docker-image dhcpd with nearly the same config-options
![image](https://user-images.githubusercontent.com/108552488/176966159-1dafd540-9adc-4ed6-a601-bc470d57f923.png)As seen, dhcpd sends all available options when AGH only sends the absolut minimum
Additional Information
config-file is loaded correctly because in logfile are no errors, and when configured an extremly short lease time (60sec) it is loaded correctly and also is sended to the client