From: Vlad Yasevich <vyasevich@gmail.com>
To: Albert Krenz <albert.krenz87@googlemail.com>, netdev@vger.kernel.org
Subject: Re: Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge
Date: Thu, 14 Nov 2013 09:52:49 -0500 [thread overview]
Message-ID: <5284E3C1.6030905@gmail.com> (raw)
In-Reply-To: <CAPRaSD6LX4BP51u0kJ6r7OEQHPyykrS+9we9bK6GnB3hbWRAVQ@mail.gmail.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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2013-11-14 14:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 11:09 Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge Albert Krenz
2013-11-14 14:52 ` Vlad Yasevich [this message]
2013-11-14 15:08 ` Albert Krenz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5284E3C1.6030905@gmail.com \
--to=vyasevich@gmail.com \
--cc=albert.krenz87@googlemail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).