if the SAPs are SNAP, based on their ethertype are I frames and UI
frames; others don't have payload to be dissected as belonging to other
protocols.
svn path=/trunk/; revision=555
temporary file with mode rw-------, so we won't assume that all UNIXes
will do so; instead, we set the umask to 0077 to take away all group and
other permissions, attempt to create the file, and then put the umask
back (puts into "try_tempfile()", called by "create_tempfile()" to
create temporary files, the "umask()" calls that Gilbert put into
"capture.c" to deal with the same problem).
svn path=/trunk/; revision=553
not using the structure members so declared, anyway; instead, put in a
comment to note that the data follows, in a certain format.
Use "guint8", "guint16", and "guint32" instead of "unsigned char",
"unsigned short", and "unsigned long", as per the rest of Ethereal; the
first two pairs are equivalent, but "unsigned long" is *not* necessarily
a 32-bit data type (it's not a 32-bit data type on most 64-bit
platforms, for example).
svn path=/trunk/; revision=550
necessary nor sufficient if you're using "struct tm" (on many, perhaps
most, perhaps even all modern UNIXes, <sys/time.h> includes <time.h>,
which declares "struct tm", but that's not necessarily the case on
non-UNIX systems).
Include <time.h> in "file.c", to declare "struct tm".
Don't use PCAP_ERRBUF_SIZE to declare a message string buffer - that
won't work if you don't have "libpcap".
svn path=/trunk/; revision=549
Have the code that opens "libpcap" files for writing check to make sure
that the Wiretap encapsulation can be written to a "libpcap" file, and
return -1 and supply a new WTAP_ERR_UNSUPPORTED_ENCAP error code if it
can't.
Handle that new error code in "wtap_strerror()".
svn path=/trunk/; revision=546
code supplied by a Wiretap routine (whether a positive UNIX "errno" code
or a negative Wiretap error code), and returns an error message
corresponding to it.
Use that to construct the message Ethereal put up in a message box for
those errors for which we don't have Ethereal put up a message of its
choice.
svn path=/trunk/; revision=545
Get rid of WTAP_ENCAP_NONE; replace it with WTAP_ENCAP_UNKNOWN, which
means "I can't handle that file, it's using an encapsulation I don't
support".
Check for encapsulations we don't support, and return an error (as is
already done in "libpcap.c").
Check for too-large packet sizes, and return an error (as is already
done in "libpcap.c").
Print unsigned quantities in Wiretap messages with "%u", not "%d".
svn path=/trunk/; revision=544
and in different capture files; throw in some heuristics to try to
figure out whether the 4-byte header is:
1) PPP-over-HDLC (some version of ISDN4BSD?);
2) big-endian AF_ value (BSD on big-endian platforms);
3) little-endian AF_ value (BSD on little-endian platforms);
4) two octets of 0 followed by an Ethernet type (Linux, at least
on little-endian platforms, as mutated by "libpcap").
Make a separate Wiretap encapsulation type, WTAP_ENCAP_NULL,
corresponding to DLT_NULL.
Have the PPP code dissect the frame if it's PPP-over-HDLC, and have
"ethertype()" dissect the Ethernet type and the rest of the packet if
it's a Linux-style header; dissect it ourselves only if it's an AF_
value.
Have Wiretap impose a maximum packet size of 65535 bytes, so that it
fails more gracefully when handed a corrupt "libpcap" capture file
(other capture file formats with more than a 16-bit capture length
field, if any, will have that check added later), and put that size in
"wtap.h" and have Ethereal use it as its notion of a maximum packet
size.
Have Ethereal put up a "this file appears to be damaged or corrupt"
message box if Wiretap returns a WTAP_ERR_BAD_RECORD error when opening
or reading a capture file.
Include loopback interfaces in the list of interfaces offered by the
"Capture" dialog box, but put them at the end of the list so that it
doesn't default to a loopback interface unless there are no other
interfaces. Also, don't require that an interface in the list have an
IP address associated with it, and only put one entry in the list for a
given interface (SIOCGIFCONF returns one entry per interface *address*,
not per *interface* - and even if you were to use only IP addresses, an
interface could conceivably have more than one IP address).
Exclusively use Wiretap encapsulation types internally, even when
capturing; don't use DLT_ types.
svn path=/trunk/; revision=540
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
Guy Harris