Question about byte/packet counts
wozz at 0xdeadbeef.org
wozz at 0xdeadbeef.org
Thu Jul 25 14:05:18 EDT 2002
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here is a demo of the problem I was describing yesterday, complete with packet captures. Let me describe what is happening here so its clear. We have 2 layers of web proxies which perform different functions. The two flows I've included here are a user talking to the first web proxy, and before responding to the user, the first web proxy talking to the second web proxy. There is data flowing in both directions (HTTP status codes at the very least), but as you can see, only one direction is being reflected in argus's packet/byte counts. Let us begin (sorry, this paste is gonna be ugly):
Argus shows:
25 Jul 02 13:00:16 tcp x.11.249.105.2176 -> x.20.21.17.8080 6 0 564 0 FIN
25 Jul 02 13:00:16 tcp x.20.21.17.45862 -> a.b.c.166.8082 0 5 0 439 FIN
So, we have a connection from x.11.249.105 (the user) to x.20.21.17 (the first proxy) which has 6 packets from the source, and none from the destination. We then have a connection from x.20.21.17 (first proxy) to a.b.c.166 (the second proxy) which has no packets from the source, and 5 packets from the destination. Now look at the packet capture, and observe that there are packets and data flowing both directions.
Packet capture shows:
No. Time Source Destination Protocol Info
22 11:00:16.2978 x.11.249.105 x.20.21.17 TCP 2176 > 8080 [SYN] Seq=1842578 Ack=0 Win=8192 Len=0
24 11:00:16.2979 x.20.21.17 x.11.249.105 TCP 8080 > 2176 [SYN, ACK] Seq=789993029 Ack=1842579 Win=24820 Len=0
32 11:00:16.3003 x.11.249.105 x.20.21.17 TCP 2176 > 8080 [ACK] Seq=1842579 Ack=789993030 Win=8760 Len=0
35 11:00:16.3034 x.11.249.105 x.20.21.17 HTTP GET http://arsdata.com/njhh/filler.gif HTTP/1.0
36 11:00:16.3047 x.20.21.17 x.11.249.105 TCP 8080 > 2176 [ACK] Seq=789993030 Ack=1842815 Win=24820 Len=0
131 11:00:16.3465 x.20.21.17 a.b.c.166 TCP 45862 > 8082 [SYN] Seq=1874838077 Ack=0 Win=24820 Len=0
297 11:00:16.4705 a.b.c.166 x.20.21.17 TCP 8082 > 45862 [SYN, ACK] Seq=179365019 Ack=1874838078 Win=8760 Len=0
298 11:00:16.4705 x.20.21.17 a.b.c.166 TCP 45862 > 8082 [ACK] Seq=1874838078 Ack=179365020 Win=24820 Len=0
299 11:00:16.4707 x.20.21.17 a.b.c.166 HTTP GET http://arsdata.com/njhh/filler.gif HTTP/1.0
870 11:00:16.8016 a.b.c.166 x.20.21.17 TCP 8082 > 45862 [ACK] Seq=179365020 Ack=1874838410 Win=8428 Len=0
915 11:00:16.8133 a.b.c.166 x.20.21.17 HTTP HTTP/1.1 304 Not Modified
916 11:00:16.8133 a.b.c.166 x.20.21.17 TCP 8082 > 45862 [FIN, ACK] Seq=179365185 Ack=1874838410 Win=8428 Len=0
917 11:00:16.8133 x.20.21.17 a.b.c.166 TCP 45862 > 8082 [ACK] Seq=1874838410 Ack=179365185 Win=24820 Len=0
918 11:00:16.8134 x.20.21.17 a.b.c.166 TCP 45862 > 8082 [ACK] Seq=1874838410 Ack=179365186 Win=24820 Len=0
927 11:00:16.8185 x.20.21.17 x.11.249.105 HTTP HTTP/1.1 200 OK
928 11:00:16.8187 x.20.21.17 a.b.c.166 TCP 45862 > 8082 [FIN, ACK] Seq=1874838410 Ack=179365186 Win=24820 Len=0
1377 11:00:16.9435 a.b.c.166 x.20.21.17 TCP 8082 > 45862 [ACK] Seq=179365186 Ack=1874838411 Win=8428 Len=0
1528 11:00:17.0067 x.11.249.105 x.20.21.17 TCP 2176 > 8080 [ACK] Seq=1842815 Ack=789993414 Win=8376 Len=0
1529 11:00:17.0070 x.20.21.17 x.11.249.105 HTTP Continuation
1580 11:00:17.0308 x.11.249.105 x.20.21.17 TCP 2176 > 8080 [ACK] Seq=1842815 Ack=789994436 Win=7355 Len=0
1581 11:00:17.0308 x.11.249.105 x.20.21.17 TCP 2176 > 8080 [FIN, ACK] Seq=1842815 Ack=789994436 Win=7355 Len=0
1587 11:00:17.0312 x.20.21.17 x.11.249.105 TCP 8080 > 2176 [ACK] Seq=789994436 Ack=1842816 Win=24820 Len=0
Weird eh?
Individual requests for the actual packet cap will be granted, but I'd rather not post it to a public mailing list.
Let me know if you have any thoughts.
On Thu, 25 Jul 2002 09:08:11 -0400, Carter Bullard <carter at qosient.com> wrote:
>Hey Wozz,
> If we can get some packet traces that demonstrate the
>problem, I can definitely look to see whats going on!!!!
>
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com
wlsEARECABsFAj1AOWMUHHdvenpAMHhkZWFkYmVlZi5vcmcACgkQ1vK8vFo3sjzKbACf
fRVnWYOsBTBycraF9tyrsvvVBBsAn069I5XVGbYSgBX/ebptUf+1FwIo
=2O9q
-----END PGP SIGNATURE-----
More information about the argus
mailing list