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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).