In Dbus the interface for org.bluez.GattCharacteristic1 has an interface StartNotify(). This works fine with a callback defined. How do I enable notify with indicate?
Whether it is notify or indicate that the StartNotify() function uses is defined by the characteristic it is operating on.
As an example, using bluetoothctl to look at two characteristics on a BBC micro:bit you can see that one supports notify and one supports indicate. You would use StartNotify() on both.
[bluetooth]# connect E1:4B:6C:22:56:F0
Attempting to connect to E1:4B:6C:22:56:F0
[CHG] Device E1:4B:6C:22:56:F0 Connected: yes
Connection successful
[CHG] Device E1:4B:6C:22:56:F0 ServicesResolved: yes
[BBC micro:bit [toveg]]# gatt.attribute-info e95d9250-251d-470a-a062-fa1922dfa9a8
Characteristic - Vendor specific
UUID: e95d9250-251d-470a-a062-fa1922dfa9a8
Service: /org/bluez/hci0/dev_E1_4B_6C_22_56_F0/service003c
Notifying: no
Flags: read
Flags: notify
[BBC micro:bit [toveg]]# gatt.attribute-info 6e400002-b5a3-f393-e0a9-e50e24dcca9e
Characteristic - Nordic UART TX
UUID: 6e400002-b5a3-f393-e0a9-e50e24dcca9e
Service: /org/bluez/hci0/dev_E1_4B_6C_22_56_F0/service0028
Notifying: no
Flags: indicate
Related
I am looking for a way to call Linux kernel crypto API from user space for RSA encryption/decryption. RSA function are implemented in linux kernel.
Currently, I found 2 way to call crypto API from user space:
AF_ALG socket, using [libkapi] (http://www.chronox.de/libkcapi.html). It seems to be the offical solution (https://www.kernel.org/doc/html/v4.19/crypto/userspace-if.html).
[cryptodev] (http://cryptodev-linux.org/) which uses ioctl.
Unfortunaly, cryptodev doesn't support asymmetric algorithms like RSA.
And I am not sur if AF_ALG supports akcipher like RSA. The result of cat /proc/crypto is:
...
name : rsa
driver : rsa-generic
module : kernel
priority : 100
refcnt : 1
selftest : passed
internal : no
type : akcipher
But, I tried to bind an AF_ALG socket with :
int sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "akcipher",
.salg_name = "rsa"
};
The bind failed with ***ERROR : bind socket failed (2) : No such file or directory.
Did I miss something ? Is there an other way to call crypto API from user space ?
From the documentation:
The kernel crypto API is accessible from user space. Currently, the
following ciphers are accessible:
Message digest including keyed message digest (HMAC, CMAC)
Symmetric ciphers
AEAD ciphers
Random Number Generators
This means, that the akcipher cipher family is not available from userspace, hence binding to it fails with ENOENT. Indeed, checking with the linux kernel source reveals, that there is no algif_akcipher.c, where the userspace interface of the akcipher family would be implemented.
Using wpa_supplicant 2.4 on ARM Debian.
Is there a way to get signal level, in decibels or percents, of the wireless network I’m currently connected to?
STATUS command only returns the following set of values: bssid, freq, ssid, id, mode, pairwise_cipher, group_cipher, key_mgmt, wpa_state, ip_address, p2p_device_address, address, uuid
I can run SCAN afterwards, wait for results and search by SSID. But that’s slow and error-prone, I'd like to do better.
The driver should already know that information (because connected, and adjusting transmit levels for energy saving), is there a way to just query for that?
This question is not about general computing hardware and software. I'm using wpa_supplicant through a C API defined in wpa_ctrl.h header, interacting with the service through a pair of unix domain sockets (one for commands, another one for unsolicited events).
One reason I don’t like my current SCAN + SCAN_RESULT solution, it doesn’t work for hidden SSID networks. Scan doesn’t find the network, therefore I’m not getting signal level this way. Another issue is minor visual glitch at application startup. My app is launched by systemd, After=multi-user.target. Unless it’s the very first launch, Linux is already connected to Wi-Fi by then. In my app’s GUI (the product will feature a touch screen), I render a phone-like status bar, that includes WiFi signal strength icon. Currently, it initially shows minimal level (I know it's connected because STATUS command shows SSID), only after ~1 second I’m getting CTRL-EVENT-SCAN-RESULTS event from wpa_supplicant, run SCAN_RESULT command and update signal strength to the correct value.
On the API level my code is straightforward. I have two threads for that, both call wpa_ctrl_open, the command thread calls wpa_ctrl_request, the event thread has an endless loop that calls poll passing wpa_ctrl_get_fd() descriptor and POLLIN event mask, followed by wpa_ctrl_pending and wpa_ctrl_recv.
And here's the list of files in /sys/class/net/wlan0:
./mtu
./type
./phys_port_name
./netdev_group
./flags
./power/control
./power/async
./power/runtime_enabled
./power/runtime_active_kids
./power/runtime_active_time
./power/autosuspend_delay_ms
./power/runtime_status
./power/runtime_usage
./power/runtime_suspended_time
./speed
./dormant
./name_assign_type
./proto_down
./addr_assign_type
./phys_switch_id
./dev_id
./duplex
./gro_flush_timeout
./iflink
./phys_port_id
./addr_len
./address
./operstate
./carrier_changes
./broadcast
./queues/rx-0/rps_flow_cnt
./queues/rx-0/rps_cpus
./queues/rx-1/rps_flow_cnt
./queues/rx-1/rps_cpus
./queues/rx-2/rps_flow_cnt
./queues/rx-2/rps_cpus
./queues/rx-3/rps_flow_cnt
./queues/rx-3/rps_cpus
./queues/tx-0/xps_cpus
./queues/tx-0/tx_maxrate
./queues/tx-0/tx_timeout
./queues/tx-0/byte_queue_limits/limit
./queues/tx-0/byte_queue_limits/limit_max
./queues/tx-0/byte_queue_limits/limit_min
./queues/tx-0/byte_queue_limits/hold_time
./queues/tx-0/byte_queue_limits/inflight
./queues/tx-1/xps_cpus
./queues/tx-1/tx_maxrate
./queues/tx-1/tx_timeout
./queues/tx-1/byte_queue_limits/limit
./queues/tx-1/byte_queue_limits/limit_max
./queues/tx-1/byte_queue_limits/limit_min
./queues/tx-1/byte_queue_limits/hold_time
./queues/tx-1/byte_queue_limits/inflight
./queues/tx-2/xps_cpus
./queues/tx-2/tx_maxrate
./queues/tx-2/tx_timeout
./queues/tx-2/byte_queue_limits/limit
./queues/tx-2/byte_queue_limits/limit_max
./queues/tx-2/byte_queue_limits/limit_min
./queues/tx-2/byte_queue_limits/hold_time
./queues/tx-2/byte_queue_limits/inflight
./queues/tx-3/xps_cpus
./queues/tx-3/tx_maxrate
./queues/tx-3/tx_timeout
./queues/tx-3/byte_queue_limits/limit
./queues/tx-3/byte_queue_limits/limit_max
./queues/tx-3/byte_queue_limits/limit_min
./queues/tx-3/byte_queue_limits/hold_time
./queues/tx-3/byte_queue_limits/inflight
./tx_queue_len
./uevent
./statistics/rx_fifo_errors
./statistics/collisions
./statistics/rx_errors
./statistics/rx_compressed
./statistics/rx_dropped
./statistics/tx_packets
./statistics/tx_errors
./statistics/rx_missed_errors
./statistics/rx_over_errors
./statistics/tx_carrier_errors
./statistics/tx_heartbeat_errors
./statistics/rx_crc_errors
./statistics/multicast
./statistics/tx_fifo_errors
./statistics/tx_aborted_errors
./statistics/rx_bytes
./statistics/tx_compressed
./statistics/tx_dropped
./statistics/rx_packets
./statistics/tx_bytes
./statistics/tx_window_errors
./statistics/rx_frame_errors
./statistics/rx_length_errors
./dev_port
./ifalias
./ifindex
./link_mode
./carrier
You can get the signal level of the connected wifi by wpa_supplicant cmd SIGNAL_POLL
The wpa_supplicant would return:
RSSI=-60
LINKSPEED=867
NOISE=9999
FREQUENCY=5745
The value of the RSSI is the signal level.
You can get the signal level of the connected wifi by wpa_supplicant cmd BSS <bssid>.
About the bssid of the connected wifi, you can get from wpa_supplicant cmd STATUS.
https://android.googlesource.com/platform/external/wpa_supplicant_8/+/622b66d6efd0cccfeb8623184fadf2f76e7e8206/wpa_supplicant/ctrl_iface.c#1986
For iw compatible devices:
Following command gives the current station(aka AP) signal strength:
iw dev wlp2s0 station dump -v
If you need C API, just dig the source code of iw.
After a quick glance, the function you need is here
For broadcom devices, try search broadcom wl. It is close source, don't know if C API is provided.
While trying to call Acquire dbus api from our application , the bluez stack gets the fd, imtu, omtu successfully, and sends it over dbus using g_dbus_send_reply. But when we call dbus_connection_send_with_reply_and_block from our application, we are unable to get the reply,and unable to get the fd, imtu and omtu.The dbus is returning org.freedesktop.DBus.Error.NoReply.
dbus version used is 1.10.10.
Bluez version - 5.37
Dbus error seen is ,
method call time=1493814994.072004 sender=:1.50 -> destination=org.bluez serial=50 path=/org/bluez/hci0/dev_A4_70_D6_7A_74_7F/fd2; interface=org.bluez.MediaTransport1; member=Acquire
error time=1493814994.074396 sender=org.freedesktop.DBus -> destination=:1.50 error_name=org.freedesktop.DBus.Error.NoReply reply_serial=50
string "Message recipient disconnected from message bus without replying"
Bluetoothd error seen is,
State changed /org/bluez/hci0/dev_88_79_7E_84_2C_54/fd2: TRANSPORT_STATE_PENDING -> TRANSPORT_STATE_ACTIVE
bluetoothd[7523]: Disconnected from D-Bus. Exiting.
Any inputs will be of great help. Awaiting for the reply.
This issue is resolved by applying Smack patch for bluetooth.
This patch allows kernel sockets to be used by applications.
Patches are,
0001-Smack-File-receive-for-sockets.patch
0002-smack-fix-cache-of-access-labels.patch
0003-Smack-ignore-null-signal-in-smack_task_kill.patch
0004-Smack-Assign-smack_known_web-label-for-kernel-thread.patch
Gerrit link -
https://gerrit.automotivelinux.org/gerrit/#/c/6995/
I can perform normal scan using ioctl SIOCSIWSCAN and SIOCGIWSCAN and get list of AP, but when I set card into monitor mode i get errno = Operation not supported.
Is there a different ioctl call for passive scans??
I know the wifi card is not the issue, because I get results with airodump-ng and I checked two different cards.
First, on the command line type:
iw phy <phy> info
and see if new_interface is listed under supported commands. You can get the phy for your cards by:
iw dev
Second, I have found that it's easier to set a card in monitor mode if I delete all interfaces on the phy first. Some cards don't play well if there are interfaces active.
Use ioctl to bring cards up or down and to get the card's hw addr. Otherwise you should be using netlink - You're looking for NL80211_CMD_NEW_INTERFACE in nl80211.h
FreeBSD: network interface address: dhcp or static
Followup question now:
I've decided to go with looking at leases files: /var/db/dhclient.leases.. What does it tell me exactly? Existence of /var/db/dhclient.leases.em0 signifies em0 has address by DHCP? This file does not seem to go away with reboot.
You should read the manual page for dhclient. This will answer most of your questions. And if that fails, you can browse the source in /usr/src/sbin/dhclient.
Another possibility might be to to use devd(8). This is a daemon that can execulte a script or program if a certain event occurs. It can e.g. note when a network interface goes "up" or "down". From the default /etc/devd.conf (see also devd.conf(5)):
# Try to start dhclient on Ethernet-like interfaces when the link comes
# up. Only devices that are configured to support DHCP will actually
# run it. No link down rule exists because dhclient automatically exits
# when the link goes down.
#
notify 0 {
match "system" "IFNET";
match "type" "LINK_UP";
media-type "ethernet";
action "/etc/rc.d/dhclient quietstart $subsystem";
};
A client is supposed to remember a DHCP lease across reboots and is supposed to remember past leases on a particular network when requesting an address. Therefore, the file should not go away across boots.