(I posted this problem on the Users list in December, but
did not reach a happy resolution. So, I am re-posting to the Dev list
with the hope of drawing additional expertise to the problem)
Recently, I started paying attention to the TCP frames on
PPPDump logs that I collected on a GPRS smart-phone device. I noticed
that on a particular HTTP transaction, Ethereal identified every other packet
coming from the HTTP server as having an *incorrect* TCP packet checksum.
At the same time, Ethereal identified *all* “data-carrying” packets
going from the smart-phone to the HTTP server as having an
“incorrect” TCP packet checksum. In the phone-to-server
direction, only the Ack packets were identified as having a correct TCP packet
checksum. Also, none of the packets appeared to be retries.
I have been scanning the log for a while now, and I think I
reached a conclusion (perhaps mistaken :-)) that Ethereal may be having
problems with parsing of PPP frames where PPP VJ Compression is
"Compressed data" (versus "Uncompressed data").
Here is what I mean: In the PPPDump attached to my original
posting, I noticed that in PPP frames coming from the server
(source=4.23.88.219),
the ones with "PPP VJ Compression: Compressed
data" all are tagged as having an *incorrect* TCP checksum. On the
other hand, all of the PPP
frames coming from the server that have "PPP VJ
Compression: Uncompressed data", are tagged as having *correct* TCP
checksum.
Also, please note that all packets coming from the phone
have "PPP VJ Compression: Compressed data", and all are in turn
tagged by Ethereal as
having *incorrect* TCP checksums.
The following is another observation that I am not quite
certain what to make of:
Another observation that I made is that for those packets
with "PPP VJ Compression: Compressed data", Ethereal appears to be
*over-reporting*
the size of the TCP payload by exactly 2 bytes. For
example, when two packets are sent by the server back to back with a TCP
payload of 1380
bytes each, the one with "PPP VJ Compression:
Compressed data" is reported by Ethereal as having a 1382-byte TCP
payload, while the one
with "PPP VJ Compression: Uncompressed data" is
correctly reported as having a 1380-byte payload.
Also, note that most of the packets coming from the phone
(with "PPP VJ Compression: Compressed data" and source=10.120.26.127)
should just be
ACK or Selective ACK packets, however Ethereal reports all
of them as having a 2-byte TCP payload.
I am using Ethereal 0.10.8 on Windows XP. I had the
same results with 0.10.6.
I am attaching the PPPDump trace (BadTCPChecksum.eth) to
this posting. I collected the PPP trace in the phone’s PPP driver,
so the server’s possible offloading of TCP checksums should not have been
a factor here. Also, there is no TCP check-sum offloading on the phone,
so the packets sent from the phone should have all the fields filled in before
I trace them. Please note that 4.23.88.219 is the HTTP server and
10.120.26.127 is the phone in this PPPDump. The server and client both
make use of VJ compression and Selective ACKs.
