Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed yesterday.
Improve this question
When I run hciconfig -a on Ubuntu/Bluez I get the info below which contains a 'Features' line with 8 bytes. How do I decode those bytes? That is, what features are represented by waht bit?
My special interest is in the Packet Length Extension feature which I presume is indicated by one of the bytes.
$ hciconfig -a
hci0: Type: Primary Bus: USB
BD Address: EC:63:D7:F1:C7:8B ACL MTU: 1021:5 SCO MTU: 96:6
UP RUNNING
RX bytes:7667 acl:0 sco:0 events:297 errors:0
TX bytes:5739 acl:0 sco:0 commands:123 errors:0
Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF
Link mode: PERIPHERAL ACCEPT
Name: 'linux'
Class: 0x7c0104
Service Classes: Rendering, Capturing, Object Transfer, Audio, Telephony
Device Class: Computer, Desktop workstation
HCI Version: 4.2 (0x8) Revision: 0x1000
LMP Version: 4.2 (0x8) Subversion: 0x1000
Manufacturer: Intel Corp. (2)
Related
I have been trying out the bluez btmon tool to monitor the bluetooth discovery result on my raspberry pi 4.
The btmon tool returns stdout which is the following:
# MGMT Event: Device Found (0x0012) plen 42 {0x0001} [hci0] 0.207973
LE Address: 61:E1:E1:49:C8:DC (Resolvable)
RSSI: -51 dBm (0xcd)
Flags: 0x00000004
Not Connectable
Data length: 28
16-bit Service UUIDs (complete): 1 entry
Google (0xfe9f)
Service Data (UUID 0xfe9f): 0000000000000000000000000000000000000000
# MGMT Event: Device Found (0x0012) plen 33 {0x0001} [hci0] 0.224956
LE Address: 48:82:8F:DB:5C:65 (Resolvable)
RSSI: -76 dBm (0xb4)
Flags: 0x00000000
Data length: 19
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 5 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 491faeca8c8638
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.298194
LE Address: 0E:AF:D9:F0:D8:F1 (Non-Resolvable)
RSSI: -68 dBm (0xbc)
Flags: 0x00000004
Not Connectable
Data length: 29
Company: Microsoft (6)
Data: 0109210a065124d7b5c04445534b544f502d44484845413434
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.940219
LE Address: 86:2A:FD:9E:57:0D (OUI 86-2A-FD)
RSSI: -77 dBm (0xb3)
Flags: 0x00000000
Data length: 29
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Service Data (UUID 0xfdf7): 01384a3dd6381b593c74d9369eefaa9b720000000003
Been looking for some official docs on explaining the field "Flags" in each discovered device info (those flag codes: 0x00000004, 0x00000000, 0x1a, 0x06), but I couldn't seem to find one that makes sense.
Would really appreciate if anyone could explain what does the Flags tell, and how to make sense of these codes?
Thanks in advance.
I don't know what you call "official docs", but the Bluetooth Core Specification and the Supplement to the Bluetooth Core Specification certainly explains it. Have a look at chapter 1.3 FLAGS of CSS
In the log you showed, you can see the advertising data of several Bluetooth LE devices. Each of this advertising data contains one ore more fields called AD Types. One of the AD Types is the "Flags" field. It may be zero or more octets long, with the first octet containing the following information:
Octet
Bit
Description
0
0
LE Limited Discoverable Mode
0
1
LE General Discoverable Mode
0
2
BR/EDR Not Supported. Bit 37 of LMP Feature Mask Definitions (Page 0)
0
3
Simultaneous LE and BR/EDR to Same Device Capable (Controller). Bit 49 of LMP Feature Mask Definitions (Page 0)
0
4
Previously Used
0
5..7
Reserved for future use
The given information tells you something about the used Bluetooth radio and about the advertising itself. If you are interested in a deeper understanding of this topic, I recommend reading this Bluetooth blog article: Advertising Works, Part 1
In prior kernels and releases of Ubuntu, it was possible to use the hci socket interface to send an arbitrary set of 31 bytes as an advertising beacon, but in ubuntu 20.04 the hci bluetooth tools were deprecated, as were some elements of the socket API they were using.
The goal is to have some N number of devices broadcast 31 bytes of sensor data to each other at a rate of 5 Hz, and have all N read the packets from the other devices.
With the hci socket API being deprecated, the replacements are the DBus BlueZ API and the Management BlueZ API. The DBus API is limited and seems to only allow a max of 25 bytes. The Management API seems more capable, and it seems to work on Ubuntu 18.04/4.15 kernel (though even there the scan seemed to only pick up the advertisements sporadically when switching between scan and advertise every 100ms while with the hci api it was rock solid), but on Ubuntu 20.04/5.4 kernel, various issues crop up.
Using the hci socket API seems like it could still be possible, but even running something like hcitool lescan results in btmon saying Command Disallowed. I believe this might be due to LE Extended Advertising being enabled, but I have not figured out how to disable it yet.
Using the DBus API (or bluetoothctl) is still limited and doesn't allow the full use of the 31 bytes (or even 30 bytes + length)
Using the Management API leads to a Advertising Timeout shortly after setting the advertising data, which I think might be from LE Extended Advertising being enabled. This problem persists even if I explicitly set the timeout in the packet.
For example, running
btmgmt add-adv -c -d 1E000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D 1
to send an advertising packet at a fixed MAC with the advertising data being length:31 payload: 0-30 results in a btmon output of:
< HCI Command:... (0x08|0x0036) plen 25 #631 [hci0] 5676.358401
Handle: 0x01
Properties: 0x0013
Connectable
Scannable
Use legacy advertising PDUs: ADV_IND
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: 127 dbm (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
> HCI Event: Command Co.. (0x0e) plen 5 #632 [hci0] 5676.359321
LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
Status: Success (0x00)
TX power (selected): 7 dbm (0x07)
< HCI Command: L.. (0x08|0x0039) plen 6 #633 [hci0] 5676.359410
Extended advertising: Enabled (0x01)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x01
Duration: 2000 ms (0xc8)
Max ext adv events: 0
> HCI Event: Command Co.. (0x0e) plen 4 #634 [hci0] 5676.361330
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
# MGMT Event: Com.. (0x0001) plen 4 {0x0003} [hci0] 5676.361372
Add Advertising (0x003e) plen 1
Status: Success (0x00)
Instance: 1
> HCI Event: LE Meta Ev.. (0x3e) plen 6 #635 [hci0] 5676.362333
LE Advertising Set Terminated (0x12)
Status: Advertising Timeout (0x3c)
Handle: 1
Connection handle: 65535
Number of completed extended advertising events: 0
Is there a good way to recreate the functionality that was available using the hci socket, or a way to disable extended advertising so that the hci socket works again?
This image from Jos Ryke might help explain what is going on. Of those 31 bytes, 3 were always used for setting the advertising flags.
Looking at the source code for btmgmt those flags are now set with the -g, and -l command line switches. Use general discoverable mode to advertise indefinitely.
static void add_adv_usage(void)
{
bt_shell_usage();
print("Options:\n"
"\t -u, --uuid <uuid> Service UUID\n"
"\t -d, --adv-data <data> Advertising Data bytes\n"
"\t -s, --scan-rsp <data> Scan Response Data bytes\n"
"\t -t, --timeout <timeout> Timeout in seconds\n"
"\t -D, --duration <duration> Duration in seconds\n"
"\t -P, --phy <phy> Phy type, Specify 1M/2M/CODED\n"
"\t -c, --connectable \"connectable\" flag\n"
"\t -g, --general-discov \"general-discoverable\" flag\n"
"\t -l, --limited-discov \"limited-discoverable\" flag\n"
"\t -n, --scan-rsp-local-name \"local-name\" flag\n"
"\t -a, --scan-rsp-appearance \"appearance\" flag\n"
"\t -m, --managed-flags \"managed-flags\" flag\n"
"\t -p, --tx-power \"tx-power\" flag\n"
"e.g.:\n"
"\tadd-adv -u 180d -u 180f -d 080954657374204C45 1");
}
The other 28 bytes must start with a byte declaring the length and a byte declaring what data type the rest of the bytes in the declared length are describing.
It is those 28 bytes that is being set with the -d option of btmgmt.
If 28 bytes are not enough, then common workarounds people use is to split the data over multiple adverts or use scan response packet.
There is more detail on the Advertising Data Format in the Core Specification where it defines an Advertising Packet as:
A packet containing an advertising PDU. See [Vol 6]
Part B, Section 2.3.1
More data is section:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C | 11 ADVERTISING AND SCAN RESPONSE DATA FORMAT
It has an example for ADV_NONCONN_IND packet type:
PDU Type: 2
ChSel: RFU
TxAdd: 1 (random)
RxAdd: RFU
AdvA: 0xC1A2A3A4A5A6 (a static device address)
AdvData: (3 octets) 0x01 0x02 0x03
Which starts with the flags data type.
I have a raspberry pi, a WLAN stick (Ralink Technology, Corp. RT5370) in monitor mode and tcpdump (+tshark) installed.
Now I want to read link layer packages from a WLAN wristband device that patients in a retirement home use. This device sends link layer data every second in order to be detected by access points using fingerprinting. The content of this packages is not important, only the RSSI values and the MAC of the device is needed.
With my rPi now I wants to detect when a patient is neat to its own flat door in order to open it automatically. For this, the Pi needs to receives this LLC packages so that I can use the associated RSSI value to calculate the distance.
Using Wireshark and Windows (Airpcap) I can read these LLC packages without problems. The output is for example:
35748 152.953461000 00:00:00_00:00:00 57:01:ff:00:00:00 LLC 62 I, N(R)=0, N(S)=0; DSAP NULL LSAP Individual, SSAP 0x1e Command
If I do the same thing on raspbian using tcpdump or tshark, I don't receive data at all.
tcpdump (command is sudo tcpdump llc -i wlan1) returns
tcpdump: 'llc' supported only on raw ATM
Looks like my linux/driver is not able to pass link layer data to tcpdump. How can I enable it?
Thank you for any hint
UPDATE
Thanks to Guy Harris I found a solution
sudo tcpdump -e -i wlan1 type data
returns all LLC packages and the -e value adds all types of mac. Output is something like this where TA is the MAC of the device. I parsed it using python line by line to get the data I needed
02:56:21.346146 11.0 Mb/s 2462 MHz 11b -53dB signal antenna 1 RA:01:40:96:00:00:03 (oui Unknown) TA:00:18:8e:40:62:03 (oui Unknown) DA:00:00:00:00:00:00 (oui Ethernet) SA:00:00:00:00:00:00 (oui Ethernet) LLC, dsap Null (0x00) Individual, ssap OSI (0xfe) Response, ctrl 0x0b: Unnumbered, 0b, Flags [Response], length 24
BR
Stefan
tcpdump: 'llc' supported only on raw ATM
First of all, the filter comes after all the command-line flags, including -i, so, if you're going to be capturing on wlan1 with a filter, what you want is
sudo tcpdump -i wlan1 {filter}
That's how tcpdump works - the filter comes after all the command-line flags and the arguments to those flags, including -i, -r, etc.
Second of all, "llc" means something very specific - from the "pcap-filter" man page (with older versions of libpcap and tcpdump, it's in the tcpdump man page, but the filter expressions aren't understood by tcpdump, they're understood by libpcap, the library tcpdump uses to capture and to read capture files):
llc True if the packet is an ATM packet, for SunATM on Solaris, and
is an LLC-encapsulated packet.
On 802.11, all 802.11 data frames have an 802.2 LLC header, so you want
tcpdump -i wlan1 type data
which will filter out management and control frames (which don't have 802.2 LLC headers).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I'm trying to determine the currently installed ram type of my linux machine by running the command 'dmidecode' but there must be an error because the ram type and other things are still unknown!?
# dmidecode 2.11
SMBIOS 2.4 present.
Handle 0x001A, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0019
Error Information Handle: Not Provided
Total Width: 2304 bits
Data Width: 2244 bits
Size: 2048 MB
Form Factor: DIMM
Set: None
Locator: A0
Bank Locator: Bank0/1
Type: Unknown
Type Detail: None
Speed: 1333 MHz
Manufacturer:
Serial Number:
Asset Tag:
Part Number:
Is there another way to find out this stats?
in SUSE Linux lshw is not installed by default, but hwinfo is.
hwinfo --bios
gives me
[...]
Memory Device: #38
Location: "DIMM1"
Manufacturer: "Hyundai"
Serial: "0F3005F1"
Asset Tag: "000109"
Part Number: "HMT125U6BFR8C-H9"
Memory Array: #36
Form Factor: 0x09 (DIMM)
Type: 0x01 (Other)
Type Detail: 0x0080 (Synchronous)
Data Width: 64 bits
Size: 2 GB
Speed: 1333 MHz
Memory Device Mapping: #39
Memory Device: #38
Array Mapping: #37
Row: 1
Interleave Pos: 0
Interleaved Depth: 1
Start Address: 0x00000000
End Address: 0x80000000
[...]
Try lshw, it will give memory description and other system information.
I have a Dell Latitude E6410, which uses an Intel Ultimate N-6300 Wireless card. iwconfig does not show the Noise level of the wireless interface , wlan0. Does anyone know the reason for that?
precise#ubuntu:~/Desktop/Work/transmitter$ iwconfig
lo no wireless extensions.
mon0 IEEE 802.11abgn Mode:Monitor Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
wlan0 IEEE 802.11abgn ESSID:"AirPennNet"
Mode:Managed Frequency:2.412 GHz Access Point: D8:C7:C8:D7:A6:C1
Bit Rate=130 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=65/70 Signal level=-45 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:800 Invalid misc:540 Missed beacon:0
eth0 no wireless extensions.
I tried to use cat /proc/net/wireless and got these results
Inter-| sta-| Quality | Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan0: 0000 64. -46. -256 0 0 0 818 566 0
Is -256 the noise level? How do i interpret this in dBm?
The answer lies within your driver and wireless card support.
I have a similar Dell Latitude model but with an Intel(R) Centrino(R) Advanced-N 6200 AGN wireless card. After issuing the iwconfig command, the output also revealed something similar - the Noise parameter was missing (this was done while in connection to an access point, of course).
Not happy with that, I got out another wireless card (Winstron NeWeb AR9170+AR9104 802.11abgn - basically a Proxim Wireless 802.11a/b/g/n Wi-Fi USB dongle) and issued the same command. The output was still the same, the Noise parameter was not there!
This wasn't what I had expected since I knew very well that we had used the same Wi-Fi dongle to detect the noise level associated with access points using a proprietary software by Fluke Network called the AirMagnet WiFi Analyzer PRO. I even tried downloading and re-compiling the Linux Wireless Tools package from Jean Tourrilhes' but similar output was shown as before.
The next step I did was to verify again that the WiFi dongle actually does show the WiFi noise levels under the AirMagnet WiFi Analyzer software. Sure enough, it does (as depicted in the attached image below).
The blue column with the header 'N' refers to the noise level. Mind you, the WiFi dongle also came along with a proprietary driver when we bought the AirMagnet software along with it.
Having done that, I decided to see what it would show for our internal WiFi card (Intel(R) Centrino(R) Advanced-N 6200 AGN). Here are the results:
All of them are displaying values of -100! So, I believe it all has something to do with the driver/card capabilities.