dns.count.answers>3

I really confused because when I try "tshark -r /root/Desktop/a.pcap -T fields -e ip.dst -E header=y -E separator=, >/root/Desktop/em.csv" it saves successfully and I can see ip numbers. It is ok. So according to this part I have a permission to write root/Desktop.

However, when I try "tshark -r /root/Desktop/a.pcap -T fields -e dns.count.answers -Y "dns.count.answers > 3" -E header=y -E separator=, >/root/Desktop/em.csv" with missing E, the file is saved but it is empty.

Also as you said without "> /root/Desktop/x.csv" it works and I can see the numbers.

So there is a problem in the second paragraph but I could not figure out from last night to this morning, if you have any idea please let me know :)

Thank you very much again

when I try

tshark -r /root/Desktop/a.pcap -T fields -e dns.count.answers -Y "dns.count.answers > 3" -E header=y -E separator=, >/root/Desktop/em.csv

with missing E, the file is saved but it is empty.

I'm lost here. No -E is missing on that line, so what did you actually want to say?

When you successfully test the complete command tshark -r /root/Desktop/a.pcap -Y "dns.count.answers > 3" -T fields -e ip.dst -e dns.count.answers -E header=y -E separator=, and then press "cursor up", just add > /root/Desktop/em.csv to the end of the line, and press Enter, is the resulting file still empty? If so, can you use just echo Hello,world > /root/Desktop/em.csv and check the file contents?

If the file is still empty after that, can you delete it and try again? I could imagine the file being owned by another user or open for writing by another application, but I would expect bash to issue an error message in either of these cases.

When I checked em.csv with using nano or any text format it is empty...

Well... how comes you are not scared by the Segmentation fault message? I would assume that the write to the output file is buffered, and that tshark crashes before the buffer is flushed for the first time, so the file remains empty due to that.

I received Segmentation fault message "tshark -r /root/Desktop/a.pcap -T fields -e ip.dst -E header=y -E separator=, >/root/Desktop/em.csv" it saves successfully and I can see ip numbers. It was ok, therefore, I did not consider it deeply.

Do you have any idea how can I fix it?

Thank you.

I would assume that the difference is the number of packets processed until the crash happens. When you do not display-filter the packets, much more lines (actually, all) make it to the output, so the buffer is flushed at least once before the crash and thus the file is not empty. With the display filter in place, so few lines get to the buffer before the crash that no flush takes place so the file remains empty.

What I would do on your place would be to run tshark with no display filter and with add -e frame.number added to the list of fields. The last packet number shown before the crash is then either the one causing the crash or, more likely, the last "safe" one.

This behaviour is usually caused by a bug in a dissector of some protocol, causing it to crash on an illegal (or even legal) field value of that protocol. So you would then use tcpdump -r /root/Desktop/a.pcap -c N -vn, where N is the number of the last packet shown above incremented by 1. The reason is that tcpdump doesn't dissect packets nearly as thoroughly as tshark so the risk that it would crash as well is negligible. This way, you'll get some information about the two suspicious packets as said above (N-1st and Nth) as they will be the last two ones printed.

Now you have two possibilities - the suspicious packet is interesting for you because it is a DNS response, or it is not (remember I don't know whether your input file only contains DNS responses, or the complete traffic on the interface, or something in between these two extremities).

If none of the two suspicious packets is a DNS response, you can use tcpdump's capture filter udp src port 53 to distill only DNS responses from the input file and write the result into another file (which you can then feed to tshark):

tcpdump -r /root/Desktop/a.pcap -w /root/Desktop/a_dns_rsp_only.pcap udp src port 53

(You cannot use tshark -f "udp src port 53" directly because tshark doesn't permit use of capture filters when reading its input from a file).

What to do further depends on the Wireshark version you use:

• If it is a current one (which is 2.4.0 as of writing this), it is worth filing a bug, attaching a pcap file which contains the killer packet, even if the killer packet is not interesting for yourself.
• If it is an old one, the first thing you should consider is an upgrade.

Or you can publish the file with the killer packet, login-free, on some common file-sharing service and put a link to it here.

If you only run tshark -r /root/Desktop/a.pcap, do you still get a "Segmentation fault"?
What version of tshark are you running? Can you post tshark -v output?
Can you post your a.pcap capture file?

Thank you very much for answers, I ll try all of them tomorrow and let you know.