Text2pcap Could Not Be Found

[Roxine Denison]

Asyou know, text2pcap doesn't currently support this data format; however, I have opened a Wireshark bug report so that one day text2pcap may natively support reading data in such a format. Feel free to follow Wireshark Bug 16193 - text2pcap could be enhanced to accept input in other formats for any updates to this enhancement request.

In the meantime, you will either have to write your own script/command(s), find someone to write one for you, or use/modify an existing script/command in order to convert the data into a format readable by text2pcap. To help get you going, I'm providing you with one method that seems to work in my testing. Assuming your output is saved in a dump.in file, you can run the following:

NOTE: I am no sed expert, but there are almost certainly sed experts out there who can probably figure out how to get this to work in 1 pass; I couldn't in the time I was willing to spend on this.

Using the command provided, I was able to convert the data to a format that text2pcap could read and then ran text2pcap -a dump.out dump.pcap to generate a valid pcap file. Running tshark -r dump.pcap generates the following output:

I have a problem with importing a frame from hex dump. When I was trying to import a frame I followed this guide: _html_chunked/ChIOImportSection.html But still it didn't work. I believe that solution is pretty simple and I am just stupid.

I am aware that I have to put in every line of the frame so called offset. This are the numbers which you can see in the article on which I posted a link above. I think that is the problem why wireshark wont accept my frame.

So could you please tell how the offset should looks like for a frame like that ? I would also be very glad for a little guide which would told me how to apply the offsets on every frame, so I would be able to import other frames to the wireshark on my own.

Then open the File -> Import from Hex Dump form, make sure that the field for date format is empty and make sure that the Direction indication field is not checked (if you use 1.x wireshark then also that the Date/time checkbox is not checked). Then use the Browse button to choose the file you've saved, and then press the Import button.

The pcap file must contain information about encapsulation type so that Wireshark would know which dissector to use for each frame as the first one. So if importing a hex dump, you must provide this information manually: in the GUI, there is a drop-down menu for that, if you use the command-line utility text2pcap, you have to use a -l n command line parameter where n is a number representing the encapsulation type. The list of supported encapsulation types is here. Of course the encapsulation type specified must match the actual contents of the packets.

If none of the available encapsulation types matches the one you need, you may use a custom encapsulation type, for which you'll have to specify the dissector through configuration, or you may prefix the packet data with a manually created bytes representing a protocol for which encapsulation exists (such as Ethernet). These may be the same for all packets or you may e.g. want to express transmission direction of the hex-dumped packets by swapping the sender and recipient address in your handcrafted headers.

