committed the patch and also to ipf_y.y in ../tools/.
I'll be pushing these and a lot of other changes upline when I'm done. The
work that has been done so far -- fixing bugs -- has also been shared with
NetBSD. I've used some of NetBSD's ipfilter patches in our tree.
--
Cheer
On 22.06.2017 21:20, Cy Schubert wrote:
Can you try the attached patch please?
Yes, replacing:
-#ifdef AF_INET6
+#ifdef USE_INET6
lets the build succeed. Is it Ok to modify stuff under contrib/ though?..
-mi
___
freebsd-current@freebsd.org
> > Maybe, the scope of the GH-project can/should be narrowed then?
> >
> > On 22.06.2017 12:54, Mark Johnston wrote:
> > > I verified that the kernel compiles with IPFILTER enabled.
> > I do not have IPFILTER in kernel -- indeed, kernel was compiling Ok
> >
In message , Hans Petter
Selasky w
rites:
> On 06/22/17 15:51, Mikhail T. wrote:
> > Trying to build 12.0-CURRENT (well, actually, the next-drm Git branch),
> > I get:
> >
> > /contrib/ipfilter/lib/printpoolnode.c:42:53: error: no member named
:
> > I verified that the kernel compiles with IPFILTER enabled.
> I do not have IPFILTER in kernel -- indeed, kernel was compiling Ok
> before. It is the "world" that was not building... And still is not:
Sorry, I missed that. I can reproduce the failure on stock FreeBSD
On Thu, Jun 22, 2017 at 04:28:34PM +0200, Hans Petter Selasky wrote:
> On 06/22/17 15:51, Mikhail T. wrote:
> > Trying to build 12.0-CURRENT (well, actually, the next-drm Git branch),
> > I get:
> >
> > /contrib/ipfilter/lib/printpoolnode.c:42:53: error: no member
On 06/22/17 15:51, Mikhail T. wrote:
Trying to build 12.0-CURRENT (well, actually, the next-drm Git branch),
I get:
/contrib/ipfilter/lib/printpoolnode.c:42:53: error: no member named
'in6' in 'union i6addr'
str = inet_ntop(AF_INET6,
&n
In message <58e656c6.8000...@gmail.com>, Ernie Luzar writes:
> Cy Schubert wrote:
> > In message <58e50379.6090...@gmail.com>, Ernie Luzar writes:
> >> I have been a ipfilter user since Freebsd 3.0 without any complaints.
> >> Now I'm trying to get i
Cy Schubert wrote:
In message <58e50379.6090...@gmail.com>, Ernie Luzar writes:
I have been a ipfilter user since Freebsd 3.0 without any complaints.
Now I'm trying to get ippool to function. I have been able to add a
pool, but now I want to refresh it's contents. From what I
In message <58e50379.6090...@gmail.com>, Ernie Luzar writes:
> I have been a ipfilter user since Freebsd 3.0 without any complaints.
> Now I'm trying to get ippool to function. I have been able to add a
> pool, but now I want to refresh it's contents. From what I rea
I have been a ipfilter user since Freebsd 3.0 without any complaints.
Now I'm trying to get ippool to function. I have been able to add a
pool, but now I want to refresh it's contents. From what I read in "man
8 ippool", I have to remove the pool from core and then re-add i
On Tue, Jul 09, 2013 at 12:49:36PM -0400, John Baldwin wrote:
J> Let's not make ipfilter some random one-off vendor source that imports code
J> into random places. The remaining instances of that that we have (such as
J> stdtime) are a PITA to deal with.
J>
J> vendor/ipfil
other
> C>
> C> How is this for a plan?
> C>
> C> Instead of importing the kernel bits into vendor-sys/ipfilter and the
> C> userland bits into vendor/ipfilter, the base tarball should be imported
> C> into vendor-sys/ipfilter (or vendor/ipfilter, doesn&#
On Friday, July 05, 2013 4:46:49 am Gleb Smirnoff wrote:
> Cy,
>
> On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote:
> C> Unfortunately it doesn't work any more. Here is what svn spit out at me.
> C>
> C> slippy$ cd $MY_WORK_DIR/current/contrib
On Tue, Jul 9, 2013, at 11:21 AM, Gleb Smirnoff wrote:
...
> No, userland tools should be placed in bin|sbin|usr.bin|usr.sbin,
> according to the place where they are installed. An exlusion can be made
> adding a intermediate subdir (like this is already done for ipfilter
> tools),
&g
kernel part in sys/netpfil certainly makes it easier
> for kernel people to adjust it to changed realities.
>
> IIRC ipfilter also has very messy ifdef's all over the place for
> every possible ancient version of FreeBSD. This probably should
> be cleaned up (and upstreamed) as w
got vendor branch
C> > already?
C> >
C> > What we lose is:
C> > - more complex Makefiles
C> > - more complex hacking: edit files in one place, run make in other
C>
C> How is this for a plan?
C>
C> Instead of importing the kernel bits into vendor-sys/i
In message <20130708134400.gh67...@glebius.int.ru>, Gleb Smirnoff writes:
> Cy,
>
> On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote:
> C> > What I'd prefer to see is the following:
> C> >
> C> > - commit new ipfilter untouched t
In message <51da85cf.3000...@freebsd.org>, Andre Oppermann writes:
> On 05.07.2013 20:38, Cy Schubert wrote:
> > In message <20130705084649.gc67...@freebsd.org>, Gleb Smirnoff writes:
> >> What I'd prefer to see is the following:
> >>
> >> -
Cy,
On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote:
C> > What I'd prefer to see is the following:
C> >
C> > - commit new ipfilter untouched to vendor-sys/ipfilter
C> > - nuke sys/contrib/ipfilter
C> > - svn copy vendor-sys/ipfilter to sys/netpfil
On 05.07.2013 20:38, Cy Schubert wrote:
In message <20130705084649.gc67...@freebsd.org>, Gleb Smirnoff writes:
What I'd prefer to see is the following:
- commit new ipfilter untouched to vendor-sys/ipfilter
- nuke sys/contrib/ipfilter
- svn copy vendor-sys/ipfilter to sys/netpf
In message <20130705084649.gc67...@freebsd.org>, Gleb Smirnoff writes:
> Cy,
>
> On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote:
> C> Unfortunately it doesn't work any more. Here is what svn spit out at me.
> C>
> C> slippy$ cd $MY_WORK_DI
Cy,
On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote:
C> Unfortunately it doesn't work any more. Here is what svn spit out at me.
C>
C> slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter
C> slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfilte
C
Hi,
Originally this email was a here is how I'm planning on doing it kind of
email but now that svn 1.8 broke the third step I need some help.
I've been getting the flattening of the ipfilter vendor branch right and
working on the importation of ipfilter 5.1.2 into my own test SVN r
On 19 Apr 2013 10:46, "David Demelier" wrote:
>
> 2013/4/14 Gary Palmer :
> > On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> >> Is it possible to move ipfilter into a port?
> >
> > That may work short term, but the ENOMAINTAINER proble
On Fri, Apr 19, 2013 at 11:45:57AM +0200, David Demelier wrote:
> 2013/4/14 Gary Palmer :
> > Do we honestly need three packet filters?
>
> No, for me only one should be present. I completely understand that
> some users still use IPFilter and IPFW but why providing thre
2013/4/14 Gary Palmer :
> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
>> Is it possible to move ipfilter into a port?
>
> That may work short term, but the ENOMAINTAINER problem will quickly creep
> up again as kernel APIs change. If the author has lost interes
As long as it's not in GENERIC should be fine.
> > A person can always load it anyway.
>
> There's a plan[1] to remove the remaining GPL components from base
> over time. Updating to the last ipfilter that's under the current
> license is probably the path forward,
t; A person can always load it anyway.
There's a plan[1] to remove the remaining GPL components from base
over time. Updating to the last ipfilter that's under the current
license is probably the path forward, unless it moves out to ports.
[1] ht
On Mon, 15 Apr 2013 12:15:49 -0700, Cy Schubert
wrote:
> It was pointed out to me that Darren Reed has changed licenses from
> his IP Filter license that's been in IPF since 2005 or so, when he
> joined Sun, to GPLv2 (probably when Darren left when Oracle took over
> Sun). Given that IPF already
On 15.04.2013 19:48, Cy Schubert wrote:
I did consider a port but given it would has to touch bits and pieces of
the source tree (/usr/src), a port would be messy and the decision was made
to work on importing it into base.
Actually it shouldn't touch many if any pieces of src/sys. Everything
In message <20130415212826.ga76...@freebsd.org>, Gleb Smirnoff writes:
> On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote:
> c> However it would of been better if said person asked me as I already
> c> offered to take it on but whatever.
Sorry, I didn't see your posting. I had a permis
tion is to remove it (or let it continue to rot and be an eyesore) but
I'll defer to those like
S> Gleb and Rui with a more vested interest in it.
I'm not a licensing guru, so I can't tell whether GPL ipfilter can live in
src/ and if it can, where should it be. So I expect someone
On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote:
c> However it would of been better if said person asked me as I already
c> offered to take it on but whatever.
More manpower - the better. Why can't you work together?
--
Totus tuus, Glebius.
_
>>>
> >>>>> I've been planning on taking on IP Filter for quite some
> >>>>> time. Unfortunately I've left my src commit bit lapse (my
> >>>>> ports commit bit is alive and well though) thus I'm looking
> >>
t is
>>>>> alive and well though) thus I'm looking for a mentor. In addition I'm
>>>>> working on an ACER WMI/ACPI kld. One mentor would be preferred but two
>>>>> would be fine too.
>>>>
>>>> What are your plans re
#x27;s going to stay in FreeBSD at all
> , it
> needs to be maintained. This could be set about a fair amount of stuff in Fr
> eeBSD,
> but IPFilter stands out since there's a high rate of needed change happening
> in
> the network stack, and it shouldn't be left to r
Filter for quite some time.
>>> Unfortunately I've left my src commit bit lapse (my ports commit bit is
>>> alive and well though) thus I'm looking for a mentor. In addition I'm
>>> working on an ACER WMI/ACPI kld. One mentor would be preferred but two
>
uld be set about a fair amount of stuff in
FreeBSD,
but IPFilter stands out since there's a high rate of needed change happening in
the network stack, and it shouldn't be left to rot nor to be a stumbling block
for
those changes.
Scott
On Apr 15, 2013, at 12:49 PM, "Sam Fourman Jr.
ced that head already differs from stable/9,
> for example network stack is entirely in network byte order. So merging
> would require a lot of attention and testing.
>
> C> I did consider a port but given it would has to touch bits and pieces of
> C> the source tree (/usr/src)
rt would be messy and the decision was made
C> to work on importing it into base.
Port isn't an option. IPFilter is too close to many kernel APIs, that
can change quickly.
--
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
htt
e left my src commit bit lapse (my
>>>>> ports commit bit is alive and well though) thus I'm looking
>>>>> for a mentor. In addition I'm working on an ACER WMI/ACPI
>>>>> kld. One mentor would be preferred but two would be fine
>>>>&
addition I'm
> >>> working on an ACER WMI/ACPI kld. One mentor would be preferred but two
> >>> would be fine too.
> >>
> >> What are your plans regarding ipfilter? I remain unconvinced that it shoul
> d b
> >> e in the base system. Perhaps you can
To my knowledge it is already off by default and you need these options to
enable it
options IPFILTER
options IPFILTER_LOG
so to those that wish to have it removed from base, if it has a maintainer
whats the trouble?
On Mon, Apr 15, 2013 at 2:49 PM, Sam Fourman Jr. wrote:
>
> Thank
> > Unfortunately I've left my src commit bit lapse (my ports commit bit is
> > > alive and well though) thus I'm looking for a mentor. In addition I'm
> > > working on an ACER WMI/ACPI kld. One mentor would be preferred but two
> > > would be fine too
src commit bit lapse (my ports commit bit is
> > alive and well though) thus I'm looking for a mentor. In addition I'm
> > working on an ACER WMI/ACPI kld. One mentor would be preferred but two
> > would be fine too.
>
> What are your plans regarding ipfilter? I remain
an ACER WMI/ACPI kld. One mentor would be preferred but two
> would be fine too.
What are your plans regarding ipfilter? I remain unconvinced that it should be
in the base system. Perhaps you can work on it as a port?
Why do you want to work on something that people hav
ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_.
Adrian
On 15 April 2013 09:55, Cy Schubert wrote:
> I've been planning on taking on IP Filter for quite some time.
> Unfortunately I've left my src commit bit lapse (my ports commit bit is
> alive and well though) thus I'm look
I've been planning on taking on IP Filter for quite some time.
Unfortunately I've left my src commit bit lapse (my ports commit bit is
alive and well though) thus I'm looking for a mentor. In addition I'm
working on an ACER WMI/ACPI kld. One mentor would be preferred but two
would be fine too.
However it would of been better if said person asked me as I already
offered to take it on but whatever.
> In message , Warren Block
> writ
> es:
>> On Sun, 14 Apr 2013, Chris Rees wrote:
>>
>> > On 14 April 2013 01:41, Rui Paulo wrote:
>> >> 2013/04/13 16:01?Scott Long ??:
>> >>
>> >>> May
Ok, seems someone has taken the job.
> In message , Warren Block
> writ
> es:
>> On Sun, 14 Apr 2013, Chris Rees wrote:
>>
>> > On 14 April 2013 01:41, Rui Paulo wrote:
>> >> 2013/04/13 16:01?Scott Long ??:
>> >>
>> >>> Maybe something else, but whatever it is, it should be done. If you
>>
In message , Warren Block
writ
es:
> On Sun, 14 Apr 2013, Chris Rees wrote:
>
> > On 14 April 2013 01:41, Rui Paulo wrote:
> >> 2013/04/13 16:01?Scott Long ??:
> >>
> >>> Maybe something else, but whatever it is, it should be done. If you and
> Gleb don't want to do this, I will.
> >>
> >
>
> I have been very stubborn IPFW user for very long time, but finally gave up
> in favor of PF. Nothing like that ever since. I am also not convinced IPFW
> is any faster than PF.
Hi Daniel,
I know that measuring PPS for a firewall is not enought for comparing
firewall performance (rfc3511 deta
On Monday April 15 2013 12:32:37 Lev Serebryakov wrote:
> And, yes, NAT64 will be useful for sure, but it is another story,
> not IPv6<->IPv6 translation.
Fear not, NPT66 prefix translation is stateless,
this is nothing like NAT44 / NAPT.
On Monday April 15 2013 12:51:00 sth...@nethelp.no wrote:
On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala wrote:
> On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote:
>> Hello, Kimmo.
>> You wrote 15 апреля 2013 г., 14:47:24:
>>
>> KP> I'm however talking about an ftp client behind a very restrictive
>> KP> firewall making an IPv6 connection an ftp
On 14.04.13 21:55, Joe Holden wrote:
For non-nat ipfw is still superior in every way, numbered rules
(think: scripts), dummynet, much faster than pf, syntax is a lot nicer
and predictable...
And, best of all, it still is buggy. At lest, it's tables handling is
unusable.
I have been very st
> >> MM> ... and as far as I can tell none of them is currently usable
> >> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> >> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
> >> IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will
> >
On Mon, Apr 15, 2013 at 02:50:23PM +0400, Lev Serebryakov wrote:
> KP> I'm however talking about an ftp client behind a very restrictive
> KP> firewall making an IPv6 connection an ftp server that uses passive
> KP> mode data ports that can't be known in advance.
> Same solution -- inspection of
On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:47:24:
>
> KP> I'm however talking about an ftp client behind a very restrictive
> KP> firewall making an IPv6 connection an ftp server that uses passive
> KP> mode data ports that can't be kn
Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:47:24:
KP> I'm however talking about an ftp client behind a very restrictive
KP> firewall making an IPv6 connection an ftp server that uses passive
KP> mode data ports that can't be known in advance.
Same solution -- inspection of connections to 21 p
On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:36:27:
>
>>> And, yes, NAT64 will be useful for sure, but it is another story,
>>> not IPv6<->IPv6 translation.
> KP> You're forgetting set ups where outgoing traffic is controlled by
> KP> f
Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:36:27:
>> And, yes, NAT64 will be useful for sure, but it is another story,
>> not IPv6<->IPv6 translation.
KP> You're forgetting set ups where outgoing traffic is controlled by
KP> filter rules, outgoing passive mode ftp needs help from the proxy to
On Mon, Apr 15, 2013 at 1:38 PM, Slawa Olhovchenkov wrote:
> On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote:
>
>> >> Yes! This is the most clever thought in this thread. Why we need 3
>> >> firewalls? Two packet filters it's excess too. We have two packet filters:
>> >> one with e
On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote:
> >> Yes! This is the most clever thought in this thread. Why we need 3
> >> firewalls? Two packet filters it's excess too. We have two packet filters:
> >> one with excellent syntax and functionality but with outdated bandwidth
> >>
On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov wrote:
> Hello, Kimmo.
> You wrote 15 апреля 2013 г., 14:26:40:
>
>>> MM> ... and as far as I can tell none of them is currently usable
>>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>>> MM> none of them supports stateful NA
Hello, Kimmo.
You wrote 15 апреля 2013 г., 14:26:40:
>> MM> ... and as far as I can tell none of them is currently usable
>> MM> on an IPv6-only FreeBSD (like protecting a host with sshguard),
>> MM> none of them supports stateful NAT64, nor IPv6 prefix translation :(
>> IPv6 prefix translation?!
On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov wrote:
> Hello, Mark.
> You wrote 15 апреля 2013 г., 2:25:07:
>
>>> Yes! This is the most clever thought in this thread. Why we need 3
>>> firewalls? Two packet filters it's excess too. We have two packet filters:
>>> one with excellent syntax and f
Hello, Mark.
You wrote 15 апреля 2013 г., 2:25:07:
>> Yes! This is the most clever thought in this thread. Why we need 3
>> firewalls? Two packet filters it's excess too. We have two packet filters:
>> one with excellent syntax and functionality but with outdated bandwidth
>> control mechanism (ak
On Sun, Apr 14, 2013 at 07:55:21PM +0100, Joe Holden wrote:
> wishmaster wrote:
>
> > --- Original message ---
> > From: "Gary Palmer"
> > Date: 14 April 2013, 19:06:59
> >
> >
> >> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Bl
ting a bunch of examples on how to do it manually. Then
> we can give people 1y to switch.
Realy? pf do FTP nat translation w/o contexst switching?
Multiple GRE nat translation?
I am use from ipfilter only ipnat.
___
freebsd-current@freebsd.org mailing
On Apr 14, 2013, at 5:25 PM, Mark Martinec wrote:
> ... and as far as I can tell none of them is currently usable
> on an IPv6-only FreeBSD (like protecting a host with sshguard),
> none of them supports stateful NAT64, nor IPv6 prefix translation :(
pfSense 2.1 has a lot of work to make this h
On Sunday April 14 2013 19:30:22 wishmaster wrote:
> > Do we honestly need three packet filters?
> Yes! This is the most clever thought in this thread. Why we need 3
> firewalls? Two packet filters it's excess too. We have two packet filters:
> one with excellent syntax and functionality but with o
On 2013/04/14, at 12:11, Anton Shterenlikht wrote:
> A migration *guide*, yes. Tools to convert one syntax to another: no.
>
> ok, so what is the brief migraiton advice?
It's still being written.
> The Handbook mentions PF and IPFW.
> I gather from your mails that PF is the recommended c
0600, Warren Block wrote:
> > > Is it possible to move ipfilter into a port?
> >
> > That may work short term, but the ENOMAINTAINER problem will quickly
> creep
> > up again as kernel APIs change. If the author has lost interest in
> > maintaining the FreeBSD port of
A migration *guide*, yes. Tools to convert one syntax to another: no.
ok, so what is the brief migraiton advice?
The Handbook mentions PF and IPFW.
I gather from your mails that PF is the recommended choice.
Is that so?
If I choose PF, can I just follow the
Handbook PF section, and once i
wishmaster wrote:
--- Original message ---
From: "Gary Palmer"
Date: 14 April 2013, 19:06:59
On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
Is it possible to move ipfilter into a port?
That may work short term, but the ENOMAINTAINER problem will quickly creep
u
Odhiambo Washington writes:
> 2. PF is being felt to be part of FreeBSD, but it too lags far behind
> OpenBSD implementation - almost like it's unmaintained. There has been
> debates about this which were never concluded. Most of you will agree with
> me on this.
FreeBSD's version of pf is active
--- Original message ---
From: "Gary Palmer"
Date: 14 April 2013, 19:06:59
> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> > Is it possible to move ipfilter into a port?
>
> That may work short term, but the ENOMAINTAINER problem will quickly c
Hi,
I will see what I can do when I come back from work. PF is based on
ipfilter so having 3 is indeed a bit much.
Chris
> On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
>> Is it possible to move ipfilter into a port?
>
> That may work short term, but the ENOMAI
On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
> Is it possible to move ipfilter into a port?
That may work short term, but the ENOMAINTAINER problem will quickly creep
up again as kernel APIs change. If the author has lost interest in
maintaining the FreeBSD port of ipfilter t
>>
>> http://www.bayofrum.net/~crees/patches/remove-ipf.diff
>
>
> This should probably be done like we did for CVS for ports. Mark it as
> deprecated, then remove the Handbook section once the code is removed.
>
> Is it possible to move ipfilter into a port?
There isn&#
e-ipf.diff<http://www.bayofrum.net/~crees/patches/remove-ipf.diff>
>>
>
> This should probably be done like we did for CVS for ports. Mark it as
> deprecated, then remove the Handbook section once the code is removed.
>
> Is it possible to move ipfilter into a port?
ave
yet another annoyed party.
http://www.bayofrum.net/~crees/patches/remove-ipf.diff
This should probably be done like we did for CVS for ports. Mark it as
deprecated, then remove the Handbook section once the code is removed.
Is it possible to move ipfil
I do not stand in any good stead to comment on this, but I have used
IPFilter more extensively than PF when it comes to FreeBSD and packet
manipulations. As a user, what I can say is this:
1. The only firewall that seems 'native' to FreeBSD is ipfw and I believe
it works very well for
t; Lack of maintainer in a near future would lead to bitrot due to changes
>>>>> in other areas of network stack, kernel APIs, etc. This already happens,
>>>>> many changes during 10.0-CURRENT cycle were only compile tested wrt
>>>>> ipfilter. If we fail to
happens,
many changes during 10.0-CURRENT cycle were only compile tested wrt
ipfilter. If we fail to find maintainer, then a correct decision would be
to remove ipfilter(4) from the base system before 10.0-RELEASE.
This has been discussed in the past. Every time someone came up and said "I&#x
Rui Paulo wrote:
> 2013/04/13 16:01、Scott Long のメッセージ:
>
>> Maybe something else, but whatever it is, it should be done. If you and
>> Gleb don't want to do this, I will.
>
> I already started writing a guide. See here for a very incomplete version:
>
> http://people.freebsd.org/~rpaulo/ipf-d
On 14 April 2013 01:41, Rui Paulo wrote:
> 2013/04/13 16:01、Scott Long のメッセージ:
>
>> Maybe something else, but whatever it is, it should be done. If you and
>> Gleb don't want to do this, I will.
>
> I already started writing a guide. See here for a very incomplete version:
>
> http://people.fre
2013/04/13 16:01、Scott Long のメッセージ:
> Maybe something else, but whatever it is, it should be done. If you and Gleb
> don't want to do this, I will.
I already started writing a guide. See here for a very incomplete version:
http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html
___
x27;m aware of that, but the problem remains. If ipfilter is broken or
> gets broken because of the networking stack changes, we'll have to fix it to
> keep the deprecation path going...
>
Welcome to the challenges of maintaining a whole OS :-)
>>>> So with tha
On 2013/04/13, at 5:03, Scott Long wrote:
> You target audience for this isn't people who track CURRENT, it's people who
> are on 7, 8, or 9 and looking to update to 10.x sometime in the future.
Yes, I'm aware of that, but the problem remains. If ipfilter is broken or ge
ers
transition and cope with the deprecation. The fear of deprecation can be
largely overcome by giving these users a clear and comprehensive path forward.
Just announcing "ipfilter is going away. EOM" is inadequate and leads to
completely justified complaints from users.
S>
Smirnoff wrote:
>>>>
>>>>> Lack of maintainer in a near future would lead to bitrot due to changes
>>>>> in other areas of network stack, kernel APIs, etc. This already happens,
>>>>> many changes during 10.0-CURRENT cycle were only compil
ture would lead to bitrot due to changes
>>>> in other areas of network stack, kernel APIs, etc. This already happens,
>>>> many changes during 10.0-CURRENT cycle were only compile tested wrt
>>>> ipfilter. If we fail to find maintainer, then a correct decision would b
tack, kernel APIs, etc. This already happens,
>>> many changes during 10.0-CURRENT cycle were only compile tested wrt
>>> ipfilter. If we fail to find maintainer, then a correct decision would be
>>> to remove ipfilter(4) from the base system before 10.0-RELEASE.
>>
&
her areas of network stack, kernel APIs, etc. This already happens,
> >> many changes during 10.0-CURRENT cycle were only compile tested wrt
> >> ipfilter. If we fail to find maintainer, then a correct decision would be
> >> to remove ipfilter(4) from the base system before
10.0-CURRENT cycle were only compile tested wrt
>> ipfilter. If we fail to find maintainer, then a correct decision would be
>> to remove ipfilter(4) from the base system before 10.0-RELEASE.
>
> This has been discussed in the past. Every time someone came up and said "I
On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
> Lack of maintainer in a near future would lead to bitrot due to changes
> in other areas of network stack, kernel APIs, etc. This already happens,
> many changes during 10.0-CURRENT cycle were only compile tested wrt
> ipfilter. If we
Hello,
here is brief status on ipfilter(4) packet filtering facility,
written by Darren Reed, that is shipped with FreeBSD kernel.
o The version of the software is v4.1.28. The license is BSD, .. erm
the license is very close to BSD, but with some additions, most
notable is:
>
On Mon, Oct 27, 2003 at 08:09:33AM -0700, Jeremy Johnston wrote:
> /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c: In function `fr_check_wrapper':
> /usr/src/sys/contrib/ipfilter/netinet/ip_fil.c:319: error: `PFIL_OUT' undeclared
> (first use in this function)
> /usr/sr
1 - 100 of 210 matches
Mail list logo
