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.
