[Ns-developers] Learning Bridge, NetDevice API changes

[Gustavo Carneiro]

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

> On Fri, 2008-07-04 at 23:50 +0100, Gustavo Carneiro wrote:
>
>
> >         1) BridgeNetDevice::GetChannel should be implemented
> >         correctly, that is,
> >         it should return a BridgeChannel which is created on the fly
> >         and
> >         references the channels of the underlying devices: it is
> >         important to
> >         implement as much as you can of the NetDevice API if it makes
> >         sense and,
> >         in this case, it makes perfect sense to make the bridge report
> >         as
> >         neighbors the neighbors of its underlying devices.
> >
> > What is the use case for that?  global routing manager?  That kinda
> > makes sense, actually.
>
> That was partly my concern but, more generally, I care about trying to
> implement as much as possible the API defined in the NetDevice base
> class to avoid weird cases where some pieces of code work with certain
> devices and not with others.
>
> >         2) I really would like to avoid the extra cruft you have added
> >         for 'api
> >         compatibility'. This means that:
> >          - we could re-use the rx callback in promisc mode
> >
> > But it needs to change not only API but also semantics.  I think if
> > the semantic change is restricted to NetDevice->Node, not so bad, but
> > from Node to protocol handlers it is really bad.
>
> Yes, I agree and you make the same point below again: I considered that
> before and tried to figure out what would be the impact on a protocol
> listening to these events and getting more packets than it should. As
> far as I can tell, at least in the case of Ipv4 or Ipv6, the
> higher-level code won't bother at all because it is doing its own
> ip-level filtering.
>
> >          - no need for the new Node::Register/Unregister methods you
> >         have added
> >
> > OK, but as I say above, protocol handlers should at least be able to
> > specify whether they want promiscuous packets or not, via a flag
> > parameter.
>
> All the cases I came up with seem to work just fine without this.
>
> >          - need to add enable/disable methods for promisc mode
> >
> > Same comment as above.  Don't you think it's evil to have a promisc
> > mode enable/disable?  I mean, suppose we have a simple protocol
> > handler.  Next, some unrelated code activates promiscuous mode.  The
> > first protocol handler starts receiving packets it is not prepared to
> > receive, and did not expect.
>
>
> I would expect to be able to set the device promiscuous bit on globally
> as root on linux. i.e., "ifconfig ethx promisc" ? So, if we do the same
> thing, we probably should be fine.


If we're going down linux road, at least we should add a packet type
parameter to make it easy for protocol handlers to ignore certain packets:
*unsigned char pkt_type;*

  Packet classification used in delivering it. The driver is responsible for
setting it to PACKET_HOST (this packet is for me), PACKET_BROADCAST,
PACKET_MULTICAST, or PACKET_OTHERHOST (no, this packet is not for me).
Ethernet drivers don't modify pkt_type explicitly because
*eth_type_trans*does it for them.

 (from http://www.xml.com/ldd/chapter/book/ch14.html)


>
>
> >         3) What is SupportsPromiscuousReceiveCallback used for ? When
> >         do you
> >         envision a device which could refuse to support this mode ?
> >
> > That is for compatibility only.
>
> ha. I see.
>
> Mathieu
>
>


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