[Openib-windows] ipoib dhcp patch

[Tzachi Dar]

Hi Fab,
 
Can you point us to the ipoib dhcp spec? I thought there was only a
draft that no one was using.
 
I guess that a full solution will also have to work with the Linux
implementation.
 
In any case the current code changes has some problems: 1) It changes
the size of the packet but doesn't change the size in the ip header.
(this can be easily fixed) 2) it bases the request identifier on the
guid + qp_num. As we don't have a mechanism for keeping the same QP
number one might get a different ip after restarting the driver. This
one is harder to resolve.
 
Thanks
Tzachi


________________________________

	From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
	Sent: Monday, January 22, 2007 7:27 PM
	To: Anatoly Lisenko; Tzachi Dar; Yossi Leybovich;
openib-windows at openib.org
	Cc: Tzahi Oved
	Subject: RE: [Openib-windows] ipoib dhcp patch
	
	

	Hi Anatoly,

	 

	When you have the DHCP server on the eth side, I assume it is
communicating with the IB hosts through your IB to Ethernet gateway.
Your gateway should perform conversion of DHCP packets to/from the IPoIB
DHCP format, and can't just forward the Ethernet DHCP packets unchanged.
See the IPoIB spec for what things need to work on DHCP.

	 

	Also, instead of disabling DHCP support, how about fixing it so
that it send properly formed packets (as per IPoIB spec) and then
convert them to the OS so that the OS is happy with them.  You can use
netmon on the host to snoop the network traffic and look at the DHCP
packet as it's given from the OS to the IPoIB driver and from the IPoIB
driver to the OS.

	 

	Disabling the DHCP packet conversion makes the DHCP packets on
the wire not compliant to the IPoIB spec.

	 

	-Fab

	 

	From: openib-windows-bounces at openib.org
[mailto:openib-windows-bounces at openib.org] On Behalf Of Anatoly Lisenko
	Sent: Monday, January 22, 2007 3:53 AM
	To: Tzachi Dar; Yossi Leybovich; openib-windows at openib.org
	Cc: Tzahi Oved
	Subject: [Openib-windows] ipoib dhcp patch

	 

	Hi,

	 

	I saw that ipoib interface fail to get automatic ip address when
DHCP server run on eth side.

	This caused by changing DHCP packet fields at
__send_mgr_filter_dhcp().

	I run ethereal on eth side and it show that the DHCP packet from
ipoib arrive damaged.

	I think this cause DHCP server to ignore this packet.

	But if DHCP server run on IB side than ipoib then interface
success to get automatic ip.

	This work because in __recv_dhcp() ipoib change all DHCP packet
fields like in the DHCP packet arrived from ETH side.

	I attach patch that disable all changes to DHCP packets:

	1. All changed related to DHCP placed into #ifdef
IPOIB_DHCP_HACK ... #endif

	2. IPOIB_DHCP_HACK isn't defined.

	 

	 

	 

	Index: ulp/ipoib/kernel/ipoib_port.c

	
===================================================================

	--- ulp/ipoib/kernel/ipoib_port.c   (revision 570)

	+++ ulp/ipoib/kernel/ipoib_port.c   (working copy)

	@@ -2089,7 +2089,9 @@

	      dhcp_pkt_t              *p_dhcp;

	      uint8_t                       *p_option;

	      uint8_t                       *p_cid = NULL;

	+#ifdef IPOIB_DHCP_HACK

	      ib_gid_t                gid;

	+#endif

	      uint8_t                       msg = 0;

	 

	      IPOIB_ENTER( IPOIB_DBG_RECV );

	@@ -2168,12 +2170,15 @@

	                        ("Failed to find required
Client-identifier option.\n") );

	                  return IB_INVALID_SETTING;

	            }

	+#ifdef IPOIB_DHCP_HACK       

	            if( p_dhcp->htype != DHCP_HW_TYPE_IB )

	            {

	                  IPOIB_PRINT_EXIT( TRACE_LEVEL_ERROR,
IPOIB_DBG_ERROR,

	                        ("Invalid hardware address type.\n") );

	                  return IB_INVALID_SETTING;

	            }

	+#endif //#ifdef IPOIB_DHCP_HACK

	+

	            break;

	      /* message from DHCP server */

	      case DHCPOFFER:

	@@ -2186,6 +2191,8 @@

	                  ("Invalide message type.\n") );

	            return IB_INVALID_PARAMETER;

	      }

	+

	+#ifdef IPOIB_DHCP_HACK

	      p_eth->type.ip.prot.udp.hdr.chksum = 0;

	      p_dhcp->htype = DHCP_HW_TYPE_ETH;

	      p_dhcp->hlen = HW_ADDR_LEN;

	@@ -2216,6 +2223,8 @@

	            status = ipoib_mac_from_guid(
gid.unicast.interface_id, (mac_addr_t*)&p_cid[3] );

	            p_cid[HW_ADDR_LEN + 3] = DHCP_OPT_END; //terminate
tag

	      }

	+#endif //#ifdef IPOIB_DHCP_HACK

	+

	      IPOIB_EXIT( IPOIB_DBG_RECV );

	      return status;

	 }

	@@ -3160,8 +3169,10 @@

	      dhcp_pkt_t              *p_ib_dhcp;

	      uint8_t                       *p_option, *p_cid = NULL;

	      uint8_t                       msg = 0;

	+#ifdef IPOIB_DHCP_HACK

	      size_t                        len;

	      ib_gid_t                gid;

	+#endif //#ifdef IPOIB_DHCP_HACK

	 

	      IPOIB_ENTER( IPOIB_DBG_SEND );

	 

	@@ -3236,6 +3247,7 @@

	      case DHCPRELEASE:

	      case DHCPINFORM:

	            /* Fix up the client identifier option */

	+#ifdef IPOIB_DHCP_HACK

	            if( p_cid )

	            {

	                  /* do we need to replace it ?  len eq ETH MAC
sz 'and' MAC is mine */

	@@ -3295,6 +3307,8 @@

	            p_ib_dhcp->htype = DHCP_HW_TYPE_IB;

	            p_ib_dhcp->hlen = 0;

	            cl_memclr( p_ib_dhcp->chaddr,
sizeof(p_ib_dhcp->chaddr) );

	+#endif //#ifdef IPOIB_DHCP_HACK

	+

	            break;

	 

	      /* Server messages. */

	 

	 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20070122/c67bc72d/attachment.html>