Created attachment 927 [details]
use ethernet over etherip over ip over ppp encapsulation to convey the source and destination addresses correctly

this appears to fix the problem for me

(In reply to comment #0)
> PointToPointNetDevice::Send ignores the 'destination' mac address. Upon
> reception, the destination address given to the receiving layers is the address
> of the receiver. This breaks code which uses multicast addresses.

Can you be more specific about what is the problem?  There are no mac addresses used in the model; some hardcoded ones are there to satisfy API requirements but PppHeader doesn't use them.  Are you trying to achieve layer-2 filtering of multicast?

I thought that you were complaining that IsMulticast () returns false, but you do not change that behavior in your patch.  I don't understand trying to apply RFC 3378 here.

(In reply to comment #2)
> > PointToPointNetDevice::Send ignores the 'destination' mac address. Upon
> > reception, the destination address given to the receiving layers is the address
> > of the receiver. This breaks code which uses multicast addresses.
> 
> Can you be more specific about what is the problem?  There are no mac addresses
> used in the model; some hardcoded ones are there to satisfy API requirements
> but PppHeader doesn't use them.  Are you trying to achieve layer-2 filtering of
> multicast?

The problem I am seeing here is that even though the device is not multicast-capable and even though I report so to my linux kernel running on top of the p2p device, I observe these ipv6 packets beeing sent over p2p:

17:49:09.326344 e6:0c:8c:c9:31:69 > 33:33:00:00:00:02, ethertype IPv6
(0x86dd), length 70: fe80::e40c:8cff:fec9:3169 > ff02::2: ICMP6,
router solicitation, length 16

Being able to convey to the receiver the destination address 33:33:00:00:00:02 is critical to allow the ipv6 neighbour discovery protocol to work because it filters the packets it receives based on the destination address so, this is why I put together this patch to preserve the addresses across p2p. (and this rfc appeared the simplest way to do so)

> I thought that you were complaining that IsMulticast () returns false, but you
> do not change that behavior in your patch.  I don't understand trying to apply
> RFC 3378 here.

I guess that changing IsMulticast to return true would be trivial to do on top of my patch but I thought that I was not exploiting the multicast capability of the device. It might be that I was wrong though. More checking needed.

(In reply to comment #3)
> 
> I guess that changing IsMulticast to return true would be trivial to do on top
> of my patch but I thought that I was not exploiting the multicast capability of
> the device. It might be that I was wrong though. More checking needed.

Would changing IsMulticast to true be sufficient here?  In practice, IPv6 RS/RA seem to be used over PPP serial devices, and there also seems to be documentation on the web to run PIM over PPP links, so maybe this flag should not be set to false.

IsMulticast returns true as of changeset 80937beaed64

this was fixed in ns-3.9

The problem is that, whatever your device reports from IsMulticast, it does not keep track of the destination address of each packet sent over the link. 

This is a problem, especially since your last patch to enable multicast (which I never asked for) because if you use multicast over this device, you are going to send a packet with a MAC multicast destination address and when the packet is received at the destination, the MAC multicast destination address will be lost (given the current logic in PointToPointNetDevice), hence resulting in incorrect behavior at the receiver. 

I am not familiar with what PPP is supposed to do this in this case but I would expect it to frame ethernet frames or, as in my patch, ethernet over etherip over ip over ppp which is something that wireshark knows how to read.

(In reply to comment #7)
> The problem is that, whatever your device reports from IsMulticast, it does not
> keep track of the destination address of each packet sent over the link. 
> 
> This is a problem, especially since your last patch to enable multicast (which
> I never asked for) because if you use multicast over this device, you are going
> to send a packet with a MAC multicast destination address and when the packet
> is received at the destination, the MAC multicast destination address will be
> lost (given the current logic in PointToPointNetDevice), hence resulting in
> incorrect behavior at the receiver. 

Even though you didn't ask for it, point to point links are multicast capable (RFC 2461):

   point-to-point - a link that connects exactly two interfaces.  A
                    point-to-point link is assumed to have multicast
                    capability and have a link-local address.
> 
> I am not familiar with what PPP is supposed to do this in this case but I would
> expect it to frame ethernet frames or, as in my patch, ethernet over etherip
> over ip over ppp which is something that wireshark knows how to read.

PPP usually frames IP, not Ethernet.  I realize you have an issue with using this interface but I do not think your patch (introducing all of these extra layers) is the right way to solve it.

> The problem I am seeing here is that even though the device is not
> multicast-capable and even though I report so to my linux kernel running on 
> top of the p2p device, I observe these ipv6 packets beeing sent over p2p:
> 
> 17:49:09.326344 e6:0c:8c:c9:31:69 > 33:33:00:00:00:02, ethertype IPv6
> (0x86dd), length 70: fe80::e40c:8cff:fec9:3169 > ff02::2: ICMP6,
> router solicitation, length 16
>
> Being able to convey to the receiver the destination address 33:33:00:00:00:02
> is critical to allow the ipv6 neighbour discovery protocol to work because it
> filters the packets it receives based on the destination address so, this is
> why I put together this patch to preserve the addresses across p2p. (and this
> rfc appeared the simplest way to do so)

I am guessing that these Ethernet addresses are coming from your environment;  I don't think that they belong.  If you can make the net device look like this in the overlying kernel:

ppp0      Link encap:Point-to-Point Protocol
          inet addr:10.1.3.103  P-t-P:10.0.31.18  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1496  Metric:1

(note the POINTTOPOINT flag is set and there are no MAC addresses) then I would expect it to work, although it should really try to hand the ns-3 PointToPoint device IP datagrams with no L2 or PPP framing.