Request for DLT for new BlueZ Monitor

[Michal Labedzki]

Hello,

It seems that in BlueZ 5 there is no interface provided for better
user experience. Let call it "monitor" and it is used for capture all
Bluetooth adapter in the same time within information about adding new
adapter or delete existing one (there are special opcodes for that
[separated packets]).
Use case (I think it should in simple way show reason/usage for that):
1. Start Wireshark.
2. Select only one available interface: let call it "bluetoothmon"
3. Start capture.
4. Insert two dongle.
5. Generate traffic.
6. Remove one dongle.
...

This interface should never fail like existing libpcap implementation
for Bluetooth for Linux (remove USB dongle == [Wireshark] fail).

Implementation can based on: BlueZ 5 "monitor" tool:
http://git.kernel.org/cgit/bluetooth/bluez.git/tree/monitor
You can see function "open_socket" in
http://git.kernel.org/cgit/bluetooth/bluez.git/tree/monitor/control.c

One advantage of new bluetoothmon is it allow to capture early command
while device is initialising (bluetooth0, etc. does not have it)

DLT may have name DLT_BLUETOOTH_BLUEZ5_MONITOR, feel free to change it.

BlueZ community extent BTSNOOP capture file-format to support multiple
interfaces too.(specially for new "monitor" format)
--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN

[Michal Labedzki]

Hello again,

I think the best name for this is DLT_BLUETOOTH_LINUX_MONITOR, because
this is Linux kernelspace, not BlueZ userland.

By the way: I have completed implementation for new interface called
bluetooth-monitor, based on this DLT. Please let me know when I can
send patch on github for inclusion (as I know I should do that after
you assign DLT value)

Technical info:
1. Bluetooth Linux Monitor use psedoheader to provide Opcode and
Adater Id which are required to correctly dissect payload (like
Bluetooth H4 with pseudoheader)
--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN

[Guy Harris]

Post by Michal Labedzki
1. Bluetooth Linux Monitor use psedoheader to provide Opcode and
Adater Id which are required to correctly dissect payload (like
Bluetooth H4 with pseudoheader)

What is the detailed format of the pseudo-header, and what is the payload that follows it?

[Michal Labedzki]

Hello,

You can see code in Wireshark side (great example, very similar, but
this is only support for capture file changes):
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=12394

Implementation in libpcap is very similar to pcap-bt-linux.c, but:
1. There is only one interface, let call it bluetooth-monitor
2. Pseudo header is:
guint16 adapter_id;
guint16 opcode;

It based on btsnoop header (this two variables are in one 32 bit field
called "flags")

3. Socket changes from
addr.hci_family = AF_BLUETOOTH;
addr.hci_dev = handlep->dev_id;
addr.hci_channel = HCI_CHANNEL_RAW;

to:
addr.hci_family = AF_BLUETOOTH;
addr.hci_dev = HCI_DEV_NONE;
addr.hci_channel = HCI_CHANNEL_MONITOR;

4. "Direction" (frame) based on "opcode"
, timestamps got from socket "SCM_TIMESTAMP".

5. Implementation from libpcap is ready, maybe you want to see it?

Post by Guy Harris

Post by Michal Labedzki
1. Bluetooth Linux Monitor use psedoheader to provide Opcode and
Adater Id which are required to correctly dissect payload (like
Bluetooth H4 with pseudoheader)

What is the detailed format of the pseudo-header, and what is the payload that follows it?

--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN

[Guy Harris]

Post by Michal Labedzki
1. There is only one interface, let call it bluetooth-monitor

I.e., it's like the "any" device".

Post by Michal Labedzki
guint16 adapter_id;

So that presumably indicates on which physical adapter the packet was sent or received.

Post by Michal Labedzki
guint16 opcode;

I infer from

