[ofw] WinVerbs address translation required administrative privileges

Christoph Müller christoph.mueller at visus.uni-stuttgart.de
Thu Mar 8 00:45:20 PST 2012


Dear Sean,

just to be sure that I am using the same version. I have installed ofed_3-0_wlh_x64.msi, which has an SHA1 checksum of 58bf5dd31bdd6f15bed1bc2b4daf7aa9d85bcc5b. The README.txt is of [12-12-2011]. I must admit though that I did not install the package myself, but the MSI DB shows the correct version...

The sample code I use is from the SVN at svn://sofa.openfabrics.org/ofw/gen1/trunk. Is that the active code path?

As suggested, I have tried the printip tool. Interestingly, the one included with the OFED MSI package did not work:

.\PrintIP.exe lip 192.168.219.250
failed to open the kernel device 'ibat' hr=0x80070005
get_rdma_dev_IP_addrs() failed?


However, the one I built from the SVN source did:

.\PrintIP.exe lip 192.168.219.250
Found 1 IP active ports
0: ca guid 0x2c9030010d2a8 port guid 0x2c9030010d2a9  [192.168.219.250]


The one from the distribution does work, too, if I use an elevated shell. The output is the same as for the one I built myself.


I also tested the rdma_server sample, which does not work without elevation:

.\rdma_server.exe
rdma_server: start
rdma_create_ep 0
rdma_server: end -1

There also seems to be a problem with errno not being set as this is always 0 in case of an error. I can also observe this behaviour in my own program.


Additionally, I wanted to include the ACLs of the infamous "ibat file", but I could not find it. I see from the source that it is located at L"\\\\.\\ibat", but I do not know the current working directory and a recursive search on c:\ did not yield a result.

Best regards,
Christoph

