> hello josh. > > I stand 100% with Jason O.'s opinion .. > netfilter/iptables has nothing to do with squid binding to some/any port. > whoever had to do his homework ... i beleive has done it. > Accessing that port is something different (-i lo -j ACCEPT), but i > beleive that's not the case. > > regards, > Georgi Alexandrov Hello George, >From experience...not speculation, I still stand by what I said. Squid can be a strange animal. In many configurations, the communication between child processes relies on being able to communicate via the loopback interface of the machine. Iptables can, and and in configurations I've worked with, has caused the same symptoms described. Basically, the daemon never gets a chance to bind to a port as the initial communication between these child processes is broken causing the entire startup procedure to fail. This makes the illusion that the problem is related to binding the port when in fact the program can't start for other reasons. This problem *can* be caused by firewall rules in place that prevent this communication from happening. If you examine the rulesets posted, it looks like he is using policy DROP on the INPUT chain which may certainly cause problems with squid if proper rules to allow the necessary traffic are not in place. Another thing to note here, and the reason that I'm of the opinion that this could be a netfilter/iptables problem is the fact that the original poster seems to have indicated that squid works when iptables is flushed. The last point mentioned above, coupled with the fact that I've dealt with this problem during the development of a transparent redirection appliance for the company I work for, is why I maintain the opinion that I do. As mentioned before, Jason has a good knowledge of netfilter, but apparently not Squid, thus my homework comment. Thanks, and hopefully this information helps to clarify the information I posted. :-) Josh Nerius -- Math problems? Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x]
