<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=386545113-02032009>This patch allows
DHCP to also work with an arbitrary GUID.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=386545113-02032009>Please note that
this patch doesn't change the client identifier that is being transferred on the
wire.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=386545113-02032009>What it does is
change the client identifier that is being passed to windows. Instead of
passing the Mac address that we have been able to create from the GUID, it
passes the GUID itself (which is always unique). Please note that for guids that
didn't pass our algorithm we used to pass a number that could change from time
to time. Now we pass the GUID itself which remains after
reboots.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=386545113-02032009>Patch was tested on
2003 and 2008.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=386545113-02032009>One thing that I
have found out was that in the function __send_mgr_filter_dhcp there was one
case in which windows was sending us a client id which is not in the format that
we have expected. I'm not sure if our handling of this is correct, and I have
marked this with an assert to see if it ever happens.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009>Thanks</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009>Tzachi</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=386545113-02032009></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=386545113-02032009>Index:
ipoib_port.c<BR>===================================================================<BR>---
ipoib_port.c (revision 4004)<BR>+++ ipoib_port.c (working copy)<BR>@@
-2219,7 +2219,6
@@<BR> dhcp_pkt_t *p_dhcp;<BR> uint8_t *p_option;<BR> uint8_t *p_cid
=
NULL;<BR>- ib_gid_t gid;<BR> uint8_t msg
= 0;<BR> <BR> IPOIB_ENTER( IPOIB_DBG_RECV );<BR>@@ -2340,18
+2339,14 @@<BR> * accesses to the
contents.<BR> * Recover CID to standard
type.<BR> */<BR>- cl_memcpy( &gid,
&p_cid[7], sizeof(ib_gid_t) );<BR>- p_cid[1] = HW_ADDR_LEN
+1;// CID length <BR>- p_cid[2] = DHCP_HW_TYPE_ETH;// CID type
<BR>- status = ipoib_mac_from_guid( gid.unicast.interface_id,
p_port->p_adapter->params.guid_mask, (mac_addr_t*)&p_cid[3]
);<BR>- if (status ==
IB_INVALID_GUID_MASK)<BR>- {<BR>- IPOIB_PRINT(
TRACE_LEVEL_WARNING, IPOIB_DBG_ERROR,<BR>- ("Invalid GUID
mask received, rejecting it")
);<BR>- ipoib_create_log(p_port->p_adapter->h_adapter,
GUID_MASK_LOG_INDEX,
EVENT_IPOIB_WRONG_PARAMETER_WRN);<BR>- status =
IB_SUCCESS;<BR>- }<BR>- p_cid[HW_ADDR_LEN + 3] =
DHCP_OPT_END; //terminate tag<BR>+<BR>+ CL_ASSERT(sizeof(ib_net64_t)
== 8);<BR>+<BR>+ p_cid[1] = sizeof (ib_net64_t) + 1;// CID
length <BR>+ p_cid[2] = DHCP_HW_TYPE_ETH;// CID
type<BR>+ RtlMoveMemory( &p_cid[3], &p_cid[15], sizeof
(ib_net64_t) );<BR>+ RtlFillMemory(&p_cid[11], 12,
0);<BR>+ p_cid[sizeof (ib_net64_t) + 3] = DHCP_OPT_END; //terminate
tag <BR> }<BR> IPOIB_EXIT( IPOIB_DBG_RECV
);<BR> return status;<BR>@@ -3613,6 +3608,7
@@<BR> }<BR> else<BR> {<BR>+ ASSERT(FALSE);
// Do we ever reach here? does it work
correct?<BR> p_cid[2] =
DHCP_HW_TYPE_IB;<BR> }<BR> }<BR></SPAN></FONT></DIV></BODY></HTML>