Subject: Re: some tcp header looking faulty when do ftp from windows and non
To: None <cheluvi@yahoo.com, tech-net@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-net
Date: 01/10/2002 12:17:39
> We did, ftp from windows machine and Linux machine to NetBSD 1.5 and
> collected the packets..
> I am observing the tcp packets by doing ftp to a NETBSD (1.5) system
> from a windows NT 4.0 system. It seems the TCP header length is
> faulty i.e, header length value is not matching to what it is
> sending. Here is the tcpdump:
> 13:34:37.817564 192.168.0.25.1042 > NETBSD2.ftp: S 57781:57781(0) win
> 8192 <mss 1460> (DF)
> 4500 002c a800 4000 8006 d15a c0a8 0019
> c0a8 0007 0412 0015 0000 e1b5 0000 0000
> 6002 2000 10d9 0000 0204 05b4 2020
I don't see the issue. Looks fine to me (except that something
incorrectly line-broke the first line).
13:34:37.817564 192.168.0.25.1042 > NETBSD2.ftp: S 57781:57781(0) win 8192 <mss 1460> (DF)
45 ip_hl=5 ip_v=4
00 ip_tos [Routine]
00 2c ip_len [44] (dropping 2 trailing bytes)
a8 00 ip_id
40 00 ip_off [0, DF]
80 ip_ttl [128]
06 ip_p [TCP]
d1 5a ip_sum
c0 a8 00 19 ip_src [192.168.0.25]
c0 a8 00 07 ip_dst [192.168.0.7]
04 12 th_sport [1042]
00 15 th_dport [21=ftp]
00 00 e1 b5 th_seq
00 00 00 00 th_ack
60 th_off=6
02 th_flags [SYN]
20 00 th_win [8192]
10 d9 th_sum
00 00 th_urp [0]
02 04 05 b4 TCP option: MSS=1460
(the last two bytes are padding; note the remark on the ip_len line).
th_off is 6, and the TCP header is indeed 6*4=24 octets long, from
th_sport through the end of the options.
Comparing with the Linux version,
> 13:32:16.701608 192.168.0.4.1026 > NETBSD2.ftp: S 517726340:517726340(0) win 32120 <mss 1460,sackOK,timestamp 343375 0,nop,wscale 0> (DF)
> 4500 003c 0066 4000 3f06 b9fa c0a8 0004
> c0a8 0007 0402 0015 1edb e084 0000 0000
> a002 7d78 0868 0000 0204 05b4 0402 080a
> 0005 3d4f 0000 0000 0103 0300
13:32:16.701608 192.168.0.4.1026 > NETBSD2.ftp: S 517726340:517726340(0) win 32120 <mss 1460,sackOK,timestamp 343375 0,nop,wscale 0> (DF)
45 ip_hl=5 ip_v=4
00 ip_tos [Routine]
00 3c ip_len [60]
00 66 ip_id
40 00 ip_off [0, DF]
3f ip_ttl [63]
06 ip_p [TCP]
b9 fa ip_sum
c0 a8 00 04 ip_src [192.168.0.4]
c0 a8 00 07 ip_dst [192.168.0.7]
04 02 th_sport [1026]
00 15 th_dport [21=ftp]
1e db e0 84 th_seq
00 00 00 00 th_ack
a0 th_off=10
02 th_flags [SYN]
7d 78 th_win [32120]
08 68 th_sum
00 00 th_urp [0]
02 04 05 b4 TCP option: MSS=1460
04 02 08 0a 00 05 3d 4f .
00 00 00 00 01 03 03 00 Unrecognized TCP option(s)
(I see I have to add some TCP options to my unpacker.) Everything
looks equally correct here; th_off is 10, and the TCP header is indeed
40 bytes long.
The only thing I can see that could be what you're talking about is the
two padding bytes in the first case. This is probably because of the
Ethernet minimum frame size. The packet as printed holds 46 bytes; add
14 for the Ethernet header and you have 60, the smallest an Ethernet
packet can be. The Ethernet software (correctly) added two padding
bytes to bring the packet up to the minimum Ethernet size. Because
they are not counted in the ip_len field, non-broken systems will
ignore them on reception. They do not mean th_off is incorrect; they
are outside the IP portion of the packet, never mind the TCP portion.
If that's not what you're talking about, you'll have to be clearer, at
least for me to explain.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B