SUM cannot download Mac OS X subscription

Hello Vlad,

assuming SUM doesn't lie (did you find the 502 in the SUMTrace log?) the error is likely somewhere upstream. Is the proxy explicitly defined in SUM's source details? In principle there's nothing special with an additional subscription (or particularly the Mac subscription). What is the failing request (is it just one, and always the same)?

Starting with SUM you could try to select the Previous package for the Mac subscription (if it's available to you) - the result might help in narrowing down the problem. If this works but the Recommended still doesn't I'd empty the Warehouse and force a complete download (this takes some time though) to rule out some inconsistency in the structure of the cached catalogs. If the error persists I'd take a look at the proxy logs whether the proxy issues the 502 or just passes it on. In the latter case I'd assume an error on the CDN or the backend and you should contact Support directly.

Christian 

Hi Christian,

Thanks for the reply. I will attempt to answer a few of your questions which hopefully will give more details to aid fixing the issue.

The 502 error appears in the Update Manager's LogViewer UI. Four of these errors are generated in succession each time an update occurs:

13/08/2014 5:20:47 PM Error Synchronize operation failed when synchronizing product release 'Sophos Anti-Virus for Mac OS X 10.6+'. Details: Error on proxy or gateway server. HTTP response code: 502

It also appears in SUMTrace.log as follows:

2014-08-15 10:17:56 : <Info> Downloading remote customer file.
2014-08-15 10:17:57 : <Info> Successfully downloaded remote customer file content from SOPHOS
2014-08-15 10:17:58 : Package synchronisation started.
2014-08-15 10:17:58 : Cmd-ALL << [I1012][639f8414c87cfb8f1c00595b74fb6374x000.dat] Starting to synchronise file '639f8414c87cfb8f1c00595b74fb6374x000.dat'...
2014-08-15 10:17:59 : Error during package synchronisation: Error on proxy or gateway server. HTTP response code: 502
2014-08-15 10:17:59 : <WARNING> Sync iteration failed. CurrentResult: 6, Error: Error on proxy or gateway server. HTTP response code: 502

The above sequence repeats 4 times each update.

The proxy is set correctly otherwise the Windows and Linux subscriptions would not have downloaded..

I have tried the previous version and it still fails. I also tried the preview version, 9.1.6, and again, it fails.

I don't really want to empty the warehouse and try downloading everything again. I will try contacting support.

Cheers for your help,

Vlad

Hello Vlad,

I don't really want to empty the warehouse and try downloading everything again

Admittedly it consumes wastes some bandwidth, disk I/O and cycles but is otherwise not deleterious. It's not necessary as this doesn't look like a SUM/Warehouse problem - the file belongs to (at least) the Mac 9.1 version (a Mach-O binary, the Preflight script from the Anti-Virus package).

The proxy is set correctly

Using the same settings you could try to download the file (/update/639f8414c87cfb8f1c00595b74fb6374x000.dat) from any of the source update servers with a browser.

Christian

Hi Christian,

Sorry, I did not get an email indicating you replied as I forgot to check the box.

I tried all the listed download sites on a web browser and d1 gave the following error:

ERROR
The requested URL could not be retrieved

The following error was encountered while trying to retrieve the URL: http://d1.sophosupd.com/update/639f8414c87cfb8f1c00595b74fb6374x000.dat

    Read Error

The system returned: (104) Connection reset by peer

An error condition occurred while reading data from the network. Please retry your request.

 The others gave the following error (as I pressume those don't contain the binaries):

File not found

Firefox can't find the file at http://d2.sophosupd.com/update/639f8414c87cfb8f1c00595b74fb6374x000.dat.

    Check the file name for capitalisation or other typing errors.
    Check to see if the file was moved, renamed or deleted.

 I have tried on a PC connected directly to the net as well as my mobile and the dat file downloads fine from the d1 site. The question begs, what is so special about that dat file that won't allow it to be downloaded via a proxy?

BTW, I tried to download some of the other DAT files as listed in the SUMTrace log via the browser from d1 and they all worked. So it is just the 639f8414c87cfb8f1c00595b74fb6374x000.dat file.

Kind Regards,

Vlad

I just looked at our squid access log for when I download a working dat and the problem dat via a browser and for the working one, the log says "direct 125.56.204.80 application/octec-stream" but for the problem dat, the log says "direct 125.56.204.80 text/html"

Why is it treating it as text instead of binary?

Kind Regards,

Vlad

Hello Vlad,

won't absolutely rule out an error on the backend CDN which acts as d1 but then, wouldn't others encounter the same error? I've just sent the request for the "problem file" to 125.56.204.80 and it correctly responded with application/octet-stream. Squid claims it received a text/html reply though - I wonder if the result codes on this log line really indicate success, text/html suggests an error reply from the CDN (but this should be accompanied by a HTTP response other than 200).

While it looks like the problem occurs only when Squid is involved I can't fathom what's the cause - there's no reason that the backend should behave differently when precisely Squid (and "your" Squid) requests this very file, OTOH why should (just "your") Squid fool around with this very request (but maybe I'm unimaginative). Makes me wonder if it's an external (network) component ...

Christian

Hi Christian,

I did some more testing. Both DAT files listed before downloads ok on a windows box on our corporate network. Both also download ok on a Linux box (using wget) on our corporate network. However, performing a wget on http://d1.sophosupd.com/update/639f8414c87cfb8f1c00595b74fb6374x000.dat fails on the proxy.

Our proxy sits on the corporate network and protects our semi-isolated network.

Here is the log generated by wget for a working DAT file:

--2014-08-21 11:16:33--  http://d1.sophosupd.com/update/27d21b5a625e90938e2b483179aa040ax000.dat
Resolving d1.sophosupd.com... 125.56.204.80, 125.56.204.202
Connecting to d1.sophosupd.com|125.56.204.80|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 149 [application/octet-stream]
Saving to: “27d21b5a625e90938e2b483179aa040ax000.dat.1”

     0K                                                       100% 13.4M=0s

2014-08-21 11:16:33 (13.4 MB/s) - “27d21b5a625e90938e2b483179aa040ax000.dat.1” saved [149/149]

Here is the log generated by wget for the problem DAT:

--2014-08-21 11:16:56--  http://d1.sophosupd.com/update/639f8414c87cfb8f1c00595b74fb6374x000.dat
Resolving d1.sophosupd.com... 125.56.204.202, 125.56.204.80
Connecting to d1.sophosupd.com|125.56.204.202|:80... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.

--2014-08-21 11:16:57--  (try: 2)  http://d1.sophosupd.com/update/639f8414c87cfb8f1c00595b74fb6374x000.dat
Connecting to d1.sophosupd.com|125.56.204.202|:80... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.
.....

 Turning off the firewall on the proxy has no effect on the outcome. The proxy is a squid installation with standard configuration on a CentOS 6.5 OS.

Any ideas how else I can diagnose the issue?

Cheers for your help thus far.

Kind Regards,

Vlad

Some more testing. I turned off squid as well as iptables and added debugging to wget and it still fails to download 639f8414c87cfb8f1c00595b74fb6374x000.dat

The wget log for the working dat file:

Setting --verbose (verbose) to 1
DEBUG output created by Wget 1.12 on linux-gnu.

--2014-08-21 12:22:57--  http://d1.sophosupd.com/update/27d21b5a625e90938e2b483179aa040ax000.dat
Resolving d1.sophosupd.com... 125.56.204.80, 125.56.204.202
Caching d1.sophosupd.com => 125.56.204.80 125.56.204.202
Connecting to d1.sophosupd.com|125.56.204.80|:80... connected.
Created socket 3.
Releasing 0x00000000025f9600 (new refcount 1).

---request begin---
GET /update/27d21b5a625e90938e2b483179aa040ax000.dat HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: d1.sophosupd.com
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.0 200 OK
Server: Apache
ETag: "27d21b5a625e90938e2b483179aa040a:1406113604"
Last-Modified: Tue, 22 Jul 2014 19:10:39 GMT
Accept-Ranges: bytes
Content-Length: 149
Date: Thu, 21 Aug 2014 02:52:49 GMT
Connection: keep-alive
Content-Type: application/octet-stream
Cache-Control: s-maxage=3600, max-age=3600

---response end---
200 OK
Registered socket 3 for persistent reuse.
Length: 149 [application/octet-stream]
Saving to: “27d21b5a625e90938e2b483179aa040ax000.dat”

     0K                                                       100% 12.0M=0s

2014-08-21 12:22:57 (12.0 MB/s) - “27d21b5a625e90938e2b483179aa040ax000.dat” saved [149/149]

 The wget log for the non-working dat file:

Setting --verbose (verbose) to 1
DEBUG output created by Wget 1.12 on linux-gnu.

--2014-08-21 12:22:21--  http://d1.sophosupd.com/update/639f8414c87cfb8f1c00595b74fb6374x000.dat
Resolving d1.sophosupd.com... 125.56.204.202, 125.56.204.80
Caching d1.sophosupd.com => 125.56.204.202 125.56.204.80
Connecting to d1.sophosupd.com|125.56.204.202|:80... connected.
Created socket 3.
Releasing 0x0000000000c5f600 (new refcount 1).

---request begin---
GET /update/639f8414c87cfb8f1c00595b74fb6374x000.dat HTTP/1.0
User-Agent: Wget/1.12 (linux-gnu)
Accept: */*
Host: d1.sophosupd.com
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Closed fd 3
Retrying.

Hello Vlad,

this is fun :smileytongue:. wget doesn't even get as far as receiving a header line it seems. Can't see what should cause the backend to cut the connection though. Well, could you try to retrieve b907221ef6a5b2205abe2aeb15946657x000.dat which is another Mach-O binary? I'd also try some other backend, 193.170.140.71 would be one. Request the 639f84...dat specifying the IP instead of the d1 hostname in the URL using the --header="Host: d1.sophosupd.com" option.

Christian