Hi, I am writing a dissector plugin for Wireshark, which decapsulates an Ethernet frame with an additional tag between src address and type/length field (like 802.1q). I understood about the wtap_encap dissector table. By default (as far as I know) Wireshark reads the link-layer type from the interface (which is usually 1 => Ethernet) and that's the first dissector that it uses. My target is to change the link-layer input type of wireshark to 147 (DLT_USER0) so that my dissector can be the entry point of the process of decapsulation. How can I do that ? I tried to make a crazy pipe tcpdump -l -nvvvXXes0 | od -Ax -tx1 -v - | text2pcap -l 147 - - | wireshark -k -i - The goal of the upper command is to capture (live) packets with tcpdump then use od to hexdump them in the appropriate format for text2pcap which then changes the link-layer type to 147 and pipes that to wireshark. The problem is that text2pcap, for some reason, merges the packets and outputs them to wireshark as 64000 byte packets. Is there any other way of making a live wireshark capture while changing the link-layer type to 147 ? asked 09 Jul '13, 06:50 dvlahovski |
3 Answers:
There are several problems with your command chain. 1.) tcpdump output to od This is what tcpdump writes on my system, if I run it with your parameters (tcpdump -l -nvvvXXes0).
Converting that output with od to hex and then piping it to text2pcap does not work, as you will pipe the hex representation of the ASCII output of tcpdump to text2pcap. This will give totally random results. 2.) Output of tcpdump The output of tcpdump is (unfortunately) not in a format that text2pcap understands (see man page of text2pcap)
Output of tcpdump:
This is what text2pcap needs:
So, you need to reformat the tcpdump output. Here is a small perl script that will reformat the text.
Then run your command like this:
Please report back, if it works. I was not able to test it yet. UPDATE: Basically it (the script) works, but without a dissector for the link-layer type 147, the data makes no sense to wireshark. Regards answered 10 Jul ‘13, 03:13 Kurt Knochner ♦ edited 11 Jul ‘13, 01:02 |
I think the problem is that your hex stream after the od command is just one continuous block of hex data, so text2pcap probably cuts it into the larges slices it can. Have you tried the -m parameter of text2pcak that limits the maximum packet size? I haven't tested if it help, but you might want to check it out. Unfortunately that will probably result in packets of the same size, and not what they originally where, so I guess it will not help that much either. You could also try to get better results by capturing with dumpcap or tshark to get the frame delimiter right, but once again I haven't tried that myself. All in all you're trying some sort of Frankenstein capture maneuver and I'm not sure if it can work at all :-) Maybe changing the link-layer type in the file after capture is complete may be an option? answered 10 Jul '13, 02:05 Jasper ♦♦ |
Try
to read a pcap file {input file} and write out the exact same packet data to a pcap file {output file}, but with a different link-layer header type in the file header. That might also work for pcap-ng files (if you're reading a pcap-ng file, you can leave out the answered 18 Jul '13, 12:23 Guy Harris ♦♦ |
Hi,
Thank you very much for the help !
The script really perfectly does the job. But for the first N packets. I mean that, when I run the command chain, the first time, I got 17 proper packets (with total length of ~2100 bytes) and then it started to print only 16 byte packets. After that, I ran it a second time and then got 64 proper packets (with total size of ~4400 bytes) and then started to output only 16 byte packets again. And it happens every time - from a given point on(undefined, I think, because the byte offset after it happens is different every time) it prints only 16 byte packets. When I changed the link-layer type to 1, to see what’s happening, I saw that it was dissecting the proper packets without a problem. The 16 byte packets ethertype was recognized, but they were (obviously) stated as malformed. Do you have any idea why does this problem occur ?
Best regards and many thanks,
D. Vlahovski
I had the same issue with text2pcap 1.6.9 (Ubuntu). After I upgraded to 1.10.0 the problem was gone.