[Ns-developers] Learning Bridge, NetDevice API changes

[Mathieu Lacage]

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.

>         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