Score:0

Two tap device can't communicate over bridge

cn flag

I want to exchange Ethernet Packet between two tap device(for implementing TCP/IP protocol stack in usermode).

The problem I encountered is that tap1 and tap2 only can receive broadcast packet through bridge but not point to point packet!

For example, when I send packet from tap1 to tap2,tcmpdump can capture packet on tap1,but tap2 can't receive packet.However,when I set detination address as "ff:ff:ff:ff:ff:ff" or any unknown mac address(this will be trigger broadcast),tap2 will receive packet.

My configuration:

  1. create two tap device
ip tuntap add mode tap tun1
ip tuntap add mode tap tun2
# assign ip address for implmenting arp protocol
ip addr add 172.19.16.1 dev tun1
ip addr add 172.19.16.2 dev tun2

ip link set tun1 up
ip link set tun2 up
  1. create a bridge
brctl addbr br0
brctl addif br0 tun1
brctl addif br0 tun2

ip link set br0 up

The following is the state of bridge and tap interface: macs:

port no mac addr                is local?       ageing timer
  2     46:44:6e:55:9b:c5       yes                0.00
  2     46:44:6e:55:9b:c5       yes                0.00
  1     f2:6b:68:c9:60:6b       yes                0.00
  1     f2:6b:68:c9:60:6b       yes                0.00

state:

br0
 bridge id              8000.46446e559bc5
 designated root        8000.46446e559bc5
 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               0.00                 tcn timer                  0.00
 topology change timer     0.00                 gc timer                  89.77
 flags


tun1 (1)
 port id                8001                    state                forwarding
 designated root        8000.46446e559bc5       path cost                100
 designated bridge      8000.46446e559bc5       message age timer          0.00
 designated port        8001                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

tun2 (2)
 port id                8002                    state                forwarding
 designated root        8000.46446e559bc5       path cost                100
 designated bridge      8000.46446e559bc5       message age timer          0.00
 designated port        8002                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

The following is my test code:

import fcntl
import os
import if_tun
import ctypes

import struct
from scapy.all import *


from if_tun import IfReq, TUNSETIFF, IFF_TUN


def register_tun(name: str):
    fd = os.open("/dev/net/tun",os.O_RDWR)
    if fd < 0:
        return fd

    r = IfReq()

    ctypes.memset(ctypes.byref(r), 0, ctypes.sizeof(r))
    r.ifr_ifru.ifru_flags = 0x0002 | 0x1000
    r.ifr_ifrn.ifrn_name = name.encode("utf-8")
    
    fcntl.ioctl(fd, TUNSETIFF,r)
    return fd


if __name__ == "__main__":
    name = input("input device name")
    fd = register_tun(name)
    if fd < 0:
        print("error")
    if name == "tun2":
        while True:
            buf = os.read(fd,1024)
            print(f"receive {len(buf)} data")
            Ether(raw(buf)).show()
    mac1 = "f2:6b:68:c9:60:6b"
    mac2 = "46:44:6e:55:9b:c5"
    while True:
        type = input()
        a = Ether(dst=mac2,src=mac1)/ARP(pdst="172.19.16.1",psrc="172.19.16.2")
        a.show()
        print("write:")
        print(os.write(fd, raw(a)))

Notes:

  1. Although device name called tun,it's type is tap
  2. I run two test code simultaneously, one connect tun1 and other connect tun2. So two device are LOWWER_UP state
A.B avatar
cl flag
A.B
See this Q/A of mine: https://serverfault.com/questions/994721/ping-does-not-work-on-tap-interfaces-with-bridge/996479#996479 (As you know you need an userland app, only a part part of it is of interest)
Miracle avatar
cn flag
@A.B Thanks for your comment, I know that I need handle arp protocol by myself. But now, I can't send Ethernet Packet from tap1 to tap2. So I can't implement arp protocol by myself.
Miracle avatar
cn flag
@A.B Which choice is better among,tap,tun(point-to-point),veth(using raw socket) if I want to implement tcp/ip stack in user-mode. As my idea, I only need a way to directly write Ether Packet to network interface, implement a network driver is obviously very complex and difficult. Using tun also have to resolve local route policy. How about veth pair(different network space,using raw socket)? I don't know which method I should try.
Miracle avatar
cn flag
@A.B My motivation is to learn tcp/ip deeply. Thank you greatly, after settings it work. But I don't quite understand why need to change mac address of tun1 f2:6b:68:c9:60:6b->f2:6b:68:c9:60:6c and tun2 46:44:6e:55:9b:c5->46:44:6e:55:9b:c6 . Both mac address are alloced by os. Whether do I also need to change the destination address of Ether Packet? If no, this will triger broacast. As I my understand, bridge act as a switch role and can route Ether Packet accroding to dest mac address. However, in this situation, it can only broadcast packet.
Score:0
cn flag

Maybe I have got the reason.

Tap/Tun link the network stack and user program.User Program can receive any data which is written to tap card by network stack.

Suppose we have program1 listen to tap1(mac1) and program2 listen to tap2(mac2).

If program1 write a Ether Packet(src=mac1,dst=mac2) to tap1, the network stack will receive the packet.Program2 can only receive the packet if network stack write the packet to tap2.

This is obviously impossible! Mac-Frame without route functionality. Futhermore, the packet belong to the current host.

However, when we write a broadcast packet, network stack will forward the packet to every network card except tap1.

Above is only my shallow understand. I don't know whether it is right.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.