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]
Message-ID: <alpine.LFD.2.20.1607081340430.26593@stoner.jakma.org>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