[Ns-developers] Requesting help for csma promiscuous mode

[Gustavo Carneiro]

2008/7/4 <craigdo at 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.


The channel does not do it, but I saw this comment:

//
// 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.
//

This comment claims that devices do not receive packets while the
transmitter is active.  Clearly the filter should be on the NetDevice
level.  Unfortunately I couldn't easily get it to work this way, and found
putting the filter at the channel level easier.


>
> 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.


I do not understand the problem as you explain it, but I'll add the XXX (or
FIXME) comment for now, as you suggest.  I think help from a csma expert
might be needed to solve this The Right Way™.

Thanks.


>
> 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
> >
> >
>
>
>


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