> On Wed, Apr 19, 2017 at 09:57:55PM +0200, Pablo Neira Ayuso wrote: > > On Wed, Apr 19, 2017 at 09:22:08AM -0700, Eric Dumazet wrote: > > > On Wed, 2017-04-19 at 17:58 +0200, Pablo Neira Ayuso wrote: > > > > On Wed, Apr 19, 2017 at 09:23:42AM +0800, gfree.wind@xxxxxxxxxxx > wrote: > > > > > From: Gao Feng <fgao@xxxxxxxxxx> > > > > > > > > > > The window scale may be enlarged from 14 to 15 according to the > > > > > itef draft https://tools.ietf.org/html/draft-nishida-tcpm-maxwin-03. > > > > > > > > > > Use the macro TCP_MAX_WSCALE to support it easily with TCP stack > > > > > in the future. > > > > > > > > Applied, thanks. > > > > > > Note that linux kernel is not ready yet for a TCP_MAX_WSCALE being > > > changed to 15. > > > > > > Signed 32bit sk counters can already be abused with 1GB TCP windows, > > > for malicious peers sending SACK forcing linux to increase its > > > memory usage above 2GB and overflows are pretty bad. > > > > We have tend to use our own definitions for the TCP connection > > tracking so far. This one I checked it refers RFC1323 too. > > > > If this semantics may change from one way to another in a way that may > > break conntracking, please let me know, I can toss it here. > > Or I can just amend the commit here to remove the "enlarged from 14 to 15" > comment, I was going to push out this now, but I'll wait a bit. Thanks Eric & Pablo, When the wscale is really enlarged to 15 one day, these Netfilter codes may be modified. Because it would reset the wscale value to the max value which Netfilter support it. if (state->td_scale > 14) state->td_scale = 14; It would cause the receive see a less window size than sender announced actually. Best Regards Feng -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
