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

[Gustavo Carneiro]

2008/7/1 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

>
> On Tue, 2008-07-01 at 00:08 +0100, Gustavo Carneiro wrote:
>
> > 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.
>
> I think so but the exact definition probably depends on the actual
> underlying physical device.
>
> > 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
>
> You can also just use '*' in your trace paths:
> /NodeList/*/DeviceList/*/$ns3::CsmaNetDevice/...
> /NodeList/*/DeviceList/*/$ns3::WifiNetDevice/...


I still have to do a number of Connects, one for each NetDevice type.  And I
need to be aware of every NetDevice type.  And potentially have a different
callback method for each trace type.  Far from desirable.


>
>
> which will connect only to the matching devices.
>
> >  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.
>
> If the "promiscuous mode" is really used for tracing only, then,
> clearly, using trace hooks is the right way to go.


It is not at all for tracing or anything like it.


>
> However, the use-case you have described in your first email, describes
> using "promiscuous" mode to implement a layer 2 learning bridge, which,
> indeed, does not sound like the best use-case for tracing. Is this
> really what you are trying to do ? Or did you simplify your use-case for
> your email ?


My use case is for something similar to TRILL (Transparent Interconnection
of Lots of Links).  Terminals connect to special "routing bridges", which
capture the frame, encapsulate it another ethernet frame, and send it to a
destination egress Rbridge.  It's not a Learning Bridge, but very closely
related to one, and the problems are the same.

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