Bugzilla – Bug 241
Trace sources not clearly documented, trace sinks not clearly documented
Last modified: 2008-12-09 22:52:48 EDT
You need to log in before you can comment on or make changes to this bug.
The CSMA device generates receive traces on packets destined for all devices on the channel and then drops all packets not destined for the particular device. The drop trace isn't functioning. Also having all devices log all received packets (even ones destined as unicast to other devices) is strange and inconsistent with other devices. Easy to fix, but means changing pcap traces for all examples / tests that use CSMA.
I have changed the positioning of the trace hooks to generate more reasonable pcap traces, but problems remain. It's too big of a change at this late state on the release to straighten it all out so I am going to reduce the priority instead of marking it as fixed and change the focus to a consistency and documentation issue regarding trace sources, sinks and helpers. In the case of the CSMA device, it seems to me that there should really be low-level (PHY?) trace hooks and higher level trace (MAC?) trace hooks. Right now traces in both places are mixed along with hooks in the transmit queue and one are clearly docuemnted. For example, from the perspective of the pcap tracing, the transmit hook is hit when a packet is dequeued from the transmit queue. In fact, because of backoff and retransmission, the packet may actually get transmitted much later, or even never transmitted and never reported as dropped since only the transmit queue drop events are traced. This needs to be thought through. I.e., what does pcap tracing mean and what events should be actually capture for all of our devices. Are there standard trace hooks that should be in devices, or not, etc.
*** Bug 354 has been marked as a duplicate of this bug. ***