<div dir="ltr"><div><div>Amos, tell me what more you need to analyze the incident.<br></div><br>Every time that I access to this  <a href="http://www.rionegro.gov.ar/download/images/00033494.jpg" rel="noreferrer" target="_blank">http://www.rionegro.gov.ar</a> I have the error TCP_MISS_ABORTED/000, but also if  access to ssl version  <a href="http://www.rionegro.gov.ar/download/images/00033494.jpg" rel="noreferrer" target="_blank">https://www.rionegro.gov.ar the error NOT occur.</a><br><br></div>regards.<br><br><div><br><a href="http://www.rionegro.gov.ar/download/images/00033494.jpg" rel="noreferrer" target="_blank"></a></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-28 1:00 GMT-03:00 Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 28/02/18 15:12, L A Walsh wrote:<br>
> Juan Manuel P wrote:<br>
>> I am using Squid Cache: Version 3.5.12, but some pages give me the<br>
>> next error:<br>
>><br>
>> 1/Feb/2018:18:14:40 -0300 || - || 10.12.43.20 ||<br>
>> TCP_MISS_ABORTED/000|| GET ||<br>
>> <a href="http://www.rionegro.gov.ar/download/images/00033494.jpg" rel="noreferrer" target="_blank">http://www.rionegro.gov.ar/<wbr>download/images/00033494.jpg</a><br>
>> <<a href="http://www.rionegro.gov.ar/download/images/00033494.jpg" rel="noreferrer" target="_blank">http://www.rionegro.gov.ar/<wbr>download/images/00033494.jpg</a>> || -<br>
> ----<br>
>    I don't know what causes it, but I see it frequently and have for a few<br>
> years.  Currently am running 3.15.3.  Was told it might be due to some<br>
<br>
Er, which version exactly?<br>
<br>
> cache corruption -- but having removed it several times over the past<br>
> few years, I sorta doubt that.  Also, I'm attempting https interception,<br>
> now<br>
> but wasn't when I first encountered this message...<br>
<br>
It can come from many reasons. One has to look at all the clues about<br>
where the message came from, which (if any) server was involved, how<br>
long it took, etc.<br>
<br>
I could write a book on the things and ways it *might* happen. But<br>
whether any of that is relevant or just hand-wavey ideas is anyones<br>
guess at present.<br>
<br>
<br>
>From what I know about it currently; corruption HTTP cache entries might<br>
be a side-effect, but very unlikely to be a cause of this.<br>
<br>
Other types of caches used by Squid may be involved, eg the DNS cache<br>
pointing Squid to a server IP that is not responding. But I don't recall<br>
any instances of that data being corrupted, and the duration of the<br>
transaction is far too short to have been some kind of timeout on the<br>
server side of things (immediate TCP reject from invalid server IPs<br>
shows up completely differently.)<br>
<br>
<br>
* ABORTED almost always means the client[1] disconnected from the TCP<br>
connection. That can happen for any number of reasons at the TCP, IP and<br>
Ethernet layers which Squid is not party to.<br>
<br>
... emphasis on "almost". In the case of CONNECT messages and NTLM<br>
Pinned connections the server can also trigger disconnect for both<br>
endpoints.<br>
<br>
<br>
* HTTPS introduces several additional possible causes. Primarily that<br>
CONNECT message server abort just mentioned. But also if SSL-Bump is<br>
being done, any TLS errors that result in "terminate" action will also<br>
show up as aborts at the TCP and HTTP(S) layers. Squid logging of those<br>
cases has been a bit buggy and there may be issues still yet to be found<br>
there.<br>
 That does not explain the pre-HTTPS occurances. But also due to the<br>
vague nature of the abort reason those earlier aborts may be completely<br>
different in cause from your current ones.<br>
<br>
<br>
The "/000" status means no HTTP reply was received from a server. Abort<br>
can also happen any time *after* a server response is received, but<br>
those should be logged with their status codes not 000.<br>
 - That may be because no server was even contacted. ie the client<br>
