It checks to see if the packet we have in front of us does not start with
one of the four NetBIOS over TCP/IP message types, or if it is a data
message, then looks for \0377SMB in the first four bytes ...
It seems to work well on one large trace of Samba activity that I have.
`
svn path=/trunk/; revision=536
global variable, dfilter_error_msg is now available, being NULL when there
was no error, or pointing to a string when an error occurred. The three
places that dfilter_compile() is called now use this global variable to
report the error message to the user. A default error message is put
in that string if no context-specific error message is available (since
I only have one context-specifici error message, namely, ETHER values,
that will be most of the time).
svn path=/trunk/; revision=530
that use display filters, TCP follow and Match Selected.
In Match Selected, I made it put the display filter that it creates
in the text entry widget. The code was already there, but it didn't work
because code was missing in the GUI initialization routine that runs
when Ethereal starts. The text entry widget pointer was not being passed
to the Match Selected menu item.
In TCP follow, I made it _not_ put the display filter that it creates
in the text entry widget. I find it annoying that a really long
display filter is left in the widget, and others have voiced their
opinion on this too. In addition, after applying the display filter
and retreiving the TCP data, the display filter (if any) that the user
had in place _before_ running TCP follow is put back and the packet
list is set back to the way it was before TCP follow is run. I think this
is more expected. The drawback is that display filtering is run twice,
once to retreive the TCP data and once to reset the display.
svn path=/trunk/; revision=529
from RADCOM WAN/LAN Analyzers.
(BTW, the previous checkin also removed the comments about the hack
wherein we pretended that ATM Sniffer captures were really Ethernet,
Token-Ring, or RFC 1483 captures, given that said hack was itself
removed.)
svn path=/trunk/; revision=526
washed out to sea the code that used to pretend that an ATM Sniffer
capture was an Ethernet or Token-Ring Sniffer capture.
svn path=/trunk/; revision=524
file, instead of throwing out all but LANE or RFC 1483 data frames and
pretending that the former are just Ethernet or Token-Ring frames.
Add some level of decoding for ATM LANE, but not all of it; the rest,
including decoding non-LANE frames, is left as an exercise for somebody
who has captures they want to decode, an interest in decoding them, ATM
expertise, and time....
svn path=/trunk/; revision=523
improving size of grammar and creating the possibility of dfilter_compile
reporting errors back to user. In this case, if an ETHER variable is
compared against a byte string that is not 6 bytes, an error condition is
flagged appropriately. I have not put in the code to conver that error flag
to a message to the user, but that's what I'm working on next.
Also, fixed sample debug session in README to show correct gdb prompt.
svn path=/trunk/; revision=522
variable from lanalyzer_t (plus an additional variable which wasn't being
used). While I was in there I cleaned up some comments and renamed a couple
variables to make more sense.
svn path=/trunk/; revision=521
capture file succeeds, so that it cleans out any state in the
"capture_file" structure it was handed before filling it in with new
state for the new capture file.
This means it destroys any read filter associated with the
"capture_file" structure it was handed, so the "rfcode" field must be
set *after* calling "open_cap_file()" but *before* calling
"read_cap_file()". Do so for the "capture file (and possibly read
filter) supplied on the command line" case.
svn path=/trunk/; revision=520
expecting it as normal. Added paragraph about iptrace oddities to README.
I also added a section to the README about how to report bugs.
svn path=/trunk/; revision=519
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=518
return 1 on success, -1 if they got an error, and 0 if the file isn't of
the type that file is checking for, and supply an error code if they
return -1; have "wtap_open_offline()" use that error code. Also, have
the per-capture-file-type open routines treat errors accessing the file
as errors, and return -1, rather than just returning 0 so that we try
another file type.
Have the per-capture-file-type read routines "wtap_loop()" calls return
-1 and supply an error code on error (and not, as they did in some
cases, call "g_error()" and abort), and have "wtap_loop()", if the read
routine returned an error, return FALSE (and pass an error-code-pointer
argument onto the read routines, so they fill it in), and return TRUE on
success.
Add some new error codes for them to return.
Now that "wtap_loop()" can return a success/failure indication and an
error code, in "read_cap_file()" put up a message box if we get an error
reading the file, and return the error code.
Handle the additional errors we can get when opening a capture file.
If the attempt to open a capture file succeeds, but the attempt to read
it fails, don't treat that as a complete failure - we may have managed
to read some of the capture file, and we should display what we managed
to read.
svn path=/trunk/; revision=516
the variable for the return value of "wtap_dump_close()", just check it
against EOF; shoving it into "ret" means it gets set to 0 on a
successful close, but a return value of 0 means "wtap_dump_close()"
failed.
svn path=/trunk/; revision=514
can't translate the encapsulation type, it should return an
encapsulation type; we add a new one, WTAP_ENCAP_UNKNOWN. and have it
return that.
Have "capture()" handle "wtap_pcap_encap_to_wtap_encap()" returning that
encapsulation type (if it happens, we need to add a new Wiretap
encapsulation type to handle the new "libpcap" encapsulation type).
svn path=/trunk/; revision=513
for errors when closing a file to which we've written packets (we don't
bother checking if we're giving up on a capture).
Add some more error checks in Wiretap.
Make a single list of all Wiretap error codes, giving them all different
values (some can be returned by more than one routine, so they shouldn't
be per-routine).
svn path=/trunk/; revision=510
write them in "libpcap" format, but the mechanism can have other formats
added.
When creating the temporary file for a capture, use "create_tempfile()",
to close a security hole opened by the fact that "tempnam()" creates a
temporary file, but doesn't open it, and we open the file with the name
it gives us - somebody could remove the file and plant a link to some
file, and, if as may well be the case when Ethereal is capturing
packets, it's running as "root", that means we write a capture on top of
that file.... (The aforementioned changes to Wiretap let you open a
capture file for writing given an file descriptor, "fdopen()"-style,
which this change requires.)
svn path=/trunk/; revision=509
used by "mkstemp()" into a buffer supplied as an argument, trying
several directories for the tempfile, in the same fashion that the BSD
(and probably other) "tempnam()" routines do.
Have that routine cope with temporary-file directory names that don't
end with "/", as "P_tmpdir" doesn't necessarily end with "/" (and
doesn't, in GNU "libc" 2.x, at least on Linux); thanks to Gilbert
Ramirez for catching this one, and supplying the code to cope with that.
Have the code that creates the temporary file for the "Follow TCP
Stream" text use it.
svn path=/trunk/; revision=507
bunch of source files.
Replace the "payload" field of a "packet_info" structure with "len" and
"captured_len" fields, which contain the total packet length and total
captured packet length (including all headers) at the current protocol
layer (i.e., if a given layer has a length field, and that length field
says its shorter than the length we got from the capture, reduce the
"pi.len" and "pi.captured_len" values appropriately). Those fields can
be used in the future if we add checks to make sure a field we're
extracting from a packet doesn't go past the end of the packet, or past
the captured part of the packet.
Get rid of the additional payload argument to some dissection functions;
use "pi.captured_len - offset" instead.
Have the END_OF_FRAME macro use "pi.captured_len" rather than
"fd->cap_len", so that "dissect the rest of the frame" becomes "dissect
the rest of the packet", and doesn't dissect end-of-frame padding such
as padding added to make an Ethernet frame 60 or more octets long. (We
might want to rename it END_OF_PACKET; if we ever want to label the
end-of-frame padding for the benefit of people curious what that extra
gunk is, we could have a separate END_OF_FRAME macro that uses
"fd->cap_len".)
svn path=/trunk/; revision=506
Check for errors reading the "Follow TCP Stream" temporary file.
Unlink the temporary file after attempting to open and read the file,
even if the attempt to open it failed.
svn path=/trunk/; revision=503
to create the temporary file to which the "Follow TCP Stream" code
writes the contents of the TCP stream; this was presumably done to close
a potential security hole opened by the possibility of somebody
replacing the file referred to by the name generated by "tmpnam()"
before we open it.
(We may have to provide our own version of "mkstemp()" if there are any
platforms on which we run that lack it. Note that Solaris 2.5.1 has it,
even though it's not documented and isn't declare in its "stdlib.h".)
Have the "Follow TCP Stream" code put up a dialog box, rather than
spitting a message out to the standard error, if the attempt to create
the temporary file fails.
Check also whether the attempt to open the "Follow TCP Stream" temporary
file for reading fails, and put up a dialog box for that as well.
svn path=/trunk/; revision=502
that means it destroys any read filter we had, so we don't need to
destroy it in "capture()" after "open_cap_file()" succeeds.
svn path=/trunk/; revision=498
want to read the next file with the same filter that you used on the
last file.
In the "File/Open" dialog box, parse the read filter before trying to
open the file, and if the parse fails, leave the dialog box up so the
user still has the filter and file name around and can try to fix the
problem.
Keep the compiled read filter attached to the "capture_file" structure,
so you don't have to reparse it on a "File/Reload".
svn path=/trunk/; revision=497
selecting a field from more than one protocol tree. It turns out that
gtktree.c doesn't clear the tree-item selection list when you use
gtk_tree_clear_items() (which calls gtk_tree_remove_items() ). So the next
time a tree item is selected in a new protocol tree (which is our old
protocol tree, with everything removed, and new things added), gtk_tree
tries to _deselect_ our old selection. But that tree-item which is trying
to be deselected is long gone, resulting in the assert because widget == NULL.
A function needs to be added to gtk_tree to deselect the tree-item selection
for us. (or we need to go through the hassle of creating a new gtk_tree
instead of recycling tree_view over and over).
I stole some code from another section of gtktree.c which lets us clear
the selection in clear_tree_and_hex_views().
Also, I modified the argument to gtk_tree_set_view_mode. We were using
"TRUE", when really we should have used a member of the GtkTreeViewMode
enumeration, namely GTK_TREE_VIEW_ITEM ( which is 1, which is TRUE :-)
svn path=/trunk/; revision=496
reason for the failure, and have it do the checks to make sure the file
being opened is a plain file or a pipe.
Have "open_cap_file()" make use of that.
Don't automatically set "last_open_dir" if a "-r" flag was specified on
the command line - do so only if the file in question could actually be
opened.
svn path=/trunk/; revision=495
it's called after "open_cap_file()" has been called, and is always
passed the file name passed to "open_cap_file()", and that file name is
stored as "cf->filename", so "read_cap_file()" can just use
"cf->filename" as the pathname of the file.
svn path=/trunk/; revision=494
The former, which used to be called by "load_cap_file()", now just opens
the file and, if the open succeeds, closes any capture file we
previously had open, reinitializes any protocols that need
reinitialization, and saves information about the new capture file in
the "capture_file" structure to which it was passed a pointer. The
latter reads the file already opened by "read_cap_file()".
For "File/Open", call "open_cap_file()" before dismissing the file
selection box; if it fails, "open_cap_file()" will have popped up a
message box complaining about it - just return, leaving the file
selection box open so the user can, after dismissing the message box,
either try again with a different file name, or dismiss the file
selection box. (Other file selection boxes should be made to work the
same way.) If "open_cap_file()" succeeds, dismiss the file selection
box, and read the capture file in.
svn path=/trunk/; revision=492
Ethereal now remembers the directory where it last opened a file, either
via the GUI File|Open or command-line '-r' option. The next time File|Open
is used, browsing starts from that directory.
svn path=/trunk/; revision=490
Gerald Combs