Apenas no caso, porque você disse que é um noob total: A interface tun (camada 3) ou tap (camada 2) é o ponto de extremidade da interface de rede de um aplicativo, e o aplicativo pode ler e gravar pacotes a partir dessa interface de rede . O que você cria com ip tuntap add ... ou o desatualizado tunctl são nomes persistentes para esses nós de extremidade, e normalmente você ainda executará o aplicativo, e ele não fará nada a menos que você execute o aplicativo.
Como o aplicativo interage com a interface de rede como uma questão de design, não há necessidade de "injetar" pacotes com um aplicativo de terceiros, a menos que você queira dizer "injetar" essa interação normal que descrevi.
Além disso, se você quiser brincar com redes, posso recomendar o uso de namespaces de rede e veth pairs . Basicamente, você pode configurar muitos computadores virtuais no seu computador que podem imitar a comunicação entre computadores reais em uma rede.
Então, se você quer fazer isso e não quer brincar com seu próprio aplicativo criando e recebendo pacotes, você não precisa de uma interface tun / tap.
Dito isso, acabei de testar sua configuração, com uma pequena variação porque você não disse o que usa para "injetar" pacotes: usei dois socat s para criar o ponto de extremidade tap0a e tap1a Depois, eu os preenchi e usei outros dois socat s em dois namespaces diferentes para criar os pacotes corretos para mim. Eles precisam estar em um namespace diferente, pois os pacotes locais sempre serão entregues via loopback lo .
E, como esperado, os dispositivos de toque de ponte funcionam bem.
Então, suponho que o problema esteja no pacote que você está injetando: Endereço Ethernet incorreto ou sem transmissão. Por favor, edite sua pergunta com tcpdump -xx ... output quando você injetar o pacote ARP.
Ou talvez você gostaria de criar namespaces de rede e fazer a ponte entre dois pontos de extremidade de dois pares de veth? Isso é muito mais simples.
Editar
O pacote ARP parece bom. Parece que não há nenhum aplicativo conectado a tap2 . Se você fizer ip link , não verá um sinal LOWER_UP para tap2 . Guess: A bridge detecta que o dispositivo está apenas parcialmente em cima e não envia pacotes para esta porta.
Tente substituí-lo por um tap que tenha um aplicativo conectado a ele, algo como
sudo socat TUN:10.0.2.2/24,tun-name=tapx,tun-type=tap,iff-up - | hexdump -C
(o endereço 10.0.2.2/24 não faz nada, mas socat não funciona se você não especificar um endereço) e em outro terminal
sudo ip link set tapx master br0
(que substitui brctl addif ), então injete seu pacote várias vezes e veja se você obtém um hexdump na primeira janela. Verifique também por LOWER_UP com ip link show dev tapx .
BTW, ifconfig e brctl estão desatualizados. Use ip e bridge .
Não atribuir endereços IP às portas da ponte não importa, porque as portas de ponte não têm endereços IP (se elas forem atribuídas a elas antes de se tornarem escravizadas por uma ponte, eles são ignorados). Veja por exemplo aqui .