[Ns-bugs] [Bug 274] point to point device cannot ignore from and to addresses

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=274





------- Comment #11 from mathieu.lacage at sophia.inria.fr  2008-08-26 11:23 -------
(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.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.