On Sep 30, 2016, at 1:38 AM, Eugene M. Zheganin <emz@xxxxxxxxxxxxx> wrote: > > Hi. > >>> 13:31:25.060 kid1| accept failure: (53) Software caused connection abort >>> 13:31:25.865 kid1| accept failure: (53) Software caused connection abort >>> 13:31:25.904 kid2| accept failure: (53) Software caused connection abort >> The timestamps are a ~second off, but AFAICT, they are a ~second off for >> successful accepts as well, so it is probably just a tcpdump logging >> artifact. >> >> In summary, your browser is probably stuck because Squid could not >> accept a connection. Why did that accept call fail with ECONNABORTED? I >> cannot say for sure -- the packet trace is rather dirty/misleading >> (e.g., it shows the redirect packet being sent to the client _after_ the >> client follows that redirect which does not make sense). >> >> Any relevant errors in you system logs? > Nothing except > > Limiting closed port RST response from 294 to 200 packets/sec Sometimes I have noticed odd problems when this appears — I’m thinking that on occasion there may be a necessary RST that is being ignored and causing a client connection to “hang”. The “net.inet.icmp.icmplim” sysctl limits the ICMP response rate to RST packets received for ports that are not open — perhaps increase that from the default of 200 to 400 and see if it helps. Otherwise, are you using dynamic IPFW rules that involve the ports used by squid? I’ve had some issues with those in the past (timeouts or maximum numbers of rules exceeded), so I’ve switched to using static IPFW rules for connections in and out of squid to avoid issues. Guy _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
