tcptrace-bugs Bug in Win32 version

From: Enrico Detoma (
Date: 09/18/04

Message-Id: <>
Date: Sun, 19 Sep 2004 01:10:53 +0200
From: Enrico Detoma <>
Subject: tcptrace-bugs Bug in Win32 version

Dear maintainers of tcptrace,

I thought I could make a patch for the bug I reported in a previous mail
(which is rewritten in this message for convenience):

--- mfiles.c 2003-11-19 14:38:02.000000000 +0100
+++ 2004-09-19 00:47:05.890625000 +0200
@@ -159,9 +159,9 @@

      if (strcmp(mode,"w") == 0)
- Mfopen_internal(pmf,"w+");
+ Mfopen_internal(pmf,"wb+");
      else if (strcmp(mode,"a") == 0)
- Mfopen_internal(pmf,"a+");
+ Mfopen_internal(pmf,"ab+");
      else {
         fprintf(stderr,"Mfopen: internal file mode inconsistancy\n");

This patch should be perfectly fine for UNIX environment too, since "wb"
option for fopen is ANSI legal.

Here are the bug details.

I found a severe bug in the Win32 port of tcptrace: when I use option '-e'
to dump whole tcp connections, all '\n' bytes are converted to "\r\n" in
the output files, because files are opened with "w" and not "wb" option in
fopen (which is a problem only in Win32). Since this enlarges the written
data, some data may also be overwritten like in this case.
Output from tcptrace:


Output from Ethereal:


As you can see, due to the enlargement of the previous data caused by
"\r\n" end of lines, that data was shifted forward and the "QUIT" line
(which is in a different packet) has overwritten the line with the single
dot (this example comes from a SMTP send).

Best regards

Enrico Detoma <>

This archive was generated by hypermail 2.1.7 : 09/19/04 EDT