Bug 274

I am not sure from the bug description what the problem is.  What configuration are you trying to support using a bridge with a PointToPointNetDevice?  Which addresses are you talking about?

I am trying to simulate an ethernet switch with a set of point to point links between the switch and each connected device. In that context, it is impossible to do what the PointToPointNetDevice object does right now, that is, assume that the "to" address of a received packet is its own address and that the "from" address of that received packet is the address of the immediately connected device.

The bottom line, is that it is impossible to implement the SendFrom and ReceivePromiscuousCallback correctly without keeping track of the to and from addresses of each packet. And since, we have decided that this feature is not "optional", we have to figure out a way to keep track of these on a per-packet basis.

tom and I discussed this so, here is a summary:

1) There are certain kinds of devices which will be incompatible with others when put under the same bridge. For example, devices which use incompatible address types won't be able to be bridged together.

2) the _model_ of the p2p device is incompatible with bridging (it is not the implementation which is at fault). This means that bridging somewhat needs to be optional at least in this case.

3) we need to figure out how we can detect bridging incompatibilities.

(In reply to comment #3)
> tom and I discussed this so, here is a summary:
> 
> 1) There are certain kinds of devices which will be incompatible with others
> when put under the same bridge. For example, devices which use incompatible
> address types won't be able to be bridged together.

At the moment the bridging code attempts to convert addresses to Mac48Address.  Any netdevice that doesn't use Mac48Address will trigger assertion errors in runtime.

The bridging code is mean to work only on 802 netdevices.  In real world I am not aware of bridging using other kinds of addresses, so in my opinion this isn't a real problem.

> 
> 2) the _model_ of the p2p device is incompatible with bridging (it is not the
> implementation which is at fault). This means that bridging somewhat needs to
> be optional at least in this case.

Indeed, this seems rather obvious to me.  The only way for p2p to be usable for bridging would be via Ethernet encapsulation (add EthernetHeader before transmitting, remove it when receiving).

> 
> 3) we need to figure out how we can detect bridging incompatibilities.

This is just about detecting a user program error.  I would say this "would be nice", but not something we _have_ to do IMHO.

(In reply to comment #4)
> (In reply to comment #3)
> > tom and I discussed this so, here is a summary:
> > 
> > 1) There are certain kinds of devices which will be incompatible with others
> > when put under the same bridge. For example, devices which use incompatible
> > address types won't be able to be bridged together.
> 
> At the moment the bridging code attempts to convert addresses to Mac48Address. 
> Any netdevice that doesn't use Mac48Address will trigger assertion errors in
> runtime.

ok.

> The bridging code is mean to work only on 802 netdevices.  In real world I am
> not aware of bridging using other kinds of addresses, so in my opinion this
> isn't a real problem.

I think that Mac64 addresses are valid 802 devices.

> 
> > 
> > 2) the _model_ of the p2p device is incompatible with bridging (it is not the
> > implementation which is at fault). This means that bridging somewhat needs to
> > be optional at least in this case.
> 
> Indeed, this seems rather obvious to me.  The only way for p2p to be usable for
> bridging would be via Ethernet encapsulation (add EthernetHeader before
> transmitting, remove it when receiving).

yes.

> 
> > 
> > 3) we need to figure out how we can detect bridging incompatibilities.
> 
> This is just about detecting a user program error.  I would say this "would be
> nice", but not something we _have_ to do IMHO.

It is important because otherwise, users won't be able to figure out what will go wrong.

Another important item which occured to me while working on that for wifi is that we probably also need:

class NetDevice {
  virtual bool SupportsBridging (void) const = 0;
};


i.e., adhoc and STA wifi devices cannot support bridging while AP wifi devices can support it.

