Stéphane Charette a écrit : > > Yes, I have one interface connected to my cable modem which DHCPs a > 192.168.1.x address, and I'm using the alias (or the TAP interface) to > bring up a different 10.x network for my local machines. > >>> But if instead of creating an alias with the ifconfig command, I >>> instead use a TAP device opened up from some C++ code with the same >>> 10.0.1.1/24 address, I don't see any traffic coming into the TAP >>> interface. >> >> How do you send trafic through the TAP interface ? > > This is the part I'm thinking I did wrong. How should I get traffic > to flow through the TAP interface? You just send packets to an address which belongs to the subnet assigned to the TAP interface (but not the TAP interface address itself). However your design is broken : assigning 10.0.1.1/24 to the TAP interface tells the system that the 10.0.1.0/24 subnet is reachable through the TAP interface. However the subnet is actually connected to the ethernet interface. That cannot work. >>> What I eventually want is to have a user-space C++ application that >>> can examine traffic, and make decisions on what traffic to drop, >>> modify packets, or packets to log. Then that C++ application sends >>> the remaining packets on their way. Is it possible to use iptables >>> for this? It may be possible with advanced routing : - Create a TUN interface, say "tun0", instead of TAP. You don't need the ethernet layer. - Activate it but don't assign any address to it. Leave 10.0.1.1/24 on the ethernet interface. - Route forwarded packets received on the ethernet interface to the TUN interface : ip rule add iif eth0 lookup 10 ip route add default dev tun0 If I'm correct, packets received on eth0 should be routed to tap0 and passed to the application, and packets sent back by the application should be received on tap0 and routed to eth0 using the main routing table. Note that locally sent or received (not forwarded) packets are not affected. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
