'configure' can update the version automatically. That way we don't
have to update the spec file every time the version of ethereal changes.
svn path=/trunk/; revision=563
and the info field an indication of whether it's Ethernet II, raw 802.3,
or (LLC-atop) 802.3 (which will be overridden by other protocols, if we
know the protocol inside the frame).
svn path=/trunk/; revision=559
In the summary display for FDDI frames, make the protocol FDDI and the
info field the description of the frame control field (which will be
overridden by other protocols, if the frame is an async LLC frame).
svn path=/trunk/; revision=558
"FDDI with the MAC addresses bit-swapped"; whether the MAC addresses are
bit-swapped is a property of the machine on which the capture was taken,
not of the machine on which the capture is being read - right now, none
of the capture file formats we read indicate whether FDDI MAC addresses
are bit-swapped, but this does let us treat non-"libpcap" captures as
being bit-swapped or not bit-swapped independent of the machine on which
they're being read (and of the machine on which they were captured, but
I have the impression they're bit-swapped on most platforms), and allows
us to, if, as, and when we implement packet capture in Wiretap, mark
packets in a capture file written in Wiretap-native format based on the
machine on which they are captured (assuming the rule "Ultrix, Alpha,
and BSD/OS are the only platforms that don't bit-swap", or some other
compile-time rule, gets the right answer, or that some platform has
drivers that can tell us whether the addresses are bit-swapped).
(NOTE: if, for any of the capture file formats used only on one
platform, FDDI MAC addresses aren't bit-swapped, the code to read that
capture file format should be fixed to flag them as not bit-swapped.)
Use the encapsulation type to decide whether to bit-swap addresses in
"dissect_fddi()".
svn path=/trunk/; revision=557
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
Gilbert Ramirez