[kea-dev] Fwd: Need Help with modifying the source code of the ISC DHCP server to send certain vender specific options to client eventhough the client doesnot request it in ORO

Fri Oct 14 08:44:48 UTC 2016

Hi Anoop,

First of all, the list you're posting to - kea-dev - is dedicated to
discussions related to development of Kea, ISC's new implementation. The
files you mentioned are from ISC DHCP. If you want to discuss them, the
best list would be either dhcp-workers (which sadly has very little
traffic, but code related topics are discussed there occasionally) or
dhcp-users (that has a lot of subscribers, but many of them are users,
not developers).

Now that you came to the kea-dev, maybe you can consider migrating you
DHCP server to Kea? Kea sources are much better documented, so any
modifications you may need to do are easier to conduct. But before I get
to specific changes you need to make, here's a bit of background.

You want your clients to receive vendor options, even though they didn't
request it. Vendor options work slightly differently than regular
options, because they're... well, vendor specific. In a network you may
have clients from different vendors and each client could request a
vendor option. To tell the difference between them, entreprise-id field
was introduced in vendor and vendor-class options. This is basically the
client saying "I was built by vendor 1234 and would like to get vendor
options specific for vendor 1234". Then the server knows which options
to send. In your case the information about the enterprise of the client
is not present, so the server won't assign any options.

Obviously, the best way forward would be to fix the clients. But since
you're looking into the server modification I presume that's not
possible for whatever reason (because it would take too long, the vendor
is unwilling or unable to modify the code etc).

Failing that, the next best solution would be to use Kea with custom
hook. Hooks is a nice mechanism that allows influencing almost every
step of the packet processing. In your particular case, you should
augment incoming packets, so they'd look like as if they had the vendor
option in them. You should use pkt6_receive hook for that. Then Kea will
process is normally and once it hits the vendor processing code, it will
assign the options.

Third and least preferred option is to mutilate the server code that
does vendor processing to skip all the checks and send the options every
time. This is strongly discouraged for several reasons. First, it may
solve your immediate problem now, but if you need to change anything,
you'd need to hack the server code again. If there are other clients,
that, say, require a different set of vendor options, you'd be out of
luck. Finally, upgrading to future versions would be painful, as you'd
have to port your fixes. You may likely not have that additional time
for every release, so the solution will get stuck on version that gets
older and older.

I hope that was sufficient to convince you to consider option 2, i.e. to
write a hook. Here are some background information that you may find
useful for that. You haven't said that explicitly, but your clients are
cable modems or other cable devices, right?

1. Go to kea.isc.org -> Developer's Guide and see Hooks Framework
section. The direct link is
https://jenkins.isc.org/job/Fedora20_32_doxygen_doc/doxygen/. In
particular, pay close attention to hook developers guide.

2. You should install your hook on pkt6_receive (documentation here:
https://jenkins.isc.org/job/Fedora20_32_doxygen_doc/doxygen/d1/d02/dhcpv6Hooks.html).
This hook provides access to the incoming client's packet via query6
parameter.

3. The hook should more or less look like this:

    // Get query6 parameter from hooks. That's the incoming packet
    Pkt6Ptr query6;
    handle.getArgument("query6", query6);

    // If there's a vendor option in the packet already, do nothing.
    // There may be other clients that are well behaving.
    if (query6->getOption(D6O_VENDOR_OPTS)) {
        return;
    }

    // Create vendor-option for cable modem, enterprise-id=4491 (that's
docsis)
    OptionPtr vendor_opt(new OptionVendor(Option::V6, 4491));

    // This option should have one sub-option with code 1. In DOCSIS world
    // that's an ORO (Option Request Option). It contains a list of docsis
    // options the server is requested to provide.
    boost::shared_ptr<OptionUint16Array>
        subopt(new OptionUint16Array(Option::V6, DOCSIS3_V6_ORO));

    // Insert two option codes into that option
    subopt->addValue(DOCSIS3_V6_TFTP_SERVERS); // code 32
    subopt->addValue(DOCSIS3_V6_CONFIG_FILE);  // code 33

    // Now put the ORO suboption into the vendor-option
    vendor_opt->addOption(subopt);

    // And finally add the option the the incoming packet.
    // With this modification it will look like as if the incoming packet
    // had vendor option in it and requested options 32 and 33.
    query6->addOption(vendor_opt);

I haven't tested the code, so you may need to tweak it a bit to make it
work, but it's more or less correct. That code along with the
explanations above should give you sufficient information to sort that
out. With this hook implemented, you can then normally configure vendor
options as explained in Kea User's Guide.

4. To see how the vendor options are assigned, see
Dhcpv6Srv::appendRequestedVendorOptions in src/bin/dhcp6/dhcp6_srv.cc.

5. Once you have everything up and running, I'd appreciate if you report
how it went. You should probably tell you vendor that his client devices
are broken, too.

Hopefully this mail will be useful for you and possibly for others to
make their first steps with hooks in Kea.

Tomek

On 14/10/16 09:41, Anoop Sreedharan wrote:
> ---- Mailing again without screenshot to reduce size ----
>
> Hello Team,
>
> First of all i am sending out this broadcast message to the developer
> list i got from the ISC site. hope it is to correct group else
> appreciate if anyone could help to divert to the right people.
>
> *Nature of request*: Need help for some proprietary implementation of
> the DHCP server implementation for version 6.
>
> *Problem statement:* I have a host of clients that can be enabled to
> to send DHCPv6 solicit request, but the problem is that my client
> doesnot add vender specific request in its ORO field. 
>
>     So in effect i am not able to send the tftp servers and boot file
>     name in vender specific option 17 suboption 32 and 33 field.
>
> *Help required*: i have read RFC's and found that standard based DHCP
> server's doesnot send options other than what is requested by the client. 
>
>     So need help to bypass this standard based limitations (Limitation
>     is actually my client's but what the heck!!!) so that the server
>     sends this suboption 32 and 3 that i configure in
>     the *dhcpd6.con*f file to the clients as per this .conf file.
>
>
> *Analysis done:* i have analyzed the dhcpv6.c file and am of the
> opinion that the file dhcpv6.c is configured to send some static
> options to client other than what was requested via the ORO. So the
> question is can this be modified to always read the venderspecific
> options configured in the dhcpd6.conf file?
> *and the bigger question, can anyone help me out on this. *
>
> *plz reach me out on my mail or skype id as i am very much in need to
> sort it out.*
> *
> *
> *
> *
> -- 
> /Regards,/
> /T Anoop Sreedharan/
> /+91-9022078298/
> /Skype: anoop.thek/
> /
> /
>
>
>
>
>
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20161014/ff4b5012/attachment-0001.html>