Re: Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR

[Sultan Khan via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Sultan Khan <sultanqasim () gmail com>
>
> Date: Fri, 10 Jul 2020 17:57:19 -0400
>
> Thanks for the feedback, your suggestions do make the specification
> clearer. I edited the specification based on your suggestions, and I also
> clarified the usage of integer bit fields within the Flags field.
>
> Link to the updated version of the spec with the latest changes:
> https://gistcdn.githack.com/sultanqasim/8b6561309f5934f084a0d938ae733b7a/raw/199fb1867642c927f768fe7d67dae2a639acb48e/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
>
> Best regards,
> Sultan
>
> On Fri, Jul 10, 2020 at 3:58 PM Guy Harris <gharris () sonic net> wrote:
>
> > A couple more editorial comments:
> >
> > In the description of the bits in the Flags field, I'd describe the 0x3000
> > bits as "PDU type dependent", and, after they're listed indicate that:
> >
> >         For PDU types other than type 1 (auxiliary advertising), the PDU
> > type dependent field indicates the checked status of the MIC portion of the
> > decrypted packet:
> >
> >                 * 0x1000 indicates the MIC portion of the decrypted LE
> > Packet was checked
> >                 * 0x2000 indicates the MIC portion of the decrypted LE
> > Packet passed its check
> >
> >         For PDU type 1 (auxiliary advertising, the PDU type dependent
> > field indicates the auxiliary advertisement type:
> >
> >                 * 0x0000: AUX_ADV_IND
> >                 * 0x1000: AUX_CHAIN_IND
> >                 * 0x2000: AUX_SYNC_IND
> >                 * 0x3000: AUX_SCAN_RSP
> >
> > I'd redo the last two paragraphs as:
> >
> >         The LE Packet field follows the previous fields. All multi-octet
> > values in the LE Packet are always expressed in little-endian format, as is
> > the normal Bluetooth practice.
> >
> >         For packets using the LE Uncoded PHYs (LE 1M PHY and LE 2M PHY) as
> > defined in the Bluetooth Core Specification v5.2, Volume 6, Part B, Section
> > 2.1, it is represented as the four-octet access address, immediately
> > followed by the PDU and CRC; it does not include the preamble.
> >
> >         For packets using the LE Coded PHY as defined in the Bluetooth
> > Core Specification v5.2, Volume 6, Part B, Section 2.2, the LE Packet is
> > represented as the four-octet access address, followed by the Coding
> > Indicator (CI), stored in a one-octet field with the lower 2 bits
> > containing the CI value, immediately followed by the PDU and the CRC; it
> > does not include the preamble. Packets using the LE Coded PHY are
> > represented in an uncoded form, so the TERM1 and TERM2 coding terminators
> > are not included in the LE packet field.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers