Optimizations for udp/icmp

2002-11-18 Thread Jason Dixon
I took a moment to peruse the pfctl.c code for the tcp settings for each of the various optimization topographies (normal, aggressive, etc.). Do these attempt to set any of the udp or icmp timeout settings (first, single, multiple, error)? I can't find anything in the pf.conf manpage or source to

Re: Optimizations for udp/icmp

2002-11-18 Thread Jason Dixon
On Mon, 2002-11-18 at 13:19, Jason Dixon wrote: > I took a moment to peruse the pfctl.c code for the tcp settings for each > of the various optimization topographies (normal, aggressive, etc.). Do > these attempt to set any of the udp or icmp timeout settings (first, > single, multiple, error)? I

Re: Optimizations for udp/icmp

2002-11-18 Thread Daniel Hartmeier
On Mon, Nov 18, 2002 at 01:25:15PM -0500, Jason Dixon wrote: > Sorry, I just realized I could figure this out on my own via "pfctl > -st". However, I can't find a flush command for options. Is there one, > or do I just need to flush/reload all? The only way to modify options is to reload the ru

Re: Optimizations for udp/icmp

2002-11-18 Thread Mike Frantzen
> I took a moment to peruse the pfctl.c code for the tcp settings for each > of the various optimization topographies (normal, aggressive, etc.). Do > these attempt to set any of the udp or icmp timeout settings (first, > single, multiple, error)? I can't find anything in the pf.conf manpage > or

Re: Optimizations for udp/icmp

2002-11-18 Thread Jason Dixon
On Mon, 2002-11-18 at 13:43, Mike Frantzen wrote: > > I took a moment to peruse the pfctl.c code for the tcp settings for each > > of the various optimization topographies (normal, aggressive, etc.). Do > > these attempt to set any of the udp or icmp timeout settings (first, > > single, multiple,

Re: Optimizations for udp/icmp

2002-11-18 Thread Russell Fulton
On Tue, 2002-11-19 at 07:43, Mike Frantzen wrote: > > I could probabley hack up a little PCAP utility to profile your UDP > traffic and let it calculate a distribution of timeouts. But I have > very little free hacking time and I'm not sure there is enough demand. You might be able to use Argus