Bugzilla – Bug 505
WifiNetDevice::Rx trace is also called for overheard frames
Last modified: 2009-03-20 23:12:25 EDT
You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=382) [details] Change the position of rxLogger As discussed in: http://groups.google.com/group/ns-3-users/browse_thread/thread/b3a5c0863a19d556, the Rx trace of WifiNetDevice is invoked even when the L2 layer just _sees_ a frame, e.g. a frame directed to some other host. This happens even when the promiscuous mode is disabled. I would expect the Rx trace source to be invoked only when the L2 receives a frame that is to be forwarded to upper layers, i.e. it is either broadcast, multicast or unicast and directed to the current host. The attached patch would make the actual behavior of the Rx trace closer to its name. Additionally, a new trace (say, "FrameSeen") could be added in the position where currently m_rxLogger is called.
waiting for craig's tracing patch first.
I believe that craig's latext patch did not improve the situation for you, francesco, right ? Can you confirm that the latest code does not do what you were expected ?
(In reply to comment #2) > I believe that craig's latext patch did not improve the situation for you, > francesco, right ? Can you confirm that the latest code does not do what you > were expected ? > Mathieu, if I understand correctly, this was removed from the tracing patch because you did not want to see the packet copy there. Presently, there is a non-promiscuous sniff trace source that is commented out-- are we going to leave it that way and ask users interested in that trace source to uncomment it?
(In reply to comment #3) > (In reply to comment #2) > > I believe that craig's latext patch did not improve the situation for you, > > francesco, right ? Can you confirm that the latest code does not do what you > > were expected ? > > > > Mathieu, if I understand correctly, this was removed from the tracing patch > because you did not want to see the packet copy there. Presently, there is a > non-promiscuous sniff trace source that is commented out-- are we going to > leave it that way and ask users interested in that trace source to uncomment > it? > 1) If there is a piece of commented code, I am not aware of it and I missed it during my code review. 2) What francesco wants is what I think craig called a 'sniff' trace but francesco does not care about the extra ethernet header craig wanted to add there so, francesco would be happy with an extra trace which does not try to add an ethernet header and that should trivial to add to the current codebase. I guess that we should not name it 'sniff' to avoid confusion with craig's own traces but, I really don't care personally: I don't really see the point of this whole 'tracing must be uniform' thing. Basically, to summarize, from the POV of francesco, the current code is far from an improvement since it removes the rx trace source from wifi-net-device.cc and thus makes it harder for him to get what he wants.
Doesn't the ns3::WifiMac::MacRx trace source provide exactly the kind of trace the bug report asks for? According to the doxygen: 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. Compare with the original comment: > I would expect the Rx trace source to be invoked only when the L2 receives a > frame that is to be forwarded to upper layers, i.e. it is either broadcast, > multicast or unicast and directed to the current host.
> 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. > Compare with the original comment: >> I would expect the Rx trace source to be invoked only when the >> L2 receives a frame that is to be forwarded to upper layers, >> i.e. it is either broadcast, multicast or unicast and directed >> to the current host. MacRx does the same thing that the source formerly known as m_rxLogger. The idea was that MacRx got hit on all the packets. Sniffer had the filtering done that Francesco wanted. Writing a Sniffer trace in the current highly modular wifi became way more painful and nasty than anyone wanted, so the Sniffer was removed (not commented out). This leaves wifi twisting in the wind with no Sniffer trace and no trace for PACKET_HOST packets. Right now the PACKET_HOST, PACKET_OTHERHOST decisions are made in wifi-net-device and the MacRx trace sources are hit in wifi-mac. In order to provide what Francesco wants, perheps we want another trace source, MacLocalRx or MacHostRx (to match up with PACKET_HOST) to differentiate between these cases. I can add this to WifiMac quite easily. It seems like a worthwhile addition (to all devices). Since this isn't a pcap-ready trace, I won't bother to add the offensive Ethernet header to the traced packet. I should also remove the vestigal m_rxLogger and m_txLogger that are still there, BTW.
WifiMac "MacRx" trace source provides a non-promiscuous mac-level trace. WifiMac "MacPromiscRx" provides a promiscuous mac-level trace. I think this resolves the issue.