On Fri, 20 Jan 2017, Kristof Provost wrote:
On 20 Jan 2017, at 22:12, Ermal Luçi wrote:
Most probably your timeouts are aggressive on states garbage collection.
Give a look to those state limit teardown it might improve things.
Less than 30 seconds seems extremely quick to time out.
I also wo
On 21 Jan 2017, at 5:21, Bakul Shah wrote:
I finally had some time to look at the sources & noticed
/sys/netpfil/pf/pf.c:pf_purge_thread now runs 10 times a
second instead of once a second, which gave me the idea of
increasing "interval" timeout by a factor of 10 and this seems
to have mostly fix
I finally had some time to look at the sources & noticed
/sys/netpfil/pf/pf.c:pf_purge_thread now runs 10 times a
second instead of once a second, which gave me the idea of
increasing "interval" timeout by a factor of 10 and this seems
to have mostly fixed the problem. But I don't know where the
ac
On Fri, Jan 20, 2017 at 1:17 PM, Bakul Shah wrote:
> On Fri, 20 Jan 2017 13:12:07 PST =?UTF-8?Q?Ermal_Lu=C3=A7i?= <
> e...@freebsd.org> wrote:
> > --001a1148cecc40685805468d1ad2
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Fri, Jan 20, 2017 at 12:59 PM, Bakul Shah
> wrote:
> >
> > > On
On Fri, 20 Jan 2017 13:12:07 PST =?UTF-8?Q?Ermal_Lu=C3=A7i?=
wrote:
> --001a1148cecc40685805468d1ad2
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jan 20, 2017 at 12:59 PM, Bakul Shah wrote:
>
> > On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost"
> > wrote:
> > > On 20 Jan 2017, at
On 20 Jan 2017, at 22:12, Ermal Luçi wrote:
Most probably your timeouts are aggressive on states garbage
collection.
Give a look to those state limit teardown it might improve things.
Less than 30 seconds seems extremely quick to time out.
I also wouldn’t expect pf to set up NAT state in the m
On Fri, Jan 20, 2017 at 12:59 PM, Bakul Shah wrote:
> On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost"
> wrote:
> > On 20 Jan 2017, at 21:31, Bakul Shah wrote:
> > >> 11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags [P.],
> > >> seq 1:10, ack 55, win 1026, options [nop,nop,TS
On Fri, 20 Jan 2017 12:59:33 PST Bakul Shah wrote:
> On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost" wrote:
> > On 20 Jan 2017, at 21:31, Bakul Shah wrote:
> > >> 11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags [P.],
> > >> seq 1:10, ack 55, win 1026, options [nop,nop,TS val
On 20 Jan 2017, at 21:59, Bakul Shah wrote:
On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost"
wrote:
On 20 Jan 2017, at 21:31, Bakul Shah wrote:
11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags
[P.],
seq 1:10, ack 55, win 1026, options [nop,nop,TS val 198426 ecr
146811372
On Fri, 20 Jan 2017 21:43:33 +0100 "Kristof Provost" wrote:
> On 20 Jan 2017, at 21:31, Bakul Shah wrote:
> >> 11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags [P.],
> >> seq 1:10, ack 55, win 1026, options [nop,nop,TS val 198426 ecr
> >> 1468113725], length 9
> > < 11:56:28.16871
On 20 Jan 2017, at 21:31, Bakul Shah wrote:
$ pfctl -s info
Status: Enabled for 167 days 13:40:11 Debug: Urgent
State Table Total Rate
current entries0
searches 2870986757 198.3/s # this
seems
On 20 Jan 2017, at 21:31, Bakul Shah wrote:
11:56:28.168693 IP 192.168.125.7.65042 > 149.20.1.200.21: Flags [P.],
seq 1:10, ack 55, win 1026, options [nop,nop,TS val 198426 ecr
1468113725], length 9
< 11:56:28.168712 IP 173.228.5.8.52015 > 149.20.1.200.21: Flags [P.],
seq 3080825147:3080825156,
On Fri, 20 Jan 2017 08:47:43 MST Alan Somers wrote:
> On Fri, Jan 20, 2017 at 3:48 AM, Kristof Provost wrote:
> > On 20 Jan 2017, at 9:35, Bakul Shah wrote:
> >>
> >> pf seems to drop NAT connections quite a bit. This seems to
> >> happen much more frequently if there are delays involved (slow
>
On Fri, Jan 20, 2017 at 3:48 AM, Kristof Provost wrote:
> On 20 Jan 2017, at 9:35, Bakul Shah wrote:
>>
>> pf seems to drop NAT connections quite a bit. This seems to
>> happen much more frequently if there are delays involved (slow
>> server or interactive use). Almost seems like pf losing
>> tra
On 20 Jan 2017, at 9:35, Bakul Shah wrote:
pf seems to drop NAT connections quite a bit. This seems to
happen much more frequently if there are delays involved (slow
server or interactive use). Almost seems like pf losing
track of NATted connections due to an uninitialized
variable Often a r
pf seems to drop NAT connections quite a bit. This seems to
happen much more frequently if there are delays involved (slow
server or interactive use). Almost seems like pf losing
track of NATted connections due to an uninitialized
variable Often a retry or two works. Connecting from
outside to
16 matches
Mail list logo