On Tue, Jan 01, 2002 at 10:08:02PM +1100, Hamish Moffatt wrote:
> I've captured the following frame off my network (contents unimportant):
>
> 0000 00 40 95 e1 16 40 00 40 05 69 a2 40 08 00 45 00 .@...@.@ .i.@..E.
> 0010 05 dc 68 3f 40 00 e5 06 3f 06 c2 49 49 71 cb 0e ..h?@... ?..IIq..
> 0020 12 0d 00 50 08 db f3 58 ca 5e 02 b6 08 57 80 10 ...P...X .^...W..
> 0030 fe 88 44 af 00 00 01 01 08 0a 07 79 a6 a0 00 06 ..D..... ...y....
> 0040 55 32 0e 0a 30 07 1f a0 8c a5 c0 9a 43 fd a6 89 U2..0... ....C...
> 0050 d0 07 65 30 04 37 50 0c 32 f0 01 1a 80 2f e8 37 ..e0.7P. 2..../.7
That frame presumably was captured with a small snapshot length,
presumably 96 bytes - most of it is missing. I ran that through
"text2pcap", and, according to the IP header, the IP part of the frame
has a total length of 1500 bytes.
> I dumped this to a text file, edited by hand, and used text2pcap
> to convert it back. I removed the ethernet headers and added
> PPP headers instead. (Used text2pcap -l 9). Here's the new dump:
>
> 0000 00 21 45 00 05 dc 68 3f 40 00 e5 06 3f 06 c2 49 .!E...h? @...?..I
> 0010 49 71 cb 0e 12 0d 00 50 08 db f3 58 ca 5e 02 b6 Iq.....P ...X.^..
> 0020 08 57 80 10 fe 88 44 af 00 00 01 01 08 0a 07 79 .W....D. .......y
> 0030 a6 a0 00 06 55 32 0e 0a 30 07 1f a0 8c a5 c0 9a ....U2.. 0.......
> 0040 43 fd a6 89 d0 07 65 30 04 37 50 0c 32 f0 01 1a C.....e0 .7P.2...
> 0050 80 2f e8 37 ./.7
Unfortunately, text2pcap doesn't dissect the frame in order to, for
example, note that the IP header length is 1500, and conclude from that
value that the total frame length should be 1502 bytes - 2 bytes for the
PPP header and 1500 bytes for the rest of the frame.
Therefore, it has a frame length equal to the number of bytes text2pcap
found, i.e. 84 bytes, which is wrong. This presumably causes confusion
at some layer of the code, causing the TCP checksumming code not to
realize that, in fact, not all data in the frame is available, and
therefore that the TCP checksum cannot be computed.