<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Arial Narrow";
panose-1:2 11 6 6 2 2 2 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=RU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>> </span><span lang=EN-US>On the surface it looks like it's either pointless behavior on the server's part or incorrect logic in the DHCP client. Am I missing something?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>Yes, without overriding serverid to one from incoming request packet, the server’s nak could be pointless.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>But with overriding, it’ll introduce the same naking issue even with clients which were checking server id and ignoring naks from non-selected servers.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>Dnsmasq starts to nak request from selecting clients in 2.46, see the story here<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><a href="http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q4/002476.html">http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q4/002476.html</a><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>Point of busybox’s udhcpc changes is described here<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><a href="https://bugs.busybox.net/show_bug.cgi?id=4267">https://bugs.busybox.net/show_bug.cgi?id=4267</a><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>As for ISC DHCP, it’s known client ignores NAK from non-selected servers in SELECTING state.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>As for server, it allow run-time control over weither or not a server, participating in failover, verifies server id option.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>This commit contains the old and new descriptions<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><a href="https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commitdiff;h=7116a34fc9b1fb307bcdca22e6963254289ecb80">https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commitdiff;h=7116a34fc9b1fb307bcdca22e6963254289ecb80</a> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:10.0pt;font-family:"Arial Narrow",sans-serif;color:#1F497D'>Best Regards, Vladislav Grishenko<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Kevin Benton [mailto:blak111@gmail.com] <br><b>Sent:</b> Monday, June 01, 2015 5:15 PM<br><b>To:</b> Vladislav Grishenko<br><b>Cc:</b> Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk<br><b>Subject:</b> Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Let me rephrase it slightly. What is the point of dnsmasq NAKing client responses to other servers if the clients are being programmed to ignore the NAKs? <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>On the surface it looks like it's either pointless behavior on the server's part or incorrect logic in the DHCP client. Am I missing something?<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jun 1, 2015 at 2:58 AM, Vladislav Grishenko <<a href="mailto:themiron@mail.ru" target="_blank">themiron@mail.ru</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Hi Kevin,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>ы</span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>> </span><span lang=EN-US>why do DHCP servers like dnsmasq generate them in the first place?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Because it’s per dnsmasq configuration and the effects are well-described in the man. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><a href="http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html" target="_blank">http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:11.0pt;color:black'>-K, --dhcp-authoritative</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt'><span lang=EN-US style='font-size:11.0pt;color:black'>Should be set when <b>dnsmasq is definitely the only DHCP server on a network</b>. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>you definitely have multiple dhcp servers, so this option is misused under your circumstances, not?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial Narrow",sans-serif;color:#1F497D'>Best Regards, Vladislav Grishenko</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Kevin Benton [mailto:<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>] <br><b>Sent:</b> Monday, June 01, 2015 2:02 PM</span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>To:</b> Vladislav Grishenko<br><b>Cc:</b> Brian Haley; Simon Kelley; <a href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">dnsmasq-discuss@lists.thekelleys.org.uk</a><br><b>Subject:</b> Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue<o:p></o:p></p></div></div></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I understand, but that eliminates the whole 'correcting rouge dhcp offers' part of the authoritative mode. <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>If we are teaching clients to ignore NAKs from other DHCP servers, why do DHCP servers like dnsmasq generate them in the first place? Wouldn't it be logically consistent to make a change to dnsmasq to prevent it from generating a NAK if the client is communicating with a different server?<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Is the client behavior regarding NAKs outlined in one of the DHCP RFCs? It does seem like there is a lot of confusion around what authoritative servers should be doing.<o:p></o:p></p></div></div></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko <<a href="mailto:themiron@mail.ru" target="_blank">themiron@mail.ru</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Hi Kevin,<br><br>Ignoring all naks – would be, but the fix is different.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>That fix ignores all naks except from the selected/requested server only, it’s ok.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:10.0pt;font-family:"Arial Narrow",sans-serif;color:#1F497D'>Best Regards, Vladislav Grishenko</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Kevin </span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Benton [mailto:<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>] <br><b>Sent:</b> Wednesday, May 27, 2015 9:32 AM<br><b>To:</b> Vladislav Grishenko<br><b>Cc:</b> Brian Haley; Simon Kelley; <a href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">dnsmasq-discuss@lists.thekelleys.org.uk</a><br><b>Subject:</b> Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue</span><o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of the 'authoritative' NAKing in the first place?<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko <<a href="mailto:themiron@mail.ru" target="_blank">themiron@mail.ru</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>> On 02/02/2015 05:47 PM, Brian Haley wrote:<br>> >><br>> >>> The one thing I'm curious about is if dnsmasq is restarted while a<br>> >>> VM holds a lease, how will it respond? As someone else has<br>> >>> pointed-out to me - isc-dhcp will respond with a DHCPNAK in that<br>> >>> case, and wondered why there would be a difference with dnsmasq.<br>> >>> Different interpretation of an RFC?<br>> >><br>> >><br>> >> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and<br>> >> therefore has its lease database deleted", then the RFC says that if<br>> >> a server gets a renewal for an unknown lease, it should return<br>> >> DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is<br>> >> set, when instead it quietly re-creates the lease.<br>> ><br>> > Yes, your assumption is correct, as --leasefile-ro is used it knows of<br>> > no current leases, and by default get a DHCPNAK.<br>> ><br>> >> dhcp-authoritative gives permission to dnsmasq to violate the RFC in<br>> >> a way which is useful in certain circumstances.<br>> ><br>> > Thanks, it does seem to do what I want with my initial testing.<br>><br>> Hi Simon,<br>><br>> Replying to my old thread since using --dhcp-authoritative seems to have<br>> introduced an issue where a DHCP client can get a NAK when using multiple<br>> dnsmasq servers on the same subnet (they both have the same host<br>> information, >1 running just to get HA).<br>><br>> Short story is that both dnsmasq's return the same lease info, but when<br>the<br>> client ACKs (sending to broadcast), one agent ACKs and the other agent<br>> NAKs.<br>> The tcpdump shows this better than I'm describing:<br>><br>> <a href="https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html" target="_blank">https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html</a><br>><br>> Does that seem like normal operation to you? Does this second dnsmasq<br>> assume this response is from a rogue server and NAKs since it didn't send<br>out<br>> the offer?<br>><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi Brian,<br><br>Second dnsmasq assume the client request is to another server and responds<br>with NAK in authoritative mode.<br>The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't<br>check server id for anything but offer packet.<br>Bug is already fixed in bb 1.23.x, see commit<br><a href="http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0" target="_blank">http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52<br>e588c0</a><br><br>Best Regards, Vladislav Grishenko<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br><br>_______________________________________________<br>Dnsmasq-discuss mailing list<br><a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br><a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-- <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Kevin Benton<o:p></o:p></p></div></div></div></div></div></div></div></div></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-- <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Kevin Benton<o:p></o:p></p></div></div></div></div></div></div></div></div></blockquote></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <o:p></o:p></p><div><div><p class=MsoNormal>Kevin Benton<o:p></o:p></p></div></div></div></div></div></body></html>