tcptrace-bugs Bug in Win32 version

From: Enrico Detoma (enrico.detoma@email.it)
Date: 09/18/04 

Message-Id: <6.1.0.6.2.20040919010657.030b7fb8@popmail.email.it>
Date: Sun, 19 Sep 2004 01:10:53 +0200
From: Enrico Detoma <enrico.detoma@email.it>
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
+++ mfiles.c.new 2004-09-19 00:47:05.890625000 +0200
@@ -159,9 +159,9 @@
             fname);

      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");
         exit(10);

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:

</body>
</html>QUIT

Output from Ethereal:

</body>
</html>
.
QUIT

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 <enrico.detoma@email.it>

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