Bug 443 - Net device pcap traces arent consistent with what tcpdump would display
Net device pcap traces arent consistent with what tcpdump would display
Product: ns-3
Classification: Unclassified
Component: devices
All All
: P1 normal
Assigned To: Craig Dowell
: 438 (view as bug list)
Depends on:
Blocks: 505
  Show dependency treegraph
Reported: 2008-12-09 23:07 EST by Craig Dowell
Modified: 2009-03-16 21:49 EDT (History)
3 users (show)

See Also:

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

Note You need to log in before you can comment on or make changes to this bug.
Description Craig Dowell 2008-12-09 23:07:09 EST
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 Tom Henderson 2008-12-19 16:22:10 EST
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 Craig Dowell 2009-02-28 19:37:06 EST
Created attachment 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 Craig Dowell 2009-02-28 19:38:52 EST
*** Bug 438 has been marked as a duplicate of this bug. ***
Comment 4 Mathieu Lacage 2009-03-01 03:39:49 EST
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 Craig Dowell 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

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

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

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