|
||||||||||
On Sat, 26 Mar 2005 11:33:30 -0500, Bryan Marc Schaubach <omschaub at gmail dot com> wrote: > > > My main machine does indeed run a gigabit card and I have had everybody > I know run that ping command.. some on the stable m0n0wall version and > some on beta versions and it all resulted in a 20-24% packet loss for > EVERYBODY.. from someone using a 400mhz machine to even better than my > 933 celeron with 512MB of ram! > Yeah! As designed!! FreeBSD limits ICMP. That means *nothing*. See your logs when you try to do that. kernel: Limiting icmp ping response from 237 to 200 packets/sec kernel: Limiting icmp ping response from 240 to 200 packets/sec kernel: Limiting icmp ping response from 232 to 200 packets/sec kernel: Limiting icmp ping response from 241 to 200 packets/sec kernel: Limiting icmp ping response from 241 to 200 packets/sec (about 10 times that many entries like that) That's because flooding ICMP is ridiculous and there's no need to bog down the system with replying to several hundred or thousand pings a second. > > So I switched to ClarkConnect and now when I run the ping command, I get > 0% packet loss.. > Heh. Congrats, you now have a firewall that doesn't limit ICMP. If you can find a real benchmark that means something, I'd like to try it. But I think there is a bug in IPFilter that it doesn't work exceptionally well with P2P because it tends to close connections (remove from state table) before they're completed sometimes. P2P seems to be the only thing that actually has problems with this, and it typically doesn't seem to cause any problems. -Chris |