This is our old Q&A Site. Please post any new questions and answers at

Hi, I'm trying to use dumpcap to do long term captures on a wifi network. Got everything setup right and it records perfectly for the files files with all data decrypted. when it reaches the 300meg mark and then creates the second file it loses the eapol handshake (or more like doesn't remember it), so the second file is just broadcast frames. is there anyway around this so that it keeps the eapol for all files or anything i can do to make this work?

Currently using the below command

dumpcap -i mon0 -a duration:30000 -b filesize:300535 -a files:32 -w \home\msriptide\test

Many thanks guys


asked 07 Nov '16, 13:40

msriptide's gravatar image

accept rate: 0%

second file is just broadcast frames

The presence or absence of EAPOL frames should have nothing to do with whether you are able to capture only broadcast frames or not.

Long term wireless captures like this are painful to work with, one of the reasons being exactly the issue you present.

A couple of options:

  1. Use wired traffic wherever possible. It's not that often we actually need decrypted wireless traces to troubleshoot a problem. Many times, wired traces will do. However, some problems certainly do need decrypted wireless traces. Usually this is related to subtle timing issues between wired and wireless networks, especially with power save behavior due to buffering. Many straight up wireless issues can be looked at with encrypted data - if the issue is 802.11 handling, encrypted data has little to do with this as probing, ACK mechanism, powersave handling, etc., are all in plain text.

  2. If you really need the data, setup a second, sometimes a third, wireless capture of the system to reduce probability that packet loss from capture system will prevent proper analysis.

  3. Setup a separate capture for EAPOL frames, separate from the main capture. Something like this on Windows or the equivalent in Linux or with Omnipeek (dumpcap would be fine too):

C:\tmp>windump -i 1 -s 1600 -w EAPOL -W 200 -C 200 ether proto 0x888e

This way, I can quickly see the EAPOLl frames from the system during the test process and determine if I have all four for decryption. If we don't get them all we can't decrypt, so that's where the duplicate mechanism comes into play: check there too.

  1. As @Amato indicates, strip out the fourway handshake appropriate for the period under review wherever you may have found it (e.g. export specified packet option) and then merge the traces. This usually works, though group keys can be a little tougher as a group rekey is usually encrypted so it may take some work to find them after decryption takes place.

It's a lot of work to manage this slicing of traces and inserting packets.

permanent link

answered 15 Dec '16, 02:53

Bob%20Jones's gravatar image

Bob Jones
accept rate: 21%

edited 15 Dec '16, 02:55

Could you use the mergecap function to combine the files?

For example: mergecap -w c:\temp\mergedfile.pcap c:\temp\inout1.pcap c:\temp\input2.pcap

permanent link

answered 14 Dec '16, 11:01

Amato_C's gravatar image

accept rate: 14%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 07 Nov '16, 13:40

question was seen: 975 times

last updated: 15 Dec '16, 02:55

p​o​w​e​r​e​d by O​S​Q​A