Bugzilla – Bug 1416
WifiMac traces not being called
Last modified: 2012-04-23 07:48:49 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.
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.
(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
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.