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

[Mathieu Lacage]

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 ?

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 ?

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
>