From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Yasevich Subject: Re: Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge Date: Thu, 14 Nov 2013 09:52:49 -0500 Message-ID: <5284E3C1.6030905@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit To: Albert Krenz , netdev@vger.kernel.org Return-path: Received: from mail-yh0-f43.google.com ([209.85.213.43]:33748 "EHLO mail-yh0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753293Ab3KNOwy (ORCPT ); Thu, 14 Nov 2013 09:52:54 -0500 Received: by mail-yh0-f43.google.com with SMTP id v1so1030830yhn.16 for ; Thu, 14 Nov 2013 06:52:51 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 11/14/2013 06:09 AM, Albert Krenz wrote: > Hello together, > i am experiencing a strange behaviour in a bridge which bridges two > tap Interfaces (namely tap0 and tap1) that are generated by two > C-Applications. > > It looks like the following: > > +------------------------+ > +-----------------------+ > | | > | | > | Application 1 | ------- tap0 ----- br1 ---- tap1 ----- | > Application 2 | > | | > | | > +------------------------+ > +-----------------------+ > > Application 1 creates tap0 and Application 2 creates tap1. The > creation of the devices is done like in > https://www.kernel.org/doc/Documentation/networking/tuntap.txt > Both Applications acces their respective tap-device via File-IO. The > bridge should bridge the network devices of both tap's. > > Here are the MAC-addresses of both tap devices (they only differ in > the last byte): > tap0: XX:XX:XX:XX:XX:B4 > tap1: XX:XX:XX:XX:XX:B3 > > What i want to accomplish is sending an Ethernet Frame (Layer 2, so no > IP Frames) from Application 1 to Application 2 and vice versa. > Therefore i am periodically (1 time per second) writing a Frame with > Dst-addr. of tap1 and Src-addr. of tap0 and vice-versa, to the > File-descriptor of the respectiv tap-device. This is your problem. You are trying to use the mac addresses assigned to the tap devices themselves. Those mac addresses identify the ports of the bridge and anything destined to those mac addresses is consumed by the bridge itself. This works just like any other bridge/switch. You typically address your packets to some device that sits behind the port, not to the port itself. > I can now check the traversing of the Frame via Wireshark from tap0 to > br1, but it never gets to tap1 and therefore Application 2 never > receives a Frame. Also in the other direction the Frames never pass > through br1 but get stuck. > > If i am not using the MAC-addr. of the TAP Devices but a random > unknown Dst-addr like XX:XX:XX:XX:XX:F0 (MAC address not known in the > bridge) it works like a charm and the Frame passes through the bridge > and is received by Application 1 or Application 2. > The same goes for Broadcast/Multicast addresses. > > I then tried disabling network Filtering via: > echo 0 > bridge-nf-call-arptables > echo 0 > bridge-nf-call-iptables > echo 0 > bridge-nf-call-ip6tables > but this didn't do the trick. > > > What also did not work was setting tap0/tap1/br1 into promiscuous > mode. Maybe i first have to add a routing rule via ebtables? I have > tried: > ebtables - A FORWARD -i br1 -o br1 -j ACCEPT > which i found on the internet and did also not work. > > My Questions is now: is it possible to bridge two tap devices to send > RAW Ethernet Frames between two Applications? I think this should work > cause it is similar to an KVM/QEMU setup where multiple Virtual Guest > OS's are also able to communicate between each other (via IP frames). > So does anyone have an idea what i am missing? Right. This works in QEMU/KVM because the packets are addressed to the guest which has a different HW address the the bridge port. What you can do is assign your application a mac address that is generated from the mac address of the tap device. Then use those addresses and it will work. -vlad > > Greetings > Albert Krenz > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >