How do I obtain such information? After digging around I was able to find the opcodes used with WinAPI
WLAN_INTF_OPCODE enumeration
However I couldn't find the necessary means of getting information on the channel width.
Unfortunately, Windows Native Wifi Api does not present the channel width information directy. But this (as well as many other parameters) can be obtained from the Wi-Fi Beacon frames transmitted by the access points.
This information can be accessed by the WlanApi WlanGetNetworkBssList function, which returns a list of WLAN_BSS_ENTRY structures (https://learn.microsoft.com/en-us/windows/win32/api/wlanapi/ns-wlanapi-wlan_bss_entry). Via that structure you have access to all the Information Elements present in the received beacons, but you have to parse that information yourself.
I needed this feature in the project I'm working on, so I found a Python wrapper library for the WlanApi (win32wifi) and added this feature to it. You can check it out on github (https://github.com/opetryna/win32wifi/commit/35bc65df12ae8e3c579f4e867b3bfcadfb6e072a).
Related
I would like to code my own client and server in C++ (which I have found plenty of tutorials on) and access to all information about the headers and all the fields in a frame that is going to be sent across a network.
I need it to be able to edit and/or manipulate information in all the header fields before sending the frame across the network. What's more, it needs to be able to receive a frame and read/manipulate all the header fields from layer 2 to up layer.
I just want to know what library in C++ I need to use or is there any information on how I can code something to accomplish this via C++ that I can be directed to?
If you want to construct a client/server, it's easy. But if you want to build a packet from MAC to Transport Layer, then you need to use the Linux kernel. You need to have some knowledge about how the packets are sent and received. What's more, we always use C to realise it.
The question is complete in itself. Adding a few more details to include the things which I have already tried:
I have searched across stackexchange platform, but was unable to get my query solved.
Through some clues which I gathered along the way, I could only count the number of connected devices.
VideoCapture class has been mentioned in some posts, but that was only so much useful.
I am working on Windows platform with C++.
I created this C++ class that allows you to enumerate the devices (including ID) that you can use in order to get the list of devices to use in OpenCV. It is hosted on GitHub
https://github.com/studiosi/OpenCVDeviceEnumerator
The idea is to use DirectShow to get all the devices that have the category with GUID CLSID_VideoInputDeviceCategory, and then, through an enumerator, you get in which order they appear on the system, which is the ID you need to open them on OpenCV by creating a VideoCapture object (by using the constructor that receives the ID, which would be the index of the device on the enumeration). Obviously, this approach only works on Windows.
I am trying to implement a C++ code (using bluez 5.43 and dbus) to read advertisement packets from a BLE sensor. As per the bluez DBus docs, there is a StartDiscovery API that can be used to scan for nearby devices. However, I am unable to find any APIs to store/parse the advertisement packets from nearby BLE devices. The advertising-api.txt lists registeradvertisement API but as per my understanding, it can be used only for creating advertisement packets and not reading from an external device (or am I wrong?) Can someone please guide me on the correct way to get advertisement packets from nearby BLE devices using bluez and DBus?
Thanks for the suggestions everyone. I was finally able to get the manufacturer data by using Intel's tinyb library. It has an enable_manufacturer_data_notifications API which enables you to be notified whenever the manufacturer data changes.
The behavior you described in one your last comment is the right one (the advertising data is not beeing updated) : if I am correct a BLE device is not supposed to be up all the time, it can sleep or turn to low-power etc.
In this context, it is not weird that the data is in some way "cached". From my experience, when you perform a scan and discover a device (even if you don't Connect to it), the device information will be stored for some time.
In your case, that's problematic because you are passing data through the advertising. However there is a way to force bluez to remove all it's cached data about a device :
the adapter-api provides a RemoveDevice(object device) method. It takes the object path (eg "/org/bluez/hci0/dev_AA_BB_AA_BB_AA") as argument.
If you're looking for DBus bindings in C, I suggest GLib GDBus (you will find links at the bottom of this tutorial on freedesktop website : https://dbus.freedesktop.org/doc/dbus-tutorial.html).
If you are familiar with bluetoothctl (a tool to interact with bluez using commands), it was developped by the bluez guys using Glib GDbus and you can find the source code here (look at the bottom to find the command list) : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/client/main.c
There are more straigthforward ways to use GDBus with bluez but bluetoothctl source code is a start and you'll find examples for pretty much anything that is possible to do with bluez =)
How do I most properly use libusb to talk to connected USB devices?
Specifically, how do I transfer data to the USB devices, receive information from the devices, find out the name of the connected device, if they have storage, etc.
More specifically, I will be running this on a Mac OS X machine, so I know I can't just use Windows header files.
If there is a good explanation on libusb and USB devices, that would be helpful too.
Here is a post on a similar question that might be useful to you. I include plenty of links.
But maybe you'd rather see it here. So in that case, here it goes!
Libusb allows you to enumerate devices and select the one you want based on a specific Vendor/Product id (V/P Id). If you don't know this and can't find it online with the product's description then you can easily find it.
If it is not online you will need to use an app similar to lsusb on Linux. (I don't believe it is on Mac.) When you run lsusb it lists connected devices and their V/P Ids. You can easily find your device by unplugging, running lsusb, and plugging the device back in and comparing. It's a piece of cake. Any usb list app on Mac will hopefully display the V/P ID like lsusb does.
Then once you have this V/P ID you will use libusb (if using 0.1) to enumerate all devices and find the device that matches that id. (I support using libusbx which happens to have a single find device function based on V/P id - in fact, libusbx is a whole lot more concise all around.)
After selecting your device you will send a packet using either Feature or Output Reports. This is the most complicated part because the packet you send is dependent on the individual device I believe. It is 8 bytes of data and only one of which is a single character you wish to send to the usb device. (If you wanted to send 8 characters, you would have to loop through an array of chars and send a feature or output report for each character.)
As an example feel free to reference a rather specific terminal example I wrote for controlling two LEDS. If it's helpful, great! It contains a libusbx and libusb-0.1 example.
I hope this helps!
The official site for libusb 1.0 (the newer and recommended version) is https://libusb.info/. The API documentation is at http://api.libusb.info. Click on the Modules section to walk through the different function areas. The source is at https://github.com/libusb/libusb and you can see some working examples at https://github.com/libusb/libusb/tree/master/examples. Hope that helps!
The article from #user2469202 is a good basic intro also.
The process that you can follow is:
Get the VID, PID for the device that you want to communicate using lsusb
Try to open the device and read the device descriptor
If you want name of the device use string descriptor to get that
Check if any kernel driver is attached. If it is, then detach it and do some raw data transfer
After getting the response again re-attach the driver.
I've stumbled through some code to enumerate my microphone devices (with some help), and am able to grab the "friendly name" and "clsid" information from each device.
I've done some tinkering with GraphEd.exe to try and figure out how I can take audio from directshow and write it to a file (I'm not currently concerned about the format, wav should be fine), and can't seem to find the right combination.
One of the articles I've read linked to this Windows SDK sample, but when I examined the code, I ended up getting pretty confused at how to use that code, ie. setting the output file, or specifying which audio capture device to use.
I also came across a codeguru article that has a nicely featured audio recorder, but it does not have an interface for selecting the audio device, and I can't seem to find where it statically picks which recording device to use.
I think I'd be most interested in figuring out how to use the Windows SDK sample, but any explanation on either of the two approaches would be fantastic.
Edit: I should mention my knowledge and ability as a win32 COM programmer is very low on the scale, so if this is easy, just explain it to me like I'm five, please.
Recording audio into file with DirectShow needs you to build the right filter graph, as you should have figured out already. The parts include:
The device itself, which you instantiate via moniker (not CLSID!), it is typically PCM format
Multiplexer component that converts streams into container format
File Writer Filter that takes file-compatible stream and writes into a file
The tricky moment is #2 since there is not standard component available. Windows SDK samples however contains the missing part - WavDest Filter Sample. Building it and making it ready for use, you can build a graph that records from device into .WAV file.
Your graph will look like this, and it's built easily programmatically as well:
I noticed that I have a variation of WavDest installed with Google Earth - for the case you have troubles building it yourself and you will be looking for prebuilt binary.
You can instruct ffmpeg to record from a directshow device, and output to a file.