From: "Kasai Takanori" Subject: [PATCH][RFC] Don't receive an unrelated packet Date: Tue, 4 Mar 2008 20:35:10 +0900 Message-ID: <025d01c87deb$e0e6ae60$e16f210a@VF03007L> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0257_01C87E37.3DE3F5F0" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. ------=_NextPart_000_0257_01C87E37.3DE3F5F0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit Hi All, We are embarrassed about the problem of the network on Xen. The application where the problem occurs receives directly the RAW packet with dev_add_pack(). This application did not work on the PV domain and the PV-on-HVM domain. We investigated this problem. The packet of different MAC address was not expected for this application to be received. Because, physical NIC drops packet of different MAC address on Native Linux. Therefore, this application doesn't check whether the MAC address of the received packet is the same. There is no problem because the packet of different MAC address is not transmitted from the bridge usually at all. However, when the bridge does the flooding, the packet is transmitted to all ports. Therefore, the packet of different mac address is received by the guest. The packet of different MAC address is dropped by the emulation of qemu-dm on the HVM domain. Therefore, the emulation of qemu-dm works like physical NIC. However, all packets are received for VNIF on the PV domain and PV-on-HVM. This application was received the packet of different MAC address and malfunctioned. Therefore, VNIF always works as promiscuous mode. We think whether VNIF should drop the packet on different MAC address. This patch was corrected to drop the packet with different MAC address with VNIF. Is there a problem though want to be corrected by us like this patch? Or, is it a specification of the network of Xen? Signed-off-by: Takanori Kasai Best Regards, -- Takanori Kasai ------=_NextPart_000_0257_01C87E37.3DE3F5F0 Content-Type: application/octet-stream; name="netfront-rx-check-macaddr.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="netfront-rx-check-macaddr.patch" # HG changeset patch=0A= # User kasai.takanori@jp.fujitsu.com=0A= # Date 1204617252 -32400=0A= # Node ID d1e7a5d5a5b111f249fd0041ad941885d62ed93f=0A= # Parent 1cf7ba68d855aa86b1c54c34c03fc62571eb5c94=0A= Don't receive an unrelated packet, =0A= and check the MAC address of the received packet.=0A= =0A= Signed-off-by: Takanori Kasai =0A= Singed-off-by: Naoki Takayama =0A= =0A= diff -r 1cf7ba68d855 -r d1e7a5d5a5b1 drivers/xen/netfront/netfront.c=0A= --- a/drivers/xen/netfront/netfront.c Mon Mar 03 13:36:57 2008 +0000=0A= +++ b/drivers/xen/netfront/netfront.c Tue Mar 04 16:54:12 2008 +0900=0A= @@ -1473,8 +1473,15 @@ err:=0A= /* Ethernet work: Delayed to here as it peeks the header. */=0A= skb->protocol =3D eth_type_trans(skb, dev);=0A= =0A= - /* Pass it up. */=0A= - netif_receive_skb(skb);=0A= + if(!(skb->dev->flags & IFF_PROMISC)=0A= + && !is_broadcast_ether_addr(skb->mac.raw)=0A= + && !is_multicast_ether_addr(skb->mac.raw)=0A= + && compare_ether_addr(skb->mac.raw, np->mac) ) {=0A= + kfree_skb(skb);=0A= + } else {=0A= + /* Pass it up. */=0A= + netif_receive_skb(skb);=0A= + }=0A= dev->last_rx =3D jiffies;=0A= }=0A= =0A= ------=_NextPart_000_0257_01C87E37.3DE3F5F0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel ------=_NextPart_000_0257_01C87E37.3DE3F5F0--