Send kea-dev mailing list submissions to
kea-dev@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
kea-dev-requ...@lists.isc.org
You can reach the person managing the list at
kea-dev-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. 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 (Anoop Sreedharan)
2. Re: 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 (Ola Thoresen)
3. Re: 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 (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Fri, 14 Oct 2016 13:11:27 +0530
From: Anoop Sreedharan <t.aanoo...@gmail.com>
To: kea-dev@lists.isc.org
Subject: [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
Message-ID:
<CACy0pi2FKhEUUJbYnwgLkieZ82Vh0ij2WtPDtA9GEa7TrCG=b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
---- 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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20161014/616afbcd/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 14 Oct 2016 09:53:24 +0200
From: Ola Thoresen <o...@nytt.no>
To: kea-dev@lists.isc.org
Subject: Re: [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
Message-ID: <316f90e8-b7c2-fd31-747c-6cccb74d6...@nytt.no>
Content-Type: text/plain; charset=windows-1252; format=flowed
This list is for development of the Kea DHCP-server, not the "old" dhcpd.
And even if I can not help you directly with your problem, it sounds
like you are trying to achieve something I made a "hook" for Kea to do.
https://github.com/Olen/kea_hooks
This hook is for DHCPv4, but it could easily be extended to DHCPv6 as
well. Unfortunately I have not been able to maintain the hook and
upgrade it to work with newer releases of Kea (it might work, I have
just not tested it). But I would _love_ it if someone forked the code
and started fixing it up.
I simply do not have the skill, nor the time, to keep up.
Rgds.
Ola Thoresen
On 14. okt. 2016 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 3
Date: Fri, 14 Oct 2016 10:44:48 +0200
From: Tomek Mrugalski <tom...@isc.org>
To: kea-dev@lists.isc.org
Subject: Re: [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
Message-ID: <645c7869-1919-a105-626f-d005fd9b9...@isc.org>
Content-Type: text/plain; charset="windows-1252"
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@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.html>
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
kea-dev@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 31, Issue 4
**************************************
