Bug 443 - Net device pcap traces arent consistent with what tcpdump would display
: Net device pcap traces arent consistent with what tcpdump would display
Status: RESOLVED FIXED
: ns-3
devices
: ns-3-dev
: All All
: P1 normal
Assigned To:
:
:
:
: 505
  Show dependency treegraph
 
Reported: 2008-12-09 23:07 EDT by
Modified: 2009-03-16 21:49 EDT (History)


Attachments
Proposed Changes to Tracing in NetDevices (99.45 KB, patch)
2009-02-28 19:37 EDT, Craig Dowell
Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-12-09 23:07:09 EDT
We have lots of trace sources in the various net devices in the system, and we
hook these traces into what we advertize as a pcap trace output.  In some
cases, we just kindof fake it.  For example, in the CSMA device the transmit
event is hooked into the transmit queue Enqueue event, which can give
misleading results.  This situation should really have a dedicated low level Tx
hook symmetric with Rx.

If we're going to advertise pcap traces, they should really work like one would
expect -- consistently across the devices.
------- Comment #1 From 2008-12-19 16:22:10 EDT -------
Craig and I agreed to the following action plan:

   1) fix known trace hook issues discovered in Csma (bug 438)
      - some drops in Csma not being traced
      - there is no available low-level trace hook for Csma
   2) determine where a trace hook would live in each device to correspond to a
real system's tcpdump, and make sure that our devices have such a hook (which
may require adding a few more hooks)
   3) cut over existing default Helpers to use the tcpdump equivalents
   4) ask for review/merge on the list
   5) consider, after that, whether it makes sense for a new TcpdumpHelper of
some sort that may be more aligned with the tcpdump program
------- Comment #2 From 2009-02-28 19:37:06 EDT -------
Created an attachment (id=393) [details]
Proposed Changes to Tracing in NetDevices

Significant changes to tracing in all non-bridge net devices.

1) Splits tracing into MAC-level and PHY-level traces for all devices;
2) Adds missing drop traces;
3) Adds "Sniffer" and "PromiscSniffer" trace hooks to do tcpdump-like traces;
4) Sniffer hooks now fire at the correct times;
4) Updates helpers to hook new sources.

Note:  Most devices are simple enough that everything is available in one
place.  Wifi is different.  The Sniffer hook in the wifi device provides
Ethernet frames for simple tracing and lives in WifiMac with the rest of the
MAC-level trace sources.  Sniffer is available using Pcap calls in the
WifiHelper.  The PromiscSniffer hook in the wifi device provides all of the
low-level wifi packets and lives in WifiPhy with all of the PHY-level trace
sources.  PromiscSniffer is available using Pcap calls in the
YansWifiPhyHelper.
------- Comment #3 From 2009-02-28 19:38:52 EDT -------
*** Bug 438 has been marked as a duplicate of this bug. ***
------- Comment #4 From 2009-03-01 03:39:49 EDT -------
Ok, I looked at the wifi patches (generated with hg diff -r 4252 -r tip
src/devices/wifi from craigdo/ns-3-traces):

1) You can't just add a tx completed event in MacLow. The whole codebase was
designed to not use a tx completed event to 'optimize' that event. If we find
out that we really need to have a tx completed event for tracing purposes,
then, we have to restructure entirely the codebase because a lot of code is
there just to work without a tx completed event so, if there is one, a lot of
code must disappear.

2) In wifi-mac.h: please, don't make the traces protected: if you need to
trigger them from subclasses, use a protected Notify method. The same goes for
wifi-phy.h.

3) WifiNetDevice::SniffPacket ?? You are making an extra copy of the packet
just for tracing, even if there are no connected trace sinks ? This really does
not look like a good idea because it is emulating something really stupid/bad
from linux (which, incidentely, I believe got fixed in recent wifi stacks) and
because its performance cost is a bit horrid.

To summarize, 2) appears easily fixable, the part of 3) which makes use of an
ethernet header for tracing looks like a really, _really_ bad idea, and 1)
worries me because it would be a lot of work to adjust the current codebase to
the presence of a tx completed event.


Sorry for not sounding too enthusiastic.
------- Comment #5 From 2009-03-11 03:02:11 EDT -------
From list mail, suggesting a policy

1) There is a set of suggested trace sources for net devices.  These are
currently found in the repo I mentioned and should be documented in the
manual.

2) Implementing the complete set of suggested trace sources in a net device
is not a requirement.  A device author may pick a subset of these sources to
implement.

3) The net device author should document what trace sources are implemented
and the state the packets are in when they come out of the trace source.
For example, raw IP, ethernet header, llc/snap, dix, p2p, wifi, etc.

4) A net device author should implement a PromiscSniffer trace source to
allow tcpdump-like functionality in helpers to be called a "standard" net
device; but you are always allowed to do whatever you think is right on your
own time.

In furtherance of this policy I did the following:

1) Remove the objectionable Sniffer (Ethernet frame) and tx complete trace
sources from the wifi device;

2) Remove the unused rx start trace sources from the csma and point-to-point
devices;

3) Remove the non-promiscuous sniffer helper code from the wifi-helper and
leave yans-wifi-phy hooked to the promisc sniffer;

4) Adding PromiscSniffer (tcpdump) functionality to the various net devices.

5) Changing the documented examples to use promiscuous sniffers as if someone
were doing tcpdump on a real net.

Changes queued for review/push in craigdo/ns-3-tracing