[Ns-developers] NS-3 promiscuous mode for NetDevice
gjcarneiro at gmail.com
Mon Jun 30 16:08:06 PDT 2008
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
> > Bridge, for instance for implementing a proper 802.11 Access Point. The
> > LearningBridge module needs to receive all L2 frames from netdevices,
> > the ones with destination address not matching the netdevice it arrived
> > I think it is clear this feature is needed. Now, I would welcome
> > on what is the best way I can implement it. I can see different ways
> > 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:
> 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
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.
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
More information about the Ns-developers