# mergecap -w /dev/stdout file1.pcap file2.pcap file3.pcap | tcpdump -r - -w output.pcap host 192.168.1.10mergecap reads the list of files at the end as input and writes them out to /dev/stdout, where tcpdump reads them in and writes the result to output.pcap after applying the filter (host 192.168.1.10).
Showing posts with label tcpdump. Show all posts
Showing posts with label tcpdump. Show all posts
Friday, October 10, 2014
Use tcpdump to Filter and Merge Multiple pcap Files
The other day I had a couple dozen pcap files (each just under 1 GB in size) that I wanted to filter the traffic of one host out of. A couple different options come to mind - merge the pcap files together and then filter, or filter each pcap separately and then merge the results together. Both of these are pretty sloppy ways of doing this if you don't do it in one line:
Thursday, August 14, 2014
Legacy tcpdump - "Packet size limited during capture"
Was doing some debugging the other day on a legacy system with an older version of tcpdump installed. When I imported to packets to Wireshark in order to better interpret the results - I saw the familiar message "Packet size limited during capture":
It's then I remembered that older versions of tcpdump default to a snaplen of 68 bytes. In order to correct this you need to manually specify a longer snaplen. From the manpage of tcpdump 3.9.4:
![]() |
You never realize there's a problem with a packet capture until after you've finished and shipped it somewhere else for analysis |
-s Snarf snaplen bytes of data from each packet rather than the default of 68 (with SunOS's NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ''[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in. Setting snaplen to 0 means use the required length to catch whole packets.So in order to capture the whole packet, you need to set a snaplen of 0 using the option "-s 0":
~]# tcpdump -i eth0 -n -s 0 host 192.168.1.1This would capture traffic (-i eth0) on the eth0 interface, (-n) not converting host addresses to names, (-s 0) capturing the entire packet, (host 192.168.1.1) where the packet is to/from a host with the IP 192.168.1.1.
Subscribe to:
Posts (Atom)