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.
