I would like to measure rssi value of modem.Is there any api to get rssi value for Windows?I used to do that with Wifi.Manager in android.But i couldn't find any api for Windows
Using Native code is the best. You will need to use WlanQueryInterface() with wlan_intf_opcode_rssi opcode which will return RSSI value as LONG data type. From there you can convert it to dbm.
DWORD WINAPI WlanQueryInterface(
__in HANDLE hClientHandle,
__in const GUID *pInterfaceGuid,
__in WLAN_INTF_OPCODE OpCode,
__reserved PVOID pReserved,
__out PDWORD pdwDataSize,
__out PVOID *ppData,
__out_opt PWLAN_OPCODE_VALUE_TYPE pWlanOpcodeValueType
);
Here using opcode wlan_intf_opcode_rssi you will get RSSI value:
WLAN_INTF_OPCODE >> wlan_intf_opcode_rssi >> LONG
Here is the C++ sample on how to start with:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms706765(v=vs.85).aspx
If you want C# Try this:
How to get SSID and RSSI for Win7 using C#
Since this question appeared on home page for review- the existing answer is outdated.
There is now a Managed Wifi API available as a wrapper around the Windows Native Wifi API.
Signal strength in percentage and RSSI could be obtained as,
Wlan.WlanAvailableNetwork[] networks = wlanIface.GetAvailableNetworkList(0);
Wlan.WlanBssEntry[] redes = wlanIface.GetNetworkBssList(); //Get the atribute that you need
foreach (Wlan.WlanBssEntry network in redes)
{
Console.Write("Network SSID {0} RSSI {1}\n ", GetStringForSSID(network.dot11Ssid),
network.rssi);
}
Related
Ordinarily XInput controllers are identified simply using an index corresponding to the player number of the controller. Is there a way to obtain more information about a controller with a specific index, such as its vendor ID, product ID, or device name?
Even better would be a identifier that corresponds uniquely and consistently to just that controller so that it can be distinguished from all other XInput devices regardless of its index, including another controller that's an identical model (i.e. same product and vendor ID), similar to the instance GUID available using DirectInput.
Can this be accomplished using XInput or another Microsoft API? I'm also open to using undocumented functions if need be.
There are a few undocumented functions inside the XInput1_4.dll. You can get the Vendor ID and Product ID like this:
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <Xinput.h>
#include <stdio.h>
struct XINPUT_CAPABILITIES_EX
{
XINPUT_CAPABILITIES Capabilities;
WORD vendorId;
WORD productId;
WORD revisionId;
DWORD a4; //unknown
};
typedef DWORD(_stdcall* _XInputGetCapabilitiesEx)(DWORD a1, DWORD dwUserIndex, DWORD dwFlags, XINPUT_CAPABILITIES_EX* pCapabilities);
_XInputGetCapabilitiesEx XInputGetCapabilitiesEx;
void main()
{
HMODULE moduleHandle = LoadLibrary(TEXT("XInput1_4.dll"));
XInputGetCapabilitiesEx = (_XInputGetCapabilitiesEx)GetProcAddress(moduleHandle, (char*)108);
for (int i = 0; i < 4; ++i)
{
printf("Gamepad %d ", i);
XINPUT_CAPABILITIES_EX capsEx;
if (XInputGetCapabilitiesEx(1, i, 0, &capsEx) == ERROR_SUCCESS)
{
printf("connected, vid = 0x%04X pid = 0x%04X\n", (int)capsEx.vendorId, (int)capsEx.productId);
}
else
{
printf("not connected\n");
}
}
}
What XInput internally does is open a device, then call DeviceIoControl on it every time it reads the joypad. (control code 0x8000e00c)
You need to hook these functions imported by "XInput1_4.dll":
CreateFileW from "api-ms-win-core-file-l1-1-0.dll"
DuplicateHandle from "api-ms-win-core-handle-l1-1-0.dll"
CloseHandle from "api-ms-win-core-handle-l1-1-0.dll"
DeviceIoControl from "api-ms-win-core-io-l1-1-0.dll"
Using the hooks for CreateFileW, DuplicateHandle and CloseHandle, you can keep track of what filename is associated with a handle.
Then when you see a call to DeviceIoControl with control code 0x8000e00c, you will know what filename is being read.
The first time you call XInputGetState, it will open multiple devices, and call DeviceIoControl multiple times, regardless of what player number you have asked for. You are only interested in the last filename seen by DeviceIoControl before XInputGetState returns. And if XInputGetState indicates the controller is not plugged in, disregard the filename you have collected for that controller number.
Examples of filenames I have seen on my own computer:
\\?\hid#{00001124-0000-1000-8000-00805f9b34fb}&vid_045e&pid_02e0&ig_00#8&7074921&2&0000#{ec87f1e3-c13b-4100-b5f7-8b84d54260cb}
\\?\usb#vid_045e&pid_028e#1&1a590e2c&1&01#{ec87f1e3-c13b-4100-b5f7-8b84d54260cb}
edit:
One more hook is required as well.
CoCreateInstance from "api-ms-win-core-com-l1-1-0.dll", to hook creating the undocumented IDeviceBroker COM object. If it can successfully create an IDeviceBroker COM object, it will use that instead of the call to CreateFileW. Parameters will be: CLSID_DeviceBroker = {acc56a05-e277-4b1e-a43e-7a73e3cd6e6c}, IID_IDeviceBroker = {8604b268-34a6-4b1a-a59f-cdbd8379fd98}. The method OpenDeviceFromInterfacePath will be called instead of CreateFileW. Alternatively, you can make creating the IDeviceBroker object simply fail, and it will proceed to use CreateFileW as usual.
How to get DTR and RTS status of serial port on a windows platform? I want to read the current state (ON or OFF) of these two pins.
I can set pins with :
EscapeCommFunction(hSerial,SETRTS);
But I don't know how to read the pin status.
Since on Linux, it can be done with the following code, I assume it is technicaly feasable:
int status=0;
ioctl(fd, TIOCMGET, &status);
return status & TIOCM_RTS;
Using inc\api\ntddser.h API and winioctl.h, you can access DTR and RTS status. Call DeviceIoControl, set the second parameter to IOCTL_SERIAL_GET_DTRRTS:
Call:
DeviceIoControl(
handle, // handle returned by CreateFile
IOCTL_SERIAL_GET_DTRRTS,
NULL,
0,
&Status, // pointer to a DWORD variable 1
sizeof(Status),
&unused, // pointer to a DWORD variable
pOverlapped // optional pointer to overlapped buffer (may be NULL)
);
Documentation about DeviceIoControl here.
Unless you are actively changing the signal line, is the value set in DCB used?
Other than that, you control the signal line yourself, so you should remember it each time you change it.
As long as you have the serial port open, you have all control and nothing else will change.
Isn't there anybody who uses handshake or toggle mode now?
SetDefaultCommConfigW function
BOOL SetDefaultCommConfigW(
LPCWSTR lpszName,
LPCOMMCONFIG lpCC,
DWORD dwSize
);
SetCommConfig function
BOOL SetCommConfig(
HANDLE hCommDev,
LPCOMMCONFIG lpCC,
DWORD dwSize
);
GetCommConfig function
BOOL GetCommConfig(
HANDLE hCommDev,
LPCOMMCONFIG lpCC,
LPDWORD lpdwSize
);
COMMCONFIG structure
typedef struct _COMMCONFIG {
...
DCB dcb;
...
} COMMCONFIG, *LPCOMMCONFIG;
DCB structure
typedef struct _DCB {
DWORD DCBlength;
...
DWORD fDtrControl : 2;
...
DWORD fRtsControl : 2;
...
} DCB, *LPDCB;
DTR_CONTROL_DISABLE 0x00
DTR_CONTROL_ENABLE 0x01
DTR_CONTROL_HANDSHAKE 0x02
RTS_CONTROL_DISABLE 0x00
RTS_CONTROL_ENABLE 0x01
RTS_CONTROL_HANDSHAKE 0x02
RTS_CONTROL_TOGGLE 0x03
If you still want to do so, use DeviceIoControl() commented by #Hans Passant.
However, there is no guarantee that it is properly supported, since most people will not use it.
Device Input and Output Control (IOCTL)
DeviceIoControl function
The following is a sample DeviceIoControl call for a DISK drive, but you can call it by changing each of these parameters to those related to IOCTL_SERIAL_GET_DTRRTS for the serial port.
Calling DeviceIoControl
Serial Device Control Requests
IOCTL_SERIAL_GET_DTRRTS IOCTL
After successfully Creating a Secure Connection Using Schannel, I am obtaining its connection attributes using QueryContextAttributes(), passing SECPKG_ATTR_CONNECTION_INFO.
The returned structure SecPkgContext_ConnectionInfo contains the field aiExch, which holds the information I am looking for - namely the used key exchange algorithm.
I am using this for months, and it always returned one of the two predefined values CALG_RSA_KEYX or CALG_DH_EPHEM. But since a couple of weeks (when I believe a Schannel update patch was issued by Microsoft) it returns an unknown value: 0x0000ae06
Using these macros, the ALG_ID can be split into its components:
#define GET_ALG_CLASS(x) (x & (7 << 13))
#define GET_ALG_TYPE(x) (x & (15 << 9))
#define GET_ALG_SID(x) (x & (511))
According to that, 0x0000ae06 would mean:
Class: ALG_CLASS_KEY_EXCHANGE
Type: (7 << 9) -> which is undefined
SID: 6 -> whose meaning depends on the type of algorithm
Anyone ran into the same issue? Can anyone explain what happened, or what 0x0000ae06 stands for?
Have a look at the code found here http://pastebin.com/TKQJ85Z9 notice that, the ID was added to the schannel library but apparently the VC headers weren't update, at any rate, as you can see from the above code (see pastebin URL), that ID corresponds to "ECDHE", that is Elliptic Curve DH with Ephemeral key exchange
[edit]
The real problem is that the value is unofficial and can only be found by some internet search, that's why I posted the link to some sample code; see, it just happened to me to find the answer by looking at this twit https://twitter.com/ericlaw/status/301083494203928576
At any rate, it sounds like the latest version of the Microsoft CNG SDK contains updated headers and libraries which add a new constant for the "QueryContextAttributes" API call, that is SECPKG_ATTR_CIPHER_INFO such a call returns a structure (see definition in code below) whose member named "szCipherSuite" reports the full string for the cipher in use, for example "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384"
Here's some sample code for such a call
/*
// -- http://www.microsoft.com/en-us/download/details.aspx?id=1251
typedef struct _SecPkgContext_CipherInfo
{
DWORD dwVersion;
DWORD dwProtocol;
DWORD dwCipherSuite;
DWORD dwBaseCipherSuite;
WCHAR szCipherSuite[SZ_ALG_MAX_SIZE];
WCHAR szCipher[SZ_ALG_MAX_SIZE];
DWORD dwCipherLen;
DWORD dwCipherBlockLen; // in bytes
WCHAR szHash[SZ_ALG_MAX_SIZE];
DWORD dwHashLen;
WCHAR szExchange[SZ_ALG_MAX_SIZE];
DWORD dwMinExchangeLen;
DWORD dwMaxExchangeLen;
WCHAR szCertificate[SZ_ALG_MAX_SIZE];
DWORD dwKeyType;
} SecPkgContext_CipherInfo, *PSecPkgContext_CipherInfo;
*/
static void DisplayConnectionInfo(CtxtHandle *phContext)
{
SECURITY_STATUS Status;
SecPkgContext_CipherInfo CipherInfo = { SECPKGCONTEXT_CIPHERINFO_V1 };
Status = QueryContextAttributes( phContext, SECPKG_ATTR_CIPHER_INFO, &CipherInfo);
if(Status != SEC_E_OK)
{
printf("Error 0x%x querying cipher info\n", Status);
return;
}
printf("%S\n", CipherInfo.szCipherSuite);
}
for further infos, please get the MS CNG SDK and have a look at the included help and headers.
I have a slightly odd problem involving a MoGo mouse failing to charge when put in the cartridge slot of my Windows XP laptop. Long story, but one suggestion to fix it is to write a bespoke driver which only says "I'm functioning OK: don't turn the power off".
I'm figuring that this should be next to trivial, but my only experience of drivers is to download and install them through provided MSIs. I realised that I don't know:
What language they're written in.
What conventions they must follow.
How they are associated with their respective hardware.
Where they are located.
Or indeed, anything at all...
I also haven't found anything staggeringly helpful on the web - probably because they are aimed at a far higher level than I'm at.
Any insights would be welcome.
Microsoft provides a "Hello World" driver example in their documentation. This is an example of "World's most simple Windows driver". Unfortunately, it's 13 pages long and thus not a good fit for a StackOverflow answer.
The language they are written in is C++.
To get started, be sure you have Microsoft Visual Studio, the Windows
SDK, and the Windows Driver Kit (WDK) installed.
Their example contains one file called Driver.c that looks like this:
#include <ntddk.h>
#include <wdf.h>
DRIVER_INITIALIZE DriverEntry;
EVT_WDF_DRIVER_DEVICE_ADD KmdfHelloWorldEvtDeviceAdd;
NTSTATUS
DriverEntry(
_In_ PDRIVER_OBJECT DriverObject,
_In_ PUNICODE_STRING RegistryPath
)
{
// NTSTATUS variable to record success or failure
NTSTATUS status = STATUS_SUCCESS;
// Allocate the driver configuration object
WDF_DRIVER_CONFIG config;
// Print "Hello World" for DriverEntry
KdPrintEx(( DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL, "KmdfHelloWorld: DriverEntry\n" ));
// Initialize the driver configuration object to register the
// entry point for the EvtDeviceAdd callback, KmdfHelloWorldEvtDeviceAdd
WDF_DRIVER_CONFIG_INIT(&config,
KmdfHelloWorldEvtDeviceAdd
);
// Finally, create the driver object
status = WdfDriverCreate(DriverObject,
RegistryPath,
WDF_NO_OBJECT_ATTRIBUTES,
&config,
WDF_NO_HANDLE
);
return status;
}
NTSTATUS
KmdfHelloWorldEvtDeviceAdd(
_In_ WDFDRIVER Driver,
_Inout_ PWDFDEVICE_INIT DeviceInit
)
{
// We're not using the driver object,
// so we need to mark it as unreferenced
UNREFERENCED_PARAMETER(Driver);
NTSTATUS status;
// Allocate the device object
WDFDEVICE hDevice;
// Print "Hello World"
KdPrintEx(( DPFLTR_IHVDRIVER_ID, DPFLTR_INFO_LEVEL, "KmdfHelloWorld: KmdfHelloWorldEvtDeviceAdd\n" ));
// Create the device object
status = WdfDeviceCreate(&DeviceInit,
WDF_NO_OBJECT_ATTRIBUTES,
&hDevice
);
return status;
}
Full details found here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/writing-a-very-small-kmdf--driver
I am hooking the ExtTextOut GDI API.
There I want to retrieve the exact location of the output String.
BOOL ExtTextOut(
__in HDC hdc,
__in int X,
__in int Y,
__in UINT fuOptions,
__in const RECT *lprc,
__in LPCTSTR lpString,
__in UINT cbCount,
__in const INT *lpDx
);
In a specific case I am getting ETO_CLIPPED for the fuOptions param which mean I can get the location of the string from the RECT param or from the X,Y params.
However when I use the LPtoDP API for translating the location (RECT or X,Y) I get wrong location (before translating I get negative values).
I guess it has a wrong offset, however when I check the followings I see no indicaton for that:
Map Mode is MM_TEXT (default)
GetWindowOrgEx is 0,0
GetViewportOrgEx is 0,0
GetWindowExtEx is 1,1
GetViewportExtEx is 1,1
Does anyone have any idea, any help will be appreciated.
Thanks.
Apparently, specifying ETO_CLIPPED in the ExtTextOut fuOptions param
does not imply that the text will be output to that clip, meaning that it is not guaranteed that the device context is of type display device context, and the device context that is used can be a memory device context, as in my case, and therefore do not contains the right coordinates.
msdn: ETO_CLIPPED The text will be clipped to the rectangle.