Re: [NETFILTER]: xt_TCPMSS: Consider reverse route's MTU in clamp-to-pmtu

[Patrick McHardy <kaber@trash.net>]

Jaco Kroon wrote:
> Jan Engelhardt wrote:
>> On Jan 23 2008 23:29, Patrick McHardy wrote:
>>   
>>>> +static u_int32_t tcpmss_reverse_mtu4(const struct iphdr *iph)
>>>> +{
>>>> +	struct flowi fl = {.nl_u = {.ip4_u = {
>>>> +		.daddr = iph->saddr,
>>>> +		.tos   = RT_TOS(iph->tos),
>>>>   
>>>>       
>>> This doesn't make much sense, we don't know the ToS value
>>> that will be used in the reverse direction.
>>>     
>> Usually it will be the same TOS with default setups.
>> Interactive SSH sessions for example set IPTOS_LOWDELAY,
>> on both sides.
>>   
> _Usually_.  I've seen cases (especially with VoIP) where TOS in one
> direction is 0x10 and then 0x68 in the other.  However, this is on top
> of udp, for which this patch has no effect.
>>   
>>> use routing rules based on source address, iif etc., so I
>>> think we should make this optional.
>>>     
>> iif yes; should be a matter of in->ifindex or so.
>>   
> I'd reckon that's a definite "yes, we should fill in iif and saddr"! 


saddr and iif don't work without more complicated changes since
we'd have to use input routing.

> This should cover 99.99% of cases where this is useful, and the only
> potentially problematic case I can envision is with asymmetric routing
> between the gateway this is running on and the final destination.  And
> chances are that even in those cases the oif of two different incoming
> routes are going to be the same.


The problem is that we can't determine all keys used in the
reverse direction, which becomes obvious if you think of
mark based routing. So I'm wondering how many setups this
would break. Leaving the routing as it is and making it
optional looks safer, with the downside that most users
probably want this and won't notice the new option.