[Ns-developers] Requesting help for csma promiscuous mode

[craigdo@ee.washington.edu]

>   4- I really think it makes no sense in NS-3 to have a 
> "promiscuous mode"
> if we have a single receive callback in netdevices.  Might as 
> well _always_
> receive in promiscuous mode because a) simplifies API, and b) 
> allows subtle
> bugs of a protocol handler not being prepared for promiscuous 
> mode, due to a
> bug, and suddenly another handler activates the promiscuous mode and
> triggers a bug in the first handler, until then undiscovered. 
>  "Modes" in
> general are usually evil because of the way they attract bugs 
> when multiple
> independent code modules are brought together into the same system.

I think having the net devices always be in promiscuous mode is very
strange.

>From the perspective of a system that tries to reflect real hardware and
real software, having devices that do something like this would be contrary
to this spirit, IMO.  In every ethernet-like device I've ever worked with,
there has been a special bit that defaults to off which you have to turn on
to get into promiscuous mode.  The root of the thing is a bit in a register
on an ethernet controller chip.  It's the way the world works.  I think it's
what people will expect.  It's what I would expect.

What kind of pcap traces would devices that always operate in promiscuous
mode generate?  Would these be terribly useful?  Wouldn't it be the case
that very often people would want to turn this promiscuous mode off to get
behaviors that reflect the real world?  Would turning on promiscuous
operation just lead to an a request for an opposite "mode" where we have a
non-promiscuous bit for people who want to model more real-world devices?

While I agree that mode switches can cause problems, there are many of them
in the real world we're trying to simulate.  If we're going to have a
simulator that reflects the real world we're going to need to have mode
switches that real systems do -- right?

I think a user would expect to set a PROMISC bit in a socket ioctl.  How
this is implemented at a low level and what it means across device types is
another question.

I think that linux has a number of bits that you can set to enable various
promiscuity levels:  RxStation, RxMulticast, RxBroadcast, RxProm.

What I would "expect" to see would be an attribute having something like
these levels and which defaults to RxStation | RxMulticast | RxBroadcast.

We could also provide a promiscuous callback that passes up all packets by
default.  Code specially written to handle promiscuous packets could just
hook this code -- including bridges and packet filters.

Anyway, I think having devices always in promiscuous mode is weird.

-- Craig