On Mon, Jul 22, 2019 at 11:31:45AM +0300, İbrahim Ercan wrote: > On Mon, Jul 1, 2019 at 9:58 PM Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > > Hi Ibrahim, > > > > On Thu, Jun 27, 2019 at 09:27:05PM +0200, Pablo Neira Ayuso wrote: > > > On Thu, Jun 27, 2019 at 09:21:09PM +0200, Florian Westphal wrote: > > > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > > > On Thu, Jun 27, 2019 at 09:00:19PM +0200, Florian Westphal wrote: > > > > > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > [...] > > > > > I see, probably place client_mss field into the synproxy_options > > > > > structure? > > > > > > > > I worked on a fix for this too (Ibrahim was faster), I > > > > tried to rename opts.mss so we have > > > > > > > > u16 mss_peer; > > > > u16 mss_configured; > > > > > > > > but I got confused myself as to where which mss is to be used. > > > > > > > > perhaps > > > > u16 mss_option; > > > > u16 mss_encode; > > > > > > > > ... would have been better. > > > > > > I would leave the opts.mss as is by now. Given there will be a > > > conflict between nf-next and nf, I was trying to minimize the number > > > of chunks for this fix, but that's just my preference (I'll have to > > > sort out this it seems). > > > > > > Then, adding follow up patches to rename fields would be great indeed > > > as you suggest. > > > > @Ibrahim: Would you follow up with patch v3? > > > > I'd name this 'mss_backend' to opts, instead of adding client_mss as > > parameter. Since this is the MSS that the server backend behind the > > proxy. > > > > I don't mind names, if you prefer Florian's, that's also fine. I'd > > just like not to add a new parameter to synproxy_send_client_synack(). > > > > Thanks. > > Sorry for late reply. I was offline for 3 weeks. I will send new patch asap. Please, do, based it on kernel 5.2 Fernando already made a patch for 5.3-rc, we'll take your patch for -stable, as a backport.
