Ethereal-users: Re: [Ethereal-users] HELP:The drawbacks of "Tethereal -V"

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Ching Tung Lo" <g931319@xxxxxxxxxxx>
Date: Mon, 17 Nov 2003 10:59:32 +0800
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxx>
To: "?$B7DF1?(B" <g931319@xxxxxxxxxxx>
Cc: <ethereal-users@xxxxxxxxxxxx>
Sent: Friday, November 14, 2003 5:39 PM
Subject: Re: [Ethereal-users] HELP:The drawbacks of "Tethereal -V"


> On Tue, Nov 11, 2003 at 10:13:16AM +0800, ?$B7DF1?(B wrote:
> > > From: "Guy Harris" <guy@xxxxxxxxxxxx>
> > >
> > > On Nov 9, 2003, at 8:14 PM, $B7DF1(B wrote:
> > >
> > > > I sent 95 packets per seconds to DNS server and use the command
> > > > "Tethereal -V port 53 " to view the detail DNS packets messages.
> > > > I ran for 5 seconds but It just show to Frame 99 and  "1031 packets
> > > > dropped".
> > >
> > > On what operating system are you running Tethereal?
> >
> > I am using Linux RedHat9.0.
>
> What kernel?

   My Linux kernel is 2.4.20-8


> The "packets dropped" count is, on 2.4.x kernels, supposed to come from
> a counter that, at least in 2.4.20, is incremented only for packets that
> pass the capture filter - but you had a capture filter of "port 53",
> sent only 95 packets/second for 5 seconds, which would be 475 packets,
> but it reported that it dropped 1031 packets!

   I am using the tool "queryperf" to produce the DNS query packets.
   So , if  I sent  95 query packets/second for 5 seconds to my
non-recursive DNS server,
   tethereal should  capture 475 query packets and 475 respond packets.
   But the command "tethereal -l -V port 53 " didn't show all detailed
decoded packets on screen.
   It dropped some packets.
   If I redirect the tethereal output to a file  "tethereal -l -V port 53 >
file ",dropped-packets condition will improve.
   If I use window-mode ethereal , no packets be dropped.

> However, you might have a kernel that doesn't have CONFIG_FILTER
> configured in; if so, the capture filtering would be done in libpcap,
> not in the kernel, which means
>
> 1) the kernel is passing *all* packets, not just port 53
>    packets, to libpcap, which means it's spending more CPU time
>    copying, so that there's less CPU time for processing
>    packets, meaning it might drop packets if it doesn't read
>    them fast enough - and more packets are arriving, so it'd
>    have to read them faster than if the filtering were done in
>    the kernel;

   Do you mean that if I recompile the linux kernel to turn on socket
filtering and network packet filtering,
   "tethereal -V " will not drop any packets?




> 2) the count of packets dropped could include packets that
>    aren't port 53 packets.
>
> You might want to check whether your kernel has CONFIG_FILTER enabled:
>
> Socket filtering
> CONFIG_FILTER
>   The Linux Socket Filter is derived from the Berkeley Packet Filter.
>   If you say Y here, user-space programs can attach a filter to any
>   socket and thereby tell the kernel that it should allow or disallow
>   certain types of data to get through the socket.  Linux Socket
>   Filtering works on all socket types except TCP for now.  See the
>   text file <file:Documentation/networking/filter.txt> for more
>   information.
>
>   You need to say Y here if you want to use PPP packet filtering
>   (see the CONFIG_PPP_FILTER option below).
>
>   If unsure, say N.
>
> and, if not, enable it, rebuild the kernel, and use the new kernel.
>