tinc - Apr 2015 - Packet reordering problem?

Hello all,

we are using tinc 1.0.24 with 6 hosts (endpoints).
Quality of service is used with prio qdisc on all network
interfaces. This means depending on the TOS value of the IP header
IP-packets will get a priority queue on the network interface.

Packets from TINC (UDP 655) maybe reordered using these queues to
send out high-prio (VoIP) packets first.
Could this create a problem on the receiving tincd?
I guess the sequence number is checked here, right?

-- 
Mit freundlichen Gr??en / Best regards
Armin Schindler

On Thu, Apr 30, 2015 at 02:55:59PM +0200, Armin Schindler wrote:
> we are using tinc 1.0.24 with 6 hosts (endpoints).
> Quality of service is used with prio qdisc on all network
> interfaces. This means depending on the TOS value of the IP header
> IP-packets will get a priority queue on the network interface.
> 
> Packets from TINC (UDP 655) maybe reordered using these queues to
> send out high-prio (VoIP) packets first.
> Could this create a problem on the receiving tincd?
> I guess the sequence number is checked here, right?
Tinc checks the sequence number, but allows reordering up to a certain
number of packets. Have a look at the ReplayWindow configuration option
in the manual:

http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-ReplayWindow

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20150430/6d7b27f4/attachment.sig>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Guus,

On 04/30/2015 03:42 PM, Guus Sliepen wrote:
> On Thu, Apr 30, 2015 at 02:55:59PM +0200, Armin Schindler wrote:
> 
>> we are using tinc 1.0.24 with 6 hosts (endpoints). Quality of service
>> is used with prio qdisc on all network interfaces. This means depending
>> on the TOS value of the IP header IP-packets will get a priority queue
>> on the network interface.
>> 
>> Packets from TINC (UDP 655) maybe reordered using these queues to send
>> out high-prio (VoIP) packets first. Could this create a problem on the
>> receiving tincd? I guess the sequence number is checked here, right?
> 
> Tinc checks the sequence number, but allows reordering up to a certain 
> number of packets. Have a look at the ReplayWindow configuration option 
> in the manual:
> 
>
http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-Re
playWindow

we
> 
didn't change that setting, so the default is 16.
What exactly will happen if tinc gets a packet which should have arrived
20 packtes before (because of the TOS prio queues)?

Since I activated the prio queues (VoIP packets get highest prio
on eth and tinc device via TOS value), we encountered instability:
We have 6 nodes connected via tinc. If one node becomes unreachable
(internet connection down), normal encrypted packets from/to other nodes
seem to be hanging. Just the high prio VoIP packets seem to be forwarded
by tinc like normal.
Example of nodes A,B,C,D,E and F: A becomes unreachable and suddenly
connections (except high prio queue packets) from B to C, and B to D and C
to D, etc. have massive packet loss.
As soon as A is back online, all goes normal.

Could there be an internal queue togehther with the reordering be the cause?

Armin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVWbo0AAoJEDzoEIEiWMkUkqsP/j2NW3WU3cmb3XEyiEL8Nmlu
Ssmd7Tpqr3XU1y9Z2Ogq4RT8VhTHpzgGcbBx0le7rZ3U2bgYZjCgEk0KNdDcDKtX
6FmCrYeRWmYM6kXvb2ge+qQqacdaghyhlRhFYnoPaBxuh2eZEyTgiG9uAtlTX+D7
PWiXXalN8yqcRPccWsXxgiBjU10HNejcnnlsgN8dHdJSxE4wg7zc07+iHcjQt/hN
AzSRWCQZXMAMwmbEISTWTD3VIErjqjmXIHZy73HqJRYBvJWic3R2sMPiO6Wf1ngN
c9wTvcIZjK02WPXAZSPY2tStU6KlDQXARvsmwyLiixLkVS/z+UoGMNTDslaGk2v9
xU8QU7Pl7D39S19jliFdVpD78Y6isPj5kIL7lXn4q2poQdFeB6NVzEt7E9ufzHRL
eG0F7k12AleFkOWmbngocYmPbYGYfNdkTwTzg+KZn3KXYJRPRvw7+qdvuCuemomH
JclIy28L/yiWwdHKJmZve2z4uQittbyKjweAhPLzSqIzNzw3U/TfBVquf7057ARA
tq1f7VNzlrr/8tyCOGDuOrm5Bf9ysfajQTnYyOkJZUf+WOO+QECWMS27zbhQ+4mJ
KLbpmaYcEZdU4uiert+sj19FtHC/FPHExcpOmv4orHJKbvMCyQjY//DEhT+EhsZ+
wLR2mu/1EsHF5EMjWAb0
=Z2L2
-----END PGP SIGNATURE-----