From: Enrico Detoma (firstname.lastname@example.org)
Message-Id: <email@example.com> Date: Sun, 19 Sep 2004 01:10:53 +0200 From: Enrico Detoma <firstname.lastname@example.org> 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 @@
if (strcmp(mode,"w") == 0)
else if (strcmp(mode,"a") == 0)
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).
Enrico Detoma <email@example.com>
This archive was generated by hypermail 2.1.7 : 09/19/04 EDT