[Ns-developers] Requesting help for csma promiscuous mode

[craigdo@ee.washington.edu]

> craig really did not like it at all: he felt that was
> really completely weird to make the channel have this 
> kind of logic.

Yup.  I think this is almost a textbook example of a hack (as in a quick,
functionally correct, but problematic or hard to understand or maintain
change).

What we're doing here is making the correct operation of a nicely
encapsulated network device object depend on a quite well-hidden behavior of
another object -- the channel.  This strikes me as a bad practice from a
software engineering practice.  Someone could come along and wire in a
"better" channel and not implement the your packet filter since the channel
has no reason to do such a thing, whence your code would break.  That is
bad.

Also, when I think of a channel, I don't think of an entity that has any
kind of smarts to do packet filtering.  A CSMA channel is a wire, and the
wire should just deliver simulated EM signals.  I don't know of any wires
with processors built into them -- it's the devices that are attached to the
wire that should figure out which signals on the wire to listen to.  So from
an understandability perspective, I would not expect this functionality to
be in the channel at all.  It would surprise the heck out of me to be
debugging a problem and find this filtering in a "wire."

There is a problem, though, in that we don't have a way to associate signals
propagated through the medium with a transmitter except with packet
addressing information.  You clearly have a need to do this.

Last week I would have suggested adding a "this packet is from me" tag on
the transmitted packets; but we discovered in separate socket exercise that
you really need to be able to find and remove tags for multiple hop
scenarios.  Unless I'm mistaken you simply can't do this now.  I think you
could iterate through the tags and look for the last one, though (are there
limitations on the number of tags you can have in a packet?).

So, on one hand I think it is bad from a software engineering and usability
perspective to add the quick filtering hack to the channel; but in the
presence of spoofing it seems to be the only reasonable way to get what you
need done without either plumbing a new device parameter through the channel
or updating the tags code to make it usable in this situation.

So, at this point, I wouldn't object to adding the "hack" with an XXX
comment to CSMA and filing a bug against the tags code to enable us to get
rid of the "hack."  A tags fix would then address two related bugs.

Regards,

-- Craig

> -----Original Message-----
> From: ns-developers-bounces at ISI.EDU 
> [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of Mathieu Lacage
> Sent: Friday, July 04, 2008 12:25 PM
> To: Gustavo Carneiro
> Cc: ns-developers
> Subject: Re: [Ns-developers] Requesting help for csma promiscuous mode
> 
> On Fri, 2008-07-04 at 18:00 +0100, Gustavo Carneiro wrote:
> > Never mind the help request.  Fixing this was simple (
> > http://code.nsnam.org/gjc/ns-3-learning-bridge/rev/9a662068646f).
> 
> I already suggested your fix above to fix the issue alluded to in the
> comment you show below but craig really did not like it at 
> all: he felt
> that was really completely weird to make the channel have this kind of
> logic. ?So, if you really want this change in, you will have 
> to be more
> successful than me to convince craig :)
> 
> > > // We never forward up packets that we sent.  Real 
> devices don't do this
> > > since
> > > // their receivers are disabled during send, so we don't. 
>  Drop the packet
> > > // silently (no tracing) since it would really never get 
> here in a real
> > > device.
> > > //
> > >   if (header.GetSource () == GetAddress ())
> > >     {
> > >       NS_LOG_LOGIC ("Ignoring packet sourced by this device");
> > >       return;
> > >     }
> 
> Mathieu
> 
>