ALTQ and PPP access concentrator
Bruno Afonso
brunomiguel at dequim.ist.utl.pt
Sun Oct 16 11:06:42 PDT 2005
Hi everyone,
I've been recently "invited" (I mean, I was the only guy they knew that
had fbsd experience :> ) to setup a pppoe server for a 20+ user base of
wifi users. basically, we're using pppoe server from freebsd and a
radius server for user authentication.
there's a document explaining how to do this using ipfw and this uses
ppp.linkup and ppp.linkdown to invoke scripts. Things get harder with pf
+ altq (I'm using cbq on tunX interfaces and hfsc on outgoing - read
upload - interface). The way I've set it up was to create a script that
reads a file that has listed all users on each interface and it
generates the pf.conf. This was the only way I found to generate altq
setup lines for each tunX interface.
In a perfect world, one would do:
altq on tun* ...
This could for example be the DEFAULT altq setup instead a user would
explicitly use
altq on tun0 ..
Having said this, it wouldn't help my setup too much since we have 3 to
4 classes of users and each has different bw priviledges so we always
need to have a script... :-)
best
bruno
Gleb Smirnoff wrote:
> 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.
>
--
Bruno Afonso, Biological Engineer
Dana-Farber Cancer Institute
1 Jimmy Fund Way
Smith Building
Boston, MA 02115
GABBA Graduate Student (http://gabba.up.pt)
Homepage @ http://brunoafonso.net/
More information about the freebsd-pf
mailing list