> However, I must say I'm still a bit confused by this answer (and the others
> I've seen). Do you understand that PF is a clear security risk for your
> system?
Yes, I see you keep agreeing that NetBSD has no safely working
packet filter. We are patiently waiting for one. Since NetBSD v1.2
in
>> I continue to use pf and not npf because : [...]
> However, I must say I'm still a bit confused by this answer (and the
> others I've seen). Do you understand that PF is a clear security
> risk for your system?
Is it? Do you know MLH's systems enough to know whether any of the
known
Le 02/04/2019 à 20:46, MLH a écrit :
I continue to use pf and not npf because :
1) I couldn't get std rulesets to seem to work (been a while though)
2) no port redirection
3) dynamic ruleset use didn't appear to be adequate
4) greylisting (not just email) for custom stuff that I can't see
I continue to use pf and not npf because :
1) I couldn't get std rulesets to seem to work (been a while though)
2) no port redirection
3) dynamic ruleset use didn't appear to be adequate
4) greylisting (not just email) for custom stuff that I can't see
how to support in npf.
5) Needs far more
On 2019-04-01 22:30, Johnny Billquist wrote:
On 2019-04-01 15:16, Emmanuel Dreyfus wrote:
On Sat, 30 Mar 2019, Maxime Villard wrote:
2) If the effort had been on one firewall instead of three, the one
chosen
would be more functional.
Well, I cannot tell for PF, but IPF is functionnal, I use
Hello,
On Tue, 02 Apr 2019 16:10:58 +0900
Tetsuya Isaki wrote:
> At Mon, 1 Apr 2019 03:24:15 -0400,
> Michael wrote:
> > > There is one thing I'm worried about. AUDIO2 requires more strict
> > > blocksize and buffersize for hardware drivers. It will be a hard
> > > work if there are any
m...@netbsd.org wrote:
I think it's very telling that all the people arguing back are using
ipf, not pf. I suspect anyone that was using pf on NetBSD is no longer
using NetBSD.
To keep the anecdotes going, I am using pf on NetBSD as my primary firewall.
Staffan
Jan Danielsson wrote:
> On 2019-04-02 08:53, Martin Husemann wrote:
> >> This, exactly, is the showstopper that has prevented me from moving to
> >> npf. The ability to add/remove IP addresses from a NAT translation
> >> without changing npf.conf doesn't seem to be possible in any
> >>
I think it's very telling that all the people arguing back are using
ipf, not pf. I suspect anyone that was using pf on NetBSD is no longer
using NetBSD.
I certainly saw people ragequit NetBSD after their obviously remotely
exploited bug reports were ignored. We can't keep having this minefield
On Tue, 2 Apr 2019 at 08:11, Tetsuya Isaki wrote:
> Here is details:
>
> On -current, as you know, blocksize are decided as follows:
> 1. audio layer selects some size and ask it to hardawre driver.
> This is round_blocksize interface.
> 2. if hardware driver cannot accept the size (for
On Mon, 1 Apr 2019, Johnny Billquist wrote:
On 2019-04-01 15:16, Emmanuel Dreyfus wrote:
On Sat, 30 Mar 2019, Maxime Villard wrote:
2) If the effort had been on one firewall instead of three, the one chosen
would be more functional.
Well, I cannot tell for PF, but IPF is functionnal, I use it
On Tue, Apr 02, 2019 at 11:02:56AM +0200, Jan Danielsson wrote:
>2) Hey, I'm at a.b.c.d, and I would like external port X to redirect
> to me at port Y. (NAT rule, this isn't supported yet).
OK, but that is easy to add.
Martin
On 2019-04-02 08:53, Martin Husemann wrote:
>> This, exactly, is the showstopper that has prevented me from moving to
>> npf. The ability to add/remove IP addresses from a NAT translation
>> without changing npf.conf doesn't seem to be possible in any
>> documentation I was able to find.
>
> It is
Hi,
At Mon, 1 Apr 2019 03:24:15 -0400,
Michael wrote:
> > There is one thing I'm worried about. AUDIO2 requires more strict
> > blocksize and buffersize for hardware drivers. It will be a hard
> > work if there are any hardware that does not satisfy the requirements.
> > # Although I believe
14 matches
Mail list logo
