blob: b3e6784abe79460601c3f8b2cbc2c4d02e74eb8f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
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.
|
