On 2020-01-24, myml...@gmx.com wrote:
> Hi All,
>
> Thanks to Jesper and Stuart, i'm using max-pkt-rate not!
>
> I'm also using max-src-conn-rate and overload in conjunction with authpf
> and I'm worried that potentially valid traffic may get blocked.
>
> I'm wondering if it's a condoned/accepted/
On 1/23/20 7:17 PM, myml...@gmx.com wrote:
Hi All,
Thanks to Jesper and Stuart, i'm using max-pkt-rate not!
I'm also using max-src-conn-rate and overload in conjunction with authpf
and I'm worried that potentially valid traffic may get blocked.
I'm wondering if it's a condoned/accepted/best pr
On 11/13/18 16:28, Stuart Henderson wrote:
On 2018/11/13 10:15, Andrew wrote:
On 11/13/18 11:08, Stuart Henderson wrote:
> On 2018-11-11, Andrew wrote:
> > ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5
> > 1 table created.
> > 1/1 addresses added.
>
> This would normally fail right here.
>
> > ~:
On 2018/11/13 10:15, Andrew wrote:
> On 11/13/18 11:08, Stuart Henderson wrote:
> > On 2018-11-11, Andrew wrote:
> > > ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5
> > > 1 table created.
> > > 1/1 addresses added.
> >
> > This would normally fail right here.
> >
> > > ~: doas pfctl -t cidr_typo -
On 11/13/18 11:08, Stuart Henderson wrote:
On 2018-11-11, Andrew wrote:
~: doas pfctl -t cidr_typo -T add 1.2.3.4*5
1 table created.
1/1 addresses added.
This would normally fail right here.
~: doas pfctl -t cidr_typo -T show
127.0.0.1
I think your name resolver may be giving out 127.0
On 2018-11-11, Andrew wrote:
> ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5
> 1 table created.
> 1/1 addresses added.
This would normally fail right here.
> ~: doas pfctl -t cidr_typo -T show
>127.0.0.1
I think your name resolver may be giving out 127.0.0.1 as an address
in respons
On 11/11/18 19:23, Klemens Nanni wrote:
On Sun, Nov 11, 2018 at 12:01:33PM -0600, Andrew wrote:
~: doas pfctl -t cidr_typo -T add 1.2.3.4*5
1 table created.
1/1 addresses added.
I fail to reproduce this with recent snapshots on both amd64 and sparc64:
# pfctl -t cidr_typo -T add 1.2.3.
On 11/11/18 19:23, Klemens Nanni wrote:
On Sun, Nov 11, 2018 at 12:01:33PM -0600, Andrew wrote:
~: doas pfctl -t cidr_typo -T add 1.2.3.4*5
1 table created.
1/1 addresses added.
I fail to reproduce this with recent snapshots on both amd64 and sparc64:
# pfctl -t cidr_typo -T add 1.2.3.
On Sun, Nov 11, 2018 at 12:01:33PM -0600, Andrew wrote:
> ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5
> 1 table created.
> 1/1 addresses added.
I fail to reproduce this with recent snapshots on both amd64 and sparc64:
# pfctl -t cidr_typo -T add 1.2.3.4*5
no IP address found for 1.
On 10/06/18 00:28, Klemens Nanni wrote:
On Fri, Oct 05, 2018 at 04:02:12PM -0600, Andrew wrote:
recent snapshot:
$> uname -vrsm
OpenBSD 6.4 GENERIC#329 amd64
What's the timestamp? Please provide more detailed information next time.
$> doas pfctl -t sample -T add 74.125.0.0*16
1 table creat
On Fri, Oct 05, 2018 at 04:02:12PM -0600, Andrew wrote:
> recent snapshot:
>
> $> uname -vrsm
> OpenBSD 6.4 GENERIC#329 amd64
What's the timestamp? Please provide more detailed information next time.
> $> doas pfctl -t sample -T add 74.125.0.0*16
> 1 table created.
> 1/1 addresses added.
It's no
On Thu, Sep 13, 2018 at 12:21:28PM -0600, Andrew wrote:
> Try this on a patched 6.3 amd64.
Not sure since when but this is fixed in -current.
$ sysctl -n kern.version
OpenBSD 6.4-beta (GENERIC.MP) #292: Mon Sep 10 18:26:22 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/am
I found out what the issue was.
As an example, this is valid with "pfctl -f /etc/pf.conf" but will throw
"pfctl: DIOCGETQSTATS: Bad file descriptor" with "pfctl -s queue":
queue test on egress bandwidth 1M default
This works properly with "pfctl -s queue" as well:
queue test on em0 bandwidth 1M
I haven't done anything other than binary releases in some time,
although it's possible I may have fat fingered a terminal at some point.
I infrequently check these boxes other than biannual release updates and
mtier patches.
The checksums and timestamps of /bsd and /sbin/pfctl match another
worki
On 01/11/16 04:44, li...@ggp2.com wrote:
Whenever running "doas pfctl -s queue -v" on a 5.8/amd64 box (PC engines
apu1d4), it outputs the error "pfctl: DIOCGETQSTATS: Bad file
descriptor".
My initial reaction when reading this was "this sounds like kernel and
userland out of sync" and a search
Em 11-11-2015 00:06, Nick Holland escreveu:
> The point is...if you put in a DNS name, odds are you are going to end
> up thinking you are blocking/passing/redirecting a DNS name..when in
> reality, you are whatevering JUST the IP address that it resolves to at
> the time the firewall rules were lo
On 11/10/15 10:57, Kent Watsen wrote:
> Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs
>
> On boot, the consoles shows error about not being able to load pf.conf
> because it can't resolve the symbolic names.
>
> http://www.openbsd.org/faq/faq6.html#Setup.activate says:
>
> Â
Hi Kent,
On 2015-11-10 Tue 10:58 AM |, Kent Watsen wrote:
>
> Anybody run into this before?? - is the fix to add all the symbolic
> names to /etc/hosts?
>
Yes, use /etc/hosts.
Same for hostnames in /etc/syslog.conf if using localhost unbound as the
only nameserver in /etc/resolv.conf.
Then a
On 15-11-10 01:45 PM, Giancarlo Razzolini wrote:
As a general rule you should avoid using dns names on anything that
might cause the boot process to fail. Even more, you should really
avoid using names on hostname.if files.
Anybody run into this before? - is the fix to add all the symbolic
na
Em 10-11-2015 13:58, Kent Watsen escreveu:
> Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs
>
> On boot, the consoles shows error about not being able to load pf.conf
> because it can't resolve the symbolic names.
If your resolver can't be accessed, this will happen.
>
> http:
Hi Henning,
you are true, i found the problem 1 week ago, a "hidden" interface in my
3000 rules' pf.conf :)
--
Best regards,
Loïc BLOT, Engineering
UNIX Systems, Security and Network Engineer
http://www.unix-experience.fr
Le samedi 02 août 2014 à 12:17 +0200, Henning Brauer a écrit :
> * Loï
* Loïc Blot [2014-07-23 17:12]:
> pfctl: DIOCADDQUEUE: No such process
that most likely means you're trying to create a queue on a nonexistant
inmterface.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. V
Erf...
i found the error.
An admin has configured a queue on a inexisting interface...
Maybe the pfctl tell us the interface doesn't exists ?
Sorry for the inconvenience
--
Best regards,
Loïc BLOT, Engineering
UNIX Systems, Security and Network Engineer
http://www.unix-experience.fr
Le vendr
Hello
after the reboot the problem persists...
pfctl: DIOCADDQUEUE: No such process
The default ruleset has been loaded:
block drop all
pass out inet6 proto ipv6-icmp all icmp6-type neighbrsol
pass out inet6 proto ipv6-icmp all icmp6-type routersol
pass out inet6 proto udp from any port = 546 to
Hi David,
in fact no, now the ruleset is empty and everything is allowed, erf.
Now i have no choice, i need to reboot this critical router :(.
I think there is a bug somewhere, i'll try to found why this is
happening before rebooting (maybe a patch if i can)
--
Best regards,
Loïc BLOT, Enginee
Am Mittwoch, den 23.07.2014, 17:10 +0200 schrieb Loïc Blot:
> Hi @misc,
> This afternoon i got a very strange issue on a router/firewall. I
> added
> a rule and then the following error appears:
>
> > pfctl -nf /etc/pf.conf
> > pfctl -f /etc/pf.conf
> pfctl: DIOCADDQUEUE: No such process
>
> I do
Hi,
thanks for the tip.
No pfpurge process is running :(
Here is dmesg.boot
OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17082220544 (16290MB)
avail mem = 16618885120 (15849MB)
mainbus0 at root
bio
> I cannot give you the dmesg output of the machine because the uptime
> (dmesg was polluted by some carp messages :p), i cannot reboot it at
> this time, it's a BGP router and the redundancy is in maintenance.
try ‘cat /var/run/dmesg.boot'
On Fri, Jul 19, 2013 at 09:22:54AM +0200, Pieter Verberne wrote:
> From 'man pfctl':
> When the variable pf is set to YES in rc.conf.local(8), the rule file
> specified with the variable pf_rules is loaded automatically by the
> rc(8)
> scripts and the packet filter is enabled.
>
> I think pf is
> From: Henning Brauer (lists-openbsdbsws.de)
> Date: Sun Dec 02 2007 - 14:45:37 CST
>
> * MikeM [2007-12-02 15:35]:
> >
> > When I run the command
> >
> > pfctl -sr
> >
> > a list of the rules is displayed, a sample line is below.
> >
> > pass in log quick on fxp0 inet proto tcp from 226.174.167
On Mon, May 28, 2012 at 03:34:04PM +0200, Jan Stary wrote:
> The manpage says
> "-P Print ports using their names in /etc/services if available".
>
> This works with "pfctl -P -sr", but not with "pfctl -P -ss"
> - is that intended?
Good catch. :) I originally created -P for use with -sr, and did
On Mon, May 9, 2011 at 9:57 AM, Nick Holland
wrote:
> as is the rest of FAQ 5.2, questioning why you are building the system from
> source, and 5.3.2, which is "install the closest snapshot".
It's been running -current for quite some time (and the original
install was from the latest snapshot), u
On 05/08/2011 03:05 PM, Otto Moerbeek wrote:
On Sun, May 08, 2011 at 02:54:21PM -0400, Chris Smith wrote:
After an update to -current yesterday Internet access was lost as
pf.conf could not be loaded. The error message was:
pfctl: DIOCADDRULE: Operation not supported by device
This error occur
On 2011-05-08, Chris Smith wrote:
> After an update to -current yesterday Internet access was lost as
> pf.conf could not be loaded. The error message was:
> pfctl: DIOCADDRULE: Operation not supported by device
Address translation would break but you should still be able to get
into the machine.
* roberth [2011-05-09 00:29]:
> On the otherhand, i have been running -current for years and never have
> had any problem with building source with the previouse kernel (without
> reboot) that i can remember.
> Maybe my 3 digit amount of builds isn't enough or i built at the wrong
> states of the
On Sun, May 8, 2011 at 3:25 PM, roberth wrote:
> Uhum. Sure that's a way to approach this.
> That's the supported way. With that ammount of "support" required.
> Fine with that.
I usually build the new kernel, major utilities that require the new
kernel as per http://openbsd.org/faq/current.html
On Sun, 08 May 2011 21:48:25 +0200
Erik wrote:
> You are aware that this question concerns following -current? And
> that you are strongly advised to follow the FAQ when building
> -current as others already pointed out?
"Building from source. Got error after kernel reboot."
"Dude, rtfaq! Kernel
Op 8-5-2011 21:16, roberth schreef:
On Sun, 8 May 2011 14:54:21 -0400
Chris Smith wrote:
Is there a good way to avoid this? Is it safe to skip rebooting
between the kernel build and userland build? Or would it work to
manually build and install pfctl before the reboot after the kernel
build? O
On Sun, 8 May 2011 14:54:21 -0400
Chris Smith wrote:
> Is there a good way to avoid this? Is it safe to skip rebooting
> between the kernel build and userland build? Or would it work to
> manually build and install pfctl before the reboot after the kernel
> build? Or something else that hasn't oc
On 2011-05-08, at 1:54 PM, Chris Smith wrote:
> After an update to -current yesterday Internet access was lost as
> pf.conf could not be loaded. The error message was:
> pfctl: DIOCADDRULE: Operation not supported by device
>
> This error occurred after upgrading the kernel and then rebooting.
> A
On Sun, May 08, 2011 at 02:54:21PM -0400, Chris Smith wrote:
> After an update to -current yesterday Internet access was lost as
> pf.conf could not be loaded. The error message was:
> pfctl: DIOCADDRULE: Operation not supported by device
>
> This error occurred after upgrading the kernel and the
Danix writes:
> To put it short:
>
> # grep 6789 /etc/pf.conf
> pass in on vic0 proto tcp from any to vic0 port 6789 rdr-to { 1.2.3.4,
> 1.2.3.5, 1.2.3.7 } round-robin
>
> # pfctl -sr | grep 6789
> pass in on vic0 inet proto tcp from any to 192.168.1.28 port = 6789
> flags S/SA keep state rdr-t
* Danix [2010-12-26 21:40]:
> Hi all,
>
> I've made a python module for managing Packet Filter and I'm
> updating it to 4.8 now; so I'm taking a close look at the pfctl
> source code and I think I've stumbled upon a little bug (tested on
> -current)...
>
> To put it short:
>
> # grep 6789 /
On Sat, Jul 3, 2010 at 9:55 AM, Henning Brauer wrote:
>> # pfctl -a atelonly -F all
>
> -Fall with -a makes no sense whatsoever. -Fa clears a lot of
> non-anchor specific shit. we'll make pfctl bail on that combo.
>
ok :-)
So what would be the best way to flush all the states created by a
specif
> # pfctl -a atelonly -F all
-Fall with -a makes no sense whatsoever. -Fa clears a lot of
non-anchor specific shit. we'll make pfctl bail on that combo.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
D
On 01/07/2010 22:21, Ryan McBride wrote:
On Thu, Jul 01, 2010 at 10:15:26PM +0200, Laurent CARON wrote:
This incidentally made my other router (running openBGPd) crash with:
uvm_fault(0x80cc7320, 0xdeafb000, 0, 1) -> e
page fault trap, code=0
Stopped at pfsync_in_c
On Thu, Jul 01, 2010 at 10:15:26PM +0200, Laurent CARON wrote:
> This incidentally made my other router (running openBGPd) crash with:
>
> uvm_fault(0x80cc7320, 0xdeafb000, 0, 1) -> e
> page fault trap, code=0
> Stopped atpfsync_in_clr+0x123:movq 0x10(%rbx),%rax
Inte
On 01/07/2010 21:21, Ryan McBride wrote:
On Thu, Jul 01, 2010 at 09:00:18PM +0200, Laurent CARON wrote:
On 01/07/2010 17:54, Ryan McBride wrote:
This sounds a lot like a kernel/userland mismatch. Please update both
kernel and userland from the same snapshot and try again.
I always upgrade both
On 01/07/2010 17:54, Ryan McBride wrote:
This sounds a lot like a kernel/userland mismatch. Please update both
kernel and userland from the same snapshot and try again.
I always upgrade both at the same time. Kernel + userland are in synch
This sounds a lot like a kernel/userland mismatch. Please update both
kernel and userland from the same snapshot and try again.
On Thu, Jul 01, 2010 at 03:33:56AM +0200, Laurent CARON wrote:
> Hi,
>
> I did upgrade one of my BGP routers today with latest current.
>
> Upon reboot I have no networ
On 21-06-2010 22:44, Ruy Bento wrote:
...
My question is: In this small env. (100 MB - RAM) I need to change the
Kernel memory or other sysctl value, which one?
Thank you for all your replys and comments.
In 4.6 everything work perfect, so what happen 4.6 -> 4.7, it need more mem?
And if
On 2010-06-21, Ruy Bento wrote:
> spamd_black=YES # set to YES to run spamd without greylisting
you don't want blacklist-only mode if you have limited RAM.
Theo de Raadt wrote:
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 234MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX
real mem =
> > OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 234MHz
> > cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX
> > real mem = 10
Ruy Bento wrote:
Hi,
I have a server with:
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 234MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,
> avail mem = 87961600 (83MB)
> with:uatraps:china:korea: -> pfctl: Cannot allocate memory.
Not enough kernel memory.
Damon McMahon gmail.com> writes:
> Probably no help, but I had similar happen to me upgrading 4.5->4.6 a
> few months ago. Similar problem with pftcl after a diligent upgrade,
> and like you I have been following the upgrade procedure diligently
> since 3.something. I checked the timestamp on pf
2010/6/1 Uwe Dippel
> To: Philip Guenther
> Date: Tue, 01 Jun 2010 16:07:47 +0800
> Subject: Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
> On 06/01/2010 05:32 AM, Philip Guenther wrote:
>
>> Was there a common thread to what did turn up? My recall is th
Joachim Schipper joachimschipper.nl> writes:
> Just untarring the release should work, but it's still odd. At least the
> md5sum of pfctl matches what I just downloaded, so that seems fine; did
> you actually use *that* tarball, though? (Note that the "right" pfctl
> binary is 500856 bytes long.)
On 2010-06-01, TeXitoi wrote:
> Stuart Henderson writes:
>
>> On 2010-06-01, TeXitoi wrote:
>> >
>> > I heard that some mirrors had corrupted tarball.
>>
>> Huh?
>
> http://thread.gmane.org/gmane.os.openbsd.french/2168
..
> it was ports.tar.gz, here.
ok, that's better. Rather than just throwin
From: Gonzalo Rodriguez [gonz...@sepp0.com.ar]
Subject: Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Download again the tar files from official mirrors and try again the upgrade.
Thanks, Gonzalo,
but the files (sets) are correct according to their SHA256.
I have actually
Download again the tar files from official mirrors and try again the upgrade.
2010/6/1 Uwe Dippel :
> Joachim Schipper joachimschipper.nl> writes:
>
>> Just untarring the release should work, but it's still odd. At least > the
>> md5sum of pfctl matches what I just downloaded, so that seems
>> fi
Stuart Henderson writes:
> On 2010-06-01, TeXitoi wrote:
> >
> > I heard that some mirrors had corrupted tarball.
>
> Huh?
http://thread.gmane.org/gmane.os.openbsd.french/2168
(in french)
it was ports.tar.gz, here.
--
Guillaume Pinot http://www.irccyn.ec-nantes.fr/~pinot/
+
On 2010-06-01, TeXitoi wrote:
>
> I heard that some mirrors had corrupted tarball.
Huh?
Joachim Schipper writes:
> On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote:
> > On 06/01/2010 05:32 AM, Philip Guenther wrote:
> >
> > >Review your upgrade procedure, because it's clearly broken.
> >
> > Thanks for your help, seriously. And I don't want to start arguing,
> > not at a
Joachim Schipper joachimschipper.nl> writes:
> Just untarring the release should work, but it's still odd. At least
> the md5sum of pfctl matches what I just downloaded, so that seems
> fine; did you actually use *that* tarball, though? (Note that the
> "right" pfctl binary is 500856 bytes lon
On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote:
> On 06/01/2010 05:32 AM, Philip Guenther wrote:
>
> >Was there a common thread to what did turn up? My recall is that
> >basically every time people get "Operation not supported by device"
> >errors from pfctl, it's because their userla
On 06/01/2010 05:32 AM, Philip Guenther wrote:
Was there a common thread to what did turn up? My recall is that
basically every time people get "Operation not supported by device"
errors from pfctl, it's because their userland and kernel don't match.
Review your upgrade procedure, because it
On Mon, May 31, 2010 at 6:20 AM, Uwe Dippel wrote:
> (I searched Google, but not much turned up.)
Was there a common thread to what did turn up? My recall is that
basically every time people get "Operation not supported by device"
errors from pfctl, it's because their userland and kernel don't m
Hi,
On Wed, 17.03.2010 at 16:24:42 +0100, Henning Brauer
wrote:
> -A, -O, -R are bullshit and I'll happily remove them. soon.
that's ok with me. I thought that changing the docs was the
less-intrusive thing to do, and I have no experience with ipf, so that
certainly wasn't on my mind.
TIA!
--
* Toni Mueller [2010-03-15 10:52]:
> I've just run into the following problem on a 4.6 box:
>
> /etc/pf.conf (excerpt):
>
>
> table const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
> block out on $extif from
>
>
> # /sbin/pfctl -F rules -R -f pf.co
* Toni Mueller [2010-03-15 12:59]:
> Not using "-R" is not too good, either, as on this particular box,
> reloading everything results in a severance of all existing
> connections.
I don't believe you.
pfctl -f /etc/pf.conf
doesn't do that.
ok, shouldn't, but I don't see where that could break.
2010/3/16 Toni Mueller
> Hi,
>
> On Tue, 16.03.2010 at 07:37:42 +0001, Jason McIntyre
> wrote:
> > On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote:
> > > An optimizer (or any other such device) which is on by default and
> > > claims to not change semantics, should imho be transpare
Hi,
On Tue, 16.03.2010 at 07:37:42 +0001, Jason McIntyre wrote:
> On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote:
> > An optimizer (or any other such device) which is on by default and
> > claims to not change semantics, should imho be transparent to the user,
> > but this one isn't
On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote:
> Hi,
>
> On Mon, 15.03.2010 at 13:04:04 +, Jason McIntyre
> wrote:
> > doesn;t "Other rules and options are ignored." already cover this?
>
> may be. But then, you are possibly only too deeply entrenched in this
> stuff to "see"
Hi,
On Mon, 15.03.2010 at 13:04:04 +, Jason McIntyre wrote:
> doesn;t "Other rules and options are ignored." already cover this?
may be. But then, you are possibly only too deeply entrenched in this
stuff to "see" the problem.
> furthermore, since -T has a load command, should we really exp
2010/3/15 Toni Mueller
>
> Hi,
>
> On Mon, 15.03.2010 at 12:22:35 +0100, matteo filippetto <
> matteo.filippe...@gmail.com> wrote:
> > for me it works good ... just don't use -R option
> >
> > http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502
>
> thanks for this link.
>
> Not using "
On Mon, Mar 15, 2010 at 12:54:09PM +0100, Toni Mueller wrote:
>
> Not using "-R" is not too good, either, as on this particular box,
> reloading everything results in a severance of all existing
> connections. A clarification in the docs is imho the way to go. My
> 'nroff' is almost nonexistant, b
Hi,
On Mon, 15.03.2010 at 12:22:35 +0100, matteo filippetto
wrote:
> for me it works good ... just don't use -R option
>
> http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502
thanks for this link.
Not using "-R" is not too good, either, as on this particular box,
reloading everythi
2010/3/15 Toni Mueller
> Hi,
>
> I've just run into the following problem on a 4.6 box:
>
> /etc/pf.conf (excerpt):
>
>
> table const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
> block out on $extif from
>
>
> # /sbin/pfctl -F rules -R -f pf.conf
> r
* Dan Harnett [2010-02-24 15:29]:
> On Wed, Feb 24, 2010 at 08:30:05AM +0100, Henning Brauer wrote:
> > * Dan Harnett [2010-02-23 21:19]:
> > >
> > > Probably wrong, but this fixes it.
> >
> > i would not call that wrong.
> >
> > i don't understand how this ever worked and I don't understand w
On Wed, Feb 24, 2010 at 08:30:05AM +0100, Henning Brauer wrote:
> * Dan Harnett [2010-02-23 21:19]:
> >
> > Probably wrong, but this fixes it.
>
> i would not call that wrong.
>
> i don't understand how this ever worked and I don't understand what
> broke it. the only commit in that timeframe t
* Dan Harnett [2010-02-23 21:19]:
> On Tue, Feb 23, 2010 at 02:28:17PM -0500, Dan Harnett wrote:
> > On Tue, Feb 23, 2010 at 05:24:30PM +0100, Henning Brauer wrote:
> > > I don't remember any changes in that area lately so this puzzles me.
> > > do we know when this breakage was introduced, approx
On Tue, Feb 23, 2010 at 02:28:17PM -0500, Dan Harnett wrote:
> On Tue, Feb 23, 2010 at 05:24:30PM +0100, Henning Brauer wrote:
> > I don't remember any changes in that area lately so this puzzles me.
> > do we know when this breakage was introduced, approximately?
>
> I have narrowed it down to be
On Tue, Feb 23, 2010 at 05:24:30PM +0100, Henning Brauer wrote:
> * Dan Harnett [2010-02-23 17:19]:
> > 'pfctl -t tablename -T expire ' is also currently broken.
> > Everything appears to be removed from the table immediately regardless
> > of ''.
> >
> > $ sudo cat /etc/pf.conf
> > table
Hi,
>> I don't remember any changes in that area lately so this puzzles me.
>> do we know when this breakage was introduced, approximately?
>>
>
> I found a couple of boxes with May 2009 kernels where expire
> works as expected. I can't think of anything I have running code
> dated between then a
On 2010-02-23, Henning Brauer wrote:
> * Dan Harnett [2010-02-23 17:19]:
>> 'pfctl -t tablename -T expire ' is also currently broken.
>> Everything appears to be removed from the table immediately regardless
>> of ''.
>>
>> $ sudo cat /etc/pf.conf
>> table persist counters
>>
>> $ sudo
* Dan Harnett [2010-02-23 17:19]:
> 'pfctl -t tablename -T expire ' is also currently broken.
> Everything appears to be removed from the table immediately regardless
> of ''.
>
> $ sudo cat /etc/pf.conf
> table persist counters
>
> $ sudo pfctl -vv -t testing -T add 172.16.1.8 172.16.1
On Mon, Feb 22, 2010 at 10:40:29PM +0100, Michael Lechtermann wrote:
> >>> it's a slightly weird side-effect. a quick glance indicates that the
> >>> tzero timestamp is part of the stats struct and tables don't keep
> >>> stats/counters by default any more. for some time tho. i don't
> >>> remember
* Michael Lechtermann [2010-02-22 22:45]:
> Hi,
>
> >>> it's a slightly weird side-effect. a quick glance indicates that the
> >>> tzero timestamp is part of the stats struct and tables don't keep
> >>> stats/counters by default any more. for some time tho. i don't
> >>> remember any recent chang
Hi,
>>> it's a slightly weird side-effect. a quick glance indicates that the
>>> tzero timestamp is part of the stats struct and tables don't keep
>>> stats/counters by default any more. for some time tho. i don't
>>> remember any recent changes to the table code (as if anybody wanted to
>>> touch
On 2010-02-22, Michael Lechtermann wrote:
> Hi,
>
>> it's a slightly weird side-effect. a quick glance indicates that the
>> tzero timestamp is part of the stats struct and tables don't keep
>> stats/counters by default any more. for some time tho. i don't
>> remember any recent changes to the tab
Hi,
> it's a slightly weird side-effect. a quick glance indicates that the
> tzero timestamp is part of the stats struct and tables don't keep
> stats/counters by default any more. for some time tho. i don't
> remember any recent changes to the table code (as if anybody wanted to
> touch that mess
* Didier Wiroth [2010-01-23 23:15]:
> On Wednesday 20 January 2010 23:21:35 Michael Lechtermann wrote:
> > Am 20.01.2010 23:15, schrieb frantisek holop:
> > > hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said
> > > that
> > >
> > >> it seems there is a bug in pfctl regarding
On Wednesday 20 January 2010 23:21:35 Michael Lechtermann wrote:
> Am 20.01.2010 23:15, schrieb frantisek holop:
> > hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said
> > that
> >
> >> it seems there is a bug in pfctl regarding the cleared time of a table
> >> entry. The attac
Am 20.01.2010 23:15, schrieb frantisek holop:
> hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said that
>> it seems there is a bug in pfctl regarding the cleared time of a table
>> entry. The attack actually happend this year, but the date shown is
>> constantly changing:
>
>
hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said that
> it seems there is a bug in pfctl regarding the cleared time of a table
> entry. The attack actually happend this year, but the date shown is
> constantly changing:
been like this forever...
-pa-r-- bad-ssh
Addr
* Danix [2009-07-09 23:13]:
> Hi all,
>
> I'm running the OpenBSD 4.6 snapshot from June 26th and I can't get
> pfctl(8) to set the debug level:
>
> # pfctl -si | grep Debug
> Status: Enabled for 0 days 01:37:04 Debug: Urgent
> # pfctl -x loud
> debug level set to 'loud'
> # pfctl -si
On Thu, Jun 18, 2009 at 04:16:02PM +0700, Egbert Krook wrote:
> Hi,
>
> I've just finished upgrading one of our systems from OpenBSD 4.2 to 4.5.
>
> I've run into a small problem with pfctl as it's no longer showing the
> details for each individual IP address in our tables, just the date the
> t
* Egbert Krook [2009-06-21 11:58]:
> I've run into a small problem with pfctl as it's no longer showing the
> details for each individual IP address in our tables, just the date the
> table was last cleared.
really. reading the manpage would solve your confusion.
--
Henning Brauer, h...@bsws.de
1 - 100 of 187 matches
Mail list logo
