RE: [squid-users] squid3 WindowsUpdate failed

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Tue, 06 Nov 2007 08:19:14 -0700

On Tue, 2007-11-06 at 09:24 +0000, Jorge Bastos wrote:
> Alex,
> The only ACL i have in squid.conf is:
>
> ---
> acl all_cache src 0.0.0.0/0.0.0.0
> no_cache deny all_cache
> ---

OK, thanks.

> I'm one of the people who's having this problems.
> Now I'm using 3.0.PRE6 until this is fixed.

Can you help us troubleshoot the problem? Can you run the latest Squid3
daily snapshot and collect full debugging (debug_options ALL,9) logs
when Windows Update is malfunctioning?

Thank you,

Alex.

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measurement-factory.com]
> Sent: segunda-feira, 5 de Novembro de 2007 16:31
> To: Amos Jeffries
> Cc: John Mok; squid-users@squid-cache.org
> Subject: Re: [squid-users] squid3 WindowsUpdate failed
>
> On Sun, 2007-11-04 at 19:30 +1300, Amos Jeffries wrote:
> > I have just had the opportunity to do WU on a customers box and
> > managed to reproduce one of the possible WU failures.
> >
> > This one was using WinXP, and the old WindowsUpdate (NOT
> > MicrosoftUpdate, teht remains untested). With squid configured to
> > permit
> > client access to:
> >
> > # Windows Update / Microsoft Update
> > #
> > redir.metaservices.microsoft.com
> > images.metaservices.microsoft.com
> > c.microsoft.com
> > windowsupdate.microsoft.com
> > #
> > # WinXP / Win2k
> > .update.microsoft.com
> > download.windowsupdate.com
> > # Win Vista
> > .download.windowsupdate.com
> > # Win98
> > wustat.windows.com
> > crl.microsoft.com
> >
> > AND also CONNECT access to www.update.microsoft.com:443
> >
> > PROBLEM:
> > The client box detects a needed update,
> > then during the "Download Updates" phase it says "...failed!" and
> > stops.
> >
> > CAUSE:
> >
> > This was caused by a bug in squid reading the ACL:
> > download.windowsupdate.com
> > ...
> > .download.windowsupdate.com
> >
> > - squid would detect that download.windowsupdate.com was a
> > subdomain
> > of .download.windowsupdate.com and .download.windowsupdate.com would
> > be
> > culled off the ACL as unneeded.
> >
> > - That culled bit held the wildcard letting v4.download.* and
> > www.download.* be retrieved later in the process.
> >
> > - BUT, specifying JUST .download.windowsupdate.com would cause
> > download.windowsupdate.com/fubar to FAIL under the same circumstances.
> >
> > during the WU process requests for application at
> > www.download.windowsupdate.com/fubar and K/Q updates at
> > v(3|4|5).download.windowsupdate.com/fubar2
> > would result in a 403 and thus the FAIL.
> >
> >
> > SOLUTION:
> > Changing the wildcard match to an explicit for fixes this and WU
> > succeeds again.
> > OR,
> > Changing the wildcard to .windowsupdate.com also fixes the problem
> > for this test.
>
> Can other folks experiencing Windows Update troubles with Squid3 confirm
> that their setup does not have the same ACL problem?
>
> In general, if we do not find a way to get more information about the
> Windows Update problem, we would have to assume it does not exist in
> most environments and release Squid3 STABLE "as is". If you want the
> problem fixed before the stable Squid3 release, please help us reproduce
> or debug the problem.
>
> Thank you,
>
> Alex.
>
>
Received on Tue Nov 06 2007 - 08:20:20 MST

This archive was generated by hypermail pre-2.1.9 : Sat Dec 01 2007 - 12:00:01 MST