On May 4, 2008, at 6:42 AM, [EMAIL PROTECTED] wrote:
P.S. I've written a unix driver that actually binds to eth0 (or
other
device) and operates there. This allows you to test inter-computer
communication in unix (tap/tun seem to only work on the machine
running the
program and no other machine can access this). Is this something
that is
useful to the community?
You need to bridge the tun/tap interface with for instance eth0
for it
to be available on the "real" network. This is my sh script that does
bridging:
There you go, I _thought_ I had already used the unix port from
inside a VM to communicate with the guest OS (which means it is
visible to the outside network). Even so, I quite like the idea of
the other driver as it is more straightforward (and bridge-utils
aren't necessary). Is there any advandage of the tun/tap over the
raw socket approach?
Simon
One issue about the direct ethernet driver is that you have to get an
IP that exists on the current network that doesn't conflict. The tun/
tap driver may have similar problems if you're on the 192.168.0 network.
One disadvantage of my driver is that it attaches to the same device
as the 'real' IP stack, so it gets first dibs at looking at the
packet before passing it on (in the kernel) to my driver. This causes
a little latency (not sure how much).
An advantage of my driver is that it will work with any OS with BSD
type sockets (i.e. it supports E_P_ALL). The tun/tap is an extension
that needs to be compiled as on in the kernel.
-rishi
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
