In message <16738440-df50-0e33-2a50-340071212...@aldan.algebra.com>,
"Mikhail T
." writes:
> This is a multi-part message in MIME format.
> --DC959F413BFB254449706900
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> On 22.06.2017 21:2
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
In message <2017060229.gd56...@wkstn-mjohnston.west.isilon.com>, Mark
Johns
ton writes:
> On Thu, Jun 22, 2017 at 02:49:24PM -0400, Mikhail T. wrote:
> > On 22.06.2017 10:28, Hans Petter Selasky wrote:
> > > Usually you only need the kernel from drm-next.
> >
> > Maybe, the scope of the GH-p
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
> > 'in6' in 'union i6addr'
> >
On Thu, Jun 22, 2017 at 02:49:24PM -0400, Mikhail T. wrote:
> On 22.06.2017 10:28, Hans Petter Selasky wrote:
> > Usually you only need the kernel from drm-next.
>
> Maybe, the scope of the GH-project can/should be narrowed then?
>
> On 22.06.2017 12:54, Mark Johnston wrote:
> > I verified that
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 named
> > 'in6' in 'union i
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,
&np->ipn_addr.adf_addr.in6,
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/ipfilter == userland bits =>
On Tuesday, July 09, 2013 5:21:36 am Gleb Smirnoff wrote:
> On Mon, Jul 08, 2013 at 01:00:02PM -0700, Cy Schubert wrote:
> C> > The BSD license allows us to put the code into FreeBSD w/o any
separation.
> C> >
> C> > So the question is: what is more handy to us?
> C> >
> C> > What do we actually
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/ipfilter
> C> slippy$ svn merge --recor
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),
> to group all r
On Mon, Jul 8, 2013, at 11:26 AM, Andre Oppermann wrote:
> I think the main distinction here is whether the adaptions to
> FreeBSD are kept local (resulting in almost a fork) or are fed
> upstream so that successive updates require less or no local
> changes.
>
> Having the kernel part in sys/netp
On Mon, Jul 08, 2013 at 01:00:02PM -0700, Cy Schubert wrote:
C> > The BSD license allows us to put the code into FreeBSD w/o any separation.
C> >
C> > So the question is: what is more handy to us?
C> >
C> > What do we actually gain having contrib/ipf, assuming we got vendor branch
C> > already?
C
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 to vendor-sys/ipfilter
> C> > - nuke sys/contrib/ipfilte
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:
> >>
> >> - commit new ipfilter untouched to vendor-sys/ipfilter
> >>
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/ipfilter
C>
C> Having ipfilter in
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/netpfil/ipfilter
Hav
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_DIR/current/contrib/ipfilter
> C> slippy$ svn
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> r/dist@252548
C>
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 problem will quickly
creep
> > up again as kernel AP
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 three packet
> filters?
>
> Th
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 interest in
> maintaining
In message
, Ed Maste writes:
> On 15 April 2013 16:12, Cy Schubert wrote:
> > The existing license isn't that BSD-friendly either, which is why it lives
> > in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as
> > Darren's IPF 4.1.X license. As long as it's not in GENERIC shoul
On 15 April 2013 16:12, Cy Schubert wrote:
> The existing license isn't that BSD-friendly either, which is why it lives
> in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as
> Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine.
> A person can always load i
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
On Mon, Apr 15, 2013 at 01:32:48PM -0600, Scott Long wrote:
S> > Given that IPF already lives in src/contrib and src/sys/contrib, would the
S> > change in License from Darren Reed's own not so BSD friendly IPF license
to
S> > GPLv2 be of concern. I recall there was a lot of concern over IPF's
l
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.
_
In message <516c58ed.40...@freebsd.org>, Jung-uk Kim writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2013-04-15 15:27:55 -0400, Cy Schubert wrote:
> > In message , Scott
> > Long writes:
> >>
> >> On Apr 15, 2013, at 11:48 AM, Cy Schubert
> >> wrote:
> >>
> >>> In message <18df
On Apr 15, 2013, at 1:27 PM, Cy Schubert wrote:
> In message , Scott Long
> writes:
>>
>> On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
>>
>>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
>>> writes:
2013/04/15 9:55$B!"(BCy Schubert
$B$N%a%C%;!<%
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 lives in src/contrib and src/sys/contrib due to the 2005 licen
On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
> writes:
>> 2013/04/15 9:55$B!"(BCy Schubert
>> $B$N%a%C%;!<%8(B:
>>
>>> I've been planning on taking on IP Filter for quite some time.
>>> Unfortunately I've left
The desire to remove it stems from the inability to give it adequate
engineering
service as the network stack evolves. Simply taking it out of a kernel config
file
doesn't address that problem at all. If it's going to stay in FreeBSD at all,
it
needs to be maintained. This could be set about
In message <20130415195544.gy76...@freebsd.org>, Gleb Smirnoff writes:
> Cy,
>
> good news that you volunteered to work on this!
>
> On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote:
> C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
> C> done much with
Cy,
good news that you volunteered to work on this!
On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote:
C> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't
C> done much with IPF while employed with Sun. Since then there has been some
C> development that is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-04-15 15:27:55 -0400, Cy Schubert wrote:
> In message , Scott
> Long writes:
>>
>> On Apr 15, 2013, at 11:48 AM, Cy Schubert
>> wrote:
>>
>>> In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>,
>>> Rui Paulo writes:
2013/04/15
In message , Scott Long
writes:
>
> On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote:
>
> > In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
> > writes:
> >> 2013/04/15 9:55$B!"(BCy Schubert
> >> $B$N%a%C%;!<%8
> (B:
> >>
> >>> I've been planning on taking on IP Fi
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 you to th
Thank you to those that have expressed interest in maintaining IP Filter..
My thoughts are, could we consider putting a option in the kernel config,
and leaving it off by default for GENERIC?
I think this is a acceptable compromise, considering some people wish for
it to be removed.
Sam Fourman J
In message <18df99b0-6e66-4906-a233-7778451b8...@felyko.com>, Rui Paulo
writes:
> 2013/04/15 9:55$B!"(BCy Schubert
> $B$N%a%C%;!<%8(B:
>
> > 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
2013/04/15 9:55、Cy Schubert のメッセージ:
> 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 w
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 Block wrote:
> >>> Is it possible to move ipfilter into a port
On Fri, Apr 12, 2013 at 11:33:30PM -0700, Rui Paulo wrote:
> It's not very difficult to switch an ipf.conf/ipnat.conf to a
> pf.conf, but I'm not sure automated tools exist. I'm also not
> convinced we need to write them and I think the issue can be deal
> with by writing a bunch of examples on ho
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
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
up again as k
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
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 ENOMAINTAINER problem wil
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 then
On 14 April 2013 16:48, Warren Block wrote:
> 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
It's NOT possible, because someone has to handle the kernel hooks, which is
the contention.
Mark as deprecated, remove the HandBook section, but only for 10.x
On 14 April 2013 18:48, Warren Block wrote:
> On Sun, 14 Apr 2013, Chris Rees wrote:
>
> On 14 April 2013 01:41, Rui Paulo wrote:
>>
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 already started writing a guide. See here for a very incomple
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 some users w
On Apr 14, 2013, at 7:20 AM, Joe wrote:
> Rui Paulo wrote:
>> On 2013/04/12, at 22:31, Scott Long wrote:
>>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>>
On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
> Lack of maintainer in a near future would lead to bitrot due to change
Rui Paulo wrote:
On 2013/04/12, at 22:31, Scott Long wrote:
On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
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
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
___
On Apr 13, 2013, at 11:43 AM, Rui Paulo wrote:
> 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 re
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 gets
broken because of the
Scott,
On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote:
S> One thing that FreeBSD is bad about (and this really applies to many open
source projects) when deprecating something is that the developer and release
engineering groups rarely provide adequate, if any, tools to help users
On Sat, Apr 13, 2013 at 3:03 PM, Scott Long wrote:
>
> On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote:
>
>> On 2013/04/12, at 22:31, Scott Long wrote:
>>
>>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>>
On 2013/04/11, at 13:18, Gleb Smirnoff wrote:
> Lack of maintainer in a n
On Apr 13, 2013, at 12:33 AM, Rui Paulo wrote:
> On 2013/04/12, at 22:31, Scott Long wrote:
>
>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>>
>>> 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
On 2013/04/12, at 22:31, Scott Long wrote:
> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>
>> 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 happ
On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote:
>
> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
>
> > 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,
On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote:
> 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
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 fail to find m
On Sat, Oct 04, 2003 at 13:01:31 +0200, Arjan van Leeuwen wrote:
> On Saturday 04 October 2003 11:21, Udo Schweigert wrote:
>> Hi all,
>>
>> since a couple of days ipfilter is broken for -current.
>>
>> kldload ipl.ko gives:
>> link_elf: symbol pfil_head_get undefined
>>
>> And the IPFILTER option
On Saturday 04 October 2003 11:21, Udo Schweigert wrote:
> Hi all,
>
> since a couple of days ipfilter is broken for -current.
>
> kldload ipl.ko gives:
> link_elf: symbol pfil_head_get undefined
>
> And the IPFILTER option inside the kernel-config results in:
>
(snip)
You should read /usr/src/UPD
On Thu, Mar 06, 2003 at 09:00:22AM -0800, Terry Lambert wrote:
> > I noticed that port 53 UDP (yes, UDP) gets through fine, though.
>
>
> Try disabling delayed ACK in the TCP stack; it's a sysctl.
>
> -- Terry
Been there, done that. No difference though.
Jiawei
--
"Without the userland, the k
leafy wrote:
> On Thu, Mar 06, 2003 at 11:22:29PM +0800, leafy wrote:
> > On Thu, Mar 06, 2003 at 11:28:45AM -0300, Daniel C. Sobral wrote:
> > > Are you sure _all_ socket calls are slow? 5.0-R had reverse resolution
> > > for sshd (which happened no matter what the configuration said) run
> > All,
On Thu, Mar 06, 2003 at 11:22:29PM +0800, leafy wrote:
> On Thu, Mar 06, 2003 at 11:28:45AM -0300, Daniel C. Sobral wrote:
> > Are you sure _all_ socket calls are slow? 5.0-R had reverse resolution
> > for sshd (which happened no matter what the configuration said) run
> All, including ssh. Only IC
On Thu, Mar 06, 2003 at 11:28:45AM -0300, Daniel C. Sobral wrote:
> Are you sure _all_ socket calls are slow? 5.0-R had reverse resolution
> for sshd (which happened no matter what the configuration said) run
All, including ssh. Only ICMP responds in time.
> connection arrives). If blackhole or fi
leafy wrote:
> With IPFILTER enabled in the kernel, all socket(2) calls
> inbound/outbound are very slow. A normal SSH connection within the
> same subnet takes 5 minutes to connect. Anything I can provide to pin
> down the problem?
Are you sure _all_ socket calls are slow? 5.0-R had reverse reso
On Mon, Feb 10, 2003 at 11:43:27PM +0100, Coercitas Temet'Nosce wrote:
> Yes, kinda :p
>
> Thanx for all your answers btw
>
Are you getting confused between ipfw in Linux and ipfw in FreeBSD maybe?
When I first saw ipfw I thought it must be old and obsolete, because it's been around
for a long t
On 2003-02-09 20:07, Coercitas Temet'Nosce <[EMAIL PROTECTED]> wrote:
> Pardon my poor knowledge about IPFW 2 but if I remember well, IPFW
> wasn't a SPI Firewall, which is what I need. Btw, previous Kernel
> allows us to fine tune its building for IPF and now, it simply
> gone...was really wonderi
1 - 100 of 143 matches
Mail list logo
