fastd v17
=========

New features
~~~~~~~~~~~~
* Per-peer-group method specification

  It is now possible to override the supported
  crypto methods per peer group.

* Connection reset via SIGUSR2

  Sending a SIGUSR2 to the fastd process will
  reset all connections.

* Support for Android 4.1+

  Contributed by Rick Lei. See ``doc/README-Android.md``.

* Faster handshake

  fastd's handshake should now take significantly less time (about
  30-50%, not regarding the network latency). Due tue this change fastd
  depends on libuecc v5 (which is released together with fastd v17) now.

Bugfixes
~~~~~~~~
* Removed broken ``pmtu`` option

  The ``pmtu`` option was changed into a no-op (and fastd's behaviour was changed to
  what was ``pmtu no`` before) as fastd didn't handle a potentially discovered smaller
  path MTU correctly. It will probably return in a future version of fastd.

* Improve handling of incoming packets from many peers after restarting fastd

  fastd will generate only one handshake per peer every 15 seconds now
  instead of one handshake per incoming packet.

* Added a missing security check during handshake

  While I don't think this issue allowed an attacker to impersonate a legitimate peer or
  perform a man-in-the-middle attack, fastd did accept some weird keys
  (the identity point) as valid keys, which shouldn't be possible.

* Fixed handling of severely reordered packets

  While fastd is supposed to handle reordered packets up to
  64 sequence numbers, a bug would cause it to drop all older
  packets after a packet with a sequence number more than 64
  packets in the future was received.

  The "verification failed" message has been downgraded from the "verbose"
  to the "debug2" level as it will cause a lot of log spam when there is
  extreme reordering.

* x86 uClibc workaround

  A workaround has been added for systems without or with broken ``epoll_pwait`` libc
  wrappers. One libc with such a broken wrapper is the uClibc version used in OpenWrt on x86,
  which made fastd fail on OpenWrt x86 systems.

* Only send packets from configured bind addresses

  When a configuration file contains only an IPv4 bind address and fastd tried to connect to an IPv6
  remote address, it would use a random source port instead of falling back to IPv4 (and vice-versa).

  The behaviour without any bind addresses in the configuration hasn't been changed.

Other changes
~~~~~~~~~~~~~
* Better debug messages

  The sender's public key will now be printed with
  more messages regarding handshake issues.

* New handshake format

  Some parts of the handshake had been submitted as little endian for historical reasons.
  As the normal network byte order is big endian, support for a new handshake format using
  big endian has been added.

  fastd will continue to send its handshake the old format for the next versions to maintain
  compatiblity, but it does also understand the new format and will thus also work with future
  fastd versions which use the new handshake.

* MTU mismatch is fatal

  fastd will now refuse to perform a handshake instead of just printing a warning when its configured MTU
  doesn't match the peer's one. Such a configuration is always broken and will lead to issues with
  big packets.