OoO En ce début d'après-midi nuageux du mercredi 06 août 2008, vers 14:38, Guus Sliepen <guus@debian.org> disait : > Ok, I see now that only one side of the etherpuppet tunnel uses a > tun/tap device, the other side copies everything to/from a real Ethernet > interface. > Still, the other tools I mentioned can all handle Ethernet frames. In > fact, tinc can be compiled to connect to a real Ethernet interface > instead of a tun/tap device, so it might already have the capability to > do what etherpuppet does. The advantage of these tools is that they can > provide encryption, and some of them can connect more than two endpoints > together. etherpuppet is just a tiny tool (one .c) that does one thing. The documentation of tinc does not mention that it is able to attach to a real Ethernet interface. It just mentions bridges which won't help in our case. > The reason I urge you to consider having upstream merge his > functionality with one of the others is that otherwise there is yet > another tunnel tool out there. As stated by others, etherpuppet is not really a tunnel tool. It is just a way to make a remote interface a local one. No routing, no switching. -- GOLDFISH DON'T BOUNCE GOLDFISH DON'T BOUNCE GOLDFISH DON'T BOUNCE -+- Bart Simpson on chalkboard in episode 9F14
Attachment:
pgpXSV_qtBuVf.pgp
Description: PGP signature