In my linux program I need to read the key presses on a bluetooth keyboard.
I tried to follow a set of examples using libbluetooth, but have so far no success.
At the last stage I am totally confused on what API to use.
As I understood, the library provides SDP and HCI interfaces and they both seem to be suitable for my need. I even could read out some information about the keyboard, but I cannot get further how to receive key presses.
So, I need you help to understand:
do I need in general to use the libbluetooth or I have to use native BT sockets?
assuming, that I do need to use the lib, which API to use: SDP or HCI (perhaps another..)?
is the lib only required to initiate data transfer from the BT device, or also to receive the data
Related
I'm currently making a Bluetooth app with BlueZ
I need to get a Pairing request.
Using BlueZ DBus API, i've made my Agent into NoInputOutput mode, and i succeed the first pairing with my phone.
However, if i delete the linux device(which uses my bluetooth app that i am developing) from my phone and try to re-connect, i can't pair it together.
I searched Python code examples that...
From BlueZ's DBus API, calling RequestAuthorization method to pair and successes it, then deleting the device and re-pairing works fine.
But in case of smartphone's pairing request, i think i should call RequestAuthorization method WHEN SOME EVENT(S) is received. And i have no idea for that.
Conclusion: How can i get a pairing request event using dbus and glib loop?
I've already checked
bluez pairing before exchange
apparently, gdbus is a combination of dbus and glib.
However, i'm using dbus and glib separated since i can sorted some codes that i do not need.
More, now i think it doesn't have any relations with deleting devices from the list.
I am familiar with different tools (like netstat, tcpdump, etc.) and files (like /sys/class/net/<dev>/statistics) with which we can get the count.
But can anyone tell me if there is a way of getting that information directly from the kernel, using netlink sockets?
Sure, take a look at IFLA_STATS. You may want to check the ifstat.c file of the iproute2 package, which is pretty much the standard tool to interact with netlink.
I'm a beginner to C, I've recently decided to make migrate this project to C from using Scapy/Python, solely because I want better performance. I wish to send layer 2 data, specifically beacon frames to advertise an access point.
So far I have found that I need to (or rather could) use libpcap and a Linux header called ieee80211.h that pre-defines packets, that's all I could gather from the other questions. I've found other information which says I should use raw sockets instead of libpcap? I'm not sure if this is all I need. Most of the information and tutorials I have found on Google refer to packet sniffing, not sending.
How do I define a custom frame and/or packet (e.g. a beacon frame or association request) and then simply send it to wlan0 etc.?
Thought I might update this. I used libpcap.
You just need to create a handle with your device, set it to monitor mode successfully (important), check the data link type (e.g. 802.11 with Radiotap for layer 2) then use pcap_sendpacket(handle, packetArrayContainingHex, size);. Hard part is forming legal packets that aren't rejected or dropped, taking a look in wireshark helps.
This link might help. It basically opens the driver at raw packet level and creates the whole packet to send over the wire, as your question suggests.
I am working on the Bluetooth media player feature of an internet radio project written in C on Linux platform.
The idea is:
Connect to a nearby BT speaker which is supporting AVRCP profile
Transmit audio through BT to the BT speaker
Handle button push events
Initially I was following the MPRIS D-Bus Interface Specification: https://specifications.freedesktop.org/mpris-spec/latest/
If I understand it well, the specification tells the following:
Request a unique bus name which looks like this: org.mpris.MediaPlayer2.AnyName
Expose the /org/mpris/MediaPlayer2 object path
Implement the following interfaces:
org.mpris.MediaPlayer2
org.mpris.MediaPlayer2.Player
All these steps are done. I am using the D-Feet D-bus tool to test property queries, method calls and all of them are working properly.
Now my problem is, that when I connect to a BT speaker and I push the buttons, the application is not getting the events.
Can you please point out what I am missing and what should I do next?
Thanks in advance!
PM: Sorry if I am not clear, I am a newborn programmer and Stackoverflow user. Please ask me if you need more information. I will appreciate any advice you have :)
EDIT1: The source I have is 1200 line long and I dont know what can I extract from the code for you. But FYI I am using the High-level D-Bus Support of GLib: https://developer.gnome.org/gio/stable/gdbus-convenience.html
uinput module is used to write AVRCP key commands, hence you will require a client to read from uinput when BT headset(A2DP) is connected, check in profiles/audio/avctp.c::uinput_create(), when a avrcp profile is connected, keys are send from handle_panel_passthrough() function to uinput module in kernel
This may not be in the right location, so tell me and I'll move it.
I am a recent EE grad and I was hired to build a system that exists on a SoC with a simple 32-bit processor. The system basically monitors several external devices and performs some DSP on it, and then is supposed to send the results using a WiFi device (in my case I have the ESP8266 using UDP) to an email server for logging/notification.
I have been trying to find a library that I can use, but my uC can only program in C and I have it set up for UDP, and everything is in C++ using some other protocol, or something else completely.
I am great at DSP, decent at SoC's and uC's, but when it come to this email server communication thing I am at a loss.
I have successfully configured everything for the sensors, the datapath, the DSP, and connected the system to my WiFi via UDP, but I have yet to figure out how to send data to any servers.
Could someone help me understand how I should go about this?
I have looked into some simple SMTP commands such as HELO, MAIL, RCPT, DATA, etc. but I cannot understand how I actually should implement them in my code.
When I send out the WiFi data via UDP what type of data do I send and how do I format it? Do I need to send any other kind of flags? How should I expect the response? I also know the data has to be transformed into base 64 which is confusing me further.
I am also not super familiar with UDP to begin with, I have been using libraries that are part of the SoC's default library to connect to my WiFi.
I know these may either seem like obvious or stupid questions but it is were I no longer have any knowledge, and everything I find online doesn't make sense, or doesn't attempt to explain it, just gives a pre-made solution
I have found the RFC2821 but it doesn't get any clearer.
I know that's a lot but any help at all would be a lifesaver!
Since you are asking this question, I'm assuming that you are not booting and running an OS suitable for micro-controllers such as an embedded variant of Linux or such. If you were, you would simply be able to take advantage of possibly built in applications or other existing code.
But you don't mention having written an Ethernet stack, so are you using some other library or operating environment which might have some of the functionality needed for an implementation of SMTP?
If you don't and really do need to write your own SMTP client to run directly on the processor you are using, then you should be able to find plenty of examples of source code for this. A quick google search of How To Write an SMTP client showed a few articles with some example code. One article seems to be an exact hit, but you need to look at it further.
However, I would highly suggest just sitting down with a telnet client and connect to an SMTP server you are allowed to use and try the commands you need to just send a message. If you only need to send text, you don't need to get involved in MIME encoding or anything like that.