[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