Re: Request for DLT for new BlueZ Monitor

[Michal Labedzki <michal.labedzki () tieto com>]

On 10 January 2014 01:47, Guy Harris <guy () alum mit edu> wrote:
> On Dec 29, 2013, at 11:21 PM, Michal Labedzki <michal.labedzki () tieto com> wrote:
>
> > Implementation in libpcap is very similar to pcap-bt-linux.c, but:
> > 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.

> > 2. Pseudo header is:
> >    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)

> >    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).

> 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.

> 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
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers