In a connection without outgoing traffic, conn->tx_num will remain 0.
In this case, conn->tx_pkt_med should be simply 0 without calculating
"conn->tx_bytes / conn->tx_num".
This was likely to happen, for example, when "btmon -w btsnoop.log"
was launched in the middle of a LE mouse connection, and a number of
incoming ACL Data RX were received as the mouse movements. When
running "btmon -a btsnoop.log", it would encounter this error.
Reviewed-by: Alain Michaud <alainm@chromium.org>
Reviewed-by: Yun-Hao Chung <howardchung@chromium.org>
Reviewed-by: Shuo-Peng Liao <deanliao@chromium.org>
This patch fixes the out-of-bounds array access caught by the ASAN.
monitor/sdp.c:497:19: runtime error: index 8 out of bounds for type
'cont_data [8]'
=================================================================
==4180==ERROR: AddressSanitizer: global-buffer-overflow on address
0x7fe2d271a542 at pc 0x7fe2d174a57d bp 0x7ffc6dcac1d0 sp 0x7ffc6dcab978
WRITE of size 9 at 0x7fe2d271a542 thread T0
#0 0x7fe2d174a57c (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c)
#1 0x7fe2d23bae85 in search_attr_rsp monitor/sdp.c:692
#2 0x7fe2d23be3f1 in sdp_packet monitor/sdp.c:771
#3 0x7fe2d23b004c in l2cap_frame monitor/l2cap.c:3247
#4 0x7fe2d23b3d9c in l2cap_packet monitor/l2cap.c:3312
#5 0x7fe2d237d5c3 in packet_hci_acldata monitor/packet.c:11638
#6 0x7fe2d2381876 in packet_monitor monitor/packet.c:3967
#7 0x7fe2d230b285 in data_callback monitor/control.c:973
#8 0x7fe2d2447029 in mainloop_run src/shared/mainloop.c:106
#9 0x7fe2d2449306 in mainloop_run_with_signal src/shared/mainloop-notify.c:188
#10 0x7fe2d230324a in main monitor/main.c:290
#11 0x7fe2d0b440b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#12 0x7fe2d2303b7d in _start (/home/han1/work/dev/bluez/monitor/btmon+0x1dbb7d)
0x7fe2d271a542 is located 30 bytes to the left of global variable 'tid_list'
defined in 'monitor/sdp.c:43:24' (0x7fe2d271a560) of size 384
0x7fe2d271a542 is located 2 bytes to the right of global variable 'cont_list'
defined in 'monitor/sdp.c:424:25' (0x7fe2d271a400) of size 320
SUMMARY: AddressSanitizer: global-buffer-overflow
(/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c)
...
==4180==ABORTING
This fixes erros such as:
monitor/packet.c:8129:2: runtime error: load of misaligned address
0x55956a438f2d for type 'const uint16_t', which requires 2 byte
alignment
AVRCP byte order is always big endian:
Audio/Video Remote Control / Profile Specification - Page 20:
'Transfer Octet Order; Packets shall transfer multiple-octet fields in
standard network octet order (Big Endian), with more significant
(high-order) octets being transferred before less-significant (low-order)
octets.'
This adds support for vendor commands reserving a single opcode (0xfc10)
so it can be extended using subcommands, similar to how MSFT works.
The first subcommand (0x00) enables the emulator to generate arbitrary
events using the commands parameters:
> tools/hcitool cmd 3f 10 00 22 24 d0 d0 d0 d0 d0 d0 ff ff
< HCI Command: Vendor (0x3f|0x0010) plen 11
00 22 24 d0 d0 d0 d0 d0 d0 ff ff
."$........
Bluetooth: hci0: Malformed HCI Event: 0x22
> HCI Event: Inquiry Result with R.. (0x22) plen 9
Num responses: 36
Page scan repetition mode: Reserved (0xff)
Page period mode: Reserved (0xff)
Class: 0xffffd0
Major class: Uncategorized, specific device code not specified
Minor class: 0x34
Limited Discoverable Mode
invalid service class
Clock offset: 0x6368
RSSI: 105 dBm (0x69)
> HCI Event: Command Complete (0x0e) plen 4
Vendor (0x3f|0x0010) ncmd 1
Status: Success (0x00)
BT core spec 5.3 promotes the usage of inclusive languages.
This CL replaces some terms with the more appropriate counterparts,
such as "central", "peripheral", "link key", and "accept list"
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
BT core spec 5.3 promotes the usage of inclusive languages.
This CL replaces some terms with the more appropriate counterparts,
such as "central", "peripheral", and "accept list".
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Milisecconds is probably the best unit to have since it is unlikely that
the controller can respond in under 1 msec as well as most time
sensitive connection e.g. A2DP, HFP, etc, also don't expect the
latencies to be over 1 sec.
Analyze code was not accounting for the fact that multiple outstanding
packets could be pending which will cause the last_tx to be overwritten
but its latency would be calculated against the very first packet
complete.
It seems timer_sub can produce negative values leading to median packet
latency to be negative e.g conn->last_tx_compl is ahead of
conn->last_tx, in which case it should be discarded.
Calculating the median packet based on the current median + size / 2
does not account for last packet could smaller e.g. opp transfer could
end with just 1 byte which would cut the median in a half, so this
switch to more traditional means of calculating by doing total bytes
sent / num of packets so each an every packet has the same weight.
Some Intel device supports two different formats of the
HCI_Intel_Read_Version command depends on the command parameter and this
patch parses the command and response parameters depends on the format.
This fixes the issue of --server <socket> parameter
last character was dropped. There is no need to use
strncpy, as the length is already checked, and it is
known that the destination buffer is big enough
A new flag was added to the kernel implementation of the Device Found
event, but had not been added to the parser leading to an "Unknown device
flag" error in btmon.
Reviewed-by: Yu Liu <yudiliu@google.com>
When RFCOMM_TEST_EA returns false, btmon assumes packet data has at
least 5 bytes long. If that assumption fails, btmon could crash when
trying to read the next byte.
This patch fix it by checking the remaining size before reading the last
byte.
Reviewed-by: apusaka@chromium.org
This patch removes the Pygments dependency from btmon .rst file.
When the code-block type is specified, the rst2man throws a warning
asking for Pygments package.
Reject type was not being decoded, so this remove the early return and
leave the callback to decode it:
< ACL Data TX: Handle 42 flags 0x00 dlen 8
Channel: 64 len 4 [PSM 25 mode Basic (0x00)] {chan 1}
AVDTP: Set Configuration (0x03) Response Reject (0x03) type 0x00 label 2 nosp 0
Service Category: Reserved (0x00)
Error code: BAD_ACP_SEID (0x12)
