lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 05 May 2009 15:15:41 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	David Miller <davem@...emloft.net>
CC:	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [RFC] macvlan: proper multicast support

David Miller wrote:
> From: Stephen Hemminger <shemminger@...tta.com>
> Date: Fri, 24 Apr 2009 09:48:08 -0700
> 
>> When using macvlan's multicast packets don't get properly passed between
>> macvlan's which should be logically sharing the network.  Any multicast
>> packet sent on a macvlan should show up lower device and all other macvlan's.
>> Likewise a multicast packet sent on lower device should be received
>> by all macvlan's.
>>
>> The following is one way to do it; build tested only.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@...tta.com>
> 
> I definitely want to see what Patrick thinks of this.

 From a functional POV the patch looks mostly fine to me, it seems
to simulate the behaviour of a real network accurately to the point
that you could probably create a loop by bridging two macvlans on
the same physical network.

This part looks incorrect however:

>>  static int macvlan_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>  {
>>  	const struct macvlan_dev *vlan = netdev_priv(dev);
>> +	const struct ethhdr *eth = eth_hdr(skb);
>>  	unsigned int len = skb->len;
>>  	int ret;
>>  
>>  	skb->dev = vlan->lowerdev;
>> +	if (is_multicast_ether_addr(eth->h_dest)) {
>> +		macvlan_broadcast(skb, vlan->port, vlan);
>> +		macvlan_clone(skb, vlan->lowerdev);
>> +	}
>> +
>>  	ret = dev_queue_xmit(skb);
>>  

macvlan_clone() will netif_rx() the packet on the lower dev,
which means it will get passed back to the macvlan receive
hook for the same lower device. This will do two things:

- it will deliver the packet to all other macvlan devices on
   the same physical device - which is fine but done twice with
   the manual delivery

- it will deliver the packet to the originating macvlan device,
   which is wrong

The first point is actually a good thing in my opinion, we need
less special handling and ordering of the reception events is
automatically correct.

The delivery to the originating device looks a bit harder, we
don't know the originating macvlan device when the packet is
delivered to the receive handler. I can't think of an easy way
to fix this right now.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