Adding git commit id and description just for the kernel team to reference as well. Thanks.
commit 9b42c336d06411e6463949d2dac63949f66ff70b
Author: Eric Dumazet <email address hidden>
Date: Mon Oct 1 13:58:36 2007 -0700
[TCP]: secure_tcp_sequence_number() should not use a too fast clock
TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
In order to follow network speed increase, we can use a faster clock, but
we should limit this clock so that the delay between two rollovers is
greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)
Choosing a 64 nsec clock should be OK, since the rollovers occur every
274 seconds.
Problem spotted by Denys Fedoryshchenko
[ This bug was introduced by f85958151900f9d30fa5ff941b0ce71eaa45a7de ]
Signed-off-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Adding git commit id and description just for the kernel team to reference as well. Thanks.
commit 9b42c336d06411e 6463949d2dac639 49f66ff70b
Author: Eric Dumazet <email address hidden>
Date: Mon Oct 1 13:58:36 2007 -0700
[TCP]: secure_ tcp_sequence_ number( ) should not use a too fast clock
TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
In order to follow network speed increase, we can use a faster clock, but
we should limit this clock so that the delay between two rollovers is
greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)
Choosing a 64 nsec clock should be OK, since the rollovers occur every
274 seconds.
Problem spotted by Denys Fedoryshchenko
[ This bug was introduced by f85958151900f9d 30fa5ff941b0ce7 1eaa45a7de ]
Signed-off-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>