(tinc-up is started after tap device is opened) and b. is needed for
tun/tap device, where the interface does not exist anymore after the
device file is closed.
- Set mymac to broadcast MAC so that ifconfig hw ether <...> is really not
needed anymore.
- Forwarding of indirect packets when in switch mode (because the kernel
will not do it for us then).
- Mode = router (default, work like tinc has always worked)
- Mode = switch (work like a switch)
- Mode = hub (work like a hub, broadcasting everything)
- Fix compiler warnings (one was a real (but harmless) bug)
- Don't send PING packets if there is UDP traffic
- Correctly terminate strings containing salt for PING/PONG packets
- flags are removed, since they were not used at all. Use options instead.
- indirectdata works now, tcponly almost...
- made functions that don't return useful information void
Note: tinc ignores private key in the main config file, tinc.conf,
because it should really be in a separate file.
- When generating new keys, check if name is known and by default append
the public key to the host configuration file (otherwise rsa_key.pub).
PrivateKey. This means thatt he meaning of this variable has changed,
it no longer should contain the private key directly.
WARNING: This code is untested.
- Added some extra search functions to rbl routines
- Fix subnet_lookup()
- Reorder some syslog messages to make more sense
- daemon() is back
- Don't let scripts execute in parallel (gives race conditions, and
anyway something MIGHT just be configured which is necessary for further
execution of tinc itself)
- Accidently merged check_child() with execute_script().
- Small fixes
- More #includes Linux doesn't seem to need
- Don't do unsetenv() on SunOS
- Use a replacement asprintf() in case the OS doesn't support it
It now compiles properly under SunOS.
- Do not free() strings that have been putenv()d, see man page of the
latter.
- Do not set IFNAME anymore, it appears that the ioctl to get the name of
the interface does not work at all. Since it is set to NETNAME in case
of tun/tap and it is known beforehand in case of ethertap, there is no
need for it anyway... (though it would've simplified things).