As for Ethernet II and 802.3 in particular, these two can even peacefully coexist on the same wire, which means that they have to be easily discriminated from one another. In particular, if the binary value of the first two bytes following the two MAC addresses is higher than 1536 (0x600), these whole frame is an Ethernet II one (where these two bytes contain an "ethertype", otherwise as an 802.3 frame (where these two bytes contain the length of the frame). So the pcap (and pcapng) file format uses the same encapsulation type for both and it is up to the application processing the file (Wireshark's "ethernet" dissector in our case) to tell apples from pears.

@grahamb, I would dare to slightly correct you - the offset is not from the beginning of the file but of each packet. And I think there is a bug in the import from hex dump - the last byte of (at least) the last packet is not imported. I even think I have filed that bug some months ago.

I would like to ask you another question. It's really stupid but I do not know how to convert .txt to .pcap. You said that I should use "text2pcap inputfile.txt output.pcap", but I do not know if you meant some online tool for converting files or something else. I tried to search for in on the web bud I did not found specific answer. So I don't know how can I do that, perhaps from within a wire shark ?

text2pcap was the original Wireshark utility for converting hex dumps to capture files, I have a long memory. text2pcap would be used from the command line and is usually installed alongside Wireshark.

after the hexdump of your last (or only) frame, put one more line like this:

0 00

This will add one more frame (of zero size thanks to the bug so not actually imported), making the actual last frame not the last one in the file, so if you then copy-paste more frames into the file, you will not have to think about which one of them was the last one before and thus which one needs to be modified

BTW, as @grahamb has stated somewhere above, much more than a single byte is missing in you hex dump - the IP header says the total size of the IP portion of the frame is 432 bytes whereas the hex dump only contains the first 114 bytes of them.

further in the text, there is another statement, "An offset of zero is indicative of starting a new packet, so a single text file with a series of hexdumps can be converted into a packet capture with multiple packets".

This already implicitly says that the offsets are valid within a single packet, and an explicit confirmation follows in the next paragraphs. But you are the native speaker, so feel free to make it sound more English ;-)

It would be also nice if you could express somehow that the last byte of the last line must be followed by at least a character because is not enough to make text2pcap interpret the last two hex characters before the as a data byte (which @Pascal Quantin considers a feature as per his comment to Bug 12674).

xxd -g 1, hexdump -C, and od -Ax -tx1 -v produce valid this kind of input. There are two are other variables besidespacket bytes that we can add: Packet direction and timestamp. Direction is specified at the beginning of a packet by I (input) or O (output).Timestamp is specified by strftime. While later on, we could specify any timestamp type (like %s for unixtime in seconds).

There are a couple articles out there that describe how to use text2pcap. It is worth mentioning that text2pcap is very picky aboutthe input formatting, so you should try to format your hexdump using linuxfu to match expected input. The Huawai article below hasa list of required formatting.

I worked in WiFi for around 10 year, five first as a tester then as a Linux driver developer. So I got a base on RF but didn't know much about Bluetooth until I started this project. What I learned from those years is that you got to get wireless trace to fully understand issues. I learned more about WiFi doing trace than reading books. Book & spec tell you what the devices are supposed to do. Trace show you the reality!

So my approach to learning Bluetooth was to get some traces first and then analyze them with the help of the Bluetooth core spec. I did try to look online but finding stuff about Classic Bluetooth (BR/EDR) is hard since pretty much everything you will find is about BLE.

With Bluetooth you got basically two ways of tracing. Over the air using some costly hardware or a ubertooth or tracing the HCI communication interface between the Bluetooth stack and the Bluetooth controller.

The controller is a mix of software and hardware handling the very low level of a Bluetooth transmission. The Bluetooth stack implement the higher level of the Bluetooth spec. As an example for ESP32 the software part of the controller is located at -bt-lib it's a closed source library. You really don't want to face bugs in there because you are then at the mercy of the vendor support. The esp-idf provide BlueDroid as the software stack.

For BlueRetro I decided to write my own "minimal" stack talking to the BT controller directly via the ESP32's VHCI interface. My reasoning for doing so was that I knew nothing about Bluetooth and duplicating what I was seeing in the HCI traces directly to the controller looked easier and faster than learning a particular stack API. I felt I would get a more generic knowledge this way. Also early game console controllers don't follow Bluetooth spec/good practice 100% and I felt that a generic stack could limit the project and I didn't want to start hacking into a giant Bluetooth stack code base. I just want reports from a HID device and it should be simple enough I thought back then.

Wireshark got that awesome and little-known feature that allows you to import hex dump and get then analyzed and saved back to pcap format. You simply need to add a hook in your code at the packet RX & TX function and format it as per the text2pcap format.

When debugging a HID device, it is good to have the HCI trace from its own point of view. Most of the time the microcontroller and Bluetooth chip are separate and they are linked via UART using the H4 protocol to pass the HCI packets. This example show a PS3 controller clone that somehow never receive my L2CAP config.

If you got a scope or logic analyzer with enough memory simply use that to get the trace. Otherwise what I do personally is to use an UART cable to sniff the data on my PC. The first step is to still look with the logic analyzer for a stop bit in the middle of a transmission and measure the rate. That PS3 clone controller use 115200 as an example.

3a8082e126