On Wed, Aug 23, 2017 at 1:08 AM, Akshat Kakkar <akshat.1...@gmail.com> wrote: > > On Tue, Aug 22, 2017 at 5:58 PM, Neal Cardwell <ncardw...@google.com> wrote: > > On Tue, Aug 22, 2017 at 1:42 AM, Akshat Kakkar <akshat.1...@gmail.com> > > wrote: > >> There are multiple hosts/clients. All are mainly windows based. > >> > >> Timestamp is not used as my clients mainly are windows based and in > >> that it tcp timestamp is by defauly disabled. > > ... > >> net.ipv4.tcp_tw_reuse=1 > >> net.ipv4.tcp_tw_recycle=1 > > > > I suspect the problem is there. The net.ipv4.tcp_tw_recycle setting > > should be 0. Running with the value 1 is known to cause buggy behavior > > related to TCP timestamps, and that feature has been removed in kernel > > v4.12. > > > > Can you please re-run your tests with net.ipv4.tcp_tw_recycle=0 or a > > newer kernel? > > > > neal > > Thanks for your reply. > > I understand that. > > But my point is, though tcp timestamp is enabled on the server, but as > client is not using it ... so how come this _bug_ (if any) is > triggered in first place.
You mention "clients mainly are windows based". if they are only "mainly" Windows-based, and some are of other OSes that do use TCP timestamps, and the remote address is the same for TCP-timestamp-using and non-TCP-timestamp-using clients, then running with timestamps enabled on the server could tickle the bugs in pre-4.12 kernels that save info from TCP-timestamp-using connections and erroneously try to use that info to validate non-TCP-timestamp-using connections. But the main point is that the configuration you cited (net.ipv4.tcp_tw_recycle=1) is an unsupported configuration with known bugs. The best resolution would be to just run with net.ipv4.tcp_tw_recycle=0. It's not worth digging any further unless you run with net.ipv4.tcp_tw_recycle=0 or a kernel that is v4.12 or later and still have problems. Hope that helps, neal
