On Sat, Jun 21, 2003 at 10:46:56AM -0700, Jeremy Evans wrote: > I used to have a mid prioritized default queue. However, whenever you > reload the pf rules (pfctl -f), it puts all already defined states in the > default queue.
that is fixed by the new queue ID allocator in -current. > I tried reloading just the filter rules (pfctl -Rf), but it does the same > thing, except it is worse because not only do all already defined states go > into the default queue, but all states created in the future will go into > the default queue. I don't know whether this is a bug or expected behavior. that is fixed by the new queue ID allocator in -current. > I think it is a design flaw, because if the queue rules haven't changed, and > all states should stay in the same queue, and packets should continue to be > assigned to queues just as before. that is fixed by the new queue ID allocator in -current. > Basically, I see it this way: If pf is going to put packets/frames in a > queue, it should give you the ability to choose which queue. For all IP > packets, this is possible. For ethernet frames, this is not. that's what the default queue is for. > I know the pf > was designed specifically for IP filtering, and that writing filtering code > for other layer 3/4 protocols (IPX/SPX, NETBEUI, etc.) is a waste of time. > However, I propose that pf be expanded to include ethernet (and at least > arp) frames, since I'd wager that there are about the same number of people > using ethernet/arp as using IP. that won't happen. the reason you have for the default queue beeing that low priorized is fixed now, so there's no need any more. aside from that, I have something cool in the works i don't want to talk about yet ;-) -- 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)
