The following reply was made to PR kern/77570; it has been noted by GNATS.
From: Yar Tikhiy <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/77570: [PATCH] ipfw: Multiple rules may have the same number.
Date: Sat, 2 Jul 2005 14:51:17 +0400
F
Hello Yar,
Saturday, July 2, 2005, 3:00:18 PM, you wrote:
YT> The following reply was made to PR kern/77570; it has been noted by GNATS.
YT> From: Yar Tikhiy <[EMAIL PROTECTED]>
YT> To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
YT> Cc:
YT> Subject: Re: kern/77570: [PATCH] ipfw: M
Synopsis: [PATCH] ipfw: Multiple rules may have the same number.
State-Changed-From-To: open->closed
State-Changed-By: maxim
State-Changed-When: Sat Jul 2 12:49:16 GMT 2005
State-Changed-Why:
The proposed ipfw behaviour will hurt, break POLA, induce tsunami,
pandemics, economic disasters, nuclear
Hello,
Back in 1997, an email was sent to hackers@ about some substantial firewall
code improvements,
along with a patch, by Julian Assange <[EMAIL PROTECTED],suburbia.net}>. A PR
(misc/2386) was then
filled, but marked 'closed' shortly after submission due to 'Misfiled PR'
reason. It seems t
Just as a slight follow-up I should have included in my earlier e-mail:
the merging of ucred and pcred should make this patch now be able to
support real and saved uids/gids as well as effective uids/gids, meaning
that it can be used to also restrict setuid applications such as ping.
Robert N M Wa
On Tue, Feb 19, 2002 at 11:40:03AM -0500, Robert Watson wrote:
> Just as a slight follow-up I should have included in my earlier e-mail:
> the merging of ucred and pcred should make this patch now be able to
> support real and saved uids/gids as well as effective uids/gids, meaning
> that it can be
Synopsis: "ipfw fwd" sometimes rewrites destination mac address when it's not
necessary (packet must not meet the rule)
Responsible-Changed-From-To: freebsd-bugs->ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Sep 11 23:24:30 GMT 2004
Responsible-Changed-Why:
Over to mailing
Hi,
The counters for queue 1 keeps increasing when I do a ftp out even for
non-ACK packets but the other counters for queue 2-4 doesn't move at
all so it seems like everything is going out one queue instead of what
the rules actually say. I have one pipe configured as 480Kbit/sec
which is what r
On Mon, 1 Nov 2004 14:20:10 +0200, Ari Suutari <[EMAIL PROTECTED]> wrote:
> > The counters for queue 1 keeps increasing when I do a ftp out even for
> > non-ACK packets but the other counters for queue 2-4 doesn't move at
> > all so it seems like everything is going out one queue instead of what
>
Hi,
I don't know how to explain my problem but it goes something like this...
[EMAIL PROTECTED] [2:05am][/home/vince] >> ipfw show
00049 1557131244839199 skipto 100 ip from 208.201.244.224/29 to any
00050 12072800468 917651580916 divert 8668 ip from any to any via xl0
00100 69518
I have generated a patch which appears to solve the lock ordering
issues associated with ucred based filtering which results in
hard locks (while mpsafenet=1).
This patch basically implements a shared locking mechanism.
http://people.freebsd.org/~csjp/ip_fw2.c.1099500281.diff
It would be appric
11 matches
Mail list logo
