I am a total noob, this is my first ever experiment with kernel networking. I am attempting to create a bridge between two tap
interfaces, and try to send traffic through. It is more of an experiment than for any particular purpose.
$ brctl showstp br0
br0
bridge id 8000.46846e0c0ff9
designated root 8000.46846e0c0ff9
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 1.98 tcn timer 0.00
topology change timer 0.00 gc timer 115.04
flags
tap1 (1)
port id 8001 state forwarding
designated root 8000.46846e0c0ff9 path cost 100
designated bridge 8000.46846e0c0ff9 message age timer 0.00
designated port 8001 forward delay timer 10.34
designated cost 0 hold timer 0.98
flags
tap2 (2)
port id 8002 state forwarding
designated root 8000.46846e0c0ff9 path cost 100
designated bridge 8000.46846e0c0ff9 message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.98
flags
I have the bridge br0
created, with both tap1
and tap2
added. I have a program injecting ARP packets into tap1
using libpcap
. Wireshark correctly shows the packets entering tap1
. However, no packet shows up at tap2
. I tried adding the follwing rule in ebtables:
sudo ebtables -I INPUT --log --log-level debug
No packets show up in the logs. I'll appreciate any inputs.
EDIT: Adding more information. Injecting fake packets is indeed the application. My intention here is to simulate, fully in software and without VMs, how packets get forwarded through the linux kernel stack. I am not creating any new network namespaces. Perhaps that's the problem?
I only have two processes. The "read" process has a file descriptor open to tap2
, and constantly tries to read from it. The write process has a file descriptor open to tap1
and waits for user prompt to send out the ARP query. The ARP query has a random source IP address. The source MAC address is set as the MAC address of tap1
. Here is the output of tcpdump:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap1, link-type EN10MB (Ethernet), capture size 262144 bytes
^[[A07:19:57.752990 ARP, Request who-has google-public-dns-a.google.com tell 0.0.248.17, length 28
0x0000: ffff ffff ffff ba9c 0589 16ad 0806 0001
0x0010: 0800 0604 0001 ba9c 0589 16ad 0000 f811
0x0020: 0000 0000 0000 0808 0808
I have configured tap1
and tap2
to not have IP addresses. Could that be the problem?
brctl addbr br0
ip tuntap add name tap1 mode tap
ip tuntap add name tap2 mode tap
brctl addif br0 tap1
brctl addif br0 tap2
ifconfig tap1 0.0.0.0 up
ifconfig tap2 0.0.0.0 up
ifconfig br0 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
ip link set br0 up
ip link set tap1 up
ip link set tap2 up
Based on the answer, I checked attaching various applications to tap2
. I notice this: when no application is using tap1
or tap2
, both interfaces don't have the LOWER_UP flag set.
4: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 46:84:6e:0c:0f:f9 brd ff:ff:ff:ff:ff:ff
25: tap1: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN mode DEFAULT group default qlen 500
link/ether ba:9c:05:89:16:ad brd ff:ff:ff:ff:ff:ff
26: tap2: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN mode DEFAULT group default qlen 500
When I start the applications, the LOWER_UP flag becomes set:
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 46:84:6e:0c:0f:f9 brd ff:ff:ff:ff:ff:ff
25: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 500
link/ether ba:9c:05:89:16:ad brd ff:ff:ff:ff:ff:ff
26: tap2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 500
link/ether 46:84:6e:0c:0f:f9 brd ff:ff:ff:ff:ff:ff
I'm sorry this is turning out to be lengthy, I'm just hoping that there is enough information to make sense of the issue.
Best Answer
Just in case, because you said you are a total noob: A tun (layer 3) or tap (layer 2) interface is the network interface endpoint of an application, and the application can read and write packets from this network interface. What you create with
ip tuntap add ...
or the outdatedtunctl
are persistent names for such endpoints, and you'll normally still run the application, and it won't do anything unless you run the application.As the application interacts with the network interface as a matter of design, there's no need to "inject" packets with a third party application, unless you mean by "inject' this normal interaction I described.
Also, if you want to play around with networking, I can recommend using network namespaces and veth pairs. Basically you can set up a lot of virtual computers on your computer that can mimic communication between real computers on a network.
So if you want to do that, and don't want to play with your own application creating and receiving packets, you don't need a tun/tap interface.
That said, I just tested your setup, with a slight variation because you didn't say what you use to "inject" packets: I used two
socat
s to create to tap endpointtap0a
andtap1a
, then I bridged them, and used another twosocat
s in two different namespaces to create the correct packets for me. They need to be in a different namespace, as local packets will always be delivered via loopbacklo
.And as expected, bridging tap devices works just fine.
So I suppose the problem is in the packet you are injecting: Wrong ethernet address, or no broadcast. Please edit your question with with
tcpdump -xx ...
output when you inject the ARP packet.Or possibly you'd like to create network namespaces and bridge two endpoints of two veth-pairs instead? That's a lot simpler.
Edit
The ARP packet looks good. It seems like there's no application connected to
tap2
. If you doip link
, you shouldn't see aLOWER_UP
flag fortap2
. Guess: The bridge detects that the device is only partially up, and doesn't send packets to this port.Try replacing it with a
tap
that has an application connected to it, something like(the
10.0.2.2/24
address doesn't do anything, butsocat
won't work if you don't specify an address), and in another terminal(that replaces
brctl addif
), then inject your packet several times and see if you get a hexdump in the first window. Also check forLOWER_UP
withip link show dev tapx
.BTW,
ifconfig
andbrctl
are outdated. Useip
andbridge
instead.Not assigning IP addresses to the ports of the bridge doesn't matter, because bridge ports don't have IP addresses (if they got some assigned to them before they became enslaved by a bridge, they are ignored). See e.g. here.