>> Date: Mon, 17 Feb 2014 11:22:27 +
>> From: Stuart Henderson
>>
>> On 2014/02/17 09:35, Philipp wrote:
>> > Am 17.02.2014 09:22 schrieb Alex Mathiasen:
>> > >Thank you! This solved my problem.
>> >
>> > Cheers.. found the hard way the other day.
>> >
>> > There should really be some dmesg
* Claudio Jeker [2014-02-17 16:27]:
> How much memory are 10'000 states using these days?
bit over 4MB with one state key per state.
> Would it be possible to auto tune these values somehow?
I keep thinking about it - maybe sth based on physmem.
> One issue I have seen is that because of adapt
On Mon, Feb 17, 2014 at 03:21:53PM +0100, Henning Brauer wrote:
> * Stuart Henderson [2014-02-17 14:45]:
> > Hmm. Well, I was assuming from the name and pfctl(8) description that
> > it should be "state-limit", but actually it seems that is just used for
> > max-src-states and this case just falls
* Stuart Henderson [2014-02-17 14:45]:
> Hmm. Well, I was assuming from the name and pfctl(8) description that
> it should be "state-limit", but actually it seems that is just used for
> max-src-states and this case just falls under "memory" which is not
> too descriptive.
indeed.
> I don't see
On 2014/02/17 12:56, Stuart Henderson wrote:
> The log entries which are at risk of being printed frequently are
> "hidden" by default, i.e. put behind LOG_DEBUG or similar. It seems to
> me that increasing the "state-limit" counter is just as useful as adding
> a new LOG_DEBUG for this..
Hmm. Wel
* Philipp [2014-02-17 13:36]:
> Am 17.02.2014 13:11 schrieb Henning Brauer:
> >how do you emit such a maessage in pcap? as payload with a dummy
> >packet header? (N!!)
> pf is taking action without telling anyone - and that's not nice.
doesn't change a thing wrt pflog. pflog d
On 2014/02/17 13:36, Philipp wrote:
> Am 17.02.2014 13:11 schrieb Henning Brauer:
> >how do you emit such a maessage in pcap? as payload with a dummy
> >packet header? (N!!)
>
> pf is taking action without telling anyone - and that's not nice.
>
> There *are* other log() entri
> Date: Mon, 17 Feb 2014 11:22:27 +
> From: Stuart Henderson
>
> On 2014/02/17 09:35, Philipp wrote:
> > Am 17.02.2014 09:22 schrieb Alex Mathiasen:
> > >Thank you! This solved my problem.
> >
> > Cheers.. found the hard way the other day.
> >
> > There should really be some dmesg when stat
Am 17.02.2014 13:11 schrieb Henning Brauer:
how do you emit such a maessage in pcap? as payload with a dummy
packet header? (N!!)
pf is taking action without telling anyone - and that's not nice.
There *are* other log() entries in pf.c already so I wonder how the
initial
* Philipp [2014-02-17 13:04]:
> Am 17.02.2014 12:22 schrieb Stuart Henderson:
> >Writing messages that show up in dmesg is not cheap, particularly
> >on systems with serial console.
> Well, ok. How about pflog?
you made my day.
forgot the pflog format?
how do you emit such a maessage in pcap? a
Am 17.02.2014 12:22 schrieb Stuart Henderson:
Writing messages that show up in dmesg is not cheap, particularly
on systems with serial console.
Well, ok. How about pflog?
On 2014/02/17 08:22, Alex Mathiasen wrote:
> Thank you! This solved my problem.
>
> The limit was reached several times within few seconds.
>
> Give this man a medal.
>
> Best regards
>
> Alex Mathiasen
Sounds like you are keeping state for all connections through your bgp
router then - if
On 2014/02/17 09:35, Philipp wrote:
> Am 17.02.2014 09:22 schrieb Alex Mathiasen:
> >Thank you! This solved my problem.
>
> Cheers.. found the hard way the other day.
>
> There should really be some dmesg when state-tables overflow.
> This "silent" dropping is wasting time in debugging such situa
Am 17.02.2014 09:22 schrieb Alex Mathiasen:
Thank you! This solved my problem.
Cheers.. found the hard way the other day.
There should really be some dmesg when state-tables overflow.
This "silent" dropping is wasting time in debugging such situations.
Sorry for talk instead of diff :-}
: 'tech@openbsd.org'
Emne: Re: Routing issues
Am 16.02.2014 14:08 schrieb Stuart Henderson:
> Some ideas:
check that the pf statetable (full or src-con) is not overflowing..
lately I had 'no route' where it was just peeking over the limit of 10,000
states spuriously. We
Am 16.02.2014 14:08 schrieb Stuart Henderson:
Some ideas:
check that the pf statetable (full or src-con) is not overflowing..
lately I had 'no route' where it was just peeking
over the limit of 10,000 states spuriously. Went me crazy.
pfctl -sm ; pfctl -si -vv
On 2014/02/14 13:03, Alex Mathiasen wrote:
> Hello,
>
> First of all: I hope I am posting this to the correct maillinglist, if not
> then I'm sorry!
>
> I am having big issues with my OpenBSD 5.4 (Also had these issues prior to
> upgrading to 5.4). The server is a complete new installation - I
Hello,
First of all: I hope I am posting this to the correct maillinglist, if not then
I'm sorry!
I am having big issues with my OpenBSD 5.4 (Also had these issues prior to
upgrading to 5.4). The server is a complete new installation - I have tried
this setup with 3 different servers from diff
18 matches
Mail list logo