All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Steinmetz <ast@domdv.de>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org,
	Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: mss to pmtu clamping partially broken?
Date: Fri, 29 Jun 2007 14:06:43 +0200	[thread overview]
Message-ID: <4684F5D3.8020506@domdv.de> (raw)
In-Reply-To: <4684F4FB.9070807@trash.net>

Patrick McHardy wrote:
> Andreas Steinmetz wrote:
>> Patrick McHardy wrote:
>>
>>> Andreas Steinmetz wrote:
>>>
>>>> [...]
>>>> The tcpdump on the client shows that the mss of the incoming syn reply
>>>> packet is *NOT* clamped to the ppp interface mtu.
>>>
>>> You forgot to mention *how* you're clamping the MSS. Using
>>> TCPMSS? Do you have a rule for incoming packets?
>>>
>>
>> The relevant iptables commands I do use for masquerading and clamping are:
>>
>> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
>> 	--clamp-mss-to-pmtu
> 
> 
> Two things here:
> 
> - tcpdumps on ppp0 will show unclamped packets since they haven't
> been forwarded yet
> 

That is true, I know this.

> - assuming you have ethernet internally, the PMTU from your router
> to the internal hosts is 1500, so it won't do any clamping.
> 

Yep, internal PMTU is 1500, still the incoming packets are clamped to
1452 on the one line and not clamped on the other.

> Does that explain it?
> 
> A useful thing for TCPMSS for routers would be to clamp to the
> minimum of the PMTU of both directions. But thats not supported
> so far.
> 

I wonder, as somteimes it gets clamped. If it would never have been
clamped I wouldn't have asked.

-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

WARNING: multiple messages have this Message-ID (diff)
From: Andreas Steinmetz <ast@domdv.de>
To: Patrick McHardy <kaber@trash.net>
Cc: Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>,
	netfilter-devel@lists.netfilter.org
Subject: Re: mss to pmtu clamping partially broken?
Date: Fri, 29 Jun 2007 14:06:43 +0200	[thread overview]
Message-ID: <4684F5D3.8020506@domdv.de> (raw)
In-Reply-To: <4684F4FB.9070807@trash.net>

Patrick McHardy wrote:
> Andreas Steinmetz wrote:
>> Patrick McHardy wrote:
>>
>>> Andreas Steinmetz wrote:
>>>
>>>> [...]
>>>> The tcpdump on the client shows that the mss of the incoming syn reply
>>>> packet is *NOT* clamped to the ppp interface mtu.
>>>
>>> You forgot to mention *how* you're clamping the MSS. Using
>>> TCPMSS? Do you have a rule for incoming packets?
>>>
>>
>> The relevant iptables commands I do use for masquerading and clamping are:
>>
>> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
>> iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
>> 	--clamp-mss-to-pmtu
> 
> 
> Two things here:
> 
> - tcpdumps on ppp0 will show unclamped packets since they haven't
> been forwarded yet
> 

That is true, I know this.

> - assuming you have ethernet internally, the PMTU from your router
> to the internal hosts is 1500, so it won't do any clamping.
> 

Yep, internal PMTU is 1500, still the incoming packets are clamped to
1452 on the one line and not clamped on the other.

> Does that explain it?
> 
> A useful thing for TCPMSS for routers would be to clamp to the
> minimum of the PMTU of both directions. But thats not supported
> so far.
> 

I wonder, as somteimes it gets clamped. If it would never have been
clamped I wouldn't have asked.

-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

  reply	other threads:[~2007-06-29 12:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 11:09 mss to pmtu clamping partially broken? Andreas Steinmetz
2007-06-29 11:39 ` Patrick McHardy
2007-06-29 11:58   ` Andreas Steinmetz
2007-06-29 11:58     ` Andreas Steinmetz
2007-06-29 12:03     ` Patrick McHardy
2007-06-29 12:06       ` Andreas Steinmetz [this message]
2007-06-29 12:06         ` Andreas Steinmetz
2007-06-29 12:13         ` Patrick McHardy
2007-06-29 12:16           ` Andreas Steinmetz
2007-06-29 12:16             ` Andreas Steinmetz
2007-07-02 17:02           ` Andreas Steinmetz
2007-06-30  8:35 ` Jan Engelhardt
2007-07-02 17:04   ` Andreas Steinmetz
2007-07-02 17:04     ` Andreas Steinmetz
2007-07-02 18:28     ` Phil Dibowitz
2007-07-02 19:16       ` Krzysztof Oledzki
2007-07-02 19:16         ` Krzysztof Oledzki
2007-07-02 19:35         ` Phil Dibowitz
2007-07-02 19:35           ` Phil Dibowitz
2007-07-02 19:50           ` Krzysztof Oledzki

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=4684F5D3.8020506@domdv.de \
    --to=ast@domdv.de \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@lists.netfilter.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.