On Wednesday 17 May 2006 12:46, Volker Kuhlmann wrote: > Ok I've made a 3x eth[012] ipcop test box and found something to connect > to each end. ipcop gui, firewall->firewall options->disable ping > response: set to no. > Bug 1: it never accepts pings from internal, server, > or outside (just logs and dumps). But you have just turned off ping response, so I wouldn't expect any. It all depends on your precise meaning of the word "accept", I wonder if you would be so kind as to elucidate.
> Bug 2: It never forwards pings from the server to the outside. This is a design feature. The IPCOP never forwards pings from the Orange network to prevent corrupted servers being able to conduct DoS attacks using ping floods. > But the server can connect to any tcp port outside... It's supposed to be able to do that, it's part of the fundamental design of tcp/ip > and the user setup doesn't allow configuration of > anything but udp or tcp. All nice-looking GUI, but the rules are put > together with an astonishing carelessness! Have you read the design documentation for both tcp/ip and IPCOP? If they are correct, I'm sure your patches would be very welcome. Please note that _I_ trust the IPCOP team completely, What I'd really like to see is the facility to run the hostap driver for the Prism 2.5 Wavelan chipset, but I believe that mandates a kernel update to the 2.6 series. Whether or not that's a good idea is highly debatable. What do you think? > Trust *that*??? Very disappointing. In practice IPCOP works supremely well for millions of people. While some of the earlier versions were not quite so hot, the current one has protected us for many months 24/7 -- CS
