Re: Experiencing Packet Loss in High Volume Packet Capture Application using DUMPCAP

[John Powell <jrp999 () gmail com>]

Hi Jeff,

Thanks for your input - sorry about the Microsoft document - for future
reference - what type of document would suggest using to detail such
information?

Up until a few months ago the vendors we looked at were unable to provide
the flexibility of my solution using wireshark.

Now one vendor appears to be able to come some ways to what we need, the
problem is the the vendor can not decode one of our VoIP signalling
protocols because it is proprietary even though Wireshark does a decent
job.  For the SIP protocols the vendor solution will work.

The problem I have is that the RTP packets come from the same gateway for
both SIP and the proprietary protocol so I can not strip them from being
captured.

That being said, I am still interested in any suggestions to may have to
mitigate the issue.

Thanks in advance!

-John

On Mon, Nov 26, 2012 at 2:49 PM, Jeff Morriss <jeff.morriss.ws () gmail com>wrote:

> John Powell wrote:
>
> > Hi Everyone,
> >
> > I am running CentOS 6.3 on a HP 8200 using 3TB WD Green drives using a
> > EXT4 file system.
> >
> > I am using Wireshark 1.8.2 compiled from source.
> >
> > I am using DUMPCAP to rotate and store historical Packet Captures.
> >
> > Whether I capture the packets with Wireshark or view the DUMPCAP created
> > file, I see dropouts in the packets being captured.
> >
> > I tried to turning off journalling but this did not seem to help much:
> >
> > umount /dev/mapper/VolGroup00-LogVol_**Data
> >
> > /sbin/tune2fs -o journal_data_writeback /dev/mapper/VolGroup00-LogVol_**
> > Data
> >
> > /sbin/tune2fs -O ^has_journal /dev/mapper/VolGroup00-LogVol_**Data
> >
> > /sbin/e2fsck -f /dev/mapper/VolGroup00-LogVol_**Data
> >
> >
> > I have a attached a couple of IOGraphs from Wireshark showing the packet
> > drops.
>
> (Note that Microsoft documents aren't the most portable way of sharing...
>  Many of us don't natively have a way to open them. Fortunately, Google
> frequently can...)
>
> The document indicates that your disks are 71% busy writing about 38
> Mbytes/sec and that you're periodically getting periods where almost
> *nothing* is captured and that those periods can be quite long (in one case
> it looks like about 500 msec).
>
> In my mind, you're crossing into the territory where a dedicated capture
> device (which has been engineered for this kind of high-speed capture) is
> needed.  You may be able to make some progress but you'll be reinventing a
> wheel that's already been solved (probably with much effort) by several
> vendors.
> ______________________________**______________________________**
> _______________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org**
> >
> Archives:    http://www.wireshark.org/**lists/wireshark-users<http://www.wireshark.org/lists/wireshark-users>
> Unsubscribe: 
> https://wireshark.org/mailman/**options/wireshark-users<https://wireshark.org/mailman/options/wireshark-users>
>             mailto:wireshark-users-**request () wireshark org<wireshark-users-request () wireshark org>
> ?subject=**unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe