| Bug ID |
10859
|
| Summary |
Bluetooth Low Energy: Advertisement packet parsing is working in a strange way
|
| Product |
Wireshark
|
| Version |
1.12.2
|
| Hardware |
x86
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Normal
|
| Priority |
Low
|
| Component |
Capture file support (libwiretap)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 13393 [details]
BLE advertisement packet
Build Information:
Version 1.12.0rc3 (Git Rev Unknown from unknown)
Copyright 1998-2014 Gerald Combs <[email protected]> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 3.10.8, with Cairo 1.13.1, with Pango 1.36.3, with
GLib 2.40.0, with libpcap, with libz 1.2.8, without POSIX capabilities, without
libnl, without SMI, with c-ares 1.10.0, without Lua, without Python, without
GnuTLS, without Gcrypt, without Kerberos, without GeoIP, without PortAudio,
with
AirPcap.
Running on Linux 3.13.0-27-generic, with locale en_US.UTF-8, with libpcap
version 1.5.3, with libz 1.2.8, without AirPcap.
Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz
Built using gcc 4.8.2.
--
For some reason Wireshark fails to correctly parse advertisement packets on
Bluetooth Low Energy, if the advertisement packet contains "Service Data" field
with "Flags" Fields. Might fail with other types also (not only "Service
Data").
The problem is in the packet length. The packet in a advertisement payload
consists of (in this order):
Length, Type, Type dependent data
For "Service Data" it looks like this:
Bytes: 1 2 3 4 ..
Length | << Service Data >> | Service UUID | (Data)
In my case, I have defined that length is 4. << Service Data >> type will take
one byte (constant 0x16), Service UUID will take 2 bytes and data 1 byte. 1 + 2
+ 1 is 4 so I should be right? And I'm pretty sure also that the type field
must be included in the length field. I might be wrong there but I read it from
a book. Where Wireshark behaves oddly is that it thinks the length is 5, not 4
which results in "malformed packet". Picture shows the situation better than I
can explain. I can also read the advertisement packet perfectly correct with
other BLE debugging tool.
I'm pretty sure it is problem in Wireshark. I may have also misunderstood the
Bluetooth 4.x core definition
You are receiving this mail because:
- You are watching all bug changes.