Message-ID: <CAPRaSD6r=SnQApFvjGWo6KSK4SMiO3L9egD6UhJ9srcUDRcd-Q@mail.gmail.com>
Date:	Thu, 14 Nov 2013 16:08:07 +0100
From:	Albert Krenz <albert.krenz87@...glemail.com>
To:	Vlad Yasevich <vyasevich@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge

ok, understood. Didn't know that the bridge handels the assigned
network devices as their own ports. Thought it's working like a
regular switch which ports have no mac address.
Thanks for your help.

Greetings
Albert Krenz

2013/11/14 Vlad Yasevich <vyasevich@...il.com>:
> 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@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
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