Repository: secdev/scapy

Issue:
rdpcap to read btle pcap file  failed with Raw protocol
**Brief Description**

Use the "rdpcap()" to read a btle pcap file failed while it displayed Raw protocol,but i can get the btle pcap file content correctly in the WireShark.

**Environment**

-   Scapy version: 2.4.0.dev548
-   Python version: 2.7.12
-   Operating System: Ubuntu 16.04 LTS

**How to reproduce**

Interact operations as follow:

(1) scapy
(2) pk = rdpcap("pair.pcap")  // "pair.pcap" file captured by command: ubertooth-btle -f -c pair.pcap
(3) pk[0]

And then i find that displayed:

>>> pk[0]
"<Raw  load='\x00\x00\x18\x00\x93\x00\x00\x006u\x0c\x00\x00b\t\x00\xc5\xc1\x00\x00\xf6\xe2\x98\x00\xd6\xbe\x89\x8e@\x14}9\xd6E\xfcc\x02\x01\x1a\n\xffL\x00\x10\x05\x03\x1c\x15 H\x87\xb0\xf3' |>"
>>>

**Expected result**

Pcap file display in WireShark:
![image](https://user-images.githubusercontent.com/7621109/47798677-d59ae880-dd63-11e8-9fb4-f2eb3ab993fd.png)

**Related resources**
Pcap file:
[pair.zip](https://github.com/secdev/scapy/files/2535054/pair.zip)

**Issues**
How can i do to get the display the fields in the pcap file?Or there is something wrong that i capture the pcap file using ubertooth-btle?

Thanks a lot.


Discussion:
Hi !
I don’t seem to be able to unzip your file. It looks like an incorrect format

Could you check that?
Firstly, Thanks for your reply.
The file is crashed while compressing.And I upload the new file, please have a check.
# unzip  pairNew.zip
[pairNew.zip](https://github.com/secdev/scapy/files/2537358/pairNew.zip)

The DLT of your pcap file is 147.
We use this list https://www.tcpdump.org/linktypes.html
To find the appropriate header. As you will see, it says

> Values in the range 147 through 162 are reserved for private use; if you have some link-layer header type that you want to use within your organization, with the capture files using that link-layer header type not ever be sent outside your organization, you can use one or more these values. No libpcap release will use these for any purpose, nor will any tcpdump release use them, either.

This is why we don’t support it: it varies between usages
I actually wonder how you are getting the file right in wireshark. It does not work for me :/

```bash
gpotter@vmg:~$ tshark -V -r pair.pcap                                               Frame 1: 44 bytes on wire (352 bits), 44 bytes captured (352 bits)                      Encapsulation type: Per-Packet Information header (97)                              Arrival Time: Oct 17, 2018 11:15:32.019579504 CEST                                  [Time shift for this packet: 0.000000000 seconds]                                   Epoch Time: 1539767732.019579504 seconds                                            [Time delta from previous captured frame: 0.000000000 seconds]                      [Time delta from previous displayed frame: 0.000000000 seconds]                     [Time since reference or first frame: 0.000000000 seconds]                          Frame Number: 1                                                                     Frame Length: 44 bytes (352 bits)                                                   Capture Length: 44 bytes (352 bits)                                                 [Frame is marked: False]                                                            [Frame is ignored: False]                                                           [Protocols in frame: ppi:pcap_pktdata:user_dlt:data]                            PPI version 0, 24 bytes                                                                 Version: 0                                                                          Flags: 0x00                                                                             .... ...0 = Alignment: Not aligned                                                  0000 000. = Reserved: 0x00                                                      Header length: 24                                                                   DLT: 147                                                                            Reserved: 36750c00009809002d5ef1791e031b00                                      User encapsulation not handled: DLT=147, check your Preferences->Protocols->DLT_USER    [Expert Info (Warning/Undecoded): User encapsulation not handled: DLT=147, check your Preferences->Protocols->DLT_USER]                                                     [User encapsulation not handled: DLT=147, check your Preferences->Protocols->DLT_USER]                                                                                  [Severity level: Warning]                                                           [Group: Undecoded]                                                          Data (20 bytes)                                                                                                                                                         0000  41 5f 6a ab 0e 0b 07 00 06 00 01 04 00 0d 10 0f   A_j.............            0010  0f 64 b1 81                                       .d..                            Data: 415f6aab0e0b070006000104000d100f0f64b181                                      [Length: 20]                                                                    
```

This isn’t scapy-specific
The PCAP file you provided is not read in Wireshark (2.6.4) either. Which version of Wireshark are you using?
@p-l-  @gpotter2  Sorry for late to answer.
The PCAP file is captured by the Ubertooth One,command as follow:
ubertooth-btle -f -c btsmp.pcap
And i get the 'btsmp' package only into the 'pair.pcap' file with the WireShark.
So i would like to know whether the packages captured by Ubertooth One could not read by scapy?
According to [ubertooh source code](https://github.com/greatscottgadgets/ubertooth/blob/master/host/ubertooth-tools/src/ubertooth-btle.c#L133), the PCAP uses the [PPI format](https://www.ikeriri.ne.jp/download/airpcap/ppi%20header%20format%201.0.9.pdf) that Scapy does not support.
The `-q` flag will write a pcap in another format, that seems easier to implement http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
We can have a look if you can send us another pcap captured using the `-q` flag.
I actually reopened this issue in the first place when I found out we had this in the code

https://github.com/secdev/scapy/blob/87916fda3b7d2de503cafd81623d0a7814ba5679/scapy/layers/bluetooth4LE.py#L308

Making it seems it has worked at some point. It wasnt tested and might have break with the https://github.com/secdev/scapy/blob/master/scapy/layers/ppi.py overhaul (we had 2 concurrent implementations that were merged)

@guedou 

1. Firstly,I try two options to capture btle packages by Ubertooth One, and read the contents.
(1) "-q" option, -q<filename> capture packets to PCAP file (DLT_BLUETOOTH_LE_LL_WITH_PHDR), and the command as follows:
`ubertooth-btle -f - q btle_q.pcap`
And then, using the scapy to read pakcage, i can get tht btle package contents correctly.
(2) "-c" option,-c<filename> capture packets to PCAP file (DLT_PPI), command as follows:
`ubertooth-btle -f - c btle_c.pcap`
I could only get the "Raw" data , and can not find the contents of the btle packages.

@gpotter2 
2. Through the scapy layers(scapy/layers/bluetooth4LE.py), i find that:
[bluetooth4LE](https://github.com/secdev/scapy/blob/master/scapy/layers/bluetooth4LE.py)
So i think that the scapy support the '-q' option of UBertooth One captured.And as you talked,it maybe  some times work well, from my test above (1).
Actually, i am looking forward to the stable scapy for bt or btle package parsed.

Thanks for all your replies,and if any question or necessary test for this issue,please contact me.


[btle_c.zip](https://github.com/secdev/scapy/files/2629003/btle_c.zip)
[btle_q.zip](https://github.com/secdev/scapy/files/2629004/btle_q.zip)


Resolving patch:
diff --git a/scapy/layers/bluetooth4LE.py b/scapy/layers/bluetooth4LE.py
--- a/scapy/layers/bluetooth4LE.py
+++ b/scapy/layers/bluetooth4LE.py
@@ -17,7 +17,7 @@
     PacketListField, X3BytesField, XBitField, XByteField, XIntField, \
     XShortField, XLEIntField, XLEShortField
 from scapy.layers.dot11 import _dbmField
-from scapy.layers.ppi import PPI, addPPIType, PPIGenericFldHdr
+from scapy.layers.ppi import PPI, addPPIType
 
 from scapy.layers.bluetooth import EIR_Hdr, L2CAP_Hdr
 
@@ -153,10 +153,6 @@ def pre_dissect(self, s):
         # move crc
         return s[:4] + s[-3:] + s[4:-3]
 
-    def post_dissection(self, pkt):
-        if isinstance(pkt, PPI):
-            pkt.notdecoded = PPIGenericFldHdr(pkt.notdecoded)
-
     def hashret(self):
         return struct.pack("!L", self.access_addr)
 


Test patch:
diff --git a/test/bluetooth4LE.uts b/test/bluetooth4LE.uts
--- a/test/bluetooth4LE.uts
+++ b/test/bluetooth4LE.uts
@@ -80,3 +80,16 @@ assert a.signal == -75
 assert a.flags == "reference_access_address_valid"
 assert a[BTLE_SCAN_REQ].ScanA == "aa:aa:aa:aa:aa:aa"
 
++ Specific tests after issue GH#1673
+
+= With PPI
+
+pkt = PPI(b'\x00\x00\x18\x00\x93\x00\x00\x006u\x0c\x00\x00b\t\x00\xe1\xcf\x01\x00\xf1\xe3\x92\x00\xd6\xbe\x89\x8e@\x14M\x95P\x16\xfev\x02\x01\x1a\n\xffL\x00\x10\x05\x0b\x1c\x0e\xa86Z\xf0\x04')
+assert BTLE_PPI in pkt.PPIFieldHeaders[0]
+assert BTLE in pkt
+
+= Without PPI
+
+pkt = BTLE_RF(b'\x00\xc6\x80\x00\xd6\xbe\x89\x8e7\x00\xd6\xbe\x89\x8e@\x14\x03g\xa6+\xcbi\x00\x01\x1a\n\xffL\x00\x12E\x03\x18y\x9e\x96\x07\xfa%')
+assert BTLE_RF in pkt
+assert BTLE in pkt