disconnected immediately, or during the wait for server DNS records to<br>
arrive, or for any other reason the client has.<br>
<br>
<br>
SSL-Bump clouds the issue a lot because it will naturally time some<br>
amount of time to do any of its checks and any server contact for server<br>
cert details etc. Again the client can disconnect for any number of<br>
reasons during all that, with the same ABORTED/000 end result.<br>
<br>
<br>
So. Maybe bug, maybe not. "insufficient data".<br>
<br>
<br>
><br>
>    Out of last 5000 requests in my squid log, I see 101 of the miss_aborted<br>
> statuses.  I just wrote a note on stackexchange, then went to look for<br>
> something on amazon (this is output from a squid log compression tool<br>
> that was mostly for listing site, request time and size:  A few lines<br>
> from no more than 15 minutes ago (usually shows time between requests, but<br>
> periodically, there's a full timestamp)...<br>
><br>
>    Part of my shortening process removes the TCP_ before error messages,<br>
> thus my error is just "MISS_ABORTED".<br>
><br>
> Since this is a grep of that shortened log, the time increments since<br>
> last message are not referring to line immediately above in the grep:<br>
><br>
><br>
> [0227_172940.00]  379ms; 0    (0/0) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://qa.sockets.stackexchange.com/" rel="noreferrer" target="_blank">https://qa.sockets.<wbr>stackexchange.com/</a> - 198.252.206.25 -]<br>
>  +0.38   372ms; 0    (0/0) MISS_ABORTED/000 <Athenae [GET <br>
> <a href="https://qa.sockets.stackexchange.com/" rel="noreferrer" target="_blank">https://qa.sockets.<wbr>stackexchange.com/</a> - 198.252.206.25 -]<br>
>  +0.01     1ms; 0    (0/0) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://images-na.ssl-images-amazon.com/images/I/61x0MG3xpeL._AC_UL160_SR160,160_.jpg" rel="noreferrer" target="_blank">https://images-na.ssl-images-<wbr>amazon.com/images/I/<wbr>61x0MG3xpeL._AC_UL160_SR160,<wbr>160_.jpg</a><br>
> - 54.230.117.34 -]<br>
>  +0.00     0ms; 0    (-/-) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://images-na.ssl-images-amazon.com/images/I/813zL5eetaL._AC_UL160_SR160,160_.jpg" rel="noreferrer" target="_blank">https://images-na.ssl-images-<wbr>amazon.com/images/I/<wbr>813zL5eetaL._AC_UL160_SR160,<wbr>160_.jpg</a><br>
> - 54.230.117.34 -]<br>
>  +0.00     0ms; 0    (-/-) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://images-na.ssl-images-amazon.com/images/I/61Uo2hXZlpL._AC_UL160_SR160,160_.jpg" rel="noreferrer" target="_blank">https://images-na.ssl-images-<wbr>amazon.com/images/I/<wbr>61Uo2hXZlpL._AC_UL160_SR160,<wbr>160_.jpg</a><br>
> - 54.230.117.34 -]<br>
>  +0.00     0ms; 0    (-/-) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://images-na.ssl-images-amazon.com/images/I/71XggjYZ7qL._AC_UL160_SR160,160_.jpg" rel="noreferrer" target="_blank">https://images-na.ssl-images-<wbr>amazon.com/images/I/<wbr>71XggjYZ7qL._AC_UL160_SR160,<wbr>160_.jpg</a><br>
> - 54.230.117.34 -]<br>
>  +0.00     1ms; 0    (-/0) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://images-na.ssl-images-amazon.com/images/I/71LT8PAs-OL._AC_UL160_SR160,160_.jpg" rel="noreferrer" target="_blank">https://images-na.ssl-images-<wbr>amazon.com/images/I/71LT8PAs-<wbr>OL._AC_UL160_SR160,160_.jpg</a><br>
> - 54.230.117.34 -]<br>
>  +0.00     1ms; 0    (-/0) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://images-na.ssl-images-amazon.com/images/I/51X+70QICxL._AC_UL160_SR160,160_.jpg" rel="noreferrer" target="_blank">https://images-na.ssl-images-<wbr>amazon.com/images/I/51X+<wbr>70QICxL._AC_UL160_SR160,160_.<wbr>jpg</a><br>
> - 54.230.117.34 -]<br>
> [0227_173215.00]   16ms; 0    (0/0) MISS_ABORTED/000 <Athenae [GET<br>
> <a href="https://www.amazon.com/gp/uedata?ul&v=0.200071.0&id=TXSV6J9MMKFJ764232PB&ctb=1&m=1&sc=TXSV6J9MMKFJ764232PB&pc=3758697&tc=-286&hob=1&hoe=3&ul=3758697&t=1519781535329&csmtags=mouseHit&pty=Detail&spty=Glance&pti=B079GH97R9&tid=TXSV6J9MMKFJ764232PB&aftb=1" rel="noreferrer" target="_blank">https://www.amazon.com/gp/<wbr>uedata?ul&v=0.200071.0&id=<wbr>TXSV6J9MMKFJ764232PB&ctb=1&m=<wbr>1&sc=TXSV6J9MMKFJ764232PB&pc=<wbr>3758697&tc=-286&hob=1&hoe=3&<wbr>ul=3758697&t=1519781535329&<wbr>csmtags=mouseHit&pty=Detail&<wbr>spty=Glance&pti=B079GH97R9&<wbr>tid=TXSV6J9MMKFJ764232PB&aftb=<wbr>1</a><br>
> - 23.192.244.68 -]<br>
> ==============================<wbr>======<br>
><br>
><br>
> Of note -- a bunch were in trying to fetch a sockets address on<br>
> stackexchange, , while most of the amazon lines seem to be referring to<br>
> jpgs.  Anyway, I too would be interested if you find the answer.<br>
<br>
If anyone seeing these is up for some detective work I'm interested in<br>
whether there is any kind of pattern for the real timing between those<br>
lines, and between a failure and previous/next successful transaction to<br>
the same server.<br>
 Bonus points for getting the info with port numbers to see if there is<br>
a pattern hidden in the client connection state.<br>
<br>
<br>
While its nice to know the frequency is decreasing (IIRC first reporters<br>
had unpleasantly large amounts, now to this ~2% of yours) that does not<br>
really tell much of use for resolving it (or 'them' if multiple issues).<br>
<br>
<br>
><br>
> Just thought I'd mention that your seeing the message isn't unique.<br>
><br>
> Found someone else who asked the same question back in May 2015...<br>
><br>
<br>
Nod. It has been cropping up since the ABORTED log tag was first added,<br>
and "000" status since long before that.<br>
<br>
Amos<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
</blockquote></div><br></div>