[squid-users] file descriptors leak
André Janna
andre61 at brazcubas.br
Sun Nov 29 00:46:40 UTC 2015
Citando Amos Jeffries <squid3 at treenet.co.nz>:
>
> So, the first place to look is not Squid I think. But why at least 6 of
> those ACK packets did not make it back to the client. That needs
> resolving first to esure that the TCP level is operating correctly.
>
> Only then if the problem remains looking at Squid, the use of port 443
> indicates it is the crypto process is possibly waiting for something and
> not closing the port on a 0-byte read(2) operation.
I took another network trace this time both at Squid and Windows client ends.
cache.log:
2015/11/27 11:30:55.610 kid1| SECURITY ALERT: Host header forgery
detected on local=177.43.198.106:443 remote=192.168.64.4:61802 FD 5465
flags=33 (local IP does not match any domain IP)
------------------------------
network trace at Squid side
client connects
11:30:55.604870 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],
seq 1701554341, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
11:30:55.604992 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags
[S.], seq 3125704417, ack 1701554342, win 29200, options [mss
1460,nop,nop,sackOK,nop,wscale 7], length 0
11:30:55.605766 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
ack 1, win 256, length 0
client sends SSL hello
11:30:55.606242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[P.], seq 1:198, ack 1, win 256, length 197
11:30:55.606306 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, length 0
client OS sends TCP keep-alive packets
11:31:05.607191 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:05.607231 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:15.608966 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:15.609005 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:25.614527 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:25.614589 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
client sends FIN
11:31:29.384280 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[F.], seq 198, ack 1, win 256, length 0
11:31:29.421787 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, length 0
client OS sends TCP keep-alive packets
11:31:39.417426 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:39.417489 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:49.425366 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:49.425443 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:59.426153 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:59.426233 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
.... it continues this way until I powered off Windows client after
three hours ...
------------------------------
network trace at Windows client side
client connects
11:30:34.894242 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [S],
seq 1701554341, win 8192, options [mss 1460,nop,wscale
8,nop,nop,sackOK], length 0
11:30:34.898234 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags
[S.], seq 3125704417, ack 1701554342, win 29200, options [mss
1460,nop,nop,sackOK,nop,wscale 7], length 0
11:30:34.898298 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
ack 1, win 256, length 0
client sends SSL hello
11:30:34.898712 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[P.], seq 1:198, ack 1, win 256, length 197
11:30:34.899479 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, length 0
client OS sends TCP keep-alive packets
11:30:44.899271 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:30:44.899986 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:30:54.900495 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:30:54.901323 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
11:31:04.905731 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 197:198, ack 1, win 256, length 1
11:31:04.906560 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 198, win 237, options [nop,nop,sack 1 {197:198}], length 0
client sends FIN
11:31:08.675299 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags
[F.], seq 198, ack 1, win 256, length 0
11:31:08.713746 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, length 0
client OS sends TCP keep-alive packets
11:31:18.708086 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:18.708917 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:28.715600 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:28.716516 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
11:31:38.714887 IP 192.168.64.4.61802 > 177.43.198.106.443: Flags [.],
seq 198:199, ack 1, win 256, length 1
11:31:38.716911 IP 177.43.198.106.443 > 192.168.64.4.61802: Flags [.],
ack 199, win 237, options [nop,nop,sack 1 {198:199}], length 0
...
So after less then one minute after connection Windows client sent a
FIN and Linux server acknowledged.
Windows netstat showed that connection changed to FIN_WAIT_2 state
while Linux netstat showed that connection at Squid endpoint changed
to CLOSE_WAIT state.
# date; netstat -tno | grep 192.168.64.4
Fri Nov 27 11:32:13 BRST 2015
tcp6 1 0 172.16.10.22:3126 192.168.64.4:61802
CLOSE_WAIT off (0.00/0/0)
According to
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm in
this state the server IP stack is waiting for Squid to be ready to
close the connection.
After 3 hours from initial connection netstat state on client was
still FIN_WAIT_2 and on server was still CLOSE_WAIT.
So I powered off Windows laptop and waited 3 hours more but nothing
changed, connection remained in CLOSE_WAIT state and Squid didn't
release the file descriptor.
Fri Nov 27 18:22:25 BRST 2015
squid 2708 proxy 5465u IPv6 620209
0t0 TCP 172.16.10.22:3126->192.168.64.4:61802 (CLOSE_WAIT)
Regards,
André
More information about the squid-users
mailing list