<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Anoop,<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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. <br>
<br>
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.<br>
<br>
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?<br>
<br>
1. Go to kea.isc.org -> Developer's Guide and see Hooks
Framework section. The direct link is
<a class="moz-txt-link-freetext" href="https://jenkins.isc.org/job/Fedora20_32_doxygen_doc/doxygen/">https://jenkins.isc.org/job/Fedora20_32_doxygen_doc/doxygen/</a>. In
particular, pay close attention to hook developers guide.<br>
<br>
2. You should install your hook on pkt6_receive (documentation
here:
<a class="moz-txt-link-freetext" href="https://jenkins.isc.org/job/Fedora20_32_doxygen_doc/doxygen/d1/d02/dhcpv6Hooks.html">https://jenkins.isc.org/job/Fedora20_32_doxygen_doc/doxygen/d1/d02/dhcpv6Hooks.html</a>).
This hook provides access to the incoming client's packet via
query6 parameter.<br>
<br>
3. The hook should more or less look like this:<br>
<br>
// Get query6 parameter from hooks. That's the incoming packet<br>
Pkt6Ptr query6;<br>
handle.getArgument("query6", query6);<br>
<br>
// If there's a vendor option in the packet already, do
nothing.<br>
// There may be other clients that are well behaving.<br>
if (query6->getOption(D6O_VENDOR_OPTS)) {<br>
return;<br>
}<br>
<br>
// Create vendor-option for cable modem, enterprise-id=4491
(that's docsis)<br>
OptionPtr vendor_opt(new OptionVendor(Option::V6, 4491));<br>
<br>
// This option should have one sub-option with code 1. In
DOCSIS world<br>
// that's an ORO (Option Request Option). It contains a list
of docsis<br>
// options the server is requested to provide.<br>
boost::shared_ptr<OptionUint16Array><br>
subopt(new OptionUint16Array(Option::V6, DOCSIS3_V6_ORO));<br>
<br>
// Insert two option codes into that option<br>
subopt->addValue(DOCSIS3_V6_TFTP_SERVERS); // code 32<br>
subopt->addValue(DOCSIS3_V6_CONFIG_FILE); // code 33<br>
<br>
// Now put the ORO suboption into the vendor-option<br>
vendor_opt->addOption(subopt);<br>
<br>
// And finally add the option the the incoming packet.<br>
// With this modification it will look like as if the incoming
packet<br>
// had vendor option in it and requested options 32 and 33.<br>
query6->addOption(vendor_opt);<br>
<br>
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.<br>
<br>
4. To see how the vendor options are assigned, see
Dhcpv6Srv::appendRequestedVendorOptions in
src/bin/dhcp6/dhcp6_srv.cc.<br>
<br>
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.<br>
<br>
Hopefully this mail will be useful for you and possibly for others
to make their first steps with hooks in Kea.<br>
<br>
Tomek<br>
<br>
On 14/10/16 09:41, Anoop Sreedharan wrote:<br>
</div>
<blockquote
cite="mid:CACy0pi2FKhEUUJbYnwgLkieZ82Vh0ij2WtPDtA9GEa7TrCG=BQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr"><span class="">---- Mailing again without
screenshot to reduce size ----</span></div>
<div dir="ltr"><span class=""><br clear="all">
<div><span style="font-size:12.8px">Hello Team,</span>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">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.</div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px"><b>Nature of request</b>:
Need help for some proprietary implementation of the
DHCP server implementation for version 6.</div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px"><b>Problem statement:</b> 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. </div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px">
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">
<div>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.</div>
<div><br>
</div>
</blockquote>
<b>Help required</b>: i have read RFC's and found that
standard based DHCP server's doesnot send options
other than what is requested by the client. </div>
<div style="font-size:12.8px">
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">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 <b>dhcpd6.con</b>f file to the
clients as per this .conf file.</blockquote>
</div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px"><b>Analysis done:</b> 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?</div>
<div style="font-size:12.8px"><b>and the bigger
question, can anyone help me out on this. </b></div>
<div style="font-size:12.8px"><br>
</div>
<div style="font-size:12.8px"><b>plz reach me out on my
mail or skype id as i am very much in need to sort
it out.</b></div>
</div>
<div style="font-size:12.8px"><b><br>
</b></div>
</span>
<div style="font-size:12.8px"><b><br>
</b></div>
<span class="">-- <br>
<div class="m_-6579569925601830621gmail_signature">
<div><i>Regards,</i></div>
<i>T Anoop Sreedharan</i></div>
<div class="m_-6579569925601830621gmail_signature"><i>+91-9022078298</i></div>
<div class="m_-6579569925601830621gmail_signature"><i>Skype:
anoop.thek</i></div>
<div class="m_-6579569925601830621gmail_signature"><i><br>
</i></div>
</span></div>
</div>
<br>
<br clear="all">
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
kea-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kea-dev@lists.isc.org">kea-dev@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-dev">https://lists.isc.org/mailman/listinfo/kea-dev</a></pre>
</blockquote>
<p><br>
</p>
</body>
</html>