[squid-users] POST upload splits tcp stream in many small 39byte sized pakets
Eliezer Croitoru
eliezer at ngtech.co.il
Tue Oct 20 16:00:25 UTC 2015
Hey Toni,
I have not reviewed your tcpdump captures but I have briefly reviewed
your squid.conf.
The number of packets per second would not be accounted as a DOS unless
the admin of the service don't really know what it means.
The TCP stack allows a connection to send small packets if there is a
need and it is a part of the TCP open and available options for the
public use.
I recommend you to open a bug in the bugzilla using this link:
http://bugs.squid-cache.org/enter_bug.cgi?product=Squid
And choose the "other" component and 3.5 as the version and as confirmed.
I have also tested this issue now after reading your issue and it seems
to be quite real.
The test I was running was on latest 3.5.10:
[root at proxy]$ http_proxy="http://192.168.10.150:3128/" curl -X POST -H
"Content-Type: multipart/form-data" -F "data=@/tmp/storeid_db"
http://ngtech.co.il/favicon.ico >/dev/null
And the tcp dump result was fascinating:
[root at www1]$ tcpdump -n port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:57:46.748661 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [S],
seq 1931160420, win 14600, options [mss 1460,sackOK,TS val 2567736261
ecr 0,nop,wscale 7], length 0
18:57:46.748801 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [S.],
seq 2253848035, ack 1931160421, win 28960, options [mss 1460,sackOK,TS
val 578191590 ecr 2567736261,nop,wscale 7], length 0
18:57:46.754405 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 1, win 115, options [nop,nop,TS val 2567736266 ecr 578191590], length 0
18:57:46.755667 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 1:270, ack 1, win 115, options [nop,nop,TS val 2567736268 ecr
578191590], length 269
18:57:46.755790 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [.],
ack 270, win 235, options [nop,nop,TS val 578191592 ecr 2567736268],
length 0
18:57:46.765041 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [P.],
seq 1:26, ack 270, win 235, options [nop,nop,TS val 578191594 ecr
2567736268], length 25
18:57:46.766184 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 26, win 115, options [nop,nop,TS val 2567736278 ecr 578191594], length 0
18:57:46.767043 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 270:309, ack 26, win 115, options [nop,nop,TS val 2567736279 ecr
578191594], length 39
18:57:46.767706 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 309:348, ack 26, win 115, options [nop,nop,TS val 2567736279 ecr
578191594], length 39
18:57:46.767744 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 348:387, ack 26, win 115, options [nop,nop,TS val 2567736279 ecr
578191594], length 39
18:57:46.767760 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 387:424, ack 26, win 115, options [nop,nop,TS val 2567736279 ecr
578191594], length 37
18:57:46.767827 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [.],
ack 424, win 235, options [nop,nop,TS val 578191595 ecr 2567736279],
length 0
18:57:46.807708 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 424:463, ack 26, win 115, options [nop,nop,TS val 2567736319 ecr
578191595], length 39
18:57:46.807762 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 463:502, ack 26, win 115, options [nop,nop,TS val 2567736319 ecr
578191595], length 39
18:57:46.807779 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 502:541, ack 26, win 115, options [nop,nop,TS val 2567736319 ecr
578191595], length 39
18:57:46.807791 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 541:580, ack 26, win 115, options [nop,nop,TS val 2567736319 ecr
578191595], length 39
18:57:46.807809 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 580:619, ack 26, win 115, options [nop,nop,TS val 2567736319 ecr
578191595], length 39
18:57:46.807823 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 619:658, ack 26, win 115, options [nop,nop,TS val 2567736320 ecr
578191595], length 39
18:57:46.807870 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [P.],
seq 658:672, ack 26, win 115, options [nop,nop,TS val 2567736320 ecr
578191595], length 14
18:57:46.807976 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [.],
ack 672, win 235, options [nop,nop,TS val 578191605 ecr 2567736319],
length 0
18:57:46.808180 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [.],
seq 26:2922, ack 672, win 235, options [nop,nop,TS val 578191605 ecr
2567736319], length 2896
18:57:46.808221 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [.],
seq 2922:5818, ack 672, win 235, options [nop,nop,TS val 578191605 ecr
2567736319], length 2896
18:57:46.808241 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [P.],
seq 5818:8714, ack 672, win 235, options [nop,nop,TS val 578191605 ecr
2567736319], length 2896
18:57:46.808260 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [.],
seq 8714:11610, ack 672, win 235, options [nop,nop,TS val 578191605 ecr
2567736319], length 2896
18:57:46.808280 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [.],
seq 11610:14506, ack 672, win 235, options [nop,nop,TS val 578191605 ecr
2567736319], length 2896
18:57:46.809154 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 2922, win 160, options [nop,nop,TS val 2567736321 ecr 578191605],
length 0
18:57:46.809226 IP 192.168.10.1.80 > 192.168.10.254.40918: Flags [P.],
seq 14506:17258, ack 672, win 235, options [nop,nop,TS val 578191605 ecr
2567736321], length 2752
18:57:46.809257 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 5818, win 205, options [nop,nop,TS val 2567736321 ecr 578191605],
length 0
18:57:46.809278 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 8714, win 250, options [nop,nop,TS val 2567736321 ecr 578191605],
length 0
18:57:46.809294 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 11610, win 269, options [nop,nop,TS val 2567736321 ecr 578191605],
length 0
18:57:46.809311 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 14506, win 296, options [nop,nop,TS val 2567736321 ecr 578191605],
length 0
18:57:46.809913 IP 192.168.10.254.40918 > 192.168.10.1.80: Flags [.],
ack 17258, win 323, options [nop,nop,TS val 2567736322 ecr 578191605],
length 0
^C
32 packets captured
32 packets received by filter
0 packets dropped by kernel
Eliezer
On 20/10/2015 16:49, Squid admin wrote:
> Dear squid team,
>
> first of all thanks for developing such a great product!
>
> Unfortunately on uploading a big test file (unencrypted POST) to apache
> webserver using a squid proxy (V 3.5.10 or 4.0.1) the upstream pakets
> get slized into thousands of small 39 byte sized pakets.
>
> Excerpt from cache.log:
>
> 2015/10/20 13:51:08.201 kid1| 5,5| Write.cc(35) Write:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: sz 583:
> asynCall 0x244b670*1
> 2015/10/20 13:51:08.201 kid1| 5,5| Write.cc(66) HandleWrite:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: off 0, sz 583.
> 2015/10/20 13:51:08.203 kid1| 5,5| Write.cc(35) Write:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: sz 16422:
> asynCall 0x2447d40*1
> 2015/10/20 13:51:08.203 kid1| 5,5| Write.cc(66) HandleWrite:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: off 0, sz 16422.
> 2015/10/20 13:51:08.204 kid1| 5,5| Write.cc(35) Write:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: sz 39:
> asynCall 0x2448ec0*1
> 2015/10/20 13:51:08.205 kid1| 5,5| Write.cc(66) HandleWrite:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: off 0, sz 39.
> 2015/10/20 13:51:08.206 kid1| 5,5| Write.cc(35) Write:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: sz 39:
> asynCall 0x2464bb0*1
> 2015/10/20 13:51:08.207 kid1| 5,5| Write.cc(66) HandleWrite:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: off 0, sz 39.
> 2015/10/20 13:51:08.208 kid1| 5,5| Write.cc(35) Write:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: sz 39:
> asynCall 0x2448ec0*1
> 2015/10/20 13:51:08.209 kid1| 5,5| Write.cc(66) HandleWrite:
> local=10.1.1.210:46731 remote=10.1.1.19:81 FD 17 flags=1: off 0, sz 39.
> ...
>
> Attached you can find a tar file containing squid configuration,
> test network topology, network trace from traffic from client to squid,
> network trace from squid to webserver and a full debug log from squid
>
> One incoming paket of size ~ 1500 bytes gets sliced into more as 40 pakets.
> On the target webserver the squid upstream traffic therefore looks like
> a DOS attack.
>
> The problem can be reproduced using squid 3.5.x and squid 4.0.x (32bit
> and 64bit variants)
> The where no such problems using squid 3.2.x
>
> Hopefully you can help me to fix this problem as this is a showstopper
> for me to upgrade to squid 3.5.x and higher.
>
> Best regards,
>
> Toni
More information about the squid-users
mailing list