> -----Ursprüngliche Nachricht-----
> Von: Hefty, Sean [mailto:sean.hefty at intel.com]
> Gesendet: Mittwoch, 7. März 2012 23:08
> An: Tzachi Dar; Smith, Stan; Fab Tillier; Christoph Müller
> Cc: ofw at lists.openfabrics.org
> Betreff: RE: [ofw] WinVerbs address translation required administrative
> privileges
> 
> According to the initial bug report, the function below is what's failing.
> There's nothing obvious to me why it should fail without administrative
> permission.  It sounds like the CreateFileW() call is failing.
> 
> TranslateAddress(const SOCKADDR* pAddress, WV_DEVICE_ADDRESS*
> pDeviceAddress) {
> 	HANDLE hIbat;
> 	IOCTL_IBAT_IP_TO_PORT_IN addr;
> 	IBAT_PORT_RECORD port;
> 	DWORD bytes;
> 	HRESULT hr;
> 
> 	hIbat = CreateFileW(IBAT_WIN32_NAME, GENERIC_READ |
> GENERIC_WRITE,
> 						FILE_SHARE_READ |
> FILE_SHARE_WRITE, NULL,
> 						OPEN_EXISTING,
> FILE_ATTRIBUTE_NORMAL, NULL);
> 	if (hIbat == INVALID_HANDLE_VALUE) {
> 		return HRESULT_FROM_WIN32(GetLastError());
> 	}
> 
> 	addr.Version = IBAT_IOCTL_VERSION;
> 	if (pAddress->sa_family == AF_INET) {
> 		addr.Address.IpVersion = 4;
> 		RtlCopyMemory(addr.Address.Address + 12,
> 					  &((SOCKADDR_IN *)pAddress)-
> >sin_addr, 4);
> 	} else {
> 		addr.Address.IpVersion = 6;
> 		RtlCopyMemory(addr.Address.Address,
> 					  &((SOCKADDR_IN6 *)pAddress)-
> >sin6_addr, 16);
> 	}
> 
> 	if (DeviceIoControl(hIbat, IOCTL_IBAT_IP_TO_PORT,
> 						&addr, sizeof addr, &port,
> sizeof port, &bytes, NULL)) {
> 		hr = WV_SUCCESS;
> 		pDeviceAddress->DeviceGuid = port.CaGuid;
> 		pDeviceAddress->Pkey = port.PKey;
> 		pDeviceAddress->PortNumber = port.PortNum;
> 	} else {
> 		hr = HRESULT_FROM_WIN32(GetLastError());
> 	}
> 
> 	CloseHandle(hIbat);
> 	return hr;
> }
> 
> If the printip test is included in the OFED release, that could be run to see if
> the permission issue is specific to IBAT, rather than some interaction
> between winverbs and ibat.  The following code in ipoib is where the ibat file
> gets created.
> 
> void
> ipoib_ref_ibat()
> {
> 	UNICODE_STRING      DeviceName;
>     UNICODE_STRING      DeviceLinkUnicodeString;
>     NDIS_DEVICE_OBJECT_ATTRIBUTES   DeviceObjectAttributes;
>     PDRIVER_DISPATCH    DispatchTable[IRP_MJ_MAXIMUM_FUNCTION+1];
> 
> 	NDIS_STATUS         Status = NDIS_STATUS_SUCCESS;
> 
> 	IPOIB_ENTER( IPOIB_DBG_IOCTL );
> 
> 	if( InterlockedIncrement( &g_ipoib.ibat_ref ) == 1 )
> 	{
> 
> 		memset(DispatchTable, 0,
> (IRP_MJ_MAXIMUM_FUNCTION+1) * sizeof(PDRIVER_DISPATCH));
> 
> 		DispatchTable[IRP_MJ_CREATE]
> 	= __ipoib_create;
> 		DispatchTable[IRP_MJ_CLEANUP]
> 	= __ipoib_cleanup;
> 		DispatchTable[IRP_MJ_CLOSE]
> 		= __ipoib_close;
> 		DispatchTable[IRP_MJ_DEVICE_CONTROL]
> 	= __ipoib_dispatch;
> 		DispatchTable[IRP_MJ_INTERNAL_DEVICE_CONTROL]
> 	= __ipoib_dispatch;
> 
> 
> 		NdisInitUnicodeString( &DeviceName, IBAT_DEV_NAME );
> 		NdisInitUnicodeString( &DeviceLinkUnicodeString,
> IBAT_DOS_DEV_NAME );
> 
> 
> 		memset(&DeviceObjectAttributes, 0,
> sizeof(NDIS_DEVICE_OBJECT_ATTRIBUTES));
> 
> 		DeviceObjectAttributes.Header.Type =
> NDIS_OBJECT_TYPE_DEFAULT; // type implicit from the context
> 		DeviceObjectAttributes.Header.Revision =
> NDIS_DEVICE_OBJECT_ATTRIBUTES_REVISION_1;
> 		DeviceObjectAttributes.Header.Size =
> sizeof(NDIS_DEVICE_OBJECT_ATTRIBUTES);
> 		DeviceObjectAttributes.DeviceName = &DeviceName;
> 		DeviceObjectAttributes.SymbolicName =
> &DeviceLinkUnicodeString;
> 		DeviceObjectAttributes.MajorFunctions = &DispatchTable[0];
> 		DeviceObjectAttributes.ExtensionSize = 0;
> 		DeviceObjectAttributes.DefaultSDDLString = NULL;
> 		DeviceObjectAttributes.DeviceClassGuid = 0;
> 
> 		Status = NdisRegisterDeviceEx(
> 
> 	g_IpoibMiniportDriverHandle,
> 
> 	&DeviceObjectAttributes,
> 							&g_ipoib.h_ibat_dev,
> 
> 	&g_ipoib.h_ibat_dev_handle);
> 
> 
> 
> 		if( Status != NDIS_STATUS_SUCCESS )
> 		{
> 			IPOIB_PRINT( TRACE_LEVEL_ERROR,
> IPOIB_DBG_ERROR,
> 				("NdisRegisterDeviceEx failed with status
> of %d\n", Status) );
> 		}
> 	}
> 
> 	IPOIB_EXIT( IPOIB_DBG_IOCTL );
> }
> 
> Note that the default SDDL string is set to NULL.  Is there a registry setting for
> ipoib (possibly inherited from NDIS or somewhere else) that gets used if the
> SDDL is NULL?
> 
> - Sean



More information about the ofw mailing list