Squid_ The Definitive Guide - Duane Wessels [84]
46 packets for unknown/unsupported protocol
If your OS has a GRE interface, run netstat -i every so often and look for increasing packet counts:
# netstat -in | grep ^gre0
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
gre0 1476 304452 0 0 4 0 Also, try running tcpdump on the GRE interface: # tcpdump -n -i gre0 Can Squid talk back to the clients? You may have a situation in which the router/switch is able to send packets to Squid, but Squid can't send packets back to the clients. This can happen if your firewall filter rules reject those outgoing packets or if Squid just doesn't have a route to the client addresses. To check for this condition, run netstat -n and look for a lot of sockets in the SYN_RCVD state: % netstat -n Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 10.102.129.246.80 10.102.0.1.36260 SYN_RCVD tcp4 0 0 10.102.129.226.80 10.102.0.1.36259 SYN_RCVD tcp4 0 0 10.102.128.147.80 10.102.0.1.36258 SYN_RCVD tcp4 0 0 10.102.129.26.80 10.102.0.2.36257 SYN_RCVD tcp4 0 0 10.102.129.29.80 10.102.0.2.36255 SYN_RCVD tcp4 0 0 10.102.129.226.80 10.102.0.1.36254 SYN_RCVD tcp4 0 0 10.102.128.117.80 10.102.0.1.36253 SYN_RCVD tcp4 0 0 10.102.128.149.80 10.102.0.1.36252 SYN_RCVD If you see this, use ping and traceroute to make sure that Squid has bidirectional communication with the clients. Can Squid talk to origin servers? Intercepted HTTP connections get stuck if Squid can't connect to origin servers. When this happens, netstat should show you a lot of connections in the SYN_SENT state: % netstat -n Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 172.16.102.66.5217 10.102.129.145.80 SYN_SENT tcp4 0 0 172.16.102.66.5216 10.102.129.224.80 SYN_SENT tcp4 0 0 172.16.102.66.5215 10.102.128.71.80 SYN_SENT tcp4 0 0 172.16.102.66.5214 10.102.129.209.80 SYN_SENT tcp4 0 0 172.16.102.66.5213 10.102.129.62.80 SYN_SENT tcp4 0 0 172.16.102.66.5212 10.102.129.160.80 SYN_SENT tcp4 0 0 172.16.102.66.5211 10.102.128.129.80 SYN_SENT tcp4 0 0 172.16.102.66.5210 10.102.129.44.80 SYN_SENT tcp4 0 0 172.16.102.66.5209 10.102.128.73.80 SYN_SENT tcp4 0 0 172.16.102.66.5208 10.102.128.43.80 SYN_SENT Again, use ping and traceroute to make sure that Squid can talk to origin servers. Are outgoing connections being intercepted? If Squid can ping origin servers, and you still see a lot of connections in the SYN_SENT state, the router/switch may be intercepting Squid's outgoing TCP connections. In some cases, Squid can detect such forwarding loops, and it writes a warning message to cache.log. Such a forwarding loop can quickly exhaust all of Squid's file descriptors, which also generates a warning in cache.log. If you suspect this problem, use the squidclient program to make some simple HTTP requests. For example, this command makes an HTTP request directly to the origin server: % /usr/local/squid/bin/squidclient -p 80 -h slashdot.org / If this command succeeds, you should see a bunch of ugly HTML from the Slashdot site on your screen. You can then try the same request through Squid: % /usr/local/squid/bin/squidclient -r -p 3128 -h 127.0.0.1 http://slashdot.org/ Again, you should see some HTML on your screen. If not check for error messages in cache.log. If you see forwarding loop errors, you need to reconfigure your router/switch so that it allows Squid's outgoing connections to pass without being intercepted. Exercises Try running Squid with a bogus httpd_accel_host value. For example:httpd_accel_host blah.blah.blah Does it still work, or do you get error messages? Disconnect Squid's network connection while your router/switch is diverting traffic to it. Does the network device bypass Squid? How long does it take to notice the problem? Repeat the same experiment, but this time kill the Squid process instead of unplugging the network cable. Enable Squid's user-agent log and see if you are intercepting any nonbrowser web traffic. Chapter 10. Talking