Bug 1416

Summary:	WifiMac traces not being called
Product:	ns-3	Reporter:	sayandev
Component:	wifi	Assignee:	Nicola Baldo <nicola>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ns-bugs, ruben, tjkopena, tomh
Priority:	P5
Version:	ns-3.13
Hardware:	All
OS:	All

Description sayandev 2012-04-20 15:38:44 UTC

I am new to ns3 as well, and I am seeing exactly the same thing with this
same example/stats/wifi-example-sim.cc script on ns-3.13 on both a Linux
(CentOS 5.7) machine and a Mac desktop (running Snow Leopard). Typing the
command
./waf --run example/stats/wifi-example-sim
gives no errors and everything appears to run. However, the results file looks like:

run run-50-1
attr experiment "wifi-distance-test"
attr strategy "wifi-default"
attr measurement "50"
attr description ""
attr "author" "tjkopena"
scalar . measurement "50"
scalar node[0] wifi-tx-frames 0
scalar node[1] wifi-rx-frames 0
scalar node[0] sender-tx-packets 30
scalar node[1] receiver-rx-packets 0
statistic node[0] tx-pkt-size
field count 30
field sum 1920
field mean 64
field min 64
field max 64
scalar . delay-count 0

Note that it counts wifi-tx-frames and
wifi-rx-frames to be both 0, when they should be 30. Both of these use
callbacks connected to the built-in trace sources of ns3, with path
"/NodeList/0/DeviceList/*/$ns3::wifiNetDevice/Mac/MacTx" for the
wifi-tx-frames and "/NodeList/1/DeviceList/*/$ns3::WifiNetDevice/Mac/MacRx"
for the wifi-rx-frames counters. I suspect something is wrong with the
callbacks, causing them not to be called at all, but this appears to be the
right syntax, judging by other usage I found in the codebase. Any
help/explanation would be much appreciated.
On the other hand, the counter for sender-tx-packets uses a custom-defined
callback connected to a custom-defined trace source for the Sender class in
wifi-example-apps.cc|h and it appears to count the correct number (30) of
packets transmitted. Then again, the counter for receiver-rx-packets,
which is directly set by the Receiver class in wifi-example-apps.cc|h is
also not updated, and I have no way to explain this. Again, any help would
be greatly appreciated.

A search of previously filed bug reports yielded nothing, except for 505 and 563, both of which are said to be fixed now.

Comment 1 Tom Henderson 2012-04-21 17:45:42 UTC

First, thank you for a well written bug report.

The problem is that the WifiMac trace sources are not being called by the model anymore. There are a number of "Notify()" methods defined that are hooked to these callbacks. However, it seems that these methods are no longer called (perhaps dropped in the past when Wifi model was refactored). We don't have any test coverage to detect this, apparently.

I am going to rename this bug report and reassign to WiFi. We need to audit these traces in WifiMac:

MacTx: A packet has been received from higher layers and is being processed in preparation for queueing for transmission.
MacTxDrop: A packet has been dropped in the MAC layer before being queued for transmission.
MacPromiscRx: A packet has been received by this device, has been passed up from the physical layer and is being forwarded up the local protocol stack. This is a promiscuous trace,
MacRx: A packet has been received by this device, has been passed up from the physical layer and is being forwarded up the local protocol stack. This is a non-promiscuous trace,
MacRxDrop: A packet has been dropped in the MAC layer after it has been passed up from the physical layer.

and make sure they are called by the subclasses, and put in some test code to cover these trace sources. It would probably help to go back to the point in time when these were added, to see what point in the Wifi stack they were calling something, and then find the corresponding places in the current code.

Comment 2 Nicola Baldo 2012-04-23 07:44:25 UTC

(In reply to comment #1)
> First, thank you for a well written bug report.
> 
> The problem is that the WifiMac trace sources are not being called by the model
> anymore.  There are a number of "Notify()" methods defined that are hooked to
> these callbacks.  However, it seems that these methods are no longer called
> (perhaps dropped in the past when Wifi model was refactored).  We don't have
> any test coverage to detect this, apparently.
> 

Actually it seems to me that the Notify() methods are called from WifiNetDevice, e.g.:

bool
WifiNetDevice::SendFrom (Ptr<Packet> packet, const Address& source, const Address& dest, uint16_t protocolNumber)
{
  [snip]
  m_mac->NotifyTx (packet);


and I think that's the correct place to fire the trace to behave like said in the trace description. The names "MacTx" etc. where chosen to be consistent with other models, please see this changeset:
http://code.nsnam.org/ns-3-dev/rev/fec2f830d015

Comment 3 Nicola Baldo 2012-04-23 07:48:49 UTC

changeset:   7861:8e2308aaeab4

turns out it was just a stupid bug in wifi-example-sim, the remote address of the application was not set properly, and the packet did not even reach the WifiNetDevice for transmission.