From: Jaco Kroon <jaco@uls.co.za>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Patrick McHardy <kaber@trash.net>,
Netfilter Developer Mailing List
<netfilter-devel@vger.kernel.org>
Subject: Re: [NETFILTER]: xt_TCPMSS: Consider reverse route's MTU in clamp-to-pmtu
Date: Thu, 24 Jan 2008 05:47:35 +0200 [thread overview]
Message-ID: <47980A57.2020702@uls.co.za> (raw)
In-Reply-To: <Pine.LNX.4.64.0801232341160.12676@fbirervta.pbzchgretzou.qr>
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"!
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.
In asymmetric routing you'd probably be using --set anyway though. Is
there perhaps a custom clamp value available, eg --clamp-to-mtu 1200?
This could be useful for those cases, as well as what we know as
"business dsl" configurations where the setup looks something like:
[ inet ]-----dsl----[bdsl-router]--ether--[LAN-gateway]
In these cases the bdsl router is often closed off to the local
administrator and run by the ISP, and I for one have been having fights
with at least one of these providers who just can't get the MSS field
clamped correctly. So far the only way for me to get that right was to
drop my mtu on the router side to that of the lowest mtu value that I
can find with snmp on the router. Often as low as, or close to, 1200.
Regards,
Jaco
next prev parent reply other threads:[~2008-01-24 4:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-23 20:57 [NETFILTER]: xt_TCPMSS: Consider reverse route's MTU in clamp-to-pmtu Jan Engelhardt
2008-01-23 22:29 ` Patrick McHardy
2008-01-23 22:43 ` Jan Engelhardt
2008-01-24 3:47 ` Jaco Kroon [this message]
2008-01-24 7:53 ` Patrick McHardy
2008-01-24 8:57 ` Jaco Kroon
2008-01-24 9:58 ` Pascal Hambourg
2008-01-24 10:49 ` Jaco Kroon
2008-01-24 11:20 ` Jan Engelhardt
2008-01-29 12:55 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47980A57.2020702@uls.co.za \
--to=jaco@uls.co.za \
--cc=jengelh@computergmbh.de \
--cc=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.