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
Resending with smaller recipients list…
From: Joyner, Eric
Sent: Friday, January 20, 2017 3:17 PM
To: 'Kevin Bowling' ; freebsd-net@freebsd.org
Cc: Scott Long ; Drew Gallatin ;
Navdeep Parhar ; Oded Shanoon ;
h...@freebsd.org; Matthew Macy ; Cramer, Jeb J
; arybc...@freebsd.org; sh...@freebsd.o
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
>
To summarize Drew's comments, which I mostly agree with, and suggest
a possible strategy for deployment:
- Irrespective of the user-facing command (ifconfig vs ethtool),
a common kernel API for the most common features is very desirable.
- There are very good reasons to take inspiration from
i
In article you write:
>Eg, I don't see why we need another tool for some of this missing
>"ethtool" functionality; it seems like most of it would naturally fit
>into ifconfig.
>From the end-user perspective, I agree with Drew. Most of this stuff
should just be part of ifconfig.
>As to other fea
On 01/19/2017 22:58, Kevin Bowling wrote:
Greetings,
I'm casting a wide net in cc, try to keep the noise minimal but we need
some input from a variety of HW vendors.
I have heard from several vendors the need for a NIC configuration tool.
Chelsio ships a cxgb/cxgbetool in FreeBSD as one exampl
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 Fri, Jan 20, 2017 at 11:00:18PM +0800, Julian Elischer wrote:
> Unless eri gets to it first I will.
>
> see https://reviews.freebsd.org/D5017
>
> If you have a server, you can put an arbitrary number of clients on
> the same port number because they all have different addresses.
>
> However
Unless eri gets to it first I will.
see https://reviews.freebsd.org/D5017
If you have a server, you can put an arbitrary number of clients on
the same port number because they all have different addresses.
However in the case of a client accessing multiple servers we are
limited to 65535 ses
Kevin Bowling wrote:
I have heard from several vendors the need for a NIC configuration
tool. Chelsio ships a cxgb/cxgbetool in FreeBSD as one example.
There is precedence for some nod toward a basic unified tool in Linux
ethtool.
From your perspective,
1) What are the common requirements?
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
21 matches
Mail list logo
