Windows Update through Squid cache fails
I have configured the (Windows XP) clients on the LAN to use Squid as a proxy for web access. This (mostly) works without any issues. However, the latest batch of updates from Microsoft are causing severe problems. The XP clients are not able to download two updates (the ones mentioned in KB890859 and KB890923). The following is logged in the access.log of Squid: 1113736515.291 300331 winxp.de-korte.org TCP_MISS/200 535 GET http://au.download.windowsupdate.com/msdownload/update/v5/psf/windowsxp-kb89... - DIRECT/63.236.111.222 application/octet-stream 1113736579.898 302423 winxp.de-korte.org TCP_MISS/200 430 GET http://au.download.windowsupdate.com/msdownload/update/v5/psf/windowsxp-kb89... - DIRECT/213.200.98.29 application/octet-stream 1113736880.519 300381 winxp.de-korte.org TCP_MISS/200 430 GET http://au.download.windowsupdate.com/msdownload/update/v5/psf/windowsxp-kb89... - DIRECT/206.24.192.222 application/octet-stream Obviously, the client in question (all show similar behaviour) are using Squid, but somehow the downloads are aborted after about five minutes. With the network connectivity available at that time, about 30MB is downloaded then. I then tried to download both files with 'wget' (which is configured to use the same Squid proxy) and ended up with two files of 334MB (!) and 60MB respectively. Also, when the clients are instructed to bypass Squid (having a PAC file is very useful in these cases), the downloads went smooth too. Apparently, Windows Update doesn't like the way Squid is configured now. Is there some kind of issue with Windows Update and Squid? Regards, Arjen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SuSE Security schrieb:
I have configured the (Windows XP) clients on the LAN to use Squid as a proxy for web access. This (mostly) works without any issues. However, the latest batch of updates from Microsoft are causing severe problems. The XP clients are not able to download two updates (the ones mentioned in KB890859 and KB890923). The following is logged in the access.log of Squid:
1113736515.291 300331 winxp.de-korte.org TCP_MISS/200 535 GET http://au.download.windowsupdate.com/msdownload/update/v5/psf/windowsxp-kb89... - DIRECT/63.236.111.222 application/octet-stream 1113736579.898 302423 winxp.de-korte.org TCP_MISS/200 430 GET http://au.download.windowsupdate.com/msdownload/update/v5/psf/windowsxp-kb89... - DIRECT/213.200.98.29 application/octet-stream 1113736880.519 300381 winxp.de-korte.org TCP_MISS/200 430 GET http://au.download.windowsupdate.com/msdownload/update/v5/psf/windowsxp-kb89... - DIRECT/206.24.192.222 application/octet-stream
Obviously, the client in question (all show similar behaviour) are using Squid, but somehow the downloads are aborted after about five minutes. With the network connectivity available at that time, about 30MB is downloaded then. I then tried to download both files with 'wget' (which is configured to use the same Squid proxy) and ended up with two files of 334MB (!) and 60MB respectively. Also, when the clients are instructed to bypass Squid (having a PAC file is very useful in these cases), the downloads went smooth too. Apparently, Windows Update doesn't like the way Squid is configured now. Is there some kind of issue with Windows Update and Squid?
Regards, Arjen
There was an issue with that round about half a year before not accepting proxy-access to windows update. Maybe you make a directive for not caching microsoft-urls: acl WINDOWS dstdomain .windowsupdate.com always_direct allow WINDOWS Maybe this fixes your problem. Reguards Philippe - -- Diese Nachricht ist digital signiert und enthält weder Siegel noch Unterschrift! Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und 823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQmKnekNg1DRVIGjBAQLnswcAi2cEzD3ChqhG6wHko6tV0blFn4hXaG1p 19FvebjKBQegjA0vXJ1OpGB6DBLgx1qmGffMJGJE/uW5WueBzwbDHmhEOgH4vh4l PiI01l+cPTFN7o4eSQl6WxbFLXvoL5/oJg3JZ3+UdBMW7IpqLJljUrw/RiBvzXjk HAK6w4nRUZzy63/oSVz4BvYfIiOeBEdTHj0P0qau+7u5jmVkVEXAsxHw0FZFD0XN K0GIewnHuKCB0lex6BuKAyyx8ojbba9p/DFMf+C+5CLx5L0zcMb2xR9qMJwy8GPW Xehdps0owjA= =va2l -----END PGP SIGNATURE-----
Philippe Vogel schreef:
There was an issue with that round about half a year before not accepting proxy-access to windows update. Maybe you make a directive for not caching microsoft-urls:
acl WINDOWS dstdomain .windowsupdate.com always_direct allow WINDOWS
Maybe this fixes your problem.
Never mind, if found the problem in the Squid configuration. There was a directive to download always the complete file (range_offset_limit -1). Apparently, Windows Update doesn't like the delay this causes (due to bandwidth restrictions) and times out before the file is downloaded. Ironically this directive was put in the Squid configuration file to try to solve problems with Windows Update and a (web content filtering) parent cache. That never flew either (probably due to the same reason), so the parent cache was bypassed with a couple of ACLs. Thanks for the help anyway, it put me in the right direction. Best regards, Arjen
participants (3)
-
Arjen de Korte -
Philippe Vogel -
SuSE Security