Ping does not work on TAP interfaces with bridge

Solution 1:

I think you didn't grasp what's the role and usage of tun/tap interfaces, and that's the cause of your problems. Let me explain.

Consider the tap0 interface as the end of a virtual wire with two sides: the visible side: tap0, and the invisible side of the wire in the application: this invisible side has to be entirely handled by the application. The application will receive ethernet frames as data payload read on a file descriptor, if needed decode this data as ethernet (because it's in tap mode), then as ARP or IP and will then react to any needed event. In short your application requires a TCP/IP network stack, to be able to answer a ping.

Examples of such applications using tun/tap devices are openvpn or the combination of QEMU+VM+OS (QEMU is here to present this data payload to a network device driver of the VM's OS the same way this driver would see from an actual network device).

When you enslave tap0 and tap1 to the bridge, they become bridge ports: that's a hint they should not receive an IP (would it make sense to assign an IP to each port of your 24-ports switch?): those IPs are mostly ignored, except as an IP belonging to the host: a route with scope local is thus added to the local routing table. You could have added those IPs to the lo loopback interface with the same result. Beside this, there's no route that will work with those interfaces bridge ports, what matters now is their master br0.

What you should do is add an IP on the bridge itself (the route will then use the br0 interface) or instead you can create a veth pair, enslave one side to the bridge, and add an IP on the other side: the route will use the veth interface with the IP on it (and leave the bridge without IP which is cleaner imho).

Now for the remaining part it all depends on your application: it has to handle those 192.168.13.1 and 192.168.13.2 IPs itself, including first replying to ARP requests for them, before replying to ICMP echo requests.

If you're now discovering that the application's role is not just to create the tun/tap interfaces, then you should forget using an application and tun/tap interfaces: use network namespaces which duplicate as many network stacks as needed, create bridges where needed, and veth interfaces accross those namespaces. It can all be tested with ip netns and ip link add ... type veth ....

Here are some links to the first 3 parts of a tutorial making use of bridge and veth interfaces with network namespaces (alas they don't use ip netns which is easier to have the job done):

Fun with veth-devices, Linux bridges and VLANs in unnamed Linux network namespaces – I II III