Why we say you should ifconfig $INTERFACE hw ether fe:fd:0:0:0:0

[Guus Sliepen]

On Tue, Jun 10, 2003 at 04:47:21PM -0500, Shashank Khanvilkar wrote:

> > ifconfig $INTERFACE hw ether fe:fd:0:0:0:0
> 
> As you pointed out, the error was with the ether net HW address. If you do 
> get time 
> in future, please let me know why this happens (and whether it happens in 
> the other modes, i.e. switch and hub).

The reason for this is mostly a historic one. When we started with what
now is called tinc, the ethertap functionality was just introduced in
the Linux kernel. There was no other method available with such a clean
userspace interface at that time.

The ethertap device simulates a real ethernet device, so you read and
write ethernet frames to and from /dev/tap0. At first, tinc could only
tunnel between two nodes and didn't care about the contents of the
packets. Because we just wanted to tunnel IPv4 traffic, we stripped the
ethernet headers and put a fake one back at the end. Because ARP isn't
an IPv4 protocol, we had to ifconfig tap0 -arp. However, tap0 was still
an ethernet device, and as such it shouldn't accept packets which don't
have the same destination MAC address as its own. Originally, the
ethertap driver didn't check for that though.

Later on the ethertap driver was modified to properly check the
destination MAC address. Because of that, we changed the fake header to
have the same destination MAC address as the default MAC address the
ethertap driver gave the tap interface: fe:fd:0:0:0:0.

Then came the Universal TUN/TAP driver, which could also function as an
Ethernet device. However, it assigned a random MAC address to the
interface. Therefore we said you'd have to ifconfig $INTERFACE hw ether
fe:fd:0:0:0:0, so tinc's fake header would still work.

Actually, tinc now always sends complete ethernet frames, but in routing
mode overwrites the destination MAC address of incoming packets before
sending them to the virtual device to ensure they will be accepted.
It is also not really needed anymore to disable ARP and use
fe:fd:0:0:0:0, because tinc can do proxy-ARP: if the kernel sends an ARP
packet to determine the MAC address of some host, tinc fakes an ARP
response. At the same time it can see the MAC address of the host tinc
is running on (because it is the source address of the ARP request), and
will use that address to overwrite the destination MAC address of
received packets. The only drawback is that if you receive a packet from
another tinc daemon before sending something yourself, tinc doesn't yet know
which MAC address its own virtual interface has. So to be on the safe
side, you should either set the MAC address to fe:fd:0:0:0:0 anyway, or
make sure a packet is sent out (for example, by adding a ping
command to tinc-up).

The cleanest way would be if tinc would use the Universal TUN/TAP
interface in tun mode if tinc is in routing mode, that way you don't
have to worry about ARP or MAC addresses at all. Maybe we should
implement this...

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at sliepen.eu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20030611/ea3a7f64/attachment.pgp