Bug 949 - Node::NonPromiscReceiveFromDevice reports a meaningless destination address to user callbacks
Node::NonPromiscReceiveFromDevice reports a meaningless destination address t...
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: network
pre-release
All All
: P5 normal
Assigned To: Craig Dowell
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-23 02:23 UTC by Mathieu Lacage
Modified: 2010-08-08 23:38 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Lacage 2010-06-23 02:23:51 UTC
In the following function, we can see that we report to the user callback that the destination address of the packet is the same as its source address.

bool
Node::NonPromiscReceiveFromDevice (Ptr<NetDevice> device, Ptr<const Packet> packet, uint16_t protocol,
                                   const Address &from)
{
  NS_LOG_FUNCTION(this);
  return ReceiveFromDevice (device, packet, protocol, from, from, NetDevice::PacketType (0), false);
}


 A much more helpful value would be something along the lines of:
diff -r ba8c1944fb6d src/node/node.cc
--- a/src/node/node.cc	Tue Jun 22 10:31:51 2010 +0200
+++ b/src/node/node.cc	Wed Jun 23 08:21:11 2010 +0200
@@ -260,7 +260,8 @@
                                    const Address &from)
 {
   NS_LOG_FUNCTION(this);
-  return ReceiveFromDevice (device, packet, protocol, from, from, NetDevice::PacketType (0), false);
+  return ReceiveFromDevice (device, packet, protocol, from, device->GetAddress (), 
+                            NetDevice::PacketType (0), false);
 }
 
 bool
Comment 1 Gustavo J. A. M. Carneiro 2010-06-23 05:40:10 UTC
The non-defined value is documented:

   * \param receiver the address of the receiver; Note: this value is
   *                 only valid for promiscuous mode protocol
   *                 handlers.

Changing 'receiver' to the value device->GetAddress() could be incorrect.  For instance, broadcast or multicast packets will still be received in non-promiscuous mode, but the destination address will not be the unicast address of the interface.
Comment 2 Mathieu Lacage 2010-06-23 05:45:17 UTC
(In reply to comment #1)
> The non-defined value is documented:
> 
>    * \param receiver the address of the receiver; Note: this value is
>    *                 only valid for promiscuous mode protocol
>    *                 handlers.
> 
> Changing 'receiver' to the value device->GetAddress() could be incorrect.  For
> instance, broadcast or multicast packets will still be received in
> non-promiscuous mode, but the destination address will not be the unicast
> address of the interface.

There is no doubt that this value is incorrect in non-promisc mode. I am merely suggesting to make it slightly less incorrect but, hey, I can live without it. 

Clearly, the idea of using the same callback signature for two different events with different semantics and numbers of arguments was a bad idea. If it was mine, I deserve to be whipped.
Comment 3 Tom Henderson 2010-06-23 10:10:05 UTC
(In reply to comment #1)
> The non-defined value is documented:
> 
>    * \param receiver the address of the receiver; Note: this value is
>    *                 only valid for promiscuous mode protocol
>    *                 handlers.
> 
> Changing 'receiver' to the value device->GetAddress() could be incorrect.  For
> instance, broadcast or multicast packets will still be received in
> non-promiscuous mode, but the destination address will not be the unicast
> address of the interface.

In WiFi and Csma, this is set to the destination address of the L2 frame.  For PointToPoint, we don't really have a L2 destination address conceptually.  I would be OK with Mathieu's proposal to change this from "from" to "device->GetAddress()" (seems to be possibly less misleading to an unsuspecting user) and suggest to change the doxygen to:

    * \param receiver the destination address of the received frame; Note: this value is
    *                 only valid for promiscuous mode protocol
    *                 handlers.  Note2:  If the L2 protocol does not use L2 addresses, the address reported here is the value of device->GetAddress().
Comment 4 Craig Dowell 2010-08-08 22:26:38 UTC
Added device->GetAddress() in changeset 1f6962c1083c