diff options
| -rw-r--r-- | README | 37 | ||||
| -rw-r--r-- | wiretap/iptrace.c | 21 |
2 files changed, 42 insertions, 16 deletions
@@ -74,6 +74,17 @@ libpcap, Sniffer (uncompresed), NetXray, Sniffer Pro, snoop, Shomiti, LANalyzer, Network Monitor, iptrace 2.0 (AIX), and RADCOM's WAN/LAN Analyzer +Although Ethereal can read AIX iptrace files, the documentation on +AIX's iptrace packet-trace command is sparse. The 'iptrace' command +starts a daemon which you must kill in order to stop the trace. Through +experimentation it appears that sending a HUP signal to that iptrace +daemon causes a graceful shutdown and a complete packet is written +to the trace file. If a partial packet is saved at the end, Ethereal +will complain when reading that file, but you will be able to read all +other packets. If this occurs, please let the Ethereal developers know +at ethereal-dev@zing.org, and be sure to send us a copy of that trace +file if it's small and contains non-sensitive data. + IPv6 ---- @@ -100,6 +111,32 @@ library but _do not_ want to have ethereal use it, you can run configure with the "--disable-snmp" option. No SNMP support will be compiled into ethereal with this option. +How to Report a Bug +------------------- +Ethereal is still under constant development, so it is possible that you will +encounter a bug while using it. Please report bugs to ethereal-dev@zing.org. +Be sure you tell us: + + 1) Operating System and version + 2) Version of GTK+ (the command 'gtk-config --version' will tell you) + 3) The command you used to invoke Ethereal + +If the bug is produced by a particular trace file, please be sure to send +a trace file along with your bug description. Please don't send a trace file +greather than 1MB when compressed. If the trace file contains sensitive +information (e.g., passwords), then please do not send it. + +If Ethereal died on you with a 'segmentation violation', you can help the +developers a lot if you have your debugger installed. A stack trace using +your debugger ('gdb' in this example), the ethereal binary, and the +resulting core file can be obtained by starting the debugger and using +the 'backtrace' command. + +$ gdb ethereal core +> backtrace +..... prints the stack trace +> quit + Disclaimer ---------- diff --git a/wiretap/iptrace.c b/wiretap/iptrace.c index 5c35a06fc5..381d22b0d2 100644 --- a/wiretap/iptrace.c +++ b/wiretap/iptrace.c @@ -1,6 +1,6 @@ /* iptrace.c * - * $Id: iptrace.c,v 1.6 1999/08/19 05:31:37 guy Exp $ + * $Id: iptrace.c,v 1.7 1999/08/20 04:07:09 gram Exp $ * * Wiretap Library * Copyright (c) 1998 by Gilbert Ramirez <gram@verdict.uthscsa.edu> @@ -75,12 +75,10 @@ static int iptrace_read(wtap *wth, int *err) *err = errno; return -1; } - /* because of the way we have to kill the iptrace command, - * the existence of a partial header or packet is probable, - * and we should not complain about it. Simply return - * quietly and pretend that the trace file ended on - * a packet boundary - */ + if (bytes_read != 0) { + *err = WTAP_ERR_SHORT_READ; + return -1; + } return 0; } @@ -94,15 +92,6 @@ static int iptrace_read(wtap *wth, int *err) packet_size, wth->fh); if (bytes_read != packet_size) { - /* don't complain about a partial packet. Just - * pretend that we reached the end of the file - * normally. If, however, there was a read error - * because of some other reason, complain - * - * XXX - this was returning -1 even on a partial - * packet; should we return 0 on a partial packet, - * so that "wtap_loop()" quits and reports success? - */ if (ferror(wth->fh)) *err = errno; else |