Re: pfctl: DIOCADDALTQ: Device busy
On 10/03/2003, Damien Miller <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]:
> After updating -current about a week ago I started getting the following
> error upon trying to load my ruleset:
>
> # pfctl -vf /etc/pf.conf
> [...]
> altq on tun0 cbq bandwidth 50Kb tbrsize 1500 queue { root std dns http
> mail ssh}
> queue root cbq( red ecn default ) { std dns http mail ssh }
> pfctl: DIOCADDALTQ: Device busy
works here.. out of sync somewhere?
ciao
--
Philipp Buehler - <[EMAIL PROTECTED]> - http://sysfive.com/
sysfive.com GmbH - UNIX. Networking. Security. Applications.
Steilshooperstr. 184, 22305 Hamburg, Germany - GSM +49-179-1136646
Re: pfctl: DIOCADDALTQ: Device busy
Philipp Buehler - sysfive.com GmbH wrote:
On 10/03/2003, Damien Miller <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]:
After updating -current about a week ago I started getting the following
error upon trying to load my ruleset:
# pfctl -vf /etc/pf.conf
[...]
altq on tun0 cbq bandwidth 50Kb tbrsize 1500 queue { root std dns http
mail ssh}
queue root cbq( red ecn default ) { std dns http mail ssh }
pfctl: DIOCADDALTQ: Device busy
works here.. out of sync somewhere?
No, I am definitely in sync and have just re-verified the problem using
a GENERIC kernel.
-d
Re: pfctl: DIOCADDALTQ: Device busy
On Mon, Mar 10, 2003 at 08:24:33PM +1100, Damien Miller wrote:
> Philipp Buehler - sysfive.com GmbH wrote:
> >On 10/03/2003, Damien Miller <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]:
> >
> >>After updating -current about a week ago I started getting the following
> >>error upon trying to load my ruleset:
> >>
> >># pfctl -vf /etc/pf.conf
> >>[...]
> >>altq on tun0 cbq bandwidth 50Kb tbrsize 1500 queue { root std dns http
> >>mail ssh}
> >>queue root cbq( red ecn default ) { std dns http mail ssh }
> >>pfctl: DIOCADDALTQ: Device busy
> >works here.. out of sync somewhere?
> No, I am definitely in sync and have just re-verified the problem using
> a GENERIC kernel.
works fine here too.
either you have more queuedefs you are hiding from us, or you are really
outta sync somewhere.
--
Henning Brauer, BS Web Services, http://bsws.de
[EMAIL PROTECTED] - [EMAIL PROTECTED]
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
Re: pfctl: DIOCADDALTQ: Device busy
Henning Brauer wrote:
On Mon, Mar 10, 2003 at 08:24:33PM +1100, Damien Miller wrote:
Philipp Buehler - sysfive.com GmbH wrote:
On 10/03/2003, Damien Miller <[EMAIL PROTECTED]> wrote To [EMAIL PROTECTED]:
After updating -current about a week ago I started getting the following
error upon trying to load my ruleset:
# pfctl -vf /etc/pf.conf
[...]
altq on tun0 cbq bandwidth 50Kb tbrsize 1500 queue { root std dns http
mail ssh}
queue root cbq( red ecn default ) { std dns http mail ssh }
pfctl: DIOCADDALTQ: Device busy
works here.. out of sync somewhere?
No, I am definitely in sync and have just re-verified the problem using
a GENERIC kernel.
works fine here too.
either you have more queuedefs you are hiding from us
No.
# grep queue /etc/pf.conf.altq
altq on tun0 cbq bandwidth 50Kb queue { root, std, dns, http, mail, ssh }
queue root bandwidth 100% cbq(default ecn) { std, dns, http, mail, ssh }
queue std bandwidth 40% cbq(borrow ecn)
queue dns bandwidth 30% priority 7 cbq(borrow ecn)
queue mail bandwidth 50% priority 0 cbq(borrow ecn)
queue http bandwidth 40% priority 5 cbq(borrow ecn)
queue ssh bandwidth 40% priority 6 cbq(borrow ecn)
pass out on tun0 all queue std
pass out on tun0 proto tcp from any port ssh to any queue ssh
pass out on tun0 proto tcp from any port http to any queue http
pass out on tun0 proto tcp from any port smtp to any queue smtp
or you are really
outta sync somewhere.
No.
# ident /usr/src/sbin/pfctl/parse.y /usr/src/sys/net/pf.c
/usr/src/sbin/pfctl/parse.y:
$OpenBSD: parse.y,v 1.340 2003/03/09 19:07:21 henning Exp $
/usr/src/sys/net/pf.c:
$OpenBSD: pf.c,v 1.327 2003/03/09 20:26:12 frantzen Exp $
Maybe src/sbin/pfctl/* should use RCSID() macros like src/usr.bin/ssh
does so this can be more directly verified.
-d
Re: pfctl: DIOCADDALTQ: Device busy
On Mon, Mar 10, 2003 at 09:43:16PM +1100, Damien Miller wrote:
> Henning Brauer wrote:
> >either you have more queuedefs you are hiding from us
> No.
yes, you have.
look, the error is obvious.
> altq on tun0 cbq bandwidth 50Kb queue { root, std, dns, http, mail, ssh }
> queue root bandwidth 100% cbq(default ecn) { std, dns, http, mail, ssh }
you defined the queues std, dns, http, mail and ssh all TWICE.
you are telling altq that these queues are BOTH childs of the implicit root
queue AND childs of the queue "root".
correct is this:
altq on tun0 cbq bandwidth 50Kb queue root
queue root bandwidth 100% cbq(default ecn) { std, dns, http, mail, ssh }
queue std bandwidth 40% cbq(borrow ecn)
...
but then this is nonsense.
the really right thing is this:
altq on tun0 cbq bandwidth 50Kb queue { std, dns, http, mail, ssh }
queue std bandwidth 40% cbq(borrow ecn)
queue dns bandwidth 30% priority 7 cbq(borrow ecn)
queue mail bandwidth 50% priority 0 cbq(borrow ecn)
queue http bandwidth 40% priority 5 cbq(borrow ecn)
queue ssh bandwidth 40% priority 6 cbq(borrow ecn)
aka leave out the queue "root".
Re: pfctl: DIOCADDALTQ: Device busy
Henning Brauer wrote:
On Mon, Mar 10, 2003 at 09:43:16PM +1100, Damien Miller wrote:
Henning Brauer wrote:
either you have more queuedefs you are hiding from us
>
yes, you have.
look, the error is obvious.
Ah, ok. Has the checking been tightened? This worked for ages...
the really right thing is this:
altq on tun0 cbq bandwidth 50Kb queue { std, dns, http, mail, ssh }
queue std bandwidth 40% cbq(borrow ecn)
queue dns bandwidth 30% priority 7 cbq(borrow ecn)
queue mail bandwidth 50% priority 0 cbq(borrow ecn)
queue http bandwidth 40% priority 5 cbq(borrow ecn)
queue ssh bandwidth 40% priority 6 cbq(borrow ecn)
aka leave out the queue "root".
Many thanks.
-d
Re: pfctl: DIOCADDALTQ: Device busy
On Mon, Mar 10, 2003 at 10:06:55PM +1100, Damien Miller wrote: > Henning Brauer wrote: > >On Mon, Mar 10, 2003 at 09:43:16PM +1100, Damien Miller wrote: > >>Henning Brauer wrote: > >>>either you have more queuedefs you are hiding from us > >yes, you have. > >look, the error is obvious. > Ah, ok. Has the checking been tightened? This worked for ages... yes, it has been tightended. we guarantee now that same named queues even on different interfaces have the same queue ID. as you were adding two same named queues even on the same interface, they were getting different queue IDs before, which is very confusing and leads to it not working like you expect. now they get the same queue ID, but the kernel notices the queue ID is already taken for the second one and throws an error. perhaps we should add the same check in userland to give a better error message.
