DragonFlyBSD

duplicate

Petr Janda wrote:

at a very fast rate. I plugged in keyboard but it isnt responding. Why
is this bug still not fixed? Ive just had 20 days uptime and this is 2nd
time it happened in 2 months. If there is a such thing as a gravely
bug, this is one.

yes, we know. but nobody was yet able to find the bug.

cheers
simon

Petr Janda wrote:
[snip]

Why
is this bug still not fixed? Ive just had 20 days uptime and this is 2nd
time it happened in 2 months. If there is a such thing as a gravely
bug, this is one.

It is incredibly difficult to locate these types of bugs without a
backtrace / coredump. Hopefully next time db> will be responsive and
you can either get a backtrace or call doadump to create a corefile.

Scott

Any ideas on why db was doing what it was doing instead of allowing me
to get a backtrace?

Petr
Scott Ullrich wrote:

Petr Janda wrote:
[snip]

Why is this bug still not fixed? Ive just had 20 days uptime and this
is 2nd time it happened in 2 months. If there is a such thing as a
gravely bug, this is one.

It is incredibly difficult to locate these types of bugs without a
backtrace / coredump. Hopefully next time db> will be responsive and
you can either get a backtrace or call doadump to create a corefile.

Scott

[TOFU reformatted]
Petr Janda wrote:

Why is this bug still not fixed? Ive just had 20 days uptime and this
is 2nd time it happened in 2 months. If there is a such thing as a
gravely bug, this is one.

It is incredibly difficult to locate these types of bugs without a
backtrace / coredump. Hopefully next time db> will be responsive and
you can either get a backtrace or call doadump to create a corefile.

Any ideas on why db was doing what it was doing instead of allowing me
to get a backtrace?

actually I think we already have about 10 backtraces. It's just that the bug is not straightforward to find, so don't worry about that.

cheers
simon

Have you tried consulting the PF devs?

Petr

Simon 'corecode' Schubert wrote:

[TOFU reformatted]
Petr Janda wrote:

Why is this bug still not fixed? Ive just had 20 days uptime and
this is 2nd time it happened in 2 months. If there is a such thing
as a gravely bug, this is one.

It is incredibly difficult to locate these types of bugs without a
backtrace / coredump. Hopefully next time db> will be responsive
and you can either get a backtrace or call doadump to create a
corefile.

Any ideas on why db was doing what it was doing instead of allowing
me to get a backtrace?

actually I think we already have about 10 backtraces. It's just that
the bug is not straightforward to find, so don't worry about that.

cheers
simon

Petr Janda wrote:

Have you tried consulting the PF devs?

Hm? Why?

If we're talking about the

db>
db>
db>
..

issue here then my impression is that it has to do with the USB keyboard
I/O not being handled properly.

Sascha

Well from what I could gather DragonFly doesnt have dev that knows the
PF code in-and-out, or is not so? (This is not an inflametory remark by
any means)

Perhaps the PF devs could look at the backtrace and be able to point to
something as to why PF is doing what its doing.

Petr Janda wrote:

Have you tried consulting the PF devs?

of course. nobody could tell us the cause, it is not a known problem. something damages the state tables.

cheers
simon

Ok I see, thanks.

Someone is porting PF from OpenBSD 3.9, what chances are there that this
bug will not happen then? If the chances are not good, perhaps there
might be some hack considered, that at least makes the kernel not panic
once in a while? What I find quite intriguing is that it happens only
after around 3 weeks of uptime. Why not earlier or later. Id rather even
sacrifice some functionality as long as it prevents the kernel panicking.

Petr

Simon 'corecode' Schubert wrote:

Petr Janda wrote:

Have you tried consulting the PF devs?

of course. nobody could tell us the cause, it is not a known
problem. something damages the state tables.

cheers
simon

Simon 'corecode' Schubert wrote:

Petr Janda wrote:

Have you tried consulting the PF devs?

of course. nobody could tell us the cause, it is not a known problem.
something damages the state tables.

Guys, next week I will deploy a filtering bridge running 1.6.1. 20-30k
states are expectable. Hope I can crash it and tell you what is wrong.
Petr, could you show me your rules file? I recall having freeezes and
device incompatibilities if PF under OpenBSD 3.7 (I use 3.8 and 3.9 now)
and maybe we have something in common.

My pf.conf is just a simple one:

ext_if="fxp0"

table <ssh-bruteforce>
block drop in quick on $ext_if from <ssh-bruteforce>

block in
pass out keep state

pass quick on { lo }
antispoof quick for { lo, fxp0 }

1. flags S/SA keep state \
2. (max-src-conn-rate 3/30, overload <ssh-bruteforce> flush global)

pass in on $ext_if proto tcp to ($ext_if) port { ssh, smtp, imap, http,
domain } keep state
pass in on $ext_if proto udp to ($ext_if) port { domain } keep state

The commented section blocks script kiddies, unfortunately it doesnt
work in our PF version. Hence why its commented.

Petr

Gergo Szakal wrote:

Simon 'corecode' Schubert wrote:

Petr Janda wrote:

Have you tried consulting the PF devs?

of course. nobody could tell us the cause, it is not a known
problem. something damages the state tables.

Guys, next week I will deploy a filtering bridge running 1.6.1. 20-30k
states are expectable. Hope I can crash it and tell you what is wrong.
Petr, could you show me your rules file? I recall having freeezes and
device incompatibilities if PF under OpenBSD 3.7 (I use 3.8 and 3.9
now) and maybe we have something in common.

Petr Janda wrote:

My pf.conf is just a simple one:

ext_if="fxp0"

table <ssh-bruteforce>
block drop in quick on $ext_if from <ssh-bruteforce>

block in
pass out keep state

pass quick on { lo }
antispoof quick for { lo, fxp0 }

#pass in on $ext_if proto tcp to ($ext_if) port ssh \

1. flags S/SA keep state \
2. (max-src-conn-rate 3/30, overload <ssh-bruteforce> flush global)

pass in on $ext_if proto tcp to ($ext_if) port { ssh, smtp, imap, http,
domain } keep state
pass in on $ext_if proto udp to ($ext_if) port { domain } keep state

The commented section blocks script kiddies, unfortunately it doesnt
work in our PF version. Hence why its commented.

Don't you have any configuration section at all? (directives starting
with set)

Thats all I have.

Gergo Szakal wrote:

Petr Janda wrote:

My pf.conf is just a simple one:

ext_if="fxp0"

table <ssh-bruteforce>
block drop in quick on $ext_if from <ssh-bruteforce>

block in
pass out keep state

pass quick on { lo }
antispoof quick for { lo, fxp0 }

#pass in on $ext_if proto tcp to ($ext_if) port ssh \

1. flags S/SA keep state \
2. (max-src-conn-rate 3/30, overload <ssh-bruteforce> flush global)

pass in on $ext_if proto tcp to ($ext_if) port { ssh, smtp, imap,
http, domain } keep state
pass in on $ext_if proto udp to ($ext_if) port { domain } keep state

The commented section blocks script kiddies, unfortunately it doesnt
work in our PF version. Hence why its commented.

Don't you have any configuration section at all? (directives starting
with set)