Two questions about pf on the mac-ppc port:

1) Is there any known issue with running ipf and pf at the same time?
one is for pf-lkm (thankyou miles nordin!) and the other is for DMZ/drop 
them nasty fake packets. They shouldnt be competeing to route the same 
packet differently, one should delay the packet and the other route it at 
most.

bash-3.00# cat /etc/ipf.conf
block in quick on any from 127.0.0.0/8 to any
block in quick on any from 0.0.0.0/8 to any
block in quick on any from 169.254.0.0/16 to any
block in quick on any from 192.0.2.0/24 to any
block in quick on any from 204.152.64.0/23 to any
block in quick on any from 224.0.0.0/3 to any
block in quick on any from 44.0.0.0/8 to any
block out quick on any from any to 44.0.0.0/8
rdr rtk3 0.0.0.0/0 port 1 -> 10.6.0.1 port 1 tcp
rdr rtk3 0.0.0.0/0 port 1 -> 10.17.0.1 port 1 udp
pass in all
pass out all

bash-3.00# cat /etc/pf/pf.conf
altq on rtk3 hfsc bandwidth 740000b queue {general, voip}
queue general bandwidth 30% hfsc( default, red )
queue voip bandwidth 70% hsfc
pass out on rtk3 inet proto udp to any tos 0xb8 queue voip

Owing to artistic differences between myself and the author(s) of pf.c in 
the way tos flag is evaluated in pf.c the 0xb8 might not work as expected 
in your compilations.


2)
Is there a maximum usable size of the redirect table?

IE can do this and expect it to work?

rdr rtk3 0.0.0.0/0 port 1 -> 10.6.0.1 port 1 tcp
rdr rtk3 0.0.0.0/0 port 1 -> 10.17.0.1 port 1 udp
. . . . . . . . . . . . . . . . . . . . . . . . . . 
rdr rtk3 0.0.0.0/0 port 4351 -> 10.6.16.255 port 4351 tcp
rdr rtk3 0.0.0.0/0 port 4351 -> 10.17.16.255 port 4351 udp

I dont feel like reauthoring the DMZ rules in a few months. Im burning the 
config to write-few read-many media and i dont want to see it again. ever.


  Microsoft: Where do you want to go tomorrow?
  Linux: Where do you want to go today?
  BSD: Are you guys coming, or what?


Robin-David Hammond	KB3IEN
 	www.aresnyc.org.