PF for netbsd
ito...@iijlab.net
has PF (openbsd packet filter) for netbsd-current as of today.
caveats:
- does not support (interface) syntax
- ip_off/ip_len endian flipping needs testing
my ultimate goal is to replace ipsec policy engine by PF tagging
(just like ALTQ integration to PF on openbsd).
itojun
Ronald van der Pol
Great. I was about to ask a question about pf support in NetBSD.
Is pf going to be part of NetBSD?
I am using ipfilter now and I think it has some shortcommings.
I have no experience with pf yet, but its rules look more flexible.
* Most of our rules are duplicated for IPv4 and IPv6. It looks
like pf tables can solve this.
* We have Ethernet and gif external interfaces. On all those interfaces
we want almost the same firewall rules. It looks like this can be done
with interface lists.
The only thing missing for me is proper syslogging support. It looks like
this is only possible with external scripts.
BTW, is there a fundamental problem with interface syntax or is it just
lack of time?
rvdp
ito...@iijlab.net
>> has PF (openbsd packet filter) for netbsd-current as of today.
>>
>> caveats:
>> - does not support (interface) syntax
>> - ip_off/ip_len endian flipping needs testing
>>
>> my ultimate goal is to replace ipsec policy engine by PF tagging
>> (just like ALTQ integration to PF on openbsd).
>
>Great. I was about to ask a question about pf support in NetBSD.
>Is pf going to be part of NetBSD?
i certainly hope so.
>I am using ipfilter now and I think it has some shortcommings.
>I have no experience with pf yet, but its rules look more flexible.
>* Most of our rules are duplicated for IPv4 and IPv6. It looks
> like pf tables can solve this.
>* We have Ethernet and gif external interfaces. On all those interfaces
> we want almost the same firewall rules. It looks like this can be done
> with interface lists.
>
>The only thing missing for me is proper syslogging support. It looks like
>this is only possible with external scripts.
pflog(8) provides that.
>BTW, is there a fundamental problem with interface syntax or is it just
>lack of time?
just lack of time. openbsd has hook_xx API, which is used to hook into
IPv4 address addition/removal ioctls, and (interface) syntax uses it.
we can either pull the hook_xx API, or do something different (like
go through in_ifaddr on every evaluation).
itojun
Andy Pyles
Hi Itojun,
how about support for ALTQ?
Further, is your goal to replace ipfilter, or be an alternative?
Vincent Jardin
Le Jeudi 26 Juin 2003 12:09, ito...@iijlab.net a écrit :
> ftp://ftp.kame.net/pub/kame/misc/netbsd-pf-20030626.diff
Do you plan to integrate PF into Kame ?
Regards,
Vincent
Joel Wilsson
> ftp://ftp.kame.net/pub/kame/misc/netbsd-pf-20030626.diff
> has PF (openbsd packet filter) for netbsd-current as of today.
>
> caveats:
> - does not support (interface) syntax
> - ip_off/ip_len endian flipping needs testing
Great! Let me know if you want any help, I have some patches against
NetBSD-current, but those are for OpenBSD 3.3's pf (both kernel-
and userland stuff). And they're only "almost" done. :)
I've updated http://foo.unix.se/joelw/pflkm.html with this info.
> my ultimate goal is to replace ipsec policy engine by PF tagging
> (just like ALTQ integration to PF on openbsd).
That would be nice.
Regards,
joelw
ito...@iijlab.net
of course i would like to sync up with openbsd.
>Further, is your goal to replace ipfilter, or be an alternative?
not sure. freebsd has 2 packet filters (or 3?) shipped with it and
has no problem, so i'd say we can ship both. but ipfilter and PF has
very similar syntax, so we could choose to replace ipfilter with PF.
itojun
ito...@iijlab.net
i'm using kame tree to port PF onto other platforms.
(in KAME repository we have open/net/free3/4/5/bsdi3/4 with shared
portion)
itojun
ito...@iijlab.net
>> has PF (openbsd packet filter) for netbsd-current as of today.
new version, 20030627.diff, is available. (replace date portion)
>> caveats:
>> - does not support (interface) syntax
it seems that (interface) syntax has some issues - namely it does not
handle multiple address on a single interface. it needs some
clarification.
- can't get gid in user{} syntax
because netbsd struct socket does not keep it
other than that, it is working quite stably. userland tools are not
included but are of course available and running.
i would like to commit it, and at the same time update ALTQ to the
latest (which uses PF as packet classifier). integration with IPsec
policy engine is still in the works.
itojun
Erik Berls
] >how about support for ALTQ?
Yes, but requiring that one runs PF in order to use ALTQ is
unacceptable.
-=erik.
ito...@iijlab.net
>] has no problem, so i'd say we can ship both. but ipfilter and PF has
>] very similar syntax, so we could choose to replace ipfilter with PF.
>Yes, but requiring that one runs PF in order to use ALTQ is
>unacceptable.
if ipfilter incorporates tagging functinality, you can run ALTQ with
ipfilter. until then, PF is needed for ALTQ.
itojun
Erik Berls
] >] not sure. freebsd has 2 packet filters (or 3?) shipped with it and
This wasn't required in 1.6. ALTQ ships with, but PF does not.
-=erik.
ito...@iijlab.net
it was because ALTQ-on-1.6 inclueded its own packet classifier (which
is very similar to packet filter). in the way of ALTQ development,
ALTQ dropped its classifier and chose to rely on packet tagging
(provided by PF), because ALTQ classifier is basically a code
duplication of packet filter.
itojun
Erik Berls
] it was because ALTQ-on-1.6 inclueded its own packet classifier (which
] is very similar to packet filter). in the way of ALTQ development,
] ALTQ dropped its classifier and chose to rely on packet tagging
] (provided by PF), because ALTQ classifier is basically a code
] duplication of packet filter.
So they decided to eliminate the ability to choose which packet
filter the end user may utilize for the sake of skipping out on some
work by piggybacking onto a codebase that is decidedly foreign to
the NetBSD tree.
-=erik.
ito...@iijlab.net
no, that's not true. we could ship NetBSD including both ipfilter
and PF (you can multiple packet filter implementation with a single OS,
see freebsd - they have been shipping ipfilter and ipfw for a long
time).
then you can
- run packet filter by ipfilter
- control ALTQ by PF
so no harm was done to you.
itojun
Erik Berls
] no, that's not true. we could ship NetBSD including both ipfilter
] and PF (you can multiple packet filter implementation with a single OS,
] see freebsd - they have been shipping ipfilter and ipfw for a long
] time).
] then you can
] - run packet filter by ipfilter
] - control ALTQ by PF
This is not what you said earlier. You had stated that one needed to
be running PF in order to use ALTQ. Which is it?
-=erik.
ito...@iijlab.net
the latter bullet is consistent with what i said before. i don't see
any contradiction.
what i meant in the previous email is "you don't have to do all of your
packet filtering task by PF, you can use ipfilter".
itojun
Kenjiro Cho
For ALTQ, it's a step forward from its home-brew classifier to
making use of external packet filters.
By this separation, the packet scheduler of ALTQ becomes independent
of packet classifiers, and possible to be used by any packet filter
capable of tagging mbufs. (the integration of userland tools is
another story, though.)
The first external packet filter for ALTQ is pf. pf is one of the
best packet filters, and still evolving rapidly.
More importantly, the pf people have been willing to collaborate with
us to integrate ALTQ.
So, it is possible to make ALTQ to work with ipf or other packet
filters in the future. But, at this moment, it seems much easier to
just import pf for those who want to use pf-extended ALTQ.
This is from the view of ALTQ. There are people interested in pf for
other reasons.
-Kenjiro
Jason Thorpe
On Thursday, June 26, 2003, at 09:41 PM, Erik Berls wrote:
> This wasn't required in 1.6. ALTQ ships with, but PF does not.
That is a much older version of ALTQ. I think it's also safe to say
that the classification engine in that older ALTQ wasn't exactly speedy.
-- Jason R. Thorpe <tho...@wasabisystems.com>
Jason Thorpe
On Thursday, June 26, 2003, at 09:51 PM, ito...@iijlab.net wrote:
> it was because ALTQ-on-1.6 inclueded its own packet classifier (which
> is very similar to packet filter). in the way of ALTQ development,
> ALTQ dropped its classifier and chose to rely on packet tagging
> (provided by PF), because ALTQ classifier is basically a code
> duplication of packet filter.
I would like to state for the record that I support removing duplicated
packet classification engines. The needs of a firewall, traffic
shaper, and IPsec SPD/SAD engine are all basically the same.
Of course, it would be nice if everything used BPF as the actual
matching engine, but I don't want to let perfect be the enemy of good.
So, if PF allows us to clean up the network code in this way, I'm all
for it.
Lennart Augustsson
> So, if PF allows us to clean up the network code in this way, I'm all
> for it.
What Jason said.
-- Lennart
Darren Reed
I'll repeat what I've said here before:
pf does not solve the single biggest problem IPFilter has.
IPFilter that is currently in NetBSD is quite dated, in some respects.
The next major release of IPFilter will go some distance in making it
better and contains the foundations for making upgrades painless.
Note, however, IPFilter doesn't exist only in a constant development
model, only, rather it exists to support users on a stablising version
that might exist for some time, a model that is seemingly foreign to
some.
Some questions for KAME people...
Do you have an official interface description for how other providers
of packet classification can integrate with ALTQ or do we need to
RTFS ?
Are you prepared to commit to providing a stable API or will others
have "API of the month" issues with ALTQ/KAME updates ?
Did you give any consideration to making ALTQ able to work with 3rd
party (and I'll group pf & ipfilter in that) packet classifiers in
general or have you just decided to adopt OpenBSD's changes that
put pf specific references into ALTQ ?
Would KAME take back changes to ALTQ that made it open to supporting
packet classifiers, in general rather than a different, specific one ?
Or is KAME interested in doing such work itself ?
Kenjiro, if you are serious about external packet filters for KAME's
IPSec then shouldn't this be the logical next step in ALTQ's evolution ?
(At present I notice hard coded references to pf...)
If ALTQ is going in that direction anyway, maybe we should just wait
until the ALTQ API is decided upon and finalised for general use before
integrating the new version of ALTQ into NetBSD. Fewer changes and
less pain for NetBSD users in general.
And just in case anyone is wondering, I don't think those behind
ALTQ ever asked or approached me about collaboration (or at least
I don't recall any such email conversation.) The reason behind
ALTQ/pf collaboration is...well...I'm sure NetBSD'ers will have
their own suspicions without me saying anything.
Darren
Martin J. Laubach
| > for it.
Of course, if ipf would grow a tagging mechanism, that would
be even better in the one unified mechanism department.
mjl
Martti Kuparinen
> IPFilter that is currently in NetBSD is quite dated, in some respects.
Just FYI, I have started to look at the new IPFilter on my -current box.
If everything goes okay I might have something to commit very soon...
Martti
Kenjiro Cho
Darren,
> Some questions for KAME people...
>
> Do you have an official interface description for how other providers
> of packet classification can integrate with ALTQ or do we need to
> RTFS ?
[snip several questions on API]
> Kenjiro, if you are serious about external packet filters for KAME's
> IPSec then shouldn't this be the logical next step in ALTQ's evolution ?
> (At present I notice hard coded references to pf...)
>
> If ALTQ is going in that direction anyway, maybe we should just wait
> until the ALTQ API is decided upon and finalised for general use before
> integrating the new version of ALTQ into NetBSD. Fewer changes and
> less pain for NetBSD users in general.
My impression is that API is not so important here.
When tagging is used, we have 2 approaches.
independent-model:
a tagger (packet filter) and a consumer (altq, ipsec, etc)
are independent, and configured independently.
unified-model:
a tagger and a consumer are unified and configured by a single
config file.
Currently, setkey(8) is the independent model and ALTQ is
the unified model but both can be implemented either way.
The independent model is too simple to be an API.
The tagger and the consumer share only tag values. All you need is a
mechanism to map a string label to the corresponding tag value.
In pf, pf creates and keeps mapping, and provides a function to
retrieve tag values.
u_int16_t pf_tagname2tag(char *tagname);
So, if IPFilter provides a similar function, we can make use of
IPFilter.
The unified model is too complex to be an API.
Different packet filters have different config syntax and different
semantics of attach/detach/enable/disable filter rules.
So, while working on pf, I realized that it is more practical to
write a queue model which fits the existing packet filter model, and
then, add necessary glues for ALTQ.
That's my impression at the moment, though others may have different
ones.
> And just in case anyone is wondering, I don't think those behind
> ALTQ ever asked or approached me about collaboration (or at least
> I don't recall any such email conversation.) The reason behind
> ALTQ/pf collaboration is...well...I'm sure NetBSD'ers will have
> their own suspicions without me saying anything.
There's no conspiracy behind it. It's just because I didn't have a
chance to drink beer with you :)
-Kenjiro
Darren Reed
>
> My impression is that API is not so important here.
I think it is - always.
Currently, based on what I've seen in OpenBSD and read here, you
should not have a kernel configuration like this:
pseudo-device ipfilter
#pseudo-device pf
options ALTQ
because various ALTQ files include pf related header files for things
like "struct pf_altq". ALTQ should be providing the interface to be
used by packet classifiers, not the other way around. I say "should
not" because strictly speakingn header files can be used like that
but it doesn't strike me as being a "Good Thing"(tm). Anyway, where
you are aiming to support a 1:N relationship, the "1" should be
providing the interface, not one of the N's.
Maybe I'm just more concerned about things architecturally and looking
for a good design...
> The tagger and the consumer share only tag values. All you need is a
> mechanism to map a string label to the corresponding tag value.
> In pf, pf creates and keeps mapping, and provides a function to
> retrieve tag values.
> u_int16_t pf_tagname2tag(char *tagname);
> So, if IPFilter provides a similar function, we can make use of
> IPFilter.
That suggests to me that IPFilter/pf couldn't co-exist if they were
both required to provide the same function name as part of an interface,
correct ?
Looking at ALTQ from KAME (I just did a cvs update from kame), there
is currently no use of m_tag that is found in the OpenBSD source.
Is this because changes are still pending being pulled up into KAME
from OpenBSD to support this ?
And if someone were to update the NetBSD altq with what appears to be
-current ALTQ from KAME, there would be no need for pf, right ?
Hopefully this means any integration/API between packet classifiers
and ALTQ is still open for discussion :)
> There's no conspiracy behind it. It's just because I didn't have a
> chance to drink beer with you :)
Damn, I'm never in the right place at the right time!
;)
Darren
ito...@iijlab.net
>is currently no use of m_tag that is found in the OpenBSD source.
>Is this because changes are still pending being pulled up into KAME
>from OpenBSD to support this ?
you have to look at kame/openbsd tar.gz, not under kame/sys/altq.
the latter is obsolete.
itojun
Kenjiro Cho
Darren Reed wrote:
> Anyway, where
> you are aiming to support a 1:N relationship, the "1" should be
> providing the interface, not one of the N's.
If I have M:N relationship in mind where there are M packet schedulers
and N packet filters, who should be providing the interface?
> Maybe I'm just more concerned about things architecturally and looking
> for a good design...
Maybe, sometimes I'm just more concerned about having things done at
the right time with the given constraints :)
> > The tagger and the consumer share only tag values. All you need is a
> > mechanism to map a string label to the corresponding tag value.
> > In pf, pf creates and keeps mapping, and provides a function to
> > retrieve tag values.
> > u_int16_t pf_tagname2tag(char *tagname);
> > So, if IPFilter provides a similar function, we can make use of
> > IPFilter.
>
> That suggests to me that IPFilter/pf couldn't co-exist if they were
> both required to provide the same function name as part of an interface,
> correct ?
You can provide ipf_tagname2tag() or whatever you want.
Since it's not in the packet forwarding path, we can go through all
the packet filters available on the system to look up the given tag.
> Looking at ALTQ from KAME (I just did a cvs update from kame), there
> is currently no use of m_tag that is found in the OpenBSD source.
> Is this because changes are still pending being pulled up into KAME
> from OpenBSD to support this ?
Right. itojun imported pf into KAME today and started working on
the setkey part. I haven't had time to catch up.
> And if someone were to update the NetBSD altq with what appears to be
> -current ALTQ from KAME, there would be no need for pf, right ?
Right, it doesn't work with pf at the moment.
And I don't intend to simply import the ALTQ code as is from OpenBSD.
> Hopefully this means any integration/API between packet classifiers
> and ALTQ is still open for discussion :)
Yes, it has been and will be always open for discussion :)
-Kenjiro
Darren Reed
Do you want to expand on this change in how KAME development is
proceeding or do we have to guess about what's going on ?
kame/kame/sys/altq shows changes as recent as June 27 but this is
obsolete, you say ? Why ?
Darren
Darren Reed
> > Anyway, where
> > you are aiming to support a 1:N relationship, the "1" should be
> > providing the interface, not one of the N's.
>
> If I have M:N relationship in mind where there are M packet schedulers
> and N packet filters, who should be providing the interface?
A middle layer. That'd probably offend OpenBSD types, however,
because it'd make things marginally slower for the added benefit
of generality. The implementation would involve things like altq
registering with some service provider that packet classifiers also
registered with, so the M:N bets split into M:1 and 1:N.
> > Maybe I'm just more concerned about things architecturally and looking
> > for a good design...
>
> Maybe, sometimes I'm just more concerned about having things done at
> the right time with the given constraints :)
What time constraints ? :)
> > > The tagger and the consumer share only tag values. All you need is a
> > > mechanism to map a string label to the corresponding tag value.
> > > In pf, pf creates and keeps mapping, and provides a function to
> > > retrieve tag values.
> > > u_int16_t pf_tagname2tag(char *tagname);
> > > So, if IPFilter provides a similar function, we can make use of
> > > IPFilter.
> >
> > That suggests to me that IPFilter/pf couldn't co-exist if they were
> > both required to provide the same function name as part of an interface,
> > correct ?
>
> You can provide ipf_tagname2tag() or whatever you want.
> Since it's not in the packet forwarding path, we can go through all
> the packet filters available on the system to look up the given tag.
What's the purpose for this? My understanding of pf is that it turns a
packet tag name into a number inside the kernel to match up packets to
its rules.
So the packet is tagged as it enters the host and then altq matches up
its policies based on its tag configuration ? Will defining queues,
etc, remain part of KAME or is it expected that this, too, is expected
by the packet classifier ? (pfctl has all this merged.)
You will have an interface to register (and deregister) functions that
resolve tag names in the altq code ?
> > Looking at ALTQ from KAME (I just did a cvs update from kame), there
> > is currently no use of m_tag that is found in the OpenBSD source.
> > Is this because changes are still pending being pulled up into KAME
> > from OpenBSD to support this ?
>
> Right. itojun imported pf into KAME today and started working on
> the setkey part. I haven't had time to catch up.
I get the impression that itojun's email was both premature and not
very well worded then, if you want to achieve the goals you're after.
> > And if someone were to update the NetBSD altq with what appears to be
> > -current ALTQ from KAME, there would be no need for pf, right ?
>
> Right, it doesn't work with pf at the moment.
> And I don't intend to simply import the ALTQ code as is from OpenBSD.
Well that's good news and not the impression that itojun is giving...
Darren
Jim Wise
Hash: SHA1
On Fri, 27 Jun 2003, Kenjiro Cho wrote:
>... pf is one of the
>best packet filters, and still evolving rapidly.
With my production sysadmin hat on, I'd say these two statements were
pretty close to mutually exclusive...
>So, it is possible to make ALTQ to work with ipf or other packet
>filters in the future. But, at this moment, it seems much easier to
>just import pf for those who want to use pf-extended ALTQ.
>
>This is from the view of ALTQ. There are people interested in pf for
>other reasons.
And there are many of us quite happy with IPF in comparison to PF, for a
variety of reasons. While I am well aware of the shortcomings of the
version of ALTQ currently in NetBSD, I would _strongly_ oppose import of
any ALTQ version which prevented me from using ALTQ and ipf at the same
time.
Is this what you are saying the current version does? Or am I
misunderstanding?
- --
Jim Wise
jw...@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)
iD8DBQE+/H1MlGcH240chEIRAqsdAKDI1utifipPiv2YRIUrJySE0jwlRwCg0muz
1qkQ4EaxR6euhaCpbu7+6E4=
=GSih
-----END PGP SIGNATURE-----
Sporleder, Matthew (CCI-Atlanta)
You just need to use pf (at the same time) for altq's work.
At least, that's the impression I've been getting.
Kenjiro Cho
Darren,
> > > Maybe I'm just more concerned about things architecturally and looking
> > > for a good design...
> >
> > Maybe, sometimes I'm just more concerned about having things done at
> > the right time with the given constraints :)
>
> What time constraints ? :)
In this particular case, OpenBSD has its release cycle, and my
collaborators and I had limited time for the job and didn't know if we
could do it in the next release cycle.
> > You can provide ipf_tagname2tag() or whatever you want.
> > Since it's not in the packet forwarding path, we can go through all
> > the packet filters available on the system to look up the given tag.
>
> What's the purpose for this? My understanding of pf is that it turns a
> packet tag name into a number inside the kernel to match up packets to
> its rules.
>
> So the packet is tagged as it enters the host and then altq matches up
> its policies based on its tag configuration ? Will defining queues,
> etc, remain part of KAME or is it expected that this, too, is expected
> by the packet classifier ? (pfctl has all this merged.)
As I said earlier, pf employs the unified model and merged all the
stuff.
If ipf employs the independent model, all the queue related part
remains in altqd(8).
If there will be no packet filter to use the independent model,
altqd(8) will go away.
> You will have an interface to register (and deregister) functions that
> resolve tag names in the altq code ?
It's one way to do that, in which one packet filter can be registered
at a time.
What I suggested was that altq doesn't care multiple packet filters
tagging packets at the same time as long as tag labels are unique.
> > Right. itojun imported pf into KAME today and started working on
> > the setkey part. I haven't had time to catch up.
>
> I get the impression that itojun's email was both premature and not
> very well worded then, if you want to achieve the goals you're after.
I haven't had much time to discuss the issues with itojun so that our
opinions may not agree.
-Kenjiro
ito...@iijlab.net
these months ALTQ development has been done on openbsd primarily
(openbsd hackerthon, kjc-PF collaboration), and openbsd/sys/altq has
the latest piece of software. kame/sys/altq is still there
(and distributed in tarballs) but is obsolete.
our plan is:
- make kame/sys/net/pf* portable (netbsd done, freebsd still to go)
- move content of openbsd/sys/altq to kame/sys/altq, put #ifdef for
portability
so, to provide PF+ALTQ on all platforms (free/net/open) is what we're
targetting.
itojun
Jonathan Stone
>I would like to state for the record that I support removing duplicated
>packet classification engines. The needs of a firewall, traffic
>shaper, and IPsec SPD/SAD engine are all basically the same.
>Of course, it would be nice if everything used BPF as the actual
>matching engine, [...]
No, it is *not* be a good idea. Ther are situations where using BPF
is a really really *bad* idea.
Consider, for example, a host with an aggregate of a gigabit or so; of
which some very small fraction requires IPsec transforms. Next
example is a system with a fast (60 Mbyte or so) IPsec accelerator
engine. Any BPF-like (bytecode interpreter) approach to that kind of
packet classification rate is completely unacceptable.
ito...@iijlab.net
PF rule for tagging. it basically eliminates code dupes between
ipsec policy engine (which is essentially a packet filter) and PF
(or ipf, if it starts support tagging).
itojun
------- Forwarded Message
Return-Path: <owner...@kame.net>
Delivered-To: ito...@coconut.itojun.org
Received: from orange.kame.net (unknown [2001:200:0:4819:203:47ff:fea5:3085])
by coconut.itojun.org (Postfix) with ESMTP id A460793
for <ito...@coconut.itojun.org>; Sat, 28 Jun 2003 08:15:33 +0900 (JST)
Received: by orange.kame.net (Postfix)
id 9E0A670BA; Sat, 28 Jun 2003 08:15:21 +0900 (JST)
Delivered-To: ito...@kame.net
Received: by orange.kame.net (Postfix)
id ABD837047; Sat, 28 Jun 2003 08:15:20 +0900 (JST)
Delivered-To: co...@kame.net
Received: by orange.kame.net (Postfix, from userid 1001)
id 5E935703C; Sat, 28 Jun 2003 08:15:20 +0900 (JST)
X-Original-To: snap-users-outgoing
Delivered-To: snap-user...@kame.net
X-Original-To: snap-...@kame.net
Delivered-To: snap-...@kame.net
To: snap-...@kame.net
X-Template-Reply-To: ito...@itojun.org
X-Template-Return-Receipt-To: ito...@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
From: ito...@iijlab.net
Date: Sat, 28 Jun 2003 08:15:18 +0900
Message-Id: <20030627231...@coconut.itojun.org>
Precedence: bulk
Reply-To: snap-...@kame.net
X-Distribute: distribute [version 2.1 (Alpha1) patchlevel=26]
X-Sequence: KAME-snap 7878
Subject: (KAME-snap 7878) PF tag and IPsec - usage example
Errors-To: owner-sn...@kame.net
Sender: owner-sn...@kame.net
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.11.1.3
X-Filter: mailagent [version 3.0 PL73] for ito...@itojun.org
on kame/netbsd we have integrated PF (from openbsd) and KAME
IPsec policy lookup engine (by using PF tags).
here's a simple example which demonstrates its use.
itojun
1. setup policy like below:
# setkey -c <<EOF
spdadd tagged "ssh" -P in ipsec esp/transport//use;
spdadd 127.0.0.1 127.0.0.1 -P in ipsec esp/transport//require;
^D
(for traffic tagged with "ssh", ipsec is not mandatory; otherwise, ipsec is
mandatory)
2. setup pfkey like below:
# pfctl -e
# pfctl -f -
pass in on lo0 proto tcp from any to any port = ssh keep state tag ssh
pass out on lo0 proto tcp from any to any port = ssh keep state tag ssh
^D
(tag ssh traffic with "ssh")
3.
now, "telnet 127.0.0.1 25" will be banned as response packet is not
IPsec protected (there's no SA). "telnet 127.0.0.1 22" will be okay as
it will be tagged by "ssh".
4. caveat
on outbound path, the order is (1) ipsec policy lookup (2) packet filtering,
therefore, tags attached on outbound is not be usable on outbound ipsec policy.
(for a router, tagging on inbound interface -> policy on outgoing would be
very useful, i think)
------- End of Forwarded Message
Sporleder, Matthew (CCI-Atlanta)
It was neither developed with NetBSD in mind or by any NetBSD
developers. (to my knowledge)
I realize that it is well established, but if new features come
around to allow better traffic shaping, or whatever, then why not
accept the use of something that we have more control over instead
of waiting on the ipf development to integrate a new feature?
_Matt
ito...@iijlab.net
>>> has PF (openbsd packet filter) for netbsd-current as of today.
> new version, 20030627.diff, is available. (replace date portion)
20030628 is ready.
>>> caveats:
>>> - does not support (interface) syntax
> it seems that (interface) syntax has some issues - namely it does not
> handle multiple address on a single interface. it needs some
> clarification.
now supported (though there's some CPU overhead if you use this syntax).
itojun
Darren Reed
> >> >is currently no use of m_tag that is found in the OpenBSD source.
> >> >Is this because changes are still pending being pulled up into KAME
> >> >from OpenBSD to support this ?
> >> you have to look at kame/openbsd tar.gz, not under kame/sys/altq.
> >> the latter is obsolete.
> >Do you want to expand on this change in how KAME development is
> >proceeding or do we have to guess about what's going on ?
> >
> >kame/kame/sys/altq shows changes as recent as June 27 but this is
> >obsolete, you say ? Why ?
>
> these months ALTQ development has been done on openbsd primarily
> (openbsd hackerthon, kjc-PF collaboration), and openbsd/sys/altq has
> the latest piece of software. kame/sys/altq is still there
> (and distributed in tarballs) but is obsolete.
While we are nutting out the proper interface for moving packet
classification from KAME to other code, is there any reason why
an update, in NetBSD, of ALTQ to something just prior to the
merging with PF would be bad ?
> our plan is:
> - make kame/sys/net/pf* portable (netbsd done, freebsd still to go)
> - move content of openbsd/sys/altq to kame/sys/altq, put #ifdef for
> portability
> so, to provide PF+ALTQ on all platforms (free/net/open) is what we're
> targetting.
OK, but I think there is more work required on the ALTQ side of things -
see my comments to Kenjiro - before it should be merged with NetBSD.
Darren
Darren Reed
> > > > Maybe I'm just more concerned about things architecturally and looking
> > > > for a good design...
> > >
> > > Maybe, sometimes I'm just more concerned about having things done at
> > > the right time with the given constraints :)
> >
> > What time constraints ? :)
>
> In this particular case, OpenBSD has its release cycle, and my
> collaborators and I had limited time for the job and didn't know if we
> could do it in the next release cycle.
Ok. Well I'll state the obvious, just in case, and that is that NetBSD
doesn't have the same release cycle pressure that OpenBSD does. I don't
think I'm aware of anyone on the inside of NetBSD who would consider
this to be a significant or important change for the next NetBSD major
release so if the integration time was longer whilst details were nutted
out, this would not be a big problem.
In short, rushing this into NetBSD (or attempting to) will not win anyone
any friends and will more than likely make enemies, especially if there
are outstanding issues in the API design (and I, at least, believe there
are).
> > > You can provide ipf_tagname2tag() or whatever you want.
> > > Since it's not in the packet forwarding path, we can go through all
> > > the packet filters available on the system to look up the given tag.
> >
> > What's the purpose for this? My understanding of pf is that it turns a
> > packet tag name into a number inside the kernel to match up packets to
> > its rules.
> >
> > So the packet is tagged as it enters the host and then altq matches up
> > its policies based on its tag configuration ? Will defining queues,
> > etc, remain part of KAME or is it expected that this, too, is expected
> > by the packet classifier ? (pfctl has all this merged.)
>
> As I said earlier, pf employs the unified model and merged all the stuff.
> If ipf employs the independent model, all the queue related part
> remains in altqd(8).
> If there will be no packet filter to use the independent model,
> altqd(8) will go away.
OK. How much of KAME is a part of FreeBSD? I believe they use dummynet
(or similar) for bandwidth shaping, but I'm trying to guess here if ipfw[2]
will support this or if it'll even be required to keep altqd.
Is a long term goal to stop supporting the independant model and altqd ?
> > You will have an interface to register (and deregister) functions that
> > resolve tag names in the altq code ?
>
> It's one way to do that, in which one packet filter can be registered
> at a time.
FreeBSD and NetBSD support having packet filters as LKMs, so the
register/deregister thing is kind of mandatory.
> What I suggested was that altq doesn't care multiple packet filters
> tagging packets at the same time as long as tag labels are unique.
When I look through the ALTQ code for OpenBSD, I see no references to
pf_tagname2tag(), only the following:
PACKET_TAG_PF_QID
struct pf_altq
includes for net/pfvar.h
Are there further changes required to this code to support what you
are talking about ?
IMHO, all of the above direct references to pf need to disappear before
the new ALTQ work is merged with NetBSD. People have written other
packet classifiers for NetBSD and they should not be required to use
any of the pf things if they want to interact with ALTQ.
> > > Right. itojun imported pf into KAME today and started working on
> > > the setkey part. I haven't had time to catch up.
> >
> > I get the impression that itojun's email was both premature and not
> > very well worded then, if you want to achieve the goals you're after.
>
> I haven't had much time to discuss the issues with itojun so that our
> opinions may not agree.
I see.
Well it is not good to hear that.
Can I suggest that any further discussion (and definately action) be put
on hold until KAME, at least, understands what it is doing ? Seems like
left hand does not know what the right hand is doing...and why am I still
sending out this full email having said it ?!
Cheers,
Darren
ito...@iijlab.net
>> > > the setkey part. I haven't had time to catch up.
>> > I get the impression that itojun's email was both premature and not
>> > very well worded then, if you want to achieve the goals you're after.
which portion seems premature?
i'm working on multiple platforms in parallel, including:
kame/freebsd4, kame/netbsd161, kame/openbsd33, openbsd-current,
netbsd-current (call me crazy, if you want to). progress of work
differs by each of the platform.
kame/netbsd161 now enjoys IPsec-and-PF integration, as forwarded,
and i would like to integrate it into netbsd-current.
itojun
ito...@iijlab.net
>classification from KAME to other code, is there any reason why
>an update, in NetBSD, of ALTQ to something just prior to the
>merging with PF would be bad ?
kjc has the answer.
itojun
Vincent Jardin
>FreeBSD and NetBSD support having packet filters as LKMs, so the
>register/deregister thing is kind of mandatory.
FYI, there is already a port of pf for FreeBSD 5:
http://www.freshports.org/security/pf/
It has been ported by Pyun YongHyeon:
http://pf4freebsd.love2party.net/
I do not know if it supports the register/deregister feature.
It would be nice if Kame and pf4freebsd could work together ;-)
Regards,
Vincent
Darren Reed
> >> > > the setkey part. I haven't had time to catch up.
> >> > I get the impression that itojun's email was both premature and not
> >> > very well worded then, if you want to achieve the goals you're after.
>
> which portion seems premature?
>
> i'm working on multiple platforms in parallel, including:
> kame/freebsd4, kame/netbsd161, kame/openbsd33, openbsd-current,
> netbsd-current (call me crazy, if you want to). progress of work
> differs by each of the platform.
I won't call you crazy...just yet...
> kame/netbsd161 now enjoys IPsec-and-PF integration, as forwarded,
> and i would like to integrate it into netbsd-current.
This last step seems premature. Given that there has been lengthy delays
in the past with the integration of KAME work into NetBSD, I see no need
to start rushing now, especially when there are issues that need to be
resolved first. I've seen no support, for this integration work besides
Jason saying that one less packet classifier in the kernel would be good.
If people want to use KAME/ALTQ/pf on NetBSD then they can download the
latest snapkit from www.kame.net, just like they would download any snap
kit to use the latest KAME code with NetBSD if they didn't want to wait
for it to be integrated into NetBSD. I think this work should spend more
time in the KAME tree before it goes into NetBSD, hopefully meaning that
NetBSD gets a more mature import, as a result, rather than getting what
appears to be a relatively unfinished/ill-prepared one. Especially if
you and Kenjiro haven't had real any conversation about where this is
all going. I doubt if I'm not the only one for whom this rings alarm
bells in their head.
The only rational reason I could see for you wanting to push this all
into NetBSD so quickly is if it was for some other reason that you have
not mentioned, here, yet because the code in KAME is clearly not ready
to be imported into NetBSD for any kind of use that doesn't involve pf.
Whilst some might be happy with that, some are not and I'd prefer we
reached a position where everyone was happy, before proceeding, and with
time I believe that position can be achieved.
To summarise, in the short term I can see lots of reasons to wait before
bringing this into NetBSD but in the longer term, the KAME code should
improve and the end result would be a welcome change, I feel. If it means
that NetBSD lags a little in the meantime whilst KAME changes, I think
that this will be acceptable given the history of KAME/ALTQ and NetBSD.
Cheers,
Darren
ito...@iijlab.net
>in the past with the integration of KAME work into NetBSD, I see no need
>to start rushing now, especially when there are issues that need to be
>resolved first. I've seen no support, for this integration work besides
>Jason saying that one less packet classifier in the kernel would be good.
by saying "KAME code" it can mean a lot of different components, so
i see in your statement some over-generalizing.
you misunderstood why there are lags between KAME IPv6 tree and NetBSD.
we specifically integrate things that made RFC status, or alike,
from KAME IPv6 code to NetBSD. therefore we waited 2292bis API
discussion to settle down into RFC3542, for instance.
itojun
Martin J. Laubach
| spdadd tagged "ssh" -P in ipsec esp/transport//use;
| spdadd 127.0.0.1 127.0.0.1 -P in ipsec esp/transport//require;
Why does the second line still specify some classification
requirements? Wouldn't it be cleaner (and simpler) to _only_
use tags here, ie.
spdadd tagged "ssh" -P in ipsec esp/transport//use;
spdadd tagged "from-to-localhost" -P in ipsec esp/transport//require;
with appropriate packet filter lines?
mjl
ito...@iijlab.net
the above is of course possible.
itojun
ito...@iijlab.net
on the contrary, KAME IPsec code and NetBSD IPsec code is mostly in
sync, because RFC240x series are already RFC.
PF is also stable and well tested, since it has been used from openbsd
3.0 (or 2.9?).
itojun
ito...@iijlab.net
>into NetBSD so quickly is if it was for some other reason that you have
>not mentioned, here, yet because the code in KAME is clearly not ready
>to be imported into NetBSD for any kind of use that doesn't involve pf.
>Whilst some might be happy with that, some are not and I'd prefer we
>reached a position where everyone was happy, before proceeding, and with
>time I believe that position can be achieved.
i don't understand what you are trying to mean. are you saying that
i have some hidden agenda? i don't have any.
(and read the other response too)
itojun
Darren Reed
> >in the past with the integration of KAME work into NetBSD, I see no need
> >to start rushing now, especially when there are issues that need to be
> >resolved first. I've seen no support, for this integration work besides
> >Jason saying that one less packet classifier in the kernel would be good.
>
> by saying "KAME code" it can mean a lot of different components, so
> i see in your statement some over-generalizing.
I am generalising, yes, but quite deliberately doing so becaues it
is not possible to separate the components, any more, in the manner
desired.
> you misunderstood why there are lags between KAME IPv6 tree and NetBSD.
> we specifically integrate things that made RFC status, or alike,
> from KAME IPv6 code to NetBSD. therefore we waited 2292bis API
> discussion to settle down into RFC3542, for instance.
Sometimes bugs take, IMHO, too long to get fixed in NetBSD after being
fixed in KAME. Don't ask me for specifics, it's just my feeling after
trying to get IPSec to work with NetBSD (I think soon after 1.5 came
out?), had problems, found some things fixed in KAME but not even in
NetBSD-current. Maybe that situation is better now, maybe it is not.
I still can find months-old IPSec in KAME code that has not made its
way into NetBSD when from my perspective, it should have but then it
is possible I just don't understand the KAME code quite well enough
to make a correct call on it. I can understand that it is not a
quick and simple process to ensure bugs get fixed in all the platforms
you support as they are fixed in KAME's CVS but lets not rush into
making the situation a bigger problem than it already is.
The problem, for me, is not with the stability of pf (in terms of
does it crash or work) but that the integration of pf/ALTQ has not
matured enough. You already have one testing ground for this work -
OpenBSD - so why do you need NetBSD to be yet another one?
Now, am I going to have to repeat myself again on API issues or
have you understood what I've said to date about the problems
with the current design being found in need of review and change ?
Then there are comments from Kenjiro which suggest that the work
is far from complete yet, in ALTQ, so you don't really have a
finished product yet to integrate. Now even if you did, and this
were it, I think I would be recommending to KAME that they go away
and spend some time improving on the current design to satisfy the
requirements for integration into NetBSD. As I've indicated in
other emails, I would he happy to support the integration of this
work when it approaches a point that I would call "finished".
I do not believe KAME is near that point and comments from Kenjiro
support that.
Even if you were to say Kenjiro is wrong (which alone would be cause
for great concern about KAME itself), my reply to you and KAME would
be that the interface you are proposing to merge is not yet of a
suitable nature for inclusion in NetBSD. Just because it is good
enough for OpenBSD does not mean it is necessarily good enough for
NetBSD. It is like you are trying to force the bar to be lowered
enough so that an unsuitable solution can be merged rather than
trying harder to get over the bar even though it has been raised a
little.
Now, the question is, are you interested in working with us or are
you interested in working against us ?
If you are willing to work with us then you should be prepared
to take back constructive comments that make the KAME code better
rather than trying to force down our throats something that is
generally considered to be unpalatable and come back with something
that we are all happy with. That isn't so hard, is it ?
Cheers,
Darren
p.s. I've read your other replies and have responded, as appropriate
within this single email.
Erik Berls
]
] Darren,
]
] > > > Maybe I'm just more concerned about things architecturally and looking
] > > > for a good design...
] > >
] > > Maybe, sometimes I'm just more concerned about having things done at
] > > the right time with the given constraints :)
] >
] > What time constraints ? :)
]
] In this particular case, OpenBSD has its release cycle, and my
] collaborators and I had limited time for the job and didn't know if we
] could do it in the next release cycle.
Woah! Time out!
My reading of this is that design desicions that are going to affect
NetBSD are being rushed because of *Open*BSD's release cycle?
This has got to stop. The OpenBSD attitude of "just upgrade to
the next release" has already caused problems with OpenSSH integration.
There has already been one ABI issue with a massive pullup on a
release branch instead of just applying a fix as a result.
The *last* thing we need is this sort of BS happening in the kernel.
At this point, my take is that if we have to find an alternate
source for priority queueing and IPv6/IPSec, then so be it.
-=erik.
Martin J. Laubach
Good. My point was, specifically, if you decide to using an
external packet classifier, you should probably go all the way
and not have a second minimalistic classification engine inside
ipsec.
Otherwise using pf doesn't really buy you anything.
mjl
ito...@iijlab.net
>the next release" has already caused problems with OpenSSH integration.
>There has already been one ABI issue with a massive pullup on a
>release branch instead of just applying a fix as a result.
what kind of ABI issue openssh have caused in the past? if there is
i would like to hear it. note that openssh is just a program, not
a library.
itojun
Martin Husemann
> then why not
> accept the use of something that we have more control over instead
> of waiting on the ipf development to integrate a new feature?
I'm not sure what you realy mean, but PF does 100% fail to meet the "more
control" criteria - which is probably still quite an understatement.
Martin
ito...@iijlab.net
>> accept the use of something that we have more control over instead
>> of waiting on the ipf development to integrate a new feature?
>
>I'm not sure what you realy mean, but PF does 100% fail to meet the "more
>control" criteria - which is probably still quite an understatement.
you can join openbsd project if you would like to participate PF
development. there's no rule such as "netbsd developer can't become
openbsd developer". i do both, and some others do.
itojun
Thor Lancelot Simon
FSVO "you", perhaps. The NetBSD project is currently home to a number of
developers who were either:
* Denied developer status in the OpenBSD project unless they
quit the NetBSD project
* Forcibly expelled from the OpenBSD project after refusing to
renounce their ties to the NetBSD project or other open-source
projects that were evidently percieved as competing with
OpenBSD
* Forcibly expelled from the OpenBSD project for some other reason.
Indeed, you're one of the only people to be found who has managed to
maintain any sort of tenure in both camps. To suggest that we should switch
packet filter/classification engines and apply en-masse for developer status
in another, frequently hostile and capricious, software project so that we
can have any influence whatsoever on the development of the enginer we are
to switch _to_ seems rather naive, so say the least, given the three
contextual points stated above.
Thor
ito...@iijlab.net
>maintain any sort of tenure in both camps.
no. do not spread lies, ok?
itojun
% ssh cvs.openbsd.org 'awk -F : "{print $1}" /etc/passwd' > /tmp/1
% ssh cvs.netbsd.org 'awk -F: "{print $1}" /etc/passwd' > /tmp/2
% cat /tmp/1 /tmp/2 |sort |uniq -c |sort -n
2 angelos
2 bin (not a human account)
2 chris
2 daemon
2 david
2 gnats (not a human account)
2 imp
2 itojun
2 jmc
2 marc
2 mark
2 matt
2 mjacob
2 named (not a human account)
2 nobody (not a human account)
2 operator (not a human account)
2 provos
2 root (not a human account)
2 shell (not a human account)
2 uucp (not a human account)
Thor Lancelot Simon
> >Indeed, you're one of the only people to be found who has managed to
> >maintain any sort of tenure in both camps.
>
> no. do not spread lies, ok?
That's some very charged language you're using; I think you owe me
an apology.
I note that you trouble yourself only to contest my statement that
you're "one of the only people to be found who has managed to maintain
any sort of tenure in both camps"; I suppose I (and the peanut gallery)
are to conclude that you can't or won't take issue with the principal
points of my message: that our project is home to a number of developers
who have been either denied developer status in the OpenBSD project or
forcibly expelled from the OpenBSD project, and that in some cases that
expulsion was, in fact, quite simply and directly because they refused
to end their association with NetBSD.
As to your diff run over the two projects' password files, I'll note
that of hundreds of developers you only managed to turn up nine
duplicates-by-username, and of those:
* Two are individuals who have identified themselves as
having been expelled from the OpenBSD project; one may
reasonably assume that their accounts exist there only
as placeholders for their files, which is a standard
Unix administrative technique, as I'm sure you know.
* A number of others appear to share a *username* but to be
highly likely to not actually be the same individual.
* You also misidentified some machine accounts (e.g.
"daemon" as belonging to humans, but I didn't count
those in my figure of nine-that-is-probably-actually-
seven-or-less.
If you're going to go throwing around invective like "spread lies"
just because I happened to say something that makes it, perhaps, a
little less likely that you'll get what you want, I think you might
at least want to be able to back it up with better evidence than
you would seem to have.
On the other hand, you could stop reacting in such a childish,
emotional fashion when others happen to not agree with you, and
actually consider and discuss what they have to say instead of
accusing them of propagandizing. It is an incontrovertable fact
that participating in OpenBSD development is simply not an option
for quite a few NetBSD developers, because they have been denied
the opportunity to do so or have been expelled forcibly from the
OpenBSD project. Consequently, the suggestion that NetBSD should
rip out a major piece of infrastructure and replace it with one
for which meaningful development participation requires OpenBSD
development status (as you yourself said) seems like a very poor
idea to say the least.
Thor
William Allen Simpson
>
> >Indeed, you're one of the only people to be found who has managed to
> >maintain any sort of tenure in both camps.
>
> no. do not spread lies, ok?
> 2 provos
Niels Provos was kicked out of OpenBSD last year, along with a host of
us in Ann Arbor. He's in Greece with his parents, or I'm sure he'd
speak up. I'm rather surprised he still shows up in the passwd file.
Some of us were kicked out just for being freinds with the others....
Actually, I've quit before (1998), and publically asked that Theo be
replaced as leader of the project, so we're not on terribly good terms.
:-)
Anyway, I for one am glad there is crossover between projects, and
don't agree that NetBSD should be wary of PF. Heck, when there are
future problems, it won't be the first time that open source projects
have split for a time, now would it?
--
William Allen Simpson
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Thor Lancelot Simon
>
> Anyway, I for one am glad there is crossover between projects, and
> don't agree that NetBSD should be wary of PF. Heck, when there are
My concern develops essentially as follows:
1) There are currently hard-coded calls into PF in the ALTQ code we
are being asked to immediately adopt into NetBSD.
2) There is currently no API for using a packet classifier or filter
other than PF with that code, though we are told such an API may
be forthcoming.
3) Significant resistance to using a slightly older version of that
code that does not have hardwired calls into PF until said API
exists has been expressed by Itojun, unless I misunderstand.
4) Concern expressed by NetBSD developers that PF development seems
to be, essentially, encapsulated within the OpenBSD project and
that this could make it difficult for NetBSD developers to work on
an important component of the system has been met with, in essence,
the direct statement that if those developers are interested in
working on PF, well, then, they should get themselves over to the
OpenBSD project.
5) My simple mention that being an OpenBSD developer is simply not an
option for some -- I'd go so far as to say "many" -- of the NetBSD
developers in question was met by some highly charged invective
calling me a liar, though the actual facts would seem to show quite
the opposite. This, too, does not bode well for cooperative
development.
--
Thor Lancelot Simon t...@rek.tjls.com
But as he knew no bad language, he had called him all the names of common
objects that he could think of, and had screamed: "You lamp! You towel! You
plate!" and so on. --Sigmund Freud
ito...@iijlab.net
>> >maintain any sort of tenure in both camps.
>> no. do not spread lies, ok?
>That's some very charged language you're using; I think you owe me
>an apology.
i hereby apologize for the use of strong wording.
however, it is still true that your statement is false (is it a strong
wording? i'm not an English-native speaker so forgive me if it is).
you may want to correct what you have said.
itojun
Thor Lancelot Simon
> >> >Indeed, you're one of the only people to be found who has managed to
> >> >maintain any sort of tenure in both camps.
> >> no. do not spread lies, ok?
> >That's some very charged language you're using; I think you owe me
> >an apology.
>
> i hereby apologize for the use of strong wording.
Thank you.
> however, it is still true that your statement is false (is it a strong
> wording? i'm not an English-native speaker so forgive me if it is).
No, that's a perfectly appropriate assertion to make. The problem is that
it's *only* a bare assertion; I've provided both facts and reasoning to
support my conclusion, while you seem to simply be ignoring most of what
I said and have provided only, in essence, a diff of two password files
and an interpretation thereof that includes some obvious mistakes (which
I pointed out, but to which you made no response) and some highly dubious
reasoning.
Saying that the world is as it's not does not, in fact, change reality, as
much as we might wish otherwise. Out of hundreds of developers, there are
at most seven *accounts that share the same name* in the two projects in
question; some of those seem to not be the same individual, and of all of
them, you and Matt Jacob (who has not maintained continuous developer
status in either project) are the only ones who seem to have been active
in both projects for any real length of time. On the other hand, even
the tiny sample you provided includes two individuals who have, in fact,
been expelled from the OpenBSD project and who are not welcome to return --
exactly what you seem to be claiming does not occur. In fact, this is
true of several other NetBSD developers, and there are a number of others
who have been told in no uncertain terms that they need not apply to the
OpenBSD project because they are not welcome. There are also, as I mentioned
(and as you did not dispute) a number of developers in the NetBSD project
who were expelled from the OpenBSD project quite explicitly because they
refused to cease working on NetBSD.
In the light of these facts -- which you claim to be not so, but for which
claim you present no evidence -- I am highly skeptical of the suggestion
that the right thing for NetBSD to do is punt the packet filter we've got,
pick up one that's maintained as part of OpenBSD, and then politely ask
for OpenBSD developer status so that we can work on our new packet filter,
too.
I can't see how the actual facts would not be rather disturbing to just
about anyone who took a careful look at them -- but wishing inconvenient
or disturbing facts out of existence, sadly, is not a productive way to
deal with them, any more than calling those who point them out liars.
Thor
ito...@iijlab.net
lines, as it does not seem to be productive for me.
>I can't see how the actual facts would not be rather disturbing to just
>about anyone who took a careful look at them -- but wishing inconvenient
>or disturbing facts out of existence, sadly, is not a productive way to
>deal with them, any more than calling those who point them out liars.
excuse me? i apologized about the strong statement i've made a couple
of minutes ago. and you still keep blame on me on that? i see why
netbsd and openbsd cannot get along with each other. there are way
too many of people with personality problem, too strong ego, or
communication problem (i don't exclude myself, to be sure).
i really hope this atmosphere to change. by working on KAME project
which is trying to create a good code that benefits all BSDs) i'm
trying to do so. KAME have made some improvements which needs PF (at
this moment), and i'm asking for permission to commit
PF-for-netbsd-current, as it is too painful to maintain local patch
myself (as said earlier i work on multiple platforms, current and
release w/kame, in parallel).
itojun
ito...@iijlab.net
> which is trying to create a good code that benefits all BSDs) i'm
> trying to do so. KAME have made some improvements which needs PF (at
> this moment), and i'm asking for permission to commit
> PF-for-netbsd-current, as it is too painful to maintain local patch
> myself (as said earlier i work on multiple platforms, current and
> release w/kame, in parallel).
also note that i'm not the only one who want PF on netbsd.
(including Joel Wilsson)
itojun
Thor Lancelot Simon
> i do read all part of your response, but i chose not to comment on each
> lines, as it does not seem to be productive for me.
Okay, fine. What I don't understand is how you can fail to dispute any
of the underlying facts, nor any of the reasoning, but then assert --
quite forcefully -- that my conclusion is false.
> >I can't see how the actual facts would not be rather disturbing to just
> >about anyone who took a careful look at them -- but wishing inconvenient
> >or disturbing facts out of existence, sadly, is not a productive way to
> >deal with them, any more than calling those who point them out liars.
>
> excuse me? i apologized about the strong statement i've made a couple
> of minutes ago. and you still keep blame on me on that? i see why
Look, I accept your apology, and I thank you for making it; but that hardly
requires me to consider calling me a liar a productive method of discourse!
Similarly, I don't call ignoring inconvenient facts a productive method of
discourse. And what I said about many NetBSD developers being unable to work
on OpenBSD because they have been expelled therefrom or denied developer
status or told not to even bother to ask for is is, indeed, factual. The
obvious next logical step from there is that "you can just go be an OpenBSD
developer if you want to work on PF" is not really a useful thing to say when
some of those developers voice some concern about whether we would be
importing a major system component over which we have, essentialy, no control.
If you want to persuade people that what you want is the right thing to do,
you need to stop exploding at them when they dispute some of your reasoning
or point out that some of your facts aren't. I'm glad you aren't calling me
a liar any more, and I'm also sorry that the discussion got as heated as it
did, but I think we've ended up pretty much where we started: NetBSD
developers are concerned about replacing a major system component with one
whose canonical sources we don't really have any way to contribute to, and
there's really been no significant effort made to address that concern --
because "you can just go work on OpenBSD" simply isn't a factual statement
for many of us!
> i really hope this atmosphere to change. by working on KAME project
> which is trying to create a good code that benefits all BSDs) i'm
> trying to do so. KAME have made some improvements which needs PF (at
> this moment), and i'm asking for permission to commit
> PF-for-netbsd-current, as it is too painful to maintain local patch
> myself (as said earlier i work on multiple platforms, current and
> release w/kame, in parallel).
I understand that. From my point of view (and, if I understand what they
have said correctly, that of a few other NetBSD developers participating
in this discussion), the only real problems are that use of PF is
currently hardcoded into the KAME code you want to import, that some of
the people working on our network stack and packet filter don't really
feel free to contribute to PF development (or, in some cases, development of
the underlying KAME code) and that PF and our existing packet filter don't
really coexist peacefully, which means that the change you want to make is
tantamount to forcing anyone using the KAME code in question to punt our
existing packet filter.
I thought Darren's suggestion of importing a slightly older ALTQ into
NetBSD while cooperating to work on a formal API for use of other
packet filters with KAME was a pretty good one, but I can see how it might
not really appeal to you or to the other KAME developers. Do you see any
middle ground that might work better for all involved?
Sean Davis
I am not against PF for NetBSD, as long as it doesn't take the place of IPF.
I'm quite happy with IP Filter, and I personally think ALTQ should be able
to use either. If this requires modifications of the IPF code, well, Darren
should be able to what is needed.
-Sean
--
/~\ The ASCII
\ / Ribbon Campaign Sean Davis
X Against HTML aka dive
/ \ Email!
Joel Wilsson
And a whole bunch of others who have emailed me privately about it.
(this is a bit of a rant, it's 5:30 am, but here goes)
Let's not get angry at each other over this. I think both Darren and
Thor
raise some valid points, especially about the latest (?) ALTQ having
hardcoded calls to pf.
That's not a good design, unless you really do want to merge pf and ALTQ
completely and not be able to use ALTQ separately. If I understood
Kenjiro correctly, you don't intend to do that.
On the other hand, I don't see why it's so horrible to have to configure
ALTQ through pfctl, even if you don't use pf for filtering. It doesn't
seem to be a big deal.
What would change if the new ALTQ code was imported, and pf along with
it?
1) You would be able to choose among pf and IPFilter for packet
filtering.
2) You would no longer be able to configure ALTQ directly, but would
have
to go through pfctl instead.
The first is good, the second seems like a minor problem (or feature).
So I must be missing something here, let me know what.
If I understand Darren correctly, he's worried that ALTQ won't get a
generic API that is not dependent on pf. That's reasonable, if he wants
to
add support for ALTQ in IPFilter. Can you (itojun or Kenjiro) make that
clear? Kenjiro wrote earlier that an API wouldn't be necessary, but I
disagree. Will ALTQ once again be free from pf, ever, and if so,
in how long? If IPFilter doesn't support ALTQ right now, it doesn't
matter
if ALTQ will depend on pf for a while - but it should not stay that way.
On Sunday, June 29, 2003, at 03:14 am, Thor Lancelot Simon wrote:
> Consequently, the suggestion that NetBSD should
> rip out a major piece of infrastructure and replace it with one
> for which meaningful development participation requires OpenBSD
> development status (as you yourself said) seems like a very poor
> idea to say the least.
I don't think anyone is suggesting that NetBSD should rip out a major
piece of infrastructure (I assume you refer to IPFilter, but it's not
very
clear) and replace it with pf. IPFilter should of course still be
available.
There is absolutely no reason why it shouldn't.
And you have the source to pf, you don't need OpenBSD development
status to
work on it. Just like the OpenBSD guys don't need NetBSD development
status
to work on e.g. uvm.
To be honest I found this statement:
"you can join openbsd project if you would like to participate PF
development"
a bit arrogant, even if it wasn't intended that way. Many people simply
can't join the OpenBSD project, for a number of reasons
(Thor have explained some of them, but there are other, less spectacular
ones like "I don't have time", "I want to focus on one project", etc.)
The good thing is, they don't have to do that just to improve pf.
Be nice to each other and think about a way to solve this, and I'm sure
we
can come up with a solution we're all mostly happy with. Don't commit
anything before that, as it'll only do more harm than good.
Goodnight,
joelw
Andrew Gillham
Itojun, I just want to make sure I understand one point.
If you import PF-for-netbsd-current (and updated ALTQ), we will be able
to use IP-Filter for packet filtering _concurrently_ with PF for
classifying traffic for ALTQ?
So theoretically all you're really proposing is to replace the existing
ALTQ classifier with PF? The fact that PF also happens to be capable of
filtering packets, not just classifying / tagging, shouldn't really
matter for that purpose.
As a NetBSD user I would like to see PF brought in with the updated
ALTQ. Being able to use IPF-like syntax for ALTQ would be nice.
-Andrew
James Chacon
simply comparing userid's isn't proving much when they're not unique...
James
ito...@iijlab.net
>
>If you import PF-for-netbsd-current (and updated ALTQ), we will be able
>to use IP-Filter for packet filtering _concurrently_ with PF for
>classifying traffic for ALTQ?
yes.
>So theoretically all you're really proposing is to replace the existing
>ALTQ classifier with PF? The fact that PF also happens to be capable of
>filtering packets, not just classifying / tagging, shouldn't really
>matter for that purpose.
"replace ALTQ classifier with PF" is kjc's part, but my understanding
is "yes".
itojun
der Mouse
> are a number of others who have been told in no uncertain terms that
> they need not apply to the OpenBSD project because they are not
> welcome.
I had an openbsd.org account for...a week? two? some short period.
Theo gave it to me out of the blue, for no reason I could discern,
shortly after the obsd/nbsd split. He took it away again after a brief
spat over some bug incident on, IIRC, bugtraq (I can recount my take on
it if anyone is interested, but this really isn't the place). It ended
with his telling me (quote is from memory) "your ethics stink, you
clearly cannot keep a promise" - a very serious charge to me, as I take
my word seriously. He never explained what promise he thought I had
made and then failed to keep (not that that surprises me).
Add to that the recent kafuffle over the copyright license on...tun.4,
I think it was...and, well, while I have not been explicitly told I
would be unwelcome as an OpenBSD developer, I have no doubt that such
is indeed the case.
Whether this is related to my continuing to use and promote NetBSD, and
being a NetBSD developer at least nominally, is a subject for some
speculation, perhaps mildly interesting to some but pretty pointless.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Manuel Bouyer
> [...]
Actually, this *is* the problem. The existing practice for NetBSD is that
code which has to interract with other piece of code doesn't get imported
before the API has been discussed and fixed; and I think this should not
change. Frequent API changes between different piece of code is a real
pain for peoples maintaining external patches.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 24 ans d'experience feront toujours la difference
--
ito...@iijlab.net
>code which has to interract with other piece of code doesn't get imported
>before the API has been discussed and fixed; and I think this should not
>change. Frequent API changes between different piece of code is a real
>pain for peoples maintaining external patches.
ok, i've moved tagname-to-tag/tag-to-tagname function to
sys/kern/uipc_mbuf2.c. it should be enough to make ipfilter-with-
tagging get going. READ DIFF BEFORE COMMENT. look for "tag2tagname".
orange.kame.net:~ftp/pub/kame/misc/netbsd-pf-20030629.diff
itojun
ito...@iijlab.net
>> generic API that is not dependent on pf. That's reasonable, if he wants
>> to
>> add support for ALTQ in IPFilter. Can you (itojun or Kenjiro) make that
>> clear? Kenjiro wrote earlier that an API wouldn't be necessary, but I
>> disagree. Will ALTQ once again be free from pf, ever, and if so,
>> in how long? If IPFilter doesn't support ALTQ right now, it doesn't
>> matter
>> if ALTQ will depend on pf for a while - but it should not stay that way.
>
>Actually, this *is* the problem. The existing practice for NetBSD is that
>code which has to interract with other piece of code doesn't get imported
>before the API has been discussed and fixed; and I think this should not
>change. Frequent API changes between different piece of code is a real
>pain for peoples maintaining external patches.
API for ALTQ itself is open to any userland program, via ioctl.
i worry about support issues (config syntax and such) if both ipfilter
and PF were to include ALTQ controller functionality.
itojun
Manuel Bouyer
> API for ALTQ itself is open to any userland program, via ioctl.
> i worry about support issues (config syntax and such) if both ipfilter
> and PF were to include ALTQ controller functionality.
Well, if altq is configured from the packet classifier engine's config file,
and each packet classifier use its own syntax to configure altq, I don't
see this as a big deal. They're different piece of software, after all.
Now, I don't see any real reason to configure altq from the
packet classifier config file. There are 2 different, separate things:
packet classifiers tag packets, and altq is one of the users of packet tags
(ipsec is one other, and I can see more packet classifiers than pf or ipf,
and more packet tags users than altq or ipsec, in some commercial developement
I'm aware). I think each packet classifier, and each packet tag user should
have its own config file with its own config tool, with only the tags names
in common.
ito...@iijlab.net
to remove ipfilter from NetBSD. i'm proposing
- addition of PF to the system
then
- upgrade of ALTQ to the latest (ALTQ-and-PF integration)
- upgrade of KAME IPsec to the latest (IPsec-and-PF integration)
please read diff before you make further comments.
orange.kame.net:~ftp/pub/kame/misc/netbsd-pf-20030629.diff
>I thought Darren's suggestion of importing a slightly older ALTQ into
>NetBSD while cooperating to work on a formal API for use of other
>packet filters with KAME was a pretty good one, but I can see how it might
>not really appeal to you or to the other KAME developers. Do you see any
>middle ground that might work better for all involved?
there are a lot of ioctl changes made during ALTQ-and-PF integration.
what we have now is like this (in kame tree):
ALTQ-and-PF with new ioctl (openbsd/sys/altq)
standalone ALTQ with old ioctl (kame/sys/altq)
and i don't think it worthwhile to put time on kame/sys/altq to
catch up with the former.
itojun
ito...@iijlab.net
>> i worry about support issues (config syntax and such) if both ipfilter
>> and PF were to include ALTQ controller functionality.
>
>Well, if altq is configured from the packet classifier engine's config file,
>and each packet classifier use its own syntax to configure altq, I don't
>see this as a big deal. They're different piece of software, after all.
>
>Now, I don't see any real reason to configure altq from the
>packet classifier config file. There are 2 different, separate things:
>packet classifiers tag packets, and altq is one of the users of packet tags
>(ipsec is one other, and I can see more packet classifiers than pf or ipf,
>and more packet tags users than altq or ipsec, in some commercial developement
>I'm aware). I think each packet classifier, and each packet tag user should
>have its own config file with its own config tool, with only the tags names
>in common.
(kjc should have better answer)
i was a little bit mistaken. ALTQ and PF is coupled by queue name also
(which is a bit different from tags - tags and queues are identfied
by m_tag attached to mbuf, but uses different m_tag ID).
to have a list of queue name PF currently has to have the ALTQ config
file. (see sys/net/pf.c:pf_qname_to_qid)
anyways, pls wait till kjc responds.
itojun
Sporleder, Matthew (CCI-Atlanta)
-----Original Message-----
From: Martin Husemann [mailto:mar...@duskware.de]
Sent: Sat 6/28/2003 7:42 PM
To: Sporleder, Matthew (CCI-Atlanta)
Cc: ito...@iijlab.net; tech...@netbsd.org
Subject: Re: PF for netbsd
On Fri, Jun 27, 2003 at 09:13:43PM -0400, Sporleder, Matthew =
(CCI-Atlanta) wrote:
> then why not
> accept the use of something that we have more control over instead
> of waiting on the ipf development to integrate a new feature?
I'm not sure what you realy mean, but PF does 100% fail to meet the =
"more
control" criteria - which is probably still quite an understatement.
Martin
Manuel Bouyer
Well, as these functions are now independant of pf, it would be better to
to rename them.
--
Manuel Bouyer, LIP6, Universite Paris VI. Manuel...@lip6.fr
ito...@iijlab.net
>> sys/kern/uipc_mbuf2.c. it should be enough to make ipfilter-with-
>> tagging get going. READ DIFF BEFORE COMMENT. look for "tag2tagname".
>>
>> orange.kame.net:~ftp/pub/kame/misc/netbsd-pf-20030629.diff
>
>Well, as these functions are now independant of pf, it would be better to
>to rename them.
pftag_ prefix means "packet filter tag", not PF :-)
itojun
Manuel Bouyer
I would prefer "packet classifier tag" then, or even "packet tag". the tag
doesn't have to be set by a packet filter :)
ito...@iijlab.net
orange.kame.net:~ftp/pub/kame/misc/netbsd-pf-20030701.diff.gz
itojun
Darren Reed
Itojun, if you're serious about making this cross platform and
not require PF then code like this:
+#if NPF > 0
+ tagvalue = pf_tagname2tag(tag->sadb_x_tag_name);
+ /* tag refcnt++ */
+ newsp = key_getspbytag(tagvalue, xpl0->sadb_x_policy_dir);
+#else
+ panic("PF");
+#endif
has to change before it goes in NetBSD.
Darren
Manuel Bouyer
> new diff is avaialble, this time includes IPsec-with-PF diff.
> orange.kame.net:~ftp/pub/kame/misc/netbsd-pf-20030701.diff.gz
As far as I can tell, qname_to_qid() & all aren't dependant from pf but
rather from altq. Maybe they should be moved to altq instead ?
Also, it seems tagname2tag() & friend is back into pf code, is it
intentionnal ?
Also there should probably be no
#if NPF > 0
in non-pf code (ipsec and altq).
And really, I'd prefer to have the struct and functions names for the
m_tag stuff with another prefix than pf. It makes the code much more readable
when each subsystem's name is properly prefixed, and really confusing when
the same prefix is used for different subsystems.
ito...@iijlab.net
see the code above there. the "panic" part will never be visited.
itojun
Darren Reed
And why won't it if I have a kernel that doesn't have PF but instead
uses another 3rd party classifier ?
Or if the "panic" part will never be visited, why is it there ?
One way or another, it seems, to me, to need fixing.
Darren
ito...@iijlab.net
>> new diff is avaialble, this time includes IPsec-with-PF diff.
>As far as I can tell, qname_to_qid() & all aren't dependant from pf but
>rather from altq. Maybe they should be moved to altq instead ?
kjc will do something about it.
>Also, it seems tagname2tag() & friend is back into pf code, is it
>intentionnal ?
see conversation w/ darrenr. anyways it's back in uipc_mbuf2.c.
>Also there should probably be no
>#if NPF > 0
>in non-pf code (ipsec and altq).
>
>And really, I'd prefer to have the struct and functions names for the
>m_tag stuff with another prefix than pf. It makes the code much more readable
>when each subsystem's name is properly prefixed, and really confusing when
>the same prefix is used for different subsystems.
"tag" is already used for m_tag, so i guess "pftag" is the best name
i can think of.
itojun
Manuel Bouyer
> orange.kame.net:~ftp/pub/kame/misc/netbsd-pf-20030703.diff.gz
>
> >> new diff is avaialble, this time includes IPsec-with-PF diff.
> >As far as I can tell, qname_to_qid() & all aren't dependant from pf but
> >rather from altq. Maybe they should be moved to altq instead ?
>
> kjc will do something about it.
OK, I'm waiting on it.
>
> >Also, it seems tagname2tag() & friend is back into pf code, is it
> >intentionnal ?
>
> see conversation w/ darrenr. anyways it's back in uipc_mbuf2.c.
I didn't see this, I musr have missed it.
>
> >Also there should probably be no
> >#if NPF > 0
> >in non-pf code (ipsec and altq).
> >
> >And really, I'd prefer to have the struct and functions names for the
> >m_tag stuff with another prefix than pf. It makes the code much more readable
> >when each subsystem's name is properly prefixed, and really confusing when
> >the same prefix is used for different subsystems.
>
> "tag" is already used for m_tag, so i guess "pftag" is the best name
> i can think of.
It's not 'tag' which makes me unconfortable, it's 'pf'. This has nothing
to do with the PF code once moved to uipc_mbuf2.c.
It's used by both packets classifiers (pf, ipf, other classifiers) and
tag consumers (altq, ipsec).
As far as I can tell, m_tag related functions are all prefixed with m_tag,
not tag. And a m_tag prefix for these functions looks fine to
me (m_tag_name2tag(), m_tag_tag2name(), etc), as they're really related to
m_tag too.
ito...@iijlab.net
>> i can think of.
>It's not 'tag' which makes me unconfortable, it's 'pf'. This has nothing
>to do with the PF code once moved to uipc_mbuf2.c.
>It's used by both packets classifiers (pf, ipf, other classifiers) and
>tag consumers (altq, ipsec).
>As far as I can tell, m_tag related functions are all prefixed with m_tag,
>not tag. And a m_tag prefix for these functions looks fine to
>me (m_tag_name2tag(), m_tag_tag2name(), etc), as they're really related to
>m_tag too.
i don't like m_tag_name2tag, because m_tag is used for other purposes.
the name2tag/tag2name functions are just for PACKET_TAG_PF_TAG tags.
itojun
Manuel Bouyer
>
> i don't like m_tag_name2tag, because m_tag is used for other purposes.
> the name2tag/tag2name functions are just for PACKET_TAG_PF_TAG tags.
There could be other things that could make use of name2tag/tag2name
functions (altq queues ?).
The m_pftag* functions could be extended to take the queue head as argument,
so they wouldn't be specific to the pf_tags list any more.
The problem is then the declaration of the queue head. For pf_tag,
as there are several independant users, this would this have to be
defined in a common place, probably uipc_mbuf2.c.
Maybe it ins't a that good idea. What do others think ?
Stuart Brooks
I have a situation where a tcp connection from a Windows to a NetBSD 1.5.1
system is being terminated at the socket level with the error "Connection
reset by peer" (on the Windows box), and at the same time on the NetBSD
system I see the kernel printout : "tlp0: transmit timeout". Does this ring
any bells with anyone?
I will give a bit more information :
1. In general the socket on the target machine closes down cleanly although
I have seen an instance where it also terminated with the "Connection reset
by peer" error. In *every* case I have seen the "tlp0: transmit timeout"
message printed out, either a few seconds before or a few seconds after the
connection was dropped on the NetBSD system
2. It generally takes some time to fail (up to a couple of hours) and the
NetBSD system is pushing out between 2 and 4 Mbits/s.
3. I am only seeing this when connecting to machines with tlp0 cards
(Davicom chipset) - I have been unable to reproduce this connecting to
NetBSD systems with Realtek 8139 cards, and the tests have been running for
days.
4. I am also *only* seeing it when I am connecting from a Windows machine
(which makes me think it could be something funny in the Windows sockets
layer). I have had stable connections running from other NetBSD systems for
days with identical code (although different compiler). I have tried
different Win98,2000 and XP with the same results.
5. I have tested with the 2 systems separated by a 100 meg switch, and with
them going through a gateway machine (down to 10 meg) with the same results.
Is there anyone out there who has seen something like this? My feeling is
that this could be a Windows funny, but the fact that Netbsd is printing
some sort of warning worries me. Is the tlp0 driver rock solid on 1.5.1?
Regards
Stuart
Patrick Welche
...
> system I see the kernel printout : "tlp0: transmit timeout". Does this ring
> any bells with anyone?
> that this could be a Windows funny, but the fact that Netbsd is printing
> some sort of warning worries me. Is the tlp0 driver rock solid on 1.5.1?
On a Power Macintosh 5500/225 I had
NetBSD 1.5.1_BETA2 (INSTALL) #5: Sat May 12 12:56:49 PDT 2001
ma...@duel.local:/u1/kobj/INSTALL
CPU: 603ev (Revision 1201)
...
tlp0 at pci0 dev 13 function 0: DECchip 21041 Ethernet, pass 2.1
tlp0: interrupting at irq 23
tlp0: Ethernet address 00:c0:f0:37:01:58
tlp0: 10baseT, 10base2, 10baseT-FDX
...
tlp0: receive ring overrun
tlp0: receive ring overrun
.. ad infinitum
From memory life wasn't any better with the de(4) driver - I'll try to get
that box back and see if it's still true with NetBSD 1.6..
Cheers,
Patrick
Bill Studenmund
May I suggest calling it "pctag" for packet classifier tag? From what I've
read, I think that Itojun has two meanings for "pf" in mind, one being
specifically the PF packet classifying and filtering code and the other
being a service that things like altq and IPsec can use so that they too
don't have to also classify a packet. At the present time, the PF packet
code is serving for both, but that can change.
By calling the packet classification service a different name from the PF
code (even if the PF code is the only implementation for the moment) will
more clearly differentiate the two.
I realize that at the moment, the pc routines may just contain something
like:
#ifdef PF
return pf_foo();
#else
#ifdef IPF
return ipf_foo();
#endif
#endif
But even that would be a step in the right direction.
Take care,
Bill
Manuel Bouyer
> > not tag. And a m_tag prefix for these functions looks fine to
> > me (m_tag_name2tag(), m_tag_tag2name(), etc), as they're really related to
> > m_tag too.
>
> May I suggest calling it "pctag" for packet classifier tag? From what I've
> read, I think that Itojun has two meanings for "pf" in mind, one being
> specifically the PF packet classifying and filtering code and the other
> being a service that things like altq and IPsec can use so that they too
> don't have to also classify a packet. At the present time, the PF packet
> code is serving for both, but that can change.
>
> By calling the packet classification service a different name from the PF
> code (even if the PF code is the only implementation for the moment) will
> more clearly differentiate the two.
>
> I realize that at the moment, the pc routines may just contain something
> like:
>
> #ifdef PF
> return pf_foo();
> #else
> #ifdef IPF
> return ipf_foo();
> #endif
> #endif
Not really, in fact PF is a user of these functions, but there's nothing
specific to pf in them. They've been moved to uipc_mbuf2.c, and that's why
I'd like to have a different name for them, so that we don't mix these
functions with the ones implementing PF.
In the current state the affetcted functions are specific to the
PACKET_TAG_PF_TAG mbuf tag type, but they can be made more generic by adding
a second argument (I don't know if this is usefull, though)
--
Manuel Bouyer <bou...@antioche.eu.org>
Jason Thorpe
On Sunday, July 6, 2003, at 02:57 AM, Manuel Bouyer wrote:
> Not really, in fact PF is a user of these functions, but there's
> nothing
> specific to pf in them. They've been moved to uipc_mbuf2.c, and that's
> why
> I'd like to have a different name for them, so that we don't mix these
> functions with the ones implementing PF.
I suggested the name "m_nametag_...()" to itojun in a private mail.
-- Jason R. Thorpe <tho...@wasabisystems.com>
Manuel Bouyer
I like it
Luke Mewburn
|
--------------------------
| Hi, my name is JASON |
| I hack network stacks. |
| How may I help you? |
--------------------------
?
;-)