netdev - Re: problem forwarding IP fragments with DF bit set (caused by ipv4: fix path MTU discovery with connection tracking)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140429144513.GA12969@macbook.localnet>
Date:	Tue, 29 Apr 2014 15:45:15 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Maxime Bizon <mbizon@...ebox.fr>
Cc:	Eric Dumazet <edumazet@...gle.com>, davem@...emloft.net,
	netdev <netdev@...r.kernel.org>
Subject: Re: problem forwarding IP fragments with DF bit set (caused by ipv4:
 fix path MTU discovery with connection tracking)

On Tue, Apr 29, 2014 at 04:42:15PM +0200, Maxime Bizon wrote:
> 
> On Tue, 2014-04-29 at 15:33 +0100, Patrick McHardy wrote:
> 
> > That is the correct behaviour.
> 
> is it ?
> 
> say the remote host is sending two 1000 bytes fragments, with DF set to
> me and my MTU is 1500, I'm suppose to route these packets to an
> interface with the same MTU.
> 
> without conntrack both fragments are correctly forwarded
> 
> with conntrack, the original packet is re-assembled, then instead of
> forwarding it, we send a "frag needed mtu = 1500" to the remote host,
> which never sent any packets bigger than 1500 at the beginning.

Right, that is not correct of course. We save the original packet size
and should either refragment to that size or send an ICMP frag required
if the original size exceeds the outgoing MTU.

So your patch does look correct, however we should probably only set
local_df in conntrack defrag.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html