<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On 20/04/2009, at 12:30 PM, Daniel Pittman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Daniel Lawson <<a href="mailto:daniel@meta.net.nz">daniel@meta.net.nz</a>> writes:<br><blockquote type="cite"><font class="Apple-style-span" color="#144FAE"><br></font></blockquote><blockquote type="cite"><blockquote type="cite">Then work out which of those features actually causes the problem<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and, ideally, report that to the technical people at AirNZ who have a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">broken Internet connection.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I reported ECN brokenness to AirNZ about a year or so ago, and they<br></blockquote><blockquote type="cite">said they'd look into. It's come up several times before that though.<br></blockquote><blockquote type="cite"><br></blockquote></div></blockquote><div><br></div><div>I have a feeling this is site-specific as the proxy is buried behind a few layers of hardware firewall.</div><div><br></div><div>My plan is to run the proxy "as is" for another week and if all is well start removing these tweaks to identify what the exact solution was.</div><div>Unfortunately the organisation where this proxy is handles a lot of Air NZ travel arrangements, so having the site work is far more important than having optimal performance :-)</div><div><br></div><div>I've tested the Air NZ site from my office using a similarly configured Centos 5.3 VM (sans TCP hacks) and it works fine, so the issue is probably between two of the internal firewall devices. I can't monitor or manage these devices, so performing debugging or making changes at this level is not possible.</div><div> </div><div>The reason I thought it was initially related to the wpad.dat file was because of the intermittent nature of the connection issue, Squid's handling of persistent connections and the way desktop support tested the problem.</div><div>e.g. The tester would try to connect with the wpad.dat config and it would fail, meanwhile a connection would be established so Squid would setup a persistent connection. Unfortunately this would all occur just in time for the second (non wpad.dat) attempt by the tester.</div><div>The result: "Hey it works when I don't use wpad.dat so that must be the problem."</div><div><br></div><div>As soon as I disabled persistent connections on Squid and monitored network connections with netstat you could see the connection to flightbookings.airnewzealand.co.nz lock up with a SYN_SENT status each time the "Search" button was pressed on the Air NZ site.</div><div>i.e. Very similar to the example in this book:</div><div><a href="http://my.safaribooksonline.com/0596001622/squid-CHP-9-SECT-6">http://my.safaribooksonline.com/0596001622/squid-CHP-9-SECT-6</a></div><div><br></div><div>I'll post the outcome from my "un-hack TCP till it breaks" session next week.</div><div><br></div><div><br></div><div>David</div><div><br></div></div></body></html>