I thought that this was being caused by a firewall because I was seeing (requests go out, but blocked coming back) so I had the ports over 1024 opened :
No. Time Source Destination Protocol Length Info
156 16.493132 152.7.114.135 140.211.169.196 TCP 74 50994 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2876033516 TSecr=0 WS=128
157 16.493333 140.211.169.196 152.7.114.135 TCP 60 443 → 50994 [RST, ACK] Seq=1 Ack=1 Win=29200 Len=0
158 16.493440 152.7.114.135 152.19.134.198 TCP 74 45744 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2876033516 TSecr=0 WS=128
159 16.493626 152.19.134.198 152.7.114.135 TCP 60 443 → 45744 [RST, ACK] Seq=1 Ack=1 Win=29200 Len=0
156 16.493132 152.7.114.135 140.211.169.196 TCP 74 50994 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2876033516 TSecr=0 WS=128
157 16.493333 140.211.169.196 152.7.114.135 TCP 60 443 → 50994 [RST, ACK] Seq=1 Ack=1 Win=29200 Len=0
158 16.493440 152.7.114.135 152.19.134.198 TCP 74 45744 → 443 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2876033516 TSecr=0 WS=128
159 16.493626 152.19.134.198 152.7.114.135 TCP 60 443 → 45744 [RST, ACK] Seq=1 Ack=1 Win=29200 Len=0
but now it is still failing and I am also seeing this in access.log. It looks like connections are going out but not coming back :
2019/08/19 13:17:38.576 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57230 flags=1
2019/08/19 13:17:52.050 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.21:48557 flags=1
2019/08/19 13:17:53.608 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57330 flags=1
2019/08/19 13:18:07.053 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.21:48651 flags=1
2019/08/19 13:18:08.725 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57426 flags=12
2019/08/19 13:17:52.050 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.21:48557 flags=1
2019/08/19 13:17:53.608 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57330 flags=1
2019/08/19 13:18:07.053 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.21:48651 flags=1
2019/08/19 13:18:08.725 kid1| 33,2| client_side.cc(817) swanSong: local=152.7.114.135:3128 remote=10.50.54.22:57426 flags=12
Do you see anything else relevant in here?
Thanks,
Tom
On Sat, Aug 10, 2019 at 1:57 PM Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 8/9/19 4:32 PM, Tom Karches wrote:
> Right now my debug is set to ALL,1 33,2. Is there a better set of
> options to provide me more visibility of what might be wrong?
In theory, yes: You can increase verbosity levels to see exactly what is
going on. However, most people get lost in the debugging noise. FWIW, I
do not recommend using cache.log above ALL,1 (the default) for triaging
connectivity problems like yours by Squid newbies like you. Most likely,
the connectivity problem is outside Squid and can be seen/reproduced
outside Squid.
I would use Wireshark, tcpdump, or a similar packet-level tool to figure
out where Squid is trying to connect and from what address Squid is
trying to connect. If you are not familiar with those basic tools, any
capable local sysadmin can help you get started -- no Squid knowledge is
needed!
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
Thomas Karches
NCSU OIT CSI - Systems Specialist
NCSU OIT CSI - Systems Specialist
M.E Student - Technology Education
Hillsborough 319 / 919.515.5508
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
