[DHCP] non of the options are transmitted

[RealKev79]

Issue Details

• Version of AdGuard Home server:
  • v0.107.7
• How did you install AdGuard Home:
  • Docker (adguard/adguardhome:latest)
• How did you setup DNS configuration:
  • ?
• If it's a router or IoT, please write device model:
  • Synology DS614!play
• CPU architecture:
  • Intel
• Operating system and version:
  • DSM 7.1-42661 Update 2

Expected Behavior

Entered DHCPv4-options are sended to the client even when not directly requested (like #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:

Screenshot from responding answer to a discover packet from AGH

Screenshot from responding answer to a discover packet from parallel installed docker-image dhcpd with nearly the same config-options

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

[EugeneOne1]

@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?

[RealKev79]

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 ;-))

[EugeneOne1]

@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):

1. the ones explicitly requested by client with the option 55;
2. the ones required for host configuration, as per RFC 2131 (which points to RFC 1122, RFC 1123, RFC 2132).

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.

[RealKev79]

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

[EugeneOne1]

@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?

[EugeneOne1]

@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?

[RealKev79]

Hi @EugeneOne1, I have tried the "edge-version" and there everything works fine, as you can see:

[EugeneOne1]

Fine, then I'll close the issue. Thank you for reporting.