Re: TUN/TAP hacking

Re: TUN/TAP hacking

[Dan Noé]

Ignacy Gawedzki wrote:
> I need some advice from network stack experts, so I hope this is the right
> place to ask.

The Linux kernel networking folks hang out at netdev
(netdev@vger.kernel.org).  I've CC'd them...

> I thought I'd be able to use the TAP interfaces to create some sort of a
> network emulator.  For a start I just "bridged" two tap interfaces, much in
> the same way as the example of br_select.c from http://vtun.sf.net , assigned
> both interfaces different IPv4 addresses (both with a /32 prefix), set them up
> and tried to transmit a UDP packet from one address to the other through the
> bridge.  Both logs from my bridge program and tcpdump tell me that the packets
> are flowing as expected, but somehow the destination process doesn't get the
> packets (despite all correct bind, etc).
> 
> Is it simply that the stack inconditionally drops any packet with the same
> source (IP and/or MAC) address as some local interface?
> 
> As ARP resolution seems not to work either (I had to put permanent entries in
> the neighbor table), I suppose this is the case indeed.
> 
> Could anyone confirm that? (please CC me, I've not subscribed)
> 
> Thanks,
> 
> Ignacy
> 


-- 
                    /--------------- - -  -  -   -   -
                    |  Dan Noé
                    |  http://isomerica.net/~dpn/

Re: TUN/TAP hacking

[Marek Kierdelewicz]

Hi Ignacy & netdev,

> I thought I'd be able to use the TAP interfaces to create some sort
> of a network emulator.  For a start I just "bridged" two tap
> interfaces, much in the same way as the example of br_select.c from
> http://vtun.sf.net , assigned both interfaces different IPv4
> addresses (both with a /32 prefix),

As far as I understand you're trying to bridge two interfaces of the
same host. It's no good for a test network, because local traffic
(from/to the same host) will always be forwarded locally (via lo?) and
will never reach any ethX or tapX interface (not without kernel
hacking). There's another way... You can use QEMU[1]/KQEMU[2]/KVM[3] for
guest system virtualization with options that create tapX interfaces
on host and ethX on guests. Then you can bridge taps the way you want
(even with eths on your host system) as described in [4][5]. For guest
system I'd recommend openwrt kamikaze[6]. It's small in terms of system
image size and memory consumption so you can build a complex virtual
network of 10+ hosts using only 200MB of disk space and 320MB of ram.

[1] http://bellard.org/qemu/
[2] http://bellard.org/qemu/kqemu-doc.html
[3] http://kvm.qumranet.com/kvmwiki
[4] http://www.fedoraforum.org/forum/showpost.php?p=530775&postcount=1
[5] http://calamari.reverse-dns.net:980/cgi-bin/moin.cgi/bridge
[6] http://openwrt.org/

Cheers,
Marek Kierdelewicz

Re: TUN/TAP hacking

[Ignacy Gawedzki]

On Thu, Jul 24, 2008 at 08:50:06AM +0200, thus spake Marek Kierdelewicz:
> Hi Ignacy & netdev,
> 
> > I thought I'd be able to use the TAP interfaces to create some sort
> > of a network emulator.  For a start I just "bridged" two tap
> > interfaces, much in the same way as the example of br_select.c from
> > http://vtun.sf.net , assigned both interfaces different IPv4
> > addresses (both with a /32 prefix),
> 
> As far as I understand you're trying to bridge two interfaces of the
> same host. It's no good for a test network, because local traffic
> (from/to the same host) will always be forwarded locally (via lo?) and
> will never reach any ethX or tapX interface (not without kernel
> hacking).

Well... surely this would happen without a little hack as you say.  Here I
thought that I could use multiple routing tables + ip rules + iptables, but
I'm not 100% convinced that locally generated packets could be marked with
iptables and directed by ip rules to the correct routing table (which would
make no mention of the destination address as a local interface).  I made a
few tests with ping (using -I to specify the outgoing interface), but ARP
resolution failed and I see no way to force the destination stack reply to
echo-requests using a specific routing table (as I intended to do for normal
applications).

>           There's another way... You can use QEMU[1]/KQEMU[2]/KVM[3] for
> guest system virtualization with options that create tapX interfaces
> on host and ethX on guests. Then you can bridge taps the way you want
> (even with eths on your host system) as described in [4][5]. For guest
> system I'd recommend openwrt kamikaze[6]. It's small in terms of system
> image size and memory consumption so you can build a complex virtual
> network of 10+ hosts using only 200MB of disk space and 320MB of ram.

Yeah, I also thought about that one, but if I could avoid the additional
overhead, it would be better.

> Cheers,
> Marek Kierdelewicz

Dzięki anyway. =)

-- 
NO CARRIER