I have a c++ application running on the Raspberry Pi that uses the bluez d-bus api. It supports multiple sensors from different vendors but for the most part adding new sensors has been fairly straight forward once I'd got the first one going. Once connected I'm not really using anything too exotic, just "StartNotify", "StopNotify", "ReadValue", and "WriteValue". Anyway, recently I've had problems adding a couple of new sensors. Both use larger packet sizes so using a packet sniffer I can see the sensors negotiating larger MTU. For whatever reason though after the negotiation I can read larger value characteristics but can't get notifications enabled (or received anyway). Trying different approaches with bluetoothctl I found that using "acquire-notify" seems to solve the problem. I also notice that the new "acquire" commands return the MTU so maybe that has something to do with it. Going back to the sensors I already support I've also found that replacing "StartNotify" with "AcquireNotify" seems to work with them as well. So my delimma is whether to use "AcquireNotify" for all sensors (keeping my code a lot cleaner) or just the new ones that give me an issue.
I haven't really found any in-depth documentation on the new "acquire" interfaces unfortunately. To someone without a lot of bluez history it's not at all clear what the ramifications of using them vs the original interfaces are. So my questions are twofold -
Is there any reason not to use "AcquireNotify"/"ReleaseNotify" for
all sensors (even older ones that use old/lower MTU)?
When using "AcquireNotify" does it matter if you use
"ReadValue"/"WriteValue" on other characteristics, or should I be
using "AcquireRead"/"AcquireWrite"?
Any info greatly appreciated, Thanks!
AcquireNotify returns a file descriptor that you can poll and read and notifications don't go through d-bus. with StartNotify you read the notification value from d-bus. you'll be able to achieve better performance with file descriptors (and without d-bus) if you're sending a lot of data in GATT notifications.
AcquireNotify/AcquireWrite are relatively new APIs and they have some stability issues (bluetoothd can terminate because of SIGPIPE). there are some patches to bluez 5.50 in their repositories that improve it.
Figured I'd follow up for anyone else seeing similar behavior. Oddly, after trying all kinds of permutations sending commands using bluetoothctl I found a way to get it working without using the notify-acquire api's. Randomly I found that if I enabled notifications via "notify on", then did the sensor vendor's recommended write command sequence to get the sensor to start sending data nothing happened. But if I did all that and then simply used "select characteristic" to go back to the notify characteristic I'd enabled it would start sending data. Not sure why. At any rate once I'd fully integrated the sensors into my application they actually worked without requiring anything extra. Not sure why exactly since my code is based directly on the bluetoothctl source but regardless it seems to work (so far anyway)...
Related
I'm posing a question here directly in relation to this issue on github for node-serialport. In a nutshell something that used to work fine in v4.x of the library no longer works in v6.x of the library. I think it must have something to do with how the library is opening the COM port (options or something), and I suspect its artificially limiting the power delivered over USB in the current version of the library.
I wrote the simplest scripts that I could to reproduce the problem (scripts posted in the issue) using:
NodeJS and v4.x of the library [works]
NodeJS and v6.x of the library [fails]
Python and PySerial equivalent [works]
Following through on a recommendation by the repository maintainer, I researched and found a utility for windows called drstrace that allowed me to capture logs of the execution of each of these scripts executing for a period of time (these logs are posted as attachments in the referenced issue).
Now I'm stuck, as I don't know how to make heads or tails of the drstrace logs, though I feel confident that the difference is probably evident in comparing the three files. I just don't know enough about how to read the drstrace logs and windows drivers and system calls to break through.
I realized posting this question here is something of an act of desperation, but I figure it's worth a shot. Hopefully it is clear that I've not lacked in effort pursuing this on my own, I'm just over my head at this point, and could use help getting further. Any guidance would be appreciated. Most awesome would be someone who is versed in this level of diagnostics giving it a look and reading the tea leaves. It would be great to contribute back to such an important open source library.
Update 2017 Nov 10
I reached out to FTDI support asking:
I use the FT231X in many of my products. I need some help with
understanding how the Windows FTDI driver manages power. More to the
point, I'm hoping you can help me understand how to direct the driver
to allow the full 500mA allowed by USB to be delivered to my product
by a Windows computer.
The reply was:
Just use our FT_Prog utility to set the max VBUS current to 500
mA:
This drive current becomes available after the FT231X enumerates.
I haven't tried this advice yet, but I wanted to share it with anyone reading this. The fact remains that node-serialport 6.0.4 behavior differs from both node-serialport 4.0.7 behavior and pyserial behavior.
Here is an alternative theory you could look into:
Windows interacting with V6.x might be interacting with the flow control settings differently, which might be causing your device to respond with an unexpected state causing your test to fail.
I Read a bit more about windows drivers and how they manage that i only found out that its related to the hardware manufacturer i think its not a fail from serialport it self since its really using the drivers it self it adds no extras on that level.
i am Contributor of SerialPort and can tell you that it offers only bindings for the Operating System to node that means it don't does any actions it offers you only a API read the following from microsoft they say you should ask your hardware vendor
Power Management in Serial Port Drivers (Windows CE 5.0)
Windows CE 5.0
Send Feedback
The minimum power management that a serial port driver can provide is to put the serial port hardware into its lowest power consumption state with the HWPowerOff function, and to turn the serial port hardware fully back on with the HWPowerOn function. Both of these functions are implemented in the lower layer. Beyond this minimal processing, a serial port driver can conserve power more effectively by keeping the port powered down unless an application has opened the serial port. If there is no need for the driver to detect docking events for removable serial port devices, the driver can go one step further and remove power from the serial port's universal asynchronous receiver-transmitter (UART) chip, if no applications are using the port.
Most serial port hardware can support reading the port's input lines even without supplying power to the serial line driver. Consult the documentation for your serial port hardware to determine what parts of the serial port circuitry can be selectively powered on and off, and what parts must be powered for various conditions of use.
Source:
https://msdn.microsoft.com/en-us/library/aa447559.aspx
about changes from serialport v4 => 6
new Stream Interface
but nothing changed with the core opening method of the port.
also nothing changed in the bindings which open the port
node serialport is a collection of bindings written in c++
I am trying to write an snmp agent for RFC 4836, Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs), to run on an embedded Linux system (Linux server 2.6.35.12+). I've used mib2c to set up my frameworks, but am stalled on finding where to get the data to fill in. I am not sure where I should be looking: if the MAU is part of the eth device or a separate interface, if I should be looking somewhere in the /sys or /proc fs, or if I need to access the device registers directly (or both?).
I know there is a lot of different data needed, and am not asking for a roadmap with everything, but at this point I am hung up and not sure where I should be concentrating my efforts - driver code?
Sorry if this seems a dumb question, but I have been looking online and in StackOverflow without finding what I need.
It turned out the information I needed is available from mii-tool. Despite what you may see on the web, this is not obsolete (it may have been a few years ago but it seems to have been updates). Or, you can access the device registers directly using ioctl calls to SIOCGMIIREG, to avoid having to parse command output.
I have an embedded system that can be treated as an Access Point. There's a program that runs in that system and performs some network communication with devices connected to that Access Point. It is sending UDP packets containing some diagnostic information (a data structure) and receiving commands. The problem is that sometimes some fields of that outgoing data structure are not filled with data (eg. there are zeroes or some garbage). I need those fields to be correctly filled every time and I know what values should be put there.
Another task that I need to accomplish is to filter incoming packets that come to this program (I know what ports it listens on) - usually I need to simply pass them, but occassionaly (eg. when I get some information from sensors) it is necessary to completely replace them with new packets that I would generate.
I have several ideas varying from some smart usage of iptables and pcap to writing my own kernel module. I do not own sources of that embedded application so I cannot embed this functionality in its code. Performance is a crucial thing here, and I'd like to hear your suggestions: what should I go for? Writing my own kernel modules seems to be the best solution to me, but I have no experience in network hacking so maybe there are some other ways that are better suited for this problem. Any opinion will be highly appreciated!
One standard approach is to use libnetfilter_queue to intercept and modify packets directly. You should at least try this before attempting to write your own kernel modules.
You could do it in userspace. Just write a server that receives the packets changes them and send them again out. You have to configure the application just to use your localhost as destination ip (or configure your system that it has the target address). Its a typical "man-in-the-middle" setup.
I spent the last days reading through man pages, documentations and anything else google brought up, but I suppose I'm even more confused now than I was at the beginning.
Here is what I want to do: I want to send and receive data packets with my own layer 3-x protocol(s) via a wireless interface (802.11) on Linux systems with C/C++.
So far, so good. I do not require beacons, association or any AP/SSID related stuff. However, for data transmissions I'd like the MAC layer to behave "as usual", meaning unicast packets are ACK'd, retransmissions, backoff etc. I'd also like to enjoy the extended QoS capabilites (802.11e with 4 queues and different access categories). Promiscuous mode on the other hand is not a concern, I require only broadcast packets and packets sent to the specific station.
What would be the right way to go about it? Most of the documentation out there on raw socket access seems to be focused on network sniffing and that does not help. I've been playing around with the monitor mode for some time now, but from what I've read so far, received packets are not ACK'd in monitor mode etc.
Without monitor mode, what would be the alternative? Using ad hoc mode and unix raw sockets? Or do I have to fiddle around with the drivers?
I'm not looking for a complete solution, just some good ideas, where to start. I read through the man pages for socket(2), socket(7) and packet(7) but that did not help concerning the behaviour of the MAC layer in different modes.
Thanks in advance.
802.11 is layer 2 (and 1) protocol specification. It was designed in a way, which allows higher-layer protocols to treat it as Ethernet network. Addressing and behaviour is generally the same. So for a layer 3 protocol you should not be concerned about 802.11 at all and write your code as if you were expecting it to run on Ethernet network.
To make it work you should first connect to a wireless network of some sort (which is conceptually equal to plugging a wire into a Ethernet card). Here you may choose ad-hoc (aka IBSS) or infrastructural (aka BSS) network (or PBSS once 802.11ad is approved ;).
Operating cards without any sort of association with network (just spitting out packets on air) is not a good idea for a couple of reasons. Most importantly it's very hardware dependent and unreliable. You can still do it using RF mon (AKA monitor mode) interface on one side and packet injection (using radiotap header) on the other but I don't recommend that. Even if you have a set of identical cards you'll most likely encounter hard to explain and random behaviour at some point. 802.11 NICs are just not designed for this kind of operation and keep different mount of state inside firmware (read about FullMAC vs. SoftMAC cards). Even SoftMAC cards differ significantly. For example theoretically in monitor mode, as you said, card should not ACK received packets. There are cards though that will ACK received frame anyway, because they base their decision exclusively on the fact that said frame is addressed to them. Some cards may even try to ACK all frames they see. Similar thing will happen with retransmissions: some cards will send injected packet only once (that's how it should work). In other NICs, retransmissions are handled by hardware (and firmware) and driver cannot turn it off, so you will get automatic retransmission even with injected data.
Sticking with layer 3 and using existing modes (like ad hoc), will give you all capabilities you want and more (QoS etc.). Ethernet frame that you send to interface will be "translated" by the kernel to 802.11 format with QoS mapping etc.
If you want to find out about MAC behaviour in various modes you'll have to either read the mac80211 code or 802.11 standard itself. http://linuxwireless.org wiki my help you with a few things, but kernel hackers are usually to busy to write documentation other than comments in the code ;)
L3 protocol implementation itself can be also done either in kernel or user mode (using raw sockets). As usual kernel-side will be harder to do, but more powerful.
Because you want to create own network layer protocol (replacement for IP), the keyword is: "raw ethernet socket". So ignore "Raw IP socket" stuff.
This is where to start:
int sockfd = socket( PF_PACKET, SOCK_RAW, htons(XXX) );
Correct man page is: packet(7).
Find more information by googling with the keyword.
One quite complete example here.
Edit: The link to the example seems to be currently broken: another examples
Probably you want something like libpcap.
Libpcap allows you to read/inject raw packets from/into a network interface.
First, there’s something you should be aware of when trying to transmit raw 802.12 frames- the device driver must support packet injection.
You mentioned monitor mode, which is at a high level the rx equivalent of the injection capability- which is not a “mode”, jist a capability/feature. I say this because some 892.11 device drivers on Linux either:
Support monitor mode and frame injection
Support monitor mode and not frame injection
Support neither
I don’t know any straightforward way to check if the driver supports frame injection aside from attempting frame injection and sniffing the air on another device to confirm it was seen.
Monitor mode is usually easy to check by using sudo wlan0 set monitor and seeing what the return code and/or output is.
It’s been a few years since I’ve worked on this but at the time, very few devices supported monitor mode and frame injection “out of the box”. Many only supported monitor mode with a modified version of the vendor or kernel driver
You’ll want to make sure your device has a driver available that fully supports both. This sort of task (frame monitoring and injection) is common for Penetration Testers who tend to use Kali Linux, which is really just an Ubuntu distribution with a bunch of “hacking” tools and (modified) 802.11 device drivers preloaded and in its repositories. You can often save time finding a well supported card by using a search engine to find the device and driver recommended for Kali users
I’m bringing this monitor/injection capability up explicitly because when I first worked on a similar project a few years ago, I needed to use a patched version of the official kernel driver to support monitor mode- it was an rtl8812au chipset. At that time, I made an incorrect assumption that monitor mode support in the driver implied full injection support. I spent 2 days banging my head against the wall, convinced my frames weren’t built correctly in my application, causing no frames to leave the card. Turned out I needed a more recent branch of the driver I was using to get the full injection support. This driver in particular supports both monitor mode and frame injection now. The most frustrating thing about diagnosing that problem was that I did not receive any errors from system calls or in kernel messages while trying to transmit the frames- they were just being silently discarded somewhere, presumably in the driver
To your main question about how to do this- the answer is almost certainly libpcap if you’re writing your application in C/C++ as libpcap provides not only packet capture APIs but also packet injection APIs
If you do it in Python, scapy is an excellent option. The benefit of Python/scapy is that
Python code is much quicker to write than C
scapy provides a significant amount of classes that you can use to intuitively create a frame layer by layer
Because the layers are implemented as classes, you can also extend and “register” existing classes to make certain frames easier to create (or parse when received)
You can do this in straight C using the UNIX sockets API with raw sockets directly- but you’ll have to deal with things that libpcap exists to abstract from you- like underlying system calls that may be required when doing raw frame transmission, aside from the standard socket(), send(), recv() calls. I’m speculating that there are a handful of ioctl calls you may need at the least, specific to the kernel 802.11x subsystem/framework- and these ioctl() calls and their values may not be completely portable across different major kernel versions. I’ll admit I ended up not using the pure C (without libpcap) approach, so I’m not 100% sure about this potential problem. It’s something you should look more into if you plan to do it without libpcap. I don’t recommend it unless you have a really good reason to
It sounds like you are getting the media and transport layers mixed up.
802.11 is what's commonly referred to as a "link", "physical", or "media" layer, meaning it only deals with the transmission of raw datagrams.
Concepts like ACKs, retransmissions, backoff (flow control) apply to the "transport" layer, and those particular terms are strongly associated with TCP/IP.
Implementing your own complete transport layer from scratch is very difficult and almost certainly not what you want to do. If instead you want to use the existing TCP/IP stack on top of your own custom interpretation of 802.11, then you probably want to create a virtual network interface. This would act as an intermediary between TCP/IP and the media layer.
Hopefully this gives you some better context and keywords to look for.
I haven't used Visual C++ before, however I'm starting a project that will require me to use it.
I want to get raw data from the USB. Almost every website tells me that I need to write a device driver for it first... Well I know that!
But I want to start simple - with my wireless mouse receiver, which obviously has a driver installed, which works. How can I access the contents which that receiver provides to the computer, using Visual C++?
This is a great project - a ton of fun too. Perhaps you can find some resources from this related post. I go into a lot more detail there. But I'll answer a little bit here too.
First off, you definitely don't want to write a driver. The time of writing drivers is mostly behind us. :) At least for what you are trying to do in particular. As I detail in the aforementioned post, we now mostly use HID descriptors to communicate with HID (usb) devices instead of writing drivers. This is awesome because it seriously simplifies the task.
I will highly recommend you or anyone in the same position use the libusbx library. It makes things very simple and straightforward in terms of communicating directly with HID devices. Again, see the post for a much more involved answer, but this should do it. Good luck!