Hi. On 29.09.2016 08:38, Eugene M. Zheganin wrote: > Hi. > > On 28.09.2016 21:21, Alex Rousskov wrote: >> >> Indeed! Fixing that exposes one HTTP request in the capture file. >> Unfortunately, >> >> 1. Squid responded to that request (with a 407 message). >> Follow (tcp.stream eq 32) in Wireshark. >> >> 2. Squid did not receive this request when debugging was on: >> $ egrep -c 'www.ru|217.112.35.75' cache.log.debug >> 0 > Yup, I noticed this too. >> It may be important to know that the captured request was received at >> minute 53 while Squid debugging starts at minute 58 (I assume the >> difference in hours is due to time zone effects and such). >> > The thing is, the client machine is in the AD domain and it's time is > NTP-synced, so is the time on the squid machine. I think I was > accurate, but mey be I still wasn't. I will redo the captures, this > time with squid-towards-the-LAN capture, and I will try to validate > them myself. Luckily, I didn't restart squid yet and this machine > still demonstrates the symptoms. Okay, second try. Same IPs, same browser; this time user opens http://turbodom.ru/index.html (www.ru/index.html got unstuck). Time is NTP-synced on both machines. This time turbodom.ru entries are present in the debug log (actually, there's no /index.html at the turbodom.ru, so anyone requesting http://turbodom.ru/index.html is me). debug log: http://zhegan.in/files/squid/cache.log.debug tcpdump capture taken from a client machine: http://zhegan.in/files/squid/squid-stuck-client.pcap tcpdump capture taken from squid machine, on the interface the client machine is connected via: http://zhegan.in/files/squid/squid-stuck-server-to-client.pcap Thanks. Eugene. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
