[Ns-developers] promiscuous mode (was: ns-3.5 planning / mac multicast)

[Gustavo Carneiro]

2009/4/22 Fabian Mauchle <f1mauchl at hsr.ch>

> -----Ursprüngliche Nachricht-----
> Von: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
> Gesendet: Donnerstag, 16. April 2009 13:42
> An: Mauchle Fabian (f1mauchl at hsr.ch)
> Cc: ns-developers at ISI.EDU
> Betreff: Re: [Ns-developers] ns-3.5 planning / mac multicast
>
> > 3. The netdevice API in Linux also allows to enable or disable
> promiscuous
> > mode. The NetDevice API in ns-3 only allows the registration of a
> > promiscuous or non-promiscuous receive callback.
>
> Yes: I already argued against the current ns-3 API and for the linux API
> but I lost that argument a long time ago so, if you want to put this
> back on the table, I would suggest you look in the mailing-list
> archives.
> -----Ursprüngliche Nachricht-----
>
> I read the mailing list and hopefully didn't miss something important.
> Just to recap: we are NOT talking about tracing (this is mainly for
> watching
> from the outside and should not affect the implemented network stack).
>
> Further, I got the feeling that there are 2 things mixed up:
> 1. Receiving all frames to be able to implement a bridge
> 2. Receiving all frames for other processing on the host (like tracing)
>
> The second point is known as promiscuous receive mode while I would not
> call
> the first promiscuous (it is for bridging and I think real bridges/switches
> implement different MAC functionality than hosts). However, since in ns-3
> there are no bridges as such, they have to be built on top of hosts
> (turning
> an normal computer into a switch). For this, we also need the promiscuous
> mode.
>
> The actual implementation is mainly designed for bridging. It makes a
> strong
> difference between registered protocols (or the bridging functionality)
> that
> want to receive all frames, and the ones that do not want this(eg. that the
> IP protocol is not affected if the same node does some bridging). I think
> this is NOT what would happen on real hosts.
>
> If I want to make use of promiscuous mode for further processing on a node,
> or more generally, test the behavior of a L3 protocol if the NetDevices are
> promiscuous (eg. Simulating a tracing application running on a node to test
> sniffer detection methods) I got 2 problems:
> 1. The Ipv4L3Protocol will register itself as a protocol (non promiscuous),
> so I'm not able to activate promiscuous mode for IP.


Your use case seems "strange".  Should we be designing a simulator around
non-realistic (or at least uncommon) use cases?  I think that "make common
things simple, uncommon things possible".  It should be possible to feed
into IPv4 promiscuous mode packets, and I believe it is possible.  At least
I have done in ns 3.2.1, and if I recall correctly I didn't even need to
modify Ipv4L3Protocol because it already has public Receive method.


>
> 2. The RegisterProtocolHandler(..., promiscuous = true) requires that a
> NetDevice supports 'send from'. This ability orthogonal to promiscuous mode
> receive (but both are required for bridges).
>
> I would propose to:
> - add a NetDevice::SetPromiscuous(bool) method.
> - if promiscuous mode is enabled for a NetDevice, it should forward up all
> correctly received packets
> Optional:
> - clean up the rest:
>  - remove the Node::NonPromiscReceiveFromDevice and use only
> Node::RedeiveFromDevice
>  - either remove the PromiscuousReceiveCallback or rename it to something
> like RawReceiveCallback
>  - in Node::RegisterProtocolHandler() activate Promiscuous if requested
> (but no deactivation)
>  - bridges must check themselves if a particular NetDevice supports
> SendFrom.


I still do not agree that one boolean setting that drastically changes the
behavior of NetDevice is a good idea.  The reason is that activating
promiscuous mode will take by surprise code that was not tested with
promiscuous mode enabled, and bugs will start appearing over time,
especially with 3rd party modules ("I have been using module XPTO, but it
starts breaking when I also use module FOO that enables promiscuous mode;
help me!").

However, the current solution is not exactly what I had first planned, it is
more of a compromise solution.  I would prefer to have two receive callbacks
in NetDevice, one "normal" and one "promiscuous".

Regarding SendFrom vs promiscuous mode, I agree they are orthogonal and one
should not imply the other.  This wasn't clear to me in the beginning, I
have to admit, but makes sense now.

That being said, I have no strong interest in the architecture of ns-3-dev
because I won't be able to use it for a long time yet (still stuck on ns-3.2
for my work).  So don't let my opinion block any refactoring you guys want
to do anyway.

Regards,
-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert