From: Paul LeoNerd Evans <leonerd@leonerd.org.uk>
To: Patrick McHardy <kaber@trash.net>, netdev@vger.kernel.org
Subject: Re: [RFC] BPF program access to transport header
Date: Fri, 30 Apr 2010 23:10:47 +0100 [thread overview]
Message-ID: <20100430221047.GA19334@cel.leo> (raw)
In-Reply-To: <4BDB3A4D.5020507@trash.net>
[-- Attachment #1: Type: text/plain, Size: 2044 bytes --]
On Fri, Apr 30, 2010 at 10:15:09PM +0200, Patrick McHardy wrote:
> > I forsee a number of issues with trying to provide this:
> >
> > * How to provide the protocol number (e.g. 6 for TCP, 1 for ICMP) to
> > the BPF program
>
> Using one of the registers?
Using, how? What operation would put the numbers in there in the first
place?
I was thinking more of simply providing an ancilliary data area field,
similar to SKF_AD_PROTO and SKF_AD_HATYPE, following along the same
idea.
LD WORD[SKF_AD_TRANSPROTO]
would then load the A register with the transport protocol number.
> > * How to obtain the transport offset - AIUI, the skf_transport_offset()
> > won't actually be set yet by the time the filter program runs.
>
> For IPv4 its trivial. For IPv6 you could use ipv6_skip_exthdr().
> A slightly more flexible way would be to use something like the
> netfilter ipv6_find_hdr() function to get the offset of any header
> type. The protocol number could be returned in one of the registers
> (the other one would contain the offset).
I sortof meant in general. I really don't think trying to add
IPv4/IPv6-specific code into net/core/filter.c is going to go down well.
On the other hand, I observe from casual experimentation, that on
receipt of a TCP packet in IPv4 over ethernet, the offets are:
mac=0 network=14 transport=14
This suggests more work needing to be done somewhere, because I'd expect
for an Ethernet/IPv4/TCP packet to get
mac=0 network=14 transport=34
> > * What to do if the underlying protocol doesn't support a transport
> > layer above it - e.g. ARP.
>
> I'd say simply abort the filter.
That sounds reasonable.
Another question occurs:
* How to obtain the transport protocol number? I can easily provide it
in the AD area; say as SKF_AD_TRANSPROTO; but how can
net/core/filter.c know the value?
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
prev parent reply other threads:[~2010-04-30 22:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 19:39 [RFC] BPF program access to transport header Paul LeoNerd Evans
2010-04-30 20:15 ` Patrick McHardy
2010-04-30 22:10 ` Paul LeoNerd Evans [this message]
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=20100430221047.GA19334@cel.leo \
--to=leonerd@leonerd.org.uk \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.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.