|
Bugzilla – Full Text Bug Listing |
| Summary: | Promiscuous mode tracing inconsistencies | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Component: | devices | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | ns-3.2 | ||
| Hardware: | All | ||
| OS: | All | ||
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 PACKET_OTHERHOST; - 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. Opinions?