On Mon, Dec 30, 2002 at 08:51:41PM +0100, Wouter Clarie wrote:
> On Mon, 30 Dec 2002, David Krause wrote:
>
> > Henning already has a diff like this. However, we both think that
> > states should be limited to a reasonable value (5000) by default, and
> > unlimited should not even be an option.
>
On Mon, Dec 30, 2002 at 06:37:55PM +0100, Wouter Clarie wrote:
> when it was moved to parse.y from pfctl.c. At that moment the "inf"
> property vanished. So there's no way to actually set it to unlimited right
> now.
well, there is, but why bother. these should never be set to unlimited.
there wil
On Mon, Dec 30, 2002 at 04:39:49PM +0100, Ed White wrote:
> I wrote that phile 8-)
> and sent an advise to Daniel, Henning and Theo.
> I had no reply, however, I would like to know which solution will be
> choosed:
we're still discussing.
thanks for the note.
--
Henning Brauer, BS Web Services,
On Mon, Dec 30, 2002 at 08:21:55PM +0100, Srebrenko Sehic wrote:
> How about having a possiblity to define a limit in relative way? Like
> 80% of free memory or something. That way, kernel would not crash and
> the limits could be dynamic, depending on the current memory utilization.
The current
On Mon, Dec 30, 2002 at 08:37:28PM +0100, Wouter Clarie wrote:
>
> On a related note: the default pf.conf in the distribution, does have:
>
> #set limit { states unlimited, frags 5000 }
>
> which is not parseable if uncommented.
/usr/src/etc/pf.conf also has,
#set loginterface none
#set optimi
On Mon, 30 Dec 2002, David Krause wrote:
> Henning already has a diff like this. However, we both think that
> states should be limited to a reasonable value (5000) by default, and
> unlimited should not even be an option.
Fine, but then "set limits states unlimited" should be removed from
src/e
* Wouter Clarie <[EMAIL PROTECTED]> [021230 13:35]:
> I just made a little diff, you can do with it as you please ;) I don't
> have any more time to spend on this today. Diff is for parse.y and
> pf.conf.5 man page, at the bottom of this mail.
Henning already has a diff like this. However, we bot
On a related note: the default pf.conf in the distribution, does have:
#set limit { states unlimited, frags 5000 }
which is not parseable if uncommented.
//Wouter
On Mon, 30 Dec 2002, Srebrenko Sehic wrote:
> How about having a possiblity to define a limit in relative way? Like
> 80% of free memory or something. That way, kernel would not crash and
> the limits could be dynamic, depending on the current memory utilization.
>
> I understand that this could ha
I just made a little diff, you can do with it as you please ;) I don't
have any more time to spend on this today. Diff is for parse.y and
pf.conf.5 man page, at the bottom of this mail.
Greetings,
//Wouter
On Mon, 30 Dec 2002, Daniel Hartmeier wrote:
> Yes, it's rather simple to add support fo
On Mon, Dec 30, 2002 at 07:40:23PM +0100, Daniel Hartmeier wrote:
> On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote:
>
> > That should be more flexible eh? I'll see if i can cook up a diff for
> > that tonight.
>
> Yes, it's rather simple to add support for either 'inf' or 'unlimit
On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote:
> That should be more flexible eh? I'll see if i can cook up a diff for
> that tonight.
Yes, it's rather simple to add support for either 'inf' or 'unlimited'
to the parser (it just has to translate to UINT_MAX).
But it really makes
On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote:
> On Mon, 30 Dec 2002, Dries Schellekens wrote:
>
> > If you don't specify a limit for states, it will be unlimited. But if you
> > choice a number, there is no way to change it back to unlimited except by
> > rebooting. So there is a
On Mon, 30 Dec 2002, Dries Schellekens wrote:
> If you don't specify a limit for states, it will be unlimited. But if you
> choice a number, there is no way to change it back to unlimited except by
> rebooting. So there is also no way to set to limit for frags to unlimited.
That should be more f
On Mon, 30 Dec 2002, Wouter Clarie wrote:
>
> I see this syntax has been changed on June 25:
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/pfctl.c.diff?r1=1.80&r2=1.81
> http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/parse.y.diff?r1=1.106&r2=1.107
>
> when it was moved to parse.y
I see this syntax has been changed on June 25:
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/pfctl.c.diff?r1=1.80&r2=1.81
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/parse.y.diff?r1=1.106&r2=1.107
when it was moved to parse.y from pfctl.c. At that moment the "inf"
property vanish
On Mon, Dec 30, 2002 at 05:17:12PM +0100, Dries Schellekens wrote:
> So I guess the correct syntax would be 'set limit states inf'. Can you try
> this?
Doesn't work either. I get,
/etc/pf.conf:15: inf is not a number
pfctl: Syntax error in file: pf rules not loaded
// haver
On Mon, 30 Dec 2002, Dries Schellekens wrote:
> On Mon, 30 Dec 2002, Srebrenko Sehic wrote:
>
> > Isn't 'set limit states unlimited' supposed to work in /etc/pf.conf?
[snip]
> The old pfctl(8) (of OpenBSD 3.1) used to say
>-m modifier
> Gets or sets hard limits on the memory pools u
On Mon, 30 Dec 2002, Srebrenko Sehic wrote:
> Isn't 'set limit states unlimited' supposed to work in /etc/pf.conf?
>
> I get this:
>
> root@hellspawn:/root# grep states /etc/pf.conf
> set limit { states unlimited, frags 5000 }
>
> root@hellspawn:/root# grep states /usr/src/etc/pf.conf
> #set limit
Isn't 'set limit states unlimited' supposed to work in /etc/pf.conf?
I get this:
root@hellspawn:/root# grep states /etc/pf.conf
set limit { states unlimited, frags 5000 }
root@hellspawn:/root# grep states /usr/src/etc/pf.conf
#set limit { states unlimited, frags 5000 }
root@hellspaw
> Phrack 60 describes a new technique of detecting firewalls using broken
> CRC. Interesting reading material.
>
> http://www.phrack.org/phrack/60/p60-0x0c.txt
I wrote that phile 8-)
and sent an advise to Daniel, Henning and Theo.
I had no reply, however, I would like to know which solution will b
Hey,
Phrack 60 describes a new technique of detecting firewalls using broken
CRC. Interesting reading material.
http://www.phrack.org/phrack/60/p60-0x0c.txt
Cheers,
Dries
--
Dries Schellekens
email: [EMAIL PROTECTED]
On Mon, Dec 30, 2002 at 12:09:05PM +0100, Daniel Hartmeier wrote:
> If I'm not mistaken, the line is pf.c:2190 's->nat_rule->states++;'.
>
> If you have pf.c prior to 1.278, that would explain the crash, it was
> fixed with 1.278 later that day (s->nat-rule could be NULL before).
I figured that s
If I'm not mistaken, the line is pf.c:2190 's->nat_rule->states++;'.
If you have pf.c prior to 1.278, that would explain the crash, it was
fixed with 1.278 later that day (s->nat-rule could be NULL before).
Daniel
On Mon, Dec 30, 2002 at 03:04:43AM -0500, jolan wrote:
> Please let me know if any other information is needed.
If you still have the same sources that you built that kernel from,
could you produce the objdump output as described on
http://www.benzedrine.cx/crashreport.html
Alternatively, do
Hi,
While constructing a new ruleset, I couldn't find the definitions of the
keywords for icmp codes & types. I now found out that they are in
src/sbin/pfctl/pfctl_parser.c, but they're not documented anywhere. Are
there any plans for a pf.conf man page section with the pf-style names of
those thi
Im running OpenBSD 3.2-stable, with tircproxy installed from the ports tree. I have
the following in my inetd.conf for tircproxy:
127.0.0.1:7666 stream tcp nowait root /usr/local/sbin/tircproxy -MIRH -i 192.168.0.1
-m 3 -x 30099
The following redirect rule, and pass rule is in my pf.conf:
D
uvm_fault(0xe37834f8, 0x24f47000, 0, 3) -> e
kernel: page fault trap, code=0
Stopped at _pf_test_udp+0x7ff: incl0x198(%eax)
ddb> trace
_pf_test_udp(e37eba7c,2,d0ac1040,d0ad3700,0) at _pf_test_udp+0x7ff
_pf_test(2,d0ac1040,e73ebd1c,d023bf5a) at _pf_test+0x322
_ip_output(d0ad3700,0,d0b9c
28 matches
Mail list logo
