netdev - RE: [PATCH] net: Fragment large datagrams even when IP

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 8 Jul 2016 13:55:11 +0100 (BST)
From:	Paul Jakma <paul@...ma.org>
To:	Alan Davey <Alan.Davey@...aswitch.com>
cc:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
	"kaber@...sh.net" <kaber@...sh.net>
Subject: RE: [PATCH] net: Fragment large datagrams even when IP_HDRINCL is
 set.

On Wed, 15 Jun 2016, Alan Davey wrote:

> The only case that would break is that where an application relies on 
> the existing (documented as a bug) feature of getting an EMSGSIZE 
> return code in the case of an over-sized packet.  Applications that 
> perform their own fragmentation would be unaffected.

If this doesn't break existing applications that are doing fragmentation 
in userspace on raw sockets (e.g. Quagga ospfd), that's better.

As per previous email, I'd love to be able to get rid of that code and 
have the kernel do it for me. However, I also don't want to have to do 
anything other non-trivial to that code either. :)

The issue for us is, how would we know on any given host whether the 
kernel will do the fragmentation or whether ospfd has to do it? We need 
to be able to probe for that capability, surely?

I guess "send an oversized packet and see if we get EMSGSIZE comes back 
or not" could be one way, though the 'man 7 raw' man page ony my system 
says that is returned on raw socket if the /IP/ max size (64 KiB) is 
exceeded - it doesn't say anything about that being returned if output 
MTU is exceeded. Also, that implies a failed packet send on startup on 
older kernels and having to rejiggle the packet we've constructed to 
retry.

Some kind of "I want kernel to do the fragmentation" sockopt, that was 
guaranteed to error with ENOPROTOOPT on non-implementing kernels, that 
we could try set when creating the socket, would seem simpler/nicer from 
my POV of my corner of user-space.

?

regards,
-- 
Paul Jakma | paul@...ma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
It would be nice to be sure of anything the way some people are of everything.