[tcpdump-workers] guessing when TSO is present

Rick Jones Thu, 20 Jan 2005 00:49:43 -0800

A while back I think I posted something asking about what to do about TSO (large send) and how it generated "IP bad-len 0" output when tracing on a TSO-enabled sender.

I had a couple spare cycles, so I decided to just take a WAG at what might be done, which was to say that if the IP len was zero, just go ahead and guess that this was a TSO and set the len to the length parm pass-in to print-ip and hope.

Basically, before the change, tracing on a system with TSO enabled would look something like this (modulo word-wrap):

000024 IP 192.168.13.223.32879 > 192.168.13.1.61941: S 3328985709:3328985709(0) win 5840 <mss 1460,sackOK,timestamp 19361257 0,nop,w scale 2> 000101 IP 192.168.13.1.61941 > 192.168.13.223.32879: S 629210769:629210769(0) ack 3328985710 win 65535 <mss 1460,nop,nop,sackOK,wsca le 2,nop,nop,nop,timestamp 945581949 19361257> 000014 IP 192.168.13.223.32879 > 192.168.13.1.61941: . ack 1 win 1460 <nop,nop,timestamp 19361257 945581949> 000033 IP bad-len 0 000202 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 1449 win 32768 <nop,nop,timestamp 945581949 19361257> 000001 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 4345 win 32768 <nop,nop,timestamp 945581949 19361257> 000145 IP bad-len 0 000229 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 8689 win 32768 <nop,nop,timestamp 945581949 19361257> 000011 IP bad-len 0 039339 IP 192.168.13.223.32878 > 192.168.13.1.12865: . ack 513 win 1996 <nop,nop,timestamp 19361297 945581949> 024992 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 13033 win 32768 <nop,nop,timestamp 945581956 19361258> 000007 IP bad-len 0 000118 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 14481 win 32768 <nop,nop,timestamp 945581956 19361322> 000001 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 17377 win 32768 <nop,nop,timestamp 945581956 19361322> 000011 IP bad-len 0

with the change, it becomes:

000024 IP 192.168.13.223.32879 > 192.168.13.1.61941: S 3328985709:3328985709(0) win 5840 <mss 1460,sackOK,timestamp 19361257 0,nop,w scale 2> 000101 IP 192.168.13.1.61941 > 192.168.13.223.32879: S 629210769:629210769(0) ack 3328985710 win 65535 <mss 1460,nop,nop,sackOK,wsca le 2,nop,nop,nop,timestamp 945581949 19361257> 000014 IP 192.168.13.223.32879 > 192.168.13.1.61941: . ack 1 win 1460 <nop,nop,timestamp 19361257 945581949> 000033 IP 192.168.13.223.32879 > 192.168.13.1.61941: . 1:4345(4344) ack 1 win 1460 <nop,nop,timestamp 19361257 945581949> 000202 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 1449 win 32768 <nop,nop,timestamp 945581949 19361257> 000001 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 4345 win 32768 <nop,nop,timestamp 945581949 19361257> 000145 IP 192.168.13.223.32879 > 192.168.13.1.61941: . 4345:8689(4344) ack 1 win 1460 <nop,nop,timestamp 19361257 945581949> 000229 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 8689 win 32768 <nop,nop,timestamp 945581949 19361257> 000011 IP 192.168.13.223.32879 > 192.168.13.1.61941: . 8689:13033(4344) ack 1 win 1460 <nop,nop,timestamp 19361258 945581949> 039339 IP 192.168.13.223.32878 > 192.168.13.1.12865: . ack 513 win 1996 <nop,nop,timestamp 19361297 945581949> 024992 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 13033 win 32768 <nop,nop,timestamp 945581956 19361258> 000007 IP 192.168.13.223.32879 > 192.168.13.1.61941: . 13033:17377(4344) ack 1 win 1460 <nop,nop,timestamp 19361322 945581956> 000118 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 14481 win 32768 <nop,nop,timestamp 945581956 19361322> 000001 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 17377 win 32768 <nop,nop,timestamp 945581956 19361322> 000011 IP 192.168.13.223.32879 > 192.168.13.1.61941: . 17377:21721(4344) ack 1 win 1460 <nop,nop,timestamp 19361322 945581956> 000113 IP 192.168.13.1.61941 > 192.168.13.223.32879: . ack 21721 win 32768 <nop,nop,timestamp 945581956 19361322>

Now, I have _no_ clue where this might fall down, and don't know if this is something that should be controlled with a run-time switch or what, but here is the rough prototype diff where it is controlled via an #ifdef:

# diff -c print-ip.c.orig print-ip.c
*** print-ip.c.orig     2005-01-12 03:19:08.000000000 -0800
--- print-ip.c  2005-01-19 11:33:40.160746848 -0800
***************
*** 21,27 ****

#ifndef lint static const char rcsid[] _U_ = ! "@(#) $Header: /tcpdump/master/tcpdump/print-ip.c,v 1.146 2005/01/12 11:19:08 hannes Exp $ (LBL)"; #endif

  #ifdef HAVE_CONFIG_H
--- 21,27 ----

#ifndef lint static const char rcsid[] _U_ = ! "@(#) $Header: /tcpdump/master/tcpdump/print-ip.c,v 1.146+TSO 2005/01/19 17:19:08 raj Exp $ (LBL)"; #endif

  #ifdef HAVE_CONFIG_H
***************
*** 399,406 ****
--- 399,417 ----
                (void)printf("truncated-ip - %u bytes missing! ",
                        len - length);
        if (len < hlen) {
+ #ifdef GUESS_TSO
+               if (len) {
+                       (void)printf("bad-len %u", len);
+                       return;
+               }
+               else {
+                       /* we guess that it is a TSO send */
+                       len = length;
+               }
+ #else
                (void)printf("bad-len %u", len);
                return;
+ #endif /* GUESS_TSO */
        }

/*

basically, if the IP len is zero, ass-u-me that the segment is TSO and wing it.

rick jones
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

[tcpdump-workers] guessing when TSO is present

Reply via email to