+static const value_string opcode_vals[] = {
+ { 0x00, "New Index" },
+ { 0x01, "Delete Index" },
+ { 0x02, "HCI Command Packet" },
+ { 0x03, "HCI Event Packet" },
+ { 0x04, "ACL Tx Packet" },
+ { 0x05, "ACL Rx Packet" },
+ { 0x06, "SCO Tx Packet" },
+ { 0x07, "SCO Rx Packet" },
+ { 0x00, NULL }

in the Wireshark patch that those are the possible opcode values. The HCI spec describes the packet types as

HCI Command Packet
HCI ACL Data Packet
HCI Synchronous Data Packet
HCI Event Packet

so presumably "ACL Tx Packet" and "ACL Rx Packet" are HCI ACL Data Packets transmitted and received by the host, respectively, and "SCO Tx Packet" and "SCO Rx Packet" are HCI Synchronous Data Packets transmitted and received by the host, respectively. (Presumably HCI Command Packets are always transmitted by the host and HCI Event Packets are always received by the host.)

Is what *follows* the pseudo-header just a regular HCI packet, except for "New Index" and "Delete Index"?

Does "New Index" mean "here's a new interface", with adapter_id being the adapter ID of the new interface, and with the payload being, as inferred from

+ case 0x00: /* New Index */
+ proto_tree_add_item(hci_mon_tree, hf_bus, tvb, offset, 1, ENC_NA);
+ offset += 1;
+
+ proto_tree_add_item(hci_mon_tree, hf_type, tvb, offset, 1, ENC_NA);
+ offset += 1;
+
+ offset = dissect_bd_addr(hf_bd_addr, hci_mon_tree, tvb, offset);
+
+ proto_tree_add_item(hci_mon_tree, hf_name, tvb, offset, 8, ENC_NA | ENC_ASCII);
+ offset += 8;
+
+ break;

having a 1-byte interface bus value from the set implied by

+static const value_string bus_vals[] = {
+ { 0x00, "BR/EDR" },
+ { 0x01, "AMP" },
+ { 0x00, NULL }
+};

followed by a 1-byte interface type value from the set implied by

+static const value_string type_vals[] = {
+ { 0x00, "Virtual" },
+ { 0x01, "USB" },
+ { 0x02, "PC Card" },
+ { 0x03, "UART" },
+ { 0x04, "RS232" },
+ { 0x05, "PCI" },
+ { 0x06, "SDIO" },
+ { 0x00, NULL }
+};

followed by a byte-reversed MAC address for the interface as implied by

+ offset = dissect_bd_addr(hf_bd_addr, hci_mon_tree, tvb, offset);

and the code of dissect_bd_addr(), followed by an 8-byte ASCII string for the interface name, and does "Delete Index" mean "this interface disappeared", with adapter_id being the adapter ID of the interface, and with no payload, as implied by

+ case 0x01: /* Delete Index */
+ /* No parameters */
+
+ break;

[Michal Labedzki]

Post by Guy Harris

Post by Michal Labedzki
1. There is only one interface, let call it bluetooth-monitor

I.e., it's like the "any" device".

"Any Bluetooth Devices", but not the same as "all existing bluetooth
interfaces in libpcap + new/delete interface packets". Timestamps is
handled differently.

Post by Guy Harris

Post by Michal Labedzki
guint16 adapter_id;

So that presumably indicates on which physical adapter the packet was sent or received.

Yes, but please remember that "adapter_id" and "opcode" are please in
BTSNOOP format header, not payload (in the other side is HCI H4 with
packet type byte in payload section)

Post by Guy Harris

Post by Michal Labedzki
guint16 opcode;

I infer from
+static const value_string opcode_vals[] = {
+ { 0x00, "New Index" },
+ { 0x01, "Delete Index" },
+ { 0x02, "HCI Command Packet" },
+ { 0x03, "HCI Event Packet" },
+ { 0x04, "ACL Tx Packet" },
+ { 0x05, "ACL Rx Packet" },
+ { 0x06, "SCO Tx Packet" },
+ { 0x07, "SCO Rx Packet" },
+ { 0x00, NULL }
in the Wireshark patch that those are the possible opcode values. The HCI spec describes the packet types as
HCI Command Packet
HCI ACL Data Packet
HCI Synchronous Data Packet
HCI Event Packet
so presumably "ACL Tx Packet" and "ACL Rx Packet" are HCI ACL Data Packets transmitted and received by the host, respectively, and "SCO Tx Packet" and "SCO Rx Packet" are HCI Synchronous Data Packets transmitted and received by the host, respectively. (Presumably HCI Command Packets are always transmitted by the host and HCI Event Packets are always received by the host.)

Ok, but "opcode" provide direction information too. So there is need
to have "direction" and "packet type" in pseudoheader or let follow
existing format provided by Linux kernel (monitor socket).

Post by Guy Harris
Is what *follows* the pseudo-header just a regular HCI packet, except for "New Index" and "Delete Index"?

Yes, but before "New/Delete Index" is pseudoheader too.

Post by Guy Harris
Does "New Index" mean "here's a new interface", with adapter_id being the adapter ID of the new interface, and with the payload being, as inferred from
+ case 0x00: /* New Index */
+ proto_tree_add_item(hci_mon_tree, hf_bus, tvb, offset, 1, ENC_NA);
+ offset += 1;
+
+ proto_tree_add_item(hci_mon_tree, hf_type, tvb, offset, 1, ENC_NA);
+ offset += 1;
+
+ offset = dissect_bd_addr(hf_bd_addr, hci_mon_tree, tvb, offset);
+
+ proto_tree_add_item(hci_mon_tree, hf_name, tvb, offset, 8, ENC_NA | ENC_ASCII);
+ offset += 8;
+
+ break;
having a 1-byte interface bus value from the set implied by
+static const value_string bus_vals[] = {
+ { 0x00, "BR/EDR" },
+ { 0x01, "AMP" },
+ { 0x00, NULL }
+};
followed by a 1-byte interface type value from the set implied by
+static const value_string type_vals[] = {
+ { 0x00, "Virtual" },
+ { 0x01, "USB" },
+ { 0x02, "PC Card" },
+ { 0x03, "UART" },
+ { 0x04, "RS232" },
+ { 0x05, "PCI" },
+ { 0x06, "SDIO" },
+ { 0x00, NULL }
+};
followed by a byte-reversed MAC address for the interface as implied by
+ offset = dissect_bd_addr(hf_bd_addr, hci_mon_tree, tvb, offset);
and the code of dissect_bd_addr(), followed by an 8-byte ASCII string for the interface name, and does "Delete Index" mean "this interface disappeared", with adapter_id being the adapter ID of the interface, and with no payload, as implied by
+ case 0x01: /* Delete Index */
+ /* No parameters */
+
+ break;

Yes, "New Index" and "Delete Index" are involved to start capturing as
early as possible. This is great improvement comparing to existing
solution (drops some early packets used to make up bluetooth
interface)

Please review my libpcap implementation of new interface:
https://github.com/MichalLabedzki/libpcap/commit/1fc3d06f1362a50925fc618470f25d9d6c0e5408

If you need clarification, please let me know.
--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN

[Guy Harris]

Post by Michal Labedzki
I think the best name for this is DLT_BLUETOOTH_LINUX_MONITOR, because
this is Linux kernelspace, not BlueZ userland.

OK, LINKTYPE_BLUETOOTH_LINUX_MONITOR and DLT_BLUETOOTH_LINUX_MONITOR have been assigned the value 254.

[Chris Kilgour]

I'd like to suggest that "struct _pcap_bluetooth_monitor_header" is too generic a name when this header only applies to the internal workings of an operating system's HCI and adapter-lifetime traffic.

There are other forms of bluetooth monitoring that are not OS-specific nor even cover HCI. For example open-source sniffers like ubertooth and gr-bluetooth capture at the RF level. It's likely that a DLT allocation request will be forthcoming for capturing bluetooth over-the-air [1].

[1] https://github.com/greatscottgadgets/ubertooth/wiki/Bluetooth-Captures-in-PCAP

Chris Kilgour

[Michal Labedzki]

Post by Chris Kilgour
I'd like to suggest that "struct _pcap_bluetooth_monitor_

header" is too generic a name when this header only applies to the
internal workings of an operating system's HCI and adapter-lifetime
traffic.

Ok, "struct _pcap_bluetooth_linux_monitor_header" is ok?
But this is for second phase. There is need to have new DLT first.

By the way:
According to [1] "supplements DLT_BLUETOOTH_LE_LL which already exists
but is not used" - is it truth? Wireshark already use it in "btle"
dissector.

Post by Chris Kilgour
I'd like to suggest that "struct _pcap_bluetooth_monitor_header" is too generic a name when this header only applies to the internal workings of an operating system's HCI and adapter-lifetime traffic.
There are other forms of bluetooth monitoring that are not OS-specific nor even cover HCI. For example open-source sniffers like ubertooth and gr-bluetooth capture at the RF level. It's likely that a DLT allocation request will be forthcoming for capturing bluetooth over-the-air [1].
[1] https://github.com/greatscottgadgets/ubertooth/wiki/Bluetooth-Captures-in-PCAP
Chris Kilgour
_______________________________________________
tcpdump-workers mailing list
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN

[Michal Labedzki]

It seems that new bluetooth DLT will be similar to existing LLCP:
http://www.tcpdump.org/linktypes/LINKTYPE_NFC_LLCP.html

Adapter Number -> Adapter Id (2 ocetets, network order)
Flags -> Opcode (2 octets, network order)
Payload -> Payload


Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN

[Michal Labedzki]

Hello,

Can I help you with something? (aka ping). Can I do Pull Request(s)?


Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN

[Michal Labedzki]

Ping.
--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation

Product Development Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN