line of ISDN routers. Much like the ascend reader, this module reads an
ASCII hex dump of trace data.
Rearranged the order in which wiretap tries trace files, to keep the
ASCII-readers (ascend and toshiba) at the end, and put the binary-readers
(everything else) at the front of the list. If a telnet session of
and ascend trace or toshiba trace were captured near the beginning of
another trace, wiretap might think the trace was ascend or toshiba if it
tried that module first.
Fixed the way wtap_seek_read() selects functions to call. It was using
the encap type instead of the file type. We got lucky because
WTAP_ENCAP_ASCEND == WTAP_FILE_ASCEND
svn path=/trunk/; revision=952
show detail of path attribute to outside of the tree, to help users
browse the structure. BGP protocol header structure is very complex
and the previous code required users to click through the tree to check,
say, AS path.
svn path=/trunk/; revision=951
name/number, and put the call/reply info, procedure, and version number
into the INFO field.
Implement "col_append_fstr()", and use it to add information to the info
field.
Make "col_add_fstr()" aware that COL_INFO fields can have more data than
other COL_XXX fields (as "col_add_str()" and "col_append_str()" already
were).
svn path=/trunk/; revision=947
in LIBS, because there's a bunch of stuff we might use that might have
been installed in "/usr/local" ("libpcap", "zlib", an SNMP library), and
we want to make sure all the stuff that looks for libraries and header
files checks there.
Also, add all the "-I" stuff to CPPFLAGS as well, as that's what's used
in many header-file searches.
And, while we're at it, add "-R/usr/local/lib" on SunOS 5.x, as its
linker doesn't automatically set the run-time library search path to
include all directories specified in "-L".
Hopefully, this will make sure we find in "/usr/local/include" and
"/usr/local/lib" everything we might want to find (e.g., SNMP headers -
on FreeBSD, we weren't adding "/usr/local/include" because we found the
"libpcap" header in "/usr/include", and thus weren't searching
"/usr/local/include" for "ucd-snmp/snmp.h" or "snmp/snmp.h", and thus
weren't finding them even if we'd installed the UCD SNMP package!).
Also, hopefully it won't cause problems on some other platform with some
other configuration of installed packages....
svn path=/trunk/; revision=940
SNMP dissection is enabled or not, so that if "register.c" was generated
by scanning a list of files that include "packet-snmp.c" even though
SNMP dissection isn't enabled (the standard "Makefile.in" and
"configure" script won't cause that to happen, but source distributions
such as BSD ports may be set up to do that), and thus includes a call to
"proto_register_snmp()", that won't cause the link to fail.
svn path=/trunk/; revision=931
all the "packet-XXX.c" files doesn't work with some "make"s; they seem
to pass only the first few names in the list to the shell, for some
reason.
Therefore, we use a script to generate the "register.c" file, and run
that script from the Makefile.
svn path=/trunk/; revision=930
"asn_parse_header()" and "snmp_constr_parse()" don't actually modify the
data to which their first arguments point - if so, we have bigger
problems; I have no reason to believe they would modify it...).
svn path=/trunk/; revision=921
Replace "add_to_conversation()" with:
"conversation_new()", which creates a new conversation, given
source and destination addresses and ports, and returns a
pointer to the structure for the conversation;
"find_conversation()", which tries to find a conversation for
given source and destination addresses and ports, and returns a
pointer to the structure for the conversation if found, and a
null pointer if not found.
Add a private data pointer field to the conversation structure, and have
"conversation_new()" take an argument that specifies what to set that
pointer to; that lets clients of the conversation code hang arbitrary
data off the conversation (e.g., a hash table of protocol requests and
replies, in case the protocol is a request/reply protocol wherein the
reply doesn't say what type of request it's a reply to, and you need
that information to dissect the reply).
svn path=/trunk/; revision=920
Print the fields of a DDP address as unsigned quantities.
The maximum length of the string for a DDP address is 13 characters
(plus a trailing '\0'); adjust the lengths of the buffers in
"atalk_addr_to_str()".
svn path=/trunk/; revision=912
either the corresponding string on success or NULL on failure, one
should use "match_strval()", rather than using "val_to_str()" with a
null format - "val_to_str()" uses the format if the lookup fails, so it
won't work correctly (e.g., it may drop core) if the format string is
NULL.
svn path=/trunk/; revision=910
structure to "dl_src"/"dl_dst", "net_src"/"net_dst", and "src"/"dst"
addresses, where an address is an address type, an address length in
bytes, and a pointer to that many bytes.
"dl_{src,dst}" are the link-layer source/destination; "net_{src,dst}"
are the network-layer source/destination; "{src,dst}" are the
source/destination from the highest of those two layers that we have in
the packet.
Add a port type to "packet_info" as well, specifying whether it's a TCP
or UDP port.
Don't set the address and port columns in the dissector functions; just
set the address and port members of the "packet_info" structure. Set
the columns in "fill_in_columns()"; this means that if we're showing
COL_{DEF,RES,UNRES}_SRC" or "COL_{DEF,RES,UNRES}_DST", we only generate
the string from "src" or "dst", we don't generate a string for the
link-layer address and then overwrite it with a string for the
network-layer address (generating those strings costs CPU).
Add support for "conversations", where a "conversation" is (at present)
a source and destination address and a source and destination port. (In
the future, we may support "conversations" above the transport layer,
e.g. a TFTP conversation, where the first packet goes from the client to
the TFTP server port, but the reply comes back from a different port,
and all subsequent packets go between the client address/port and the
server address/new port, or an NFS conversation, which might include
lock manager, status monitor, and mount packets, as well as NFS
packets.)
Currently, all we support is a call that takes the source and
destination address/port pairs, looks them up in a hash table, and:
if nothing is found, creates a new entry in the hash table, and
assigns it a unique 32-bit conversation ID, and returns that
conversation ID;
if an entry is found, returns its conversation ID.
Use that in the SMB and AFS code to keep track of individual SMB or AFS
conversations. We need to match up requests and replies, as, for
certain replies, the operation code for the request to which it's a
reply doesn't show up in the reply - you have to find the request with a
matching transaction ID. Transaction IDs are per-conversation, so the
hash table for requests should include a conversation ID and transaction
ID as the key.
This allows SMB and AFS decoders to handle IPv4 or IPv6 addresses
transparently (and should allow the SMB decoder to handle NetBIOS atop
other protocols as well, if the source and destination address and port
values in the "packet_info" structure are set appropriately).
In the "Follow TCP Connection" code, check to make sure that the
addresses are IPv4 addressses; ultimately, that code should be changed
to use the conversation code instead, which will let it handle IPv6
transparently.
svn path=/trunk/; revision=909
added misc. constants for parsing flags, and converting time
stamps;
added flags and primary sources explanations;
added function for converting time stamps;
improved item analysis;
new item definitions;
from Tomislav Vujec.
svn path=/trunk/; revision=908
print them with "%lu" and cast the result of "ntohl()" to "unsigned
long" (so as to cope with platforms where "ntohl()" returns a value with
an "int"-based type and platforms where it returns a value with a
"long"-sized type).
svn path=/trunk/; revision=907
than a command name of "ethereal-dump-fields", to decide whether to run
as normal Ethereal or to just dump out the list of fields that can be
used in a display filter.
This allows us to continue to make that check without doing the regular
command line flag parsing (which we don't want to do, as we don't want
to call "gtk_init()" before making that check, as "gtk_init()" tries to
open an X display, and some people want not to have to have X running in
order to build Ethereal, or want not to have Ethereal try to open an X
connection over a slow line if it's just going to print field names to
the standard output), without having to make a link to "../ethereal"
from the "doc" directory (said link couldn't be a hard link, as ATK
apparently disallows hard links between directories, and I have the
vague impression that a symbolic link might cause other problems).
svn path=/trunk/; revision=902
Gilbert Ramirez