check whether the two packets are going in the same direction in the
same conversation fails, check whether the two packets are going in
opposite directions in the same conversation.
svn path=/trunk/; revision=1014
Added proto_registrar_get_name routine to proto.c to retrieve the name
of particular proto_tree field.
Added dissect_rpc_string_item to packet-rpc.c. This routine does the same
thing as dissect_rpc_string, except it takes a hfindex of a
proto_tree item instead of a name. It uses the p_r_get_name call
to get the name, and adds the actual string content as a hidden
field (so that the subtree highlights the entire data area - length,
data, and padding). There is only one call to dissect_rpc_string, so
I believe that this routine should replace it.
svn path=/trunk/; revision=1011
header, under the assumption that the address field was two octets.
It should return the length of the *control* field, and leave it up to
its caller to add in the length of the address field. (The address
field appears to be one byte in SNA, not two bytes.)
svn path=/trunk/; revision=1006
colors.c wasn't freeing path in one place
main.c wasn't freeing rc_file
the frame_buffer fix in wtap.c didn't clear everything.
svn path=/trunk/; revision=1001
and aligned g_malloc calls with g_free calls (i.e, we no longer mix-and-match
C-library malloc with GLIB g_free, and vice-versa).
svn path=/trunk/; revision=1000
portmap
ypserv
ypxfr
ypserv
bootparams
Stubs currently just map procedure numbers to names. I'll add some more
decoding of the actual procedure call/reply contents eventually.
svn path=/trunk/; revision=998
of the "libpcap" patch that changes the per-packet header but not the
magic number - it seems to work on at least one capture file I tried it
on.
Give the modified "libpcap" format a WTAP_FILE type of its own (so that,
in the future, we could support writing captures out in that format,
possibly).
svn path=/trunk/; revision=987
Kuznetsov's modified "libpcap" *as long as you have the ss990915 or
later patch*; the 990417 patch, alas, changes the per-packet header but
*doesn't* change the magic number, so you can't just look at the magic
number to see that it's Not Standard Libpcap. (Even more unfortunately,
Red Hat appears to have picked up *that* patch for Red Hat 6.1; I've
filed bug 6773 with Bugzilla on their site - hopefully, if I'm not
misremembering the RH 6.1 code I've seen, and they really *did* pick up
the older patch, they'll fix it ASAP to use the new magic number, and
will make updates available.)
svn path=/trunk/; revision=986
filter to search forward or backward in the list of displayed frames for
a matching frame.
When filtering the display, readjust the display to show the "current"
frame if it passed the display filter. When a file is read in, the
first frame becomes the "current" frame; when a frame is selected, it
becomes the "current" frame, and remains so *even if you unselect it*,
until another frame is selected.
Select the first frame when a file is read in.
Disable most of the "Display" and "Tools" menu items if there's no
current capture file, and enable the relevant ones if there is.
svn path=/trunk/; revision=983
filter to search forward or backward in the list of displayed frames for
a matching frame.
When filtering the display, readjust the display to show the "current"
frame if it passed the display filter. When a file is read in, the
first frame becomes the "current" frame; when a frame is selected, it
becomes the "current" frame, and remains so *even if you unselect it*,
until another frame is selected.
Select the first frame when a file is read in.
Disable most of the "Display" and "Tools" menu items if there's no
current capture file, and enable the relevant ones if there is.
svn path=/trunk/; revision=982
- separate tree for each message
- added some comments
- merged my code for OPEN message, mainly just terminology updates
- searched all RFCs and defined known attributes
from: Greg Hankins <gregh@cc.gatech.edu>
svn path=/trunk/; revision=979
Define the hardware type, protocol type, and opcode values fields as
enums.
Dissect the addresses the same way the ARP dissector does, so that we
don't completely give up if the hardware addresses aren't 6-byte
Ethernet/Token Ring addresses or the protocol addresses aren't 4-byte
Appletalk IDs.
svn path=/trunk/; revision=972
appears to be the case on AIX 4.3.2 - it defines BIG_ENDIAN or
LITTLE_ENDIAN differently from the way "global.h" defines them, and also
defines BYTE_ORDER, we don't get a compiler warning - instead,
"global.h" refrains from defining them (as BYTE_ORDER is defined).
svn path=/trunk/; revision=970
quite possibly other UNIX-flavored OSes), in order to declare "ntohs()"
and the like. Put the include back (I guess we could include "global.h"
after including it, or move the byte-order stuff into a separate header
file and include *that* after <netinet.h>, in order to squelch the
complaints somebody saw compiling on AIX).
svn path=/trunk/; revision=969
<sys/machine.h> to be included (presumably to define the machine's byte
order, to declare the "ntoh" and "hton" routines/macros correctly),
which causes BIG_ENDIAN and LITTLE_ENDIAN to be defined, but that's done
after we've included "globals.h", so they're already defined, and the
compiler complains. We don't need it (at least not on FreeBSD).
svn path=/trunk/; revision=967
compiler warning because it was also defined by <netinet/in.h>, and
we're not using it.
Don't define IPV6_VERSION, either.
svn path=/trunk/; revision=966
Guy Harris