[Ns-developers] NS-3 promiscuous mode for NetDevice

[Gustavo Carneiro]

2008/6/30 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

> On Mon, 2008-06-30 at 18:16 +0100, Gustavo Carneiro wrote:
> > One thing that I need from NS-3 right now, and is not possible without
> > patching the core, is to enable promiscuous mode protocol handlers.  My
> > particular use case is rather complicated, but let's suppose a simpler
> > scenario to illustrate the case.  Suppose I want to create a 802.1D
> Learning
> > Bridge, for instance for implementing a proper 802.11 Access Point.  The
> > LearningBridge module needs to receive all L2 frames from netdevices,
> even
> > the ones with destination address not matching the netdevice it arrived
> on.
> >
> >   I think it is clear this feature is needed.  Now, I would welcome
> advice
> > on what is the best way I can implement it[1].  I can see different ways
> to
> > accomplish the goal:
>
> An even simpler way to do this than any of the two options you describe
> and what is done in the 802.11 code is to simply make your netdevice
> model export two sets of trace sources which hook at different locations
> in your model.
>
> For example, the wifi model has the two following trace sources:
> /NodeList/x/DeviceList/y/Phy/Tx
> and,
> /NodeList/x/DeviceList/y/Mac/Tx
>
> The former hooks at the top of the PHY layer while the latter hooks at
> the top of the MAC layer. If you hook at the PHY layer, you get the
> promiscuous output. If you hook at the MAC layer, you get the
> non-promiscuous output (in fact, for wifi, there is no such thing as
> "promiscuous". It is usually called "monitor" mode on linux).
>
> The question then, is, what does the helper API export and, do you want
> to allow the helper API to export the two different modes. I would say
> that this really depends on your model. Right now, the wifi code exports
> the PHY hook traces, hence generating pcap traces for "monitor" mode by
> default but, I would be happy to see patches to add support for a
> non-monitor mode to the helper API. Anyhow, my point, though, is that
> none of that has much to do with the NetDevice API, and everything to do
> with the helper API.


I don't really care about pcacp traces being monitor mode or not.  And that
is orthogonal to this discussion.

Regarding promiscuous mode vs monitor mode, it's almost, but not quite, just
a matter of terminology.  I think that in monitor mode the netdevice
captures and records 802.11 control frames as packets.  Promiscuous mode is
less demanding, as it only captures data frames, regardless of
source/destination, but not control frames.

Regarding tracing, sopme things I don't like so much about that approach:

  1. Harmonization.  Tracing paths, as general rule, are not "standardized"
interfaces across multiple NetDevice types.  If I want to capture frames in
both csma and wifi netdevices (which I really do), I'll have to code a
series of IFs to check what is the type of the netdevice I want to monitor
and what trace path and callback type I can use for each device type.
Extending the NetDevice class with a new SetPromiscuousReceiveCallback API,
on the other hand, pushes the harmonization job onto the netdevices
themselves, where it belongs;

 2.  API inconsistency.  Using netdevice tracing directly does not integrate
as nicely with the Node::AddProtocolHandler API style.  In addition, why do
we have NetDevice::SetReceiveCallback?  You could have said the exact same
thing, to use tracing instead of providing an explicit callback API.

Since my last post I have actually coded an API based on the
NetDevice::SetPromiscuousReceiveCallback and
Node::AddPromiscuousProtocolHandler, in my private tree.  So any argument
about effort to code it is moot; it's already done :-)  The only issue
really is what API is better design for NS-3 in general, if any.

Thanks.

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