Hello, Here is a curious bug for your inspection. In the case where a UD [non-CM (Connected Mode)] IPoIB receives an ARP Request from a CM enabled IPoIB, the UD IPoIB can falsely advertise a CM (Connect Mode) capability in the ARP Reply src hardware address due to an uninitialized CM flags field. The ARP reply packet is constructed from a send_buf_list allocated buffer. The cm field byte of the src hardware address in the ARP Request never gets initialized, hence the IPoIB UD ARP reply can falsely advertise a CM capability depending on the value of the CM capability byte; turns out 1 is a somewhat common memory value. :-) It's not a problem for UD IPoIB talking to another UD IPoIB; CM flags are ignored. OFED/Linux CM IPoIB would attempt to RC connect which would fail.
The fix is to always set the CM capabilities byte of the ARP Reply src hardware address.flags_qpn field with the current IPoIB CM capability byte. signed-off-by: stan smith <[email protected]> --- a/ulp/ipoib_NDIS6_CM/kernel/ipoib_port.cpp Mon Sep 13 13:08:48 2010 +++ b/ulp/ipoib_NDIS6_CM/kernel/ipoib_port.cpp Mon Sep 13 11:18:39 2010 @@ -4891,6 +4891,7 @@ p_ib_arp->op = p_arp->op; ipoib_addr_set_qpn( &p_ib_arp->src_hw, s_buf->p_port->ib_mgr.qpn ); + ipoib_addr_set_flags( &p_ib_arp->src_hw, 0 ); #if 0 if( p_port->p_adapter->params.cm_enabled ) _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
