Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- I think so, based on what Chris said previously about those BT related spec pages hosted on his site. The link type list page should probably be updated to point to the tcpdump.org version of the LINKTYPE_BLUETOOTH_BREDR_BB spec. Sultan >> On Jul 13, 2020, at 3:20 PM, Guy Harris wrote: > On Jul 13, 2020, at 8:09 AM, Sultan Khan wrote: > >> Hmm. Chris Kilgour (whiterocker) originally created the spec, and the >> version on tcpdump.org was just a backup copy. Now, Chris has said that he >> is no longer active in the Bluetooth LE sniffing space, and he doesn’t want >> to be in charge of the spec any more. > > Does this also apply to the LINKTYPE_BLUETOOTH_BREDR_BB specification? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- On Jul 13, 2020, at 8:09 AM, Sultan Khan wrote: > Hmm. Chris Kilgour (whiterocker) originally created the spec, and the version > on tcpdump.org was just a backup copy. Now, Chris has said that he is no > longer active in the Bluetooth LE sniffing space, and he doesn’t want to be > in charge of the spec any more. Does this also apply to the LINKTYPE_BLUETOOTH_BREDR_BB specification?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- Pull request submitted: https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/17 On Mon, Jul 13, 2020 at 1:49 PM Sultan Khan via tcpdump-workers < tcpdump-workers@lists.tcpdump.org> wrote: > > > > -- Forwarded message -- > From: Sultan Khan > To: Guy Harris > Cc: Chris Kilgour , tcpdump-workers < > tcpdump-workers@lists.tcpdump.org>, Joakim Andersson < > joakim.anders...@nordicsemi.no>, virtual...@gmail.com > Bcc: > Date: Mon, 13 Jul 2020 13:51:48 -0400 > Subject: Re: [tcpdump-workers] Proposed update to > DLT_BLUETOOTH_LE_LL_WITH_PHDR > Correct, it's a superset of the old version. OK, I'll omit the link then. > > On Mon, Jul 13, 2020 at 1:11 PM Guy Harris wrote: > > > On Jul 13, 2020, at 9:02 AM, Sultan Khan wrote: > > > > > Thanks Chris. I’ll make a pull request to tcpdump-htdocs later today, > > and I’ll include a link to the previous version of the spec as an > > archive.org link to the old one on whiterocker.com. > > > > The new version is a superset of the old version, so that any header that > > conforms to the old version also conforms to the new version, right? > > > > If so, I don't see any need for an archive.org link to the old version. > > > > -- Forwarded message -- > From: Sultan Khan via tcpdump-workers > To: Guy Harris > Cc: Chris Kilgour , virtual...@gmail.com, Joakim > Andersson , tcpdump-workers < > tcpdump-workers@lists.tcpdump.org> > Bcc: > Date: Mon, 13 Jul 2020 13:51:48 -0400 > Subject: Re: [tcpdump-workers] Proposed update to > DLT_BLUETOOTH_LE_LL_WITH_PHDR > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- Correct, it's a superset of the old version. OK, I'll omit the link then. On Mon, Jul 13, 2020 at 1:11 PM Guy Harris wrote: > On Jul 13, 2020, at 9:02 AM, Sultan Khan wrote: > > > Thanks Chris. I’ll make a pull request to tcpdump-htdocs later today, > and I’ll include a link to the previous version of the spec as an > archive.org link to the old one on whiterocker.com. > > The new version is a superset of the old version, so that any header that > conforms to the old version also conforms to the new version, right? > > If so, I don't see any need for an archive.org link to the old version. --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- On Jul 13, 2020, at 9:02 AM, Sultan Khan wrote: > Thanks Chris. I’ll make a pull request to tcpdump-htdocs later today, and > I’ll include a link to the previous version of the spec as an archive.org > link to the old one on whiterocker.com. The new version is a superset of the old version, so that any header that conforms to the old version also conforms to the new version, right? If so, I don't see any need for an archive.org link to the old version.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- Thanks Chris. I’ll make a pull request to tcpdump-htdocs later today, and I’ll include a link to the previous version of the spec as an archive.org link to the old one on whiterocker.com. Cheers, Sultan >>> On Jul 13, 2020, at 11:54 AM, Chris Kilgour wrote: >> On 2020-07-13 8:09 a.m., Sultan Khan wrote: >> Hmm. Chris Kilgour (whiterocker) originally created the spec, and the >> version on tcpdump.org was just a backup copy. Now, Chris has said that he >> is no longer active in the Bluetooth LE sniffing space, and he doesn’t want >> to be in charge of the spec any more. >> Perhaps the spec on tcpdump.org can be the definitive spec now? >> Do you think we should link to the old spec on whiterocker.com, noting it’s >> the previous version? >> Chris - do you have an opinion on this? > > Since my interest has faded over the past several years, I'm okay with > anything the group decides. > >> Thanks, >> Sultan --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- Hmm. Chris Kilgour (whiterocker) originally created the spec, and the version on tcpdump.org was just a backup copy. Now, Chris has said that he is no longer active in the Bluetooth LE sniffing space, and he doesn’t want to be in charge of the spec any more. Perhaps the spec on tcpdump.org can be the definitive spec now? Do you think we should link to the old spec on whiterocker.com, noting it’s the previous version? Chris - do you have an opinion on this? Thanks, Sultan > On Jul 13, 2020, at 3:53 AM, Guy Harris wrote: > > On Jul 10, 2020, at 2:57 PM, Sultan Khan wrote: > >> 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 > > So > >https://www.tcpdump.org/linktypes.html > > currently links to > >http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html > > for LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR. What should it link to now? > > > > > --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- On Jul 10, 2020, at 2:57 PM, Sultan Khan wrote: > 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 So https://www.tcpdump.org/linktypes.html currently links to http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html for LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR. What should it link to now? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- The reason the extra auxiliary PDU type field is needed is that the four-bit auxiliary PDU type is ambiguous and context-dependent for auxiliary PDUs. See Volume 6, Part B, Section 2.3, Table 2.3. The four least significant bits of the advertising PDU header will be 0b0111 for AUX_ADV_IND, AUX_CHAIN_IND, AUX_SYNC_IND, and AUX_SCAN_RSP, so you need extra information to distinguish those. The ADV_EXT_IND PDU can be distinguished from those despite also being 0b0111 because it's not on a secondary advertising channel (ie. not an auxiliary advertisement). Sultan On Fri, Jul 10, 2020 at 6:30 PM Guy Harris wrote: > For an advertising physical channel PDU, it appears that the PDU type is > in the least-significant 4 bits of the PDU header. > > Is that not present in an auxiliary advertising packet? --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- For an advertising physical channel PDU, it appears that the PDU type is in the least-significant 4 bits of the PDU header. Is that not present in an auxiliary advertising packet?--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- 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 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: > > * 0x: 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
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- 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: * 0x: 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
[tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- Hello all, DLT_BLUETOOTH_LE_LL_WITH_PHDR was created close to a decade ago mainly to support Bluetooth LE sniffers. It includes parameters describing sniffer RF capture settings in addition to the BLE link layer packet. It was created in the days of Bluetooth 4.0, when BLE was simpler, without multiple PHY modes, extended advertising, isochronous PDU types etc. This link type is used mainly by Bluetooth LE sniffers and software processing sniffer output, most notably: - Ubertooth: https://github.com/greatscottgadgets/ubertooth - libbtbb (mainly used by Ubertooth): https://github.com/greatscottgadgets/libbtbb - Crackle: https://github.com/mikeryan/crackle - BtleJack (to support Crackle): https://github.com/virtualabs/btlejack - Sniffle (created by me): https://github.com/nccgroup/Sniffle Sniffle is a Bluetooth LE sniffer that supports many of the new features in Bluetooth 5.x, such as multiple PHY modes and extended advertising. Unfortunately, the existing link type definition lacks support for indicating PHY modes and distinguishing types of extended advertising packets. Also, the existing link type lacks means to indicate the direction of a packet when the direction is known; this reduces the effectiveness of advanced packet dissectors, and makes it harder to interpret PCAPs. There does exist another DLT for BLE sniffers (DLT_NORDIC_BLE), and its dissector implementation in Wireshark does support Bluetooth LE features up to v5.1. However the Nordic packet format is rather specific to the design of the Nordic BLE sniffer's firmware, so I'd need to mimic the firmware state machine of the Nordic sniffer if I were to use it. Also, the Nordic DLT is not compatible with existing tooling using DLT_BLUETOOTH_LE_LL_WITH_PHDR such as Crackle. Thus, there is a need to modernize DLT_BLUETOOTH_LE_LL_WITH_PHDR to support Bluetooth 5.x while maintaining backwards and forwards compatibility with existing software. Through discussions with Joakim Anderson (of Nordic) and Mike Ryan (Ubertooth developer), and going through several iterations of proposed protocol updates, I/we came up with this: https://gistcdn.githack.com/sultanqasim/8b6561309f5934f084a0d938ae733b7a/raw/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html I implemented support for it in the Wireshark dissector with this change: https://code.wireshark.org/review/#/c/37142/ The design goals for this change were: 1. Support new features added to the Bluetooth LE specification between versions 4.0 (when this DLT was first defined) and 5.2 (current). 2. Maintain backward compatibility so that old PCAPs, and PCAPs generated using software following the old version of the specification, retain their meanings unchanged under the new version of the specification. 3. Maintain forward compatibility so that PCAPs generated using the new version of the specification can be handled sensibly by software compliant with the old version of the spec (such as current/older Wireshark and Crackle versions). By repurposing unused flag bits, the proposed changes add the following features in a manner compatible with existing software: - Indication of the PHY mode used by the packet - Disambiguation of auxiliary advertisement packet types under BLE5 extended advertising - Indication of data packet direction when it is known (while maintaining support for unknown direction for backwards compatibility) - Disambiguation of broadcast and connected isochronous PDU types from advertising and data PDU types A couple other notes regarding the changes: - Repurposing MIC flag bits 0x3000 for auxiliary advertising is safe because advertising is never encrypted or authenticated. - I'm encoding the PHY in the flag bits rather than the two most significant bits of the RF channel field because some software (eg. existing Wireshark versions) don't mask out the currently unused upper bits of the channel. - I avoided creating an "extended header" flag because it would break forward compatibility (old Wireshark and Crackle versions would misinterpret new PCAPs with an extended header, which would annoy users). - In case future changes to the Bluetooth specification require more fields through an "extended header", the "Reserved for Future Use" PDU type 7 could indicate the presence of an extended header, but we'll cross that bridge when we get there. For now, we can maintain forward compatibility while fully supporting Bluetooth 5.2, and this makes life easier for everyone. Any comments on the proposed changes? What would it take to formalize these changes and have the definition on tcpdump.org updated? https://www.tcpdump.org/linktypes/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html Thanks, Sultan --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpd
Re: [tcpdump-workers] Proposed update to DLT_BLUETOOTH_LE_LL_WITH_PHDR
--- Begin Message --- On Jul 9, 2020, at 1:46 PM, Sultan Khan wrote: > Through discussions with Joakim Anderson (of Nordic) and Mike Ryan (Ubertooth > developer), and going through several iterations of proposed protocol > updates, I/we came up with this: > https://gistcdn.githack.com/sultanqasim/8b6561309f5934f084a0d938ae733b7a/raw/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html In the last paragraph, it says: For packets using the LE Coded PHY as defined in the Bluetooth Core Specification v5.2, Volume 6, Part B, Section 2.2, the Coding Indicator (CI) is represented by the two least significant bits of a dedicated coding indicator byte between the Access Address and PDU. Packets received 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. Perhaps that's a bit clearer if stated as 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 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. Packets received 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
