From owner-freebsd-pf@FreeBSD.ORG Sun Oct 16 15:59:51 2005 Return-Path: X-Original-To: freebsd-pf@FreeBSD.org Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7787316A41F; Sun, 16 Oct 2005 15:59:51 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C051743D49; Sun, 16 Oct 2005 15:59:50 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id j9GFxlqd047414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Oct 2005 19:59:48 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id j9GFxgll047413; Sun, 16 Oct 2005 19:59:42 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 16 Oct 2005 19:59:42 +0400 From: Gleb Smirnoff To: Max Laier Message-ID: <20051016155942.GG14542@cell.sick.ru> References: <20051015142431.GC14542@cell.sick.ru> <200510151639.51156.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200510151639.51156.max@love2party.net> User-Agent: Mutt/1.5.6i Cc: Brian Fundakowski Feldman , freebsd-pf@FreeBSD.org Subject: Re: ALTQ and PPP access concentrator X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2005 15:59:51 -0000 On Sat, Oct 15, 2005 at 04:39:37PM +0200, Max Laier wrote: M> I agree that ALTQ configuration (esp for big setups) has some limitations and M> gotchas as is. I'd like to take the opportunity to start a discussion about M> what features are required to make it more useable. It is certainly M> interesting to look at decoupling /dev/pf and altq configuration. The end M> result would be a (in-kernel) lookup service that allows pf (or any other M> end-user of ALTQ) to lookup QIDs by interface:qname. In order to keep things M> in sync I am thinking of a eventhandler of some kind. M> M> This would allow us to keep the inlined configuration as it happens right now Yes, I agree. Some work is needed here. Except the already described obstacles, we also have dangling pointers after the interfaces had been removed: pfctl -Af /etc/altq /usr/local/etc/rc.d/mpd4.sh restart [ this creates new ifnet instances, and destroys old ones] pfctl -Af /etc/altq boom! #5 0xc06fe33a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #6 0xc05c1b91 in turnstile_setowner (ts=0xc1867dc0, owner=0x2839ea60) at /usr/src/sys/kern/subr_turnstile.c:417 #7 0xc05c1e94 in turnstile_wait (lock=0xc1cba10c, owner=0x2839ea60) at /usr/src/sys/kern/subr_turnstile.c:576 #8 0xc0598968 in _mtx_lock_sleep (m=0xc1cba10c, tid=0xc1c544e0, opts=0x0, file=0x0, line=0x0) at /usr/src/sys/kern/kern_mutex.c:553 #9 0xc045fe0e in priq_class_destroy (cl=0xc1bb6dc0) at /usr/src/sys/contrib/altq/altq/altq_priq.c:416 #10 0xc045fa7a in priq_clear_interface (pif=0xc1c45400) at /usr/src/sys/contrib/altq/altq/altq_priq.c:252 #11 0xc045f910 in priq_remove_altq (a=0xc1867dc0) at /usr/src/sys/contrib/altq/altq/altq_priq.c:161 #12 0xc0463290 in altq_remove (a=0xc1867dc0) at /usr/src/sys/contrib/altq/altq/altq_subr.c:647 #13 0xc048d72e in pf_commit_altq (ticket=0xc1c54500) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:1116 #14 0xc04910e7 in pfioctl (dev=0xc1711400, cmd=0x4, addr=0x0, flags=0x3, td=0xc1c54500) M> (just a little rewriting in pfctl), but enable easy changes for interfaces M> coming late. mpd would just trigger necessary altq-configuration from its M> UP-script. Actually I am dreaming to implement a RADIUS bandwidth management for mpd. In this case ALTQ configuration needs to be changed when the user logs in, for the interface he came. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE