Ethereal-users: Re: [Ethereal-users] Duplicate packets captured in local machine.

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

Date: Wed, 7 Apr 2004 12:48:22 -0700
On Tuesday, April 06, 2004 10:42 PM, Guy Harris wrote:
> On Mon, Apr 05, 2004 at 02:51:36PM -0700, Chau Dang wrote:
> > I got a little annoying problem.  When I run Ethereal on my PC, it
captures
> > packets sent from the PC duplicatedly with different time stamp.  And I
know
> > that this is Ethereal problem because I used other packet capture
utilities
> > and that problem does not show up.
>
> What other packet capture utilities did you use?
>
> If, for example, this is Windows, and the other utilities are
> non-WinPcap-based utilities, it might be a WinPcap problem - in that
> case, you'd have to test with WinDump or Analyzer or Packetyzer, which
> are also WinPcap-based, to see if it's a WinPcap problem or a problem
> specific to Ethereal.

I'm betting that the observation Chau Dang has made (about receiving
transmitted packets multiple times) is a "feature" of the NIC driver that is
being used on his Windows system.

I say this based on my experience with an application I support.  This
application uses WinPcap to both send and receive raw ethernet frames.  We
have observed that on some platforms (various Unix and windows), that the
packet stream we get through libpcap (in promiscuous mode), will contain 0,
1 or even 2 copies of every frame that is transmitted by the local system.
Our application tolerates this by testing the environment upon startup and
counting the "reflections" of known test packets we initially send.  Things
subsequently proceed with the knowledge of how to deal with transmitted
duplicates.  In general, on Unix/unix-like hosts we see 0 reflections, and
on Windows, we usually see 1 reflection, and sometimes (depending on the
NIC+Driver being ), we see 2 reflections.  The Unix/Unix-like reflection
count is usually 1, when the interface we're using is a bridge device
constructed by locally available kernel bridging.

So, another question for Chau Dang, is:

Does he see the same "behavior" on other systems which have different
vendor's NIC cards, or, on his system if he uses a different vendor's NIC?

Upgrading to the latest NIC driver from his chosen vendor "may" fix his
problem.

- Mark Pizzolato