[Ns-bugs] [Bug 354] New: Promiscuous mode tracing inconsistencies
bugzilla-daemon at nsnam-www.ece.gatech.edu
Thu Sep 18 03:15:12 PDT 2008
Summary: Promiscuous mode tracing inconsistencies
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
I am playing with my gjc/ns-3-pyviz branch and been noticing inconsistencies
wrt. tracing and promiscuous mode. I am sorry I did not catch this sooner, but
better late than never.
- CsmaNetDevice does not generate any trace when a packet is received
promiscuously (PACKET_OTHERHOST). In my branch, I experimentally added a new
PromiscRx trace and generate it for all packets but only when there is a
promiscuous mode protocol handler:
if (!m_promiscRxCallback.IsNull ())
m_promiscRxTrace (originalPacket, packetType);
m_promiscRxCallback (this, packet, protocol, header.GetSource (),
header.GetDestination (), packetType);
- Wifi does not have a separate protocol handler for promiscuous mode, instead
unconditionally always generates Rx trace for all packets, even
- PointToPointNetDevice does not even care about destination addresses, it's
like it is permanently in promiscuous mode.
I think it would be better to converge. On one hand, I can probably manage to
not use a PromiscRx trace, by looking at the netdevice and checking if it is
part of at BridgeNetDevice (once a proper BridgeNetDevice API is provided for
that). On the other hand, doing so would be more complex in terms of code and
probably less efficient computationally than listening to a PromiscRx trace.
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the Ns-bugs