(In reply to comment #5)
> Another important item which occured to me while working on that for wifi is
> that we probably also need:
> 
> class NetDevice {
>   virtual bool SupportsBridging (void) const = 0;
> };
> 
> 
> i.e., adhoc and STA wifi devices cannot support bridging while AP wifi devices
> can support it.

You could just add a NS_FATAL_ERROR("SendFrom can only be used in AP devices, not STAs.") to SendFrom in the Sta netdevice.

(In reply to comment #6)
> (In reply to comment #5)
> > Another important item which occured to me while working on that for wifi is
> > that we probably also need:
> > 
> > class NetDevice {
> >   virtual bool SupportsBridging (void) const = 0;
> > };
> > 
> > 
> > i.e., adhoc and STA wifi devices cannot support bridging while AP wifi devices
> > can support it.
> 
> You could just add a NS_FATAL_ERROR("SendFrom can only be used in AP devices,
> not STAs.") to SendFrom in the Sta netdevice.

That would make it harder to go back to which part of the simulation script topology setup is wrong.
 

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Another important item which occured to me while working on that for wifi is
> > > that we probably also need:
> > > 
> > > class NetDevice {
> > >   virtual bool SupportsBridging (void) const = 0;
> > > };
> > > 
> > > 
> > > i.e., adhoc and STA wifi devices cannot support bridging while AP wifi devices
> > > can support it.
> > 
> > You could just add a NS_FATAL_ERROR("SendFrom can only be used in AP devices,
> > not STAs.") to SendFrom in the Sta netdevice.
> 
> That would make it harder to go back to which part of the simulation script
> topology setup is wrong.

I missed in my previous comment what you implied, that is, that there is no such thing as Bridging support but that it just happens that the STA and ADHOC modes cannot implement correctly the SendFrom method. How about this instead ?

class NetDevice {
  virtual bool SupportsSendFrom (void) const = 0;
};

> I missed in my previous comment what you implied, that is, that there is no
> such thing as Bridging support but that it just happens that the STA and ADHOC
> modes cannot implement correctly the SendFrom method. How about this instead ?
> 
> class NetDevice {
>   virtual bool SupportsSendFrom (void) const = 0;
> };
> 

FWIW, the method name SupportsBridging () seems more appealing to me.  I don't know whether SendFrom () could be useful independent of SupportsBridging () (mac spoofing support?).

But I would be OK with SupportsSendsFrom ().

It's true that Wifi STAs cannot implement SendFrom correctly.  SendFrom assumes a different MAC address on a per-frame basis.  As Mathieu explains, if you do that then ACKs will not work correctly.

MAC spoofing is different.  Wikipedia defines it as:

   "Although intended to be a permanent and globally unique identification, it is possible to change the MAC address on most of today's hardware, an action often referred to as MAC spoofing."

What I think this means is that, while hardware devices have a manufacturer assigned builtin MAC address, cards allow one to switch to another address.  But not on a per-frame basis, like SendFrom tries to do, instead it can be done on per "session" basis.  In NS-3 there is no hardware address.  We can still say we support MAC spoofing, in in Wifi STAs.

On the surface, whether netdevice supports SendFrom appears to be the only deciding factor to determine whether or not the netdevice can become a bridge port.  So I am inclined to agree that SupportsSendFrom is appropriate, more than SupportsPromiscuous.

The only question now is, is it worth having SupportsSendFrom?  How would it be used.  What is the difference between that use and just asserting inside SendFrom?

(In reply to comment #10)
> It's true that Wifi STAs cannot implement SendFrom correctly.  SendFrom assumes
> a different MAC address on a per-frame basis.  As Mathieu explains, if you do
> that then ACKs will not work correctly.
> 
> MAC spoofing is different.  Wikipedia defines it as:
> 
>    "Although intended to be a permanent and globally unique identification, it
> is possible to change the MAC address on most of today's hardware, an action
> often referred to as MAC spoofing."
> 
> What I think this means is that, while hardware devices have a manufacturer
> assigned builtin MAC address, cards allow one to switch to another address. 
> But not on a per-frame basis, like SendFrom tries to do, instead it can be done
> on per "session" basis.  In NS-3 there is no hardware address.  We can still
> say we support MAC spoofing, in in Wifi STAs.

yes: in ns-3, we can change the mac address of a device whenever we re-associate.

> 
> On the surface, whether netdevice supports SendFrom appears to be the only
> deciding factor to determine whether or not the netdevice can become a bridge
> port.  So I am inclined to agree that SupportsSendFrom is appropriate, more
> than SupportsPromiscuous.

The options are:
1) SupportsBridging + SendFrom + SetPromiscReceiveCallback
2) SupportsSendFrom + SendFrom + SupportsPromiscuous + SetPromiscReceiveCallback

The rationale for 2) is that in wifi STAs, we can implement promisc mode but we cannot implement SendFrom.


> 
> The only question now is, is it worth having SupportsSendFrom?  How would it be
> used.  What is the difference between that use and just asserting inside
> SendFrom?

The use for a SupportsFoo method is to check for compatibility with bridging from BridgeHelper::Install or NetDeviceBridge::AddPort. If it fails there and if we assert there, running the code in a debugger will show you a backtrace which shows you exactly which container contains a problematic device.

If you don't do that, it is going to be hard for a user to figure out which part of his topology setup is at fault.

*** Bug 268 has been marked as a duplicate of this bug. ***

Tom, craig and I discussed this issue at length. Here is the latest proposal:

1) remove SupportsPromiscuous
2) add SupportsSendFrom
3) leave in SendFrom and SetRecvPromiscuous
4) modify BridgetNetDevice::AddPort to check that device returns true on SupportsSendFrom. FATAL_ERROR if not.

will do later

changing title to reflect actual bug content

changeset 4eb48239b4dc