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

I lose data when filtering in a reassembled PDU


Hi all!

I'm trying to filter out a real large pcap file using tshark (I don't want to load that really large file in Wireshark) into a new pcap file. I'm filtering by rating group in Diameter but when it applies the filter over a reassembled PDU it seems that it only filters one of the segments of that PDU because when I open the new file, I find that in those frames belonging to reassembled PDU I only get Data over TCP instead of Diameter. Do you know how can I do to be able to extract all the segments which belong to the PDUs that match the filter?

For example when I filter in the filter tab I don't have the problem but when I extract the frames it found to a new file then I have this data problem :(

Thanks all in advance!

Regards, JC

asked 18 Feb '16, 20:52

JCuadri's gravatar image

accept rate: 0%

What version of Ws are you using? This was a problem in some earlier version. I don't remember when it got fixed but it should work in 1.12 and later.

(18 Feb '16, 21:43) Anders ♦

I'm using 1.12.1, I'll try the "2 pass" solution using tshark and I'll tell you the results.


(19 Feb '16, 13:34) JCuadri

One Answer:


To get tshark to save "dependent" frames (i.e., frames that are required to properly dissect another frame due to, for example, reassembly) you need to give tshark the "-2" option in addition to the display filter.

Think of it this way: normally tshark makes a single pass through the capture file. In the case of reassembly if, for examples, frames 5, 7, and 9 are reassembled into a single upper-layer PDU then tshark won't know that it needs to display (or save) frames 5 and 7 until it's gotten to frame 9, finished the reassembly, and found that frame 9 passes the display filter. By enabling 2 passes tshark can see frames 5 and 7 again this time with the knowledge that they need to be displayed/saved (since they are required for frame 9 to pass the display filter).

answered 19 Feb '16, 06:12

JeffMorriss's gravatar image

JeffMorriss ♦
accept rate: 27%

Thanks Jeff, I'll try that and will share my results.

Regards JC

(19 Feb '16, 13:35) JCuadri

Hi Jeff, I still have a problem. Now it takes all the frames (the ones that pass the filter and the ones that need to be considered for the reassembly of one PDU which passes the filter) into the new file. The problem is that in the new file I've got them separated and Wireshark does not assemble them.

For example I've got in my original file frames 548 and 558 which parts of them are reassembled to create my Diameter protocol in frame 558. When I pass the filter and create a new file (either with "2-pass" tshark or with display filter in graphic interface) those frames are separated in the new file and I can't read Diameter because for Wireshark separated that data doesn't mean anything. I've made a detailed analysis and the problem is that frame 548 depends also on frame 540 and frame 540 depends on frame 520, the problem is that the filter doesn't take those last frames... :( is it a bug or I can do something to solve this? One frame which passes the filter depends on other and this last one on other and like that for five or six times...

(19 Feb '16, 21:10) JCuadri

Ohhhh... This is TCP isn't it?

I'm guessing that, in your example, frame 548 does not start a Diameter PDU (which is then completed in frame 558) but rather frame 548 contains, for example, the end of a PDU and then the start of a new one (which is finished in frame 558)?

The attachment to bug 11144 shows the same behavior.

With TCP the "dependent frame" stuff will only really work when there's a single frame on which the dissected (passed the display filter) frame depends. IIRC I was pretty happy just to get that much working. :-)

And frankly I don't really see a way to get it to work without also including earlier upper-layer PDUs that didn't pass the display filter.

I think to solve your use case you'd really need to use the "export PDUs to file" functionality (which may not be present in 1.12 and is almost certainly not available in tshark--maybe it should be).

(22 Feb '16, 10:24) JeffMorriss ♦

I think we have unfinished code to add it to TShark in gerrit.

(22 Feb '16, 12:21) Anders ♦