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

[Gustavo Carneiro]

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

> hi,
>
> To summarize a lengthy discussion on irc, gustavo and I agreed that we
> might need to add couple of features to the NetDevice base class to
> support that use-case:
>  - allow the specification of a from address when sending a packet to a
> NetDevice
>  - allow the listener of a NetDevice to get the source and destination
> address of an incoming packet
>  - allow a NetDevice to be put into promiscuous mode
>
> The details of the API needed to support that are not very complicated
> but they all depend on making a couple of decisions on API stability: it
> is possible to add the above features without breaking existing API by
> adding new methods but doing so would duplicate nearly-similar existing
> methods so, it is also possible to break the existing API and methods to
> make them handle this new case. Gustavo does not want to break the API
> because he does not want to make it harder to migrate from ns-3.1 to
> newer versions. I want to break it because I don't want to introduce
> cruft in our APIs. Tom, craig, opinions ?


Actually I am breaking the API right now, in my code experiments :P

In my opinion we should wait for the learning bridge to be  finalized before
deciding.  I am making some adhoc API decisions, right now, in order to move
on quickly, but of course I am expecting peer review on the proposed API.

IMHO it would be great to have two API proposals on the table, one which
preserves API compatibility, and one that doesn't, for a more informed
decision.

But first things first, I need to finish the code first :-)


> On a related note, I got a couple of private emails somewhat related to
> that use-case (I think) from someone who wants to be able to build a
> layer 2 network which spans multiple wifi/p2p networks. i.e., this
> person wants to be able to make his wifi AP act as a layer 2 bridge
> between a wifi network and a p2p network to make sure that ARP
> resolution works across the bridge (ARP request from wifi network goes
> onto connected p2p/csma network). If I am not totally mistaken, that
> could be supported by using promiscuous mode with an l2 bridge on top of


> it, right ? Gustavo ?


I was going to say:

> Absolutely.  A Wifi Access Point is just a bridge.  This will easily work
> with a BridgeNetDevice.
>

Then I noticed the p2p.  I am aiming to implement 802.1D bridges, which work
on 802 links.  I am not sure wifi<->p2p will work out of the box, without
some code tweaks.  But wifi<->csma will work for sure.


>
> Mathieu
>
> On Mon, 2008-06-30 at 16:18 -0700, Mathieu Lacage wrote:
> > 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/...
> >
> > 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.
> >
> > 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 ?
> >
> > Mathieu
> >
>
>


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