From: Eric B Munson <emunson@akamai.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "David S. Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
James Morris <jmorris@namei.org>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Patrick McHardy <kaber@trash.net>,
Network Development <netdev@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Allow TCP connections to cache SYN packet for userspace inspection
Date: Fri, 1 May 2015 16:01:36 -0400 [thread overview]
Message-ID: <20150501200136.GA6113@akamai.com> (raw)
In-Reply-To: <CALCETrWi6h3DRu6Z8jJ_-MiWqRRyKZHntpJFNON=GpAjMDYXmQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]
On Fri, 01 May 2015, Andy Lutomirski wrote:
> On Fri, May 1, 2015 at 10:43 AM, Eric B Munson <emunson@akamai.com> wrote:
> > In order to enable policy decisions in userspace, the data contained in
> > the SYN packet would be useful for tracking or identifying connections.
> > Only parts of this data are available to userspace after the hand shake
> > is completed. This patch exposes a new setsockopt() option that will,
> > when used with a listening socket, ask the kernel to cache the skb
> > holding the SYN packet for retrieval later. The SYN skbs will not be
> > saved while the kernel is in syn cookie mode.
> >
> > The same option will ask the kernel for the packet headers when used
> > with getsockopt() with the socket returned from accept(). The cached
> > packet will only be available for the first getsockopt() call, the skb
> > is consumed after the requested data is copied to userspace. Subsequent
> > calls will return -ENOENT. Because of this behavior, getsockopt() will
> > return -E2BIG if the caller supplied a buffer that is too small to hold
> > the skb header.
>
> What's the purpose and what headers are you returning?
Currently the ethernet, IP, and TCP headers are being returned. The IP
and TCP headers will be used by userspace to make decisions on how to
handle incoming connections. The ethernet headers are being returned
for completeness, I would be fine not including them in what is copied
if that is a concern, however the team requesting this change here
requires the IP and TCP headers.
>
> There was a bit of a mixup with tx timestamps where the set of headers
> returned was possibly excessive and incompletely thought out the first
> time around.
With this in mind, we could drop copying the ethernet headers and simply
hold onto the IP and TCP headers.
>
> --Andy
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-05-01 20:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 17:43 [PATCH] Allow TCP connections to cache SYN packet for userspace inspection Eric B Munson
2015-05-01 18:42 ` Eric Dumazet
2015-05-01 19:55 ` Tom Herbert
2015-05-01 20:14 ` Eric B Munson
2015-05-01 20:23 ` Eric Dumazet
2015-05-01 20:29 ` Eric B Munson
2015-05-01 20:41 ` Eric Dumazet
2015-05-01 19:27 ` Andy Lutomirski
2015-05-01 20:01 ` Eric B Munson [this message]
2015-05-01 20:28 ` Andy Lutomirski
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=20150501200136.GA6113@akamai.com \
--to=emunson@akamai.com \
--cc=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox