Bluetooth packets - Missing HCI events
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 12.6k
- Forks
- 2.2k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 56
Description
Brief description
Sniffing bluetooth packets and the device's mac address from the raw load of the packets is not the same as the load that i get from hcidump. (The mac address is wrong in the SCAPY bluetooth packets)
Environment
- Scapy version: Version 2.4.3.dev454
- Python version:
2.7 - Operating System: Linux raspberrypi 4.19.75-v7+
How to reproduce
I am using this linux command to make a connection between my raspberry pi and my phone:
sudo hcitool cc 1C:39:47:75:BE:94
Then i sniff the packets with hcidump, and then i try again with the pkts = bt.sniff() too.
Actual result
As a result the device mac address in the raw load of all scapy packets is not correct or is not, what it should be!
Example of packets:
With hcidump the packet is this:
2020-04-09 13:43:23.218009 < HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr 1C:39:47:75:BE:94 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
With scapy the packet is this:
pkts[0].show()
###[ HCI header ]###
type= Command
###[ HCI Command header ]###
opcode= 0x405
len= 13
###[ Raw ]###
load= '\x94\xbeuG9\x1c\x18\xcc\x02\x00\x00\x00\x01'
Expected result
The problem is the LOAD of the scapy packet:
hcidump -> bdaddr 1C:39:47:75:BE:94 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
scapy -> \x94\xbe uG9 \x1c \x18\xcc \x02 \x00\x00 \x00\x01
I suppose it should be -> \x94\xbe \x75 \x47 \x39 \x1c
As you can see the mac address is almost the same, but there are some wrong bytes.
Also i tried with another phone, and the result is the same:
With hcidump the packet is this:
2020-04-09 13:54:27.662396 < HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr B8:C1:11:1F:30:1E ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
With scapy the packet is this:
pkts[0].show()
###[ HCI header ]###
type= Command
###[ HCI Command header ]###
opcode= 0x405
len= 13
###[ Raw ]###
load= '\x1e0\x1f\x11\xc1\xb8\x18\xcc\x02\x00\x00\x00\x01'
Again the load is wrong:
hcidump -> bdaddr B8:C1:11:1F:30:1E ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
scapy -> \x1e0\x1f\x11\xc1\xb8 \x18\xcc \x02 \x00\x00\x00\x01
This time only one byte is wrong! ( this -> 30:1E is represented like this -> \x1e0 )
I am not sure, if this is a real bug, but i think that some how the mac address is not correctly extracted. I hope that i am wrong! As i said the mac address is the same in all of the packet, but not correct!!! I hope this is useful for improving your software, if you need some more details just ask :) !
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the Bluetooth connection with hcitool cc 1C:39:47:75:BE:94, then compare hcidump output with packets captured by bt.sniff(). Trace how the HCI Create Connection command payload is decoded, focusing on the Bluetooth address byte order and missing HCI events. Done means Scapy exposes the same address and relevant event data as hcidump for the reported examples.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100