GtkItemFactory for the item it's modifying, with NULL meaning "all
pop-up menus". Use the full path for the menu item in all such calls;
have separate calls for the main menu item and pop-up menu items as
necessary.
svn path=/trunk/; revision=7521
1. Add definitions for Novell defined Object ID's
2. Cleanup displayed information
3. Object ID's no longer displayed by default. To enable then set
option in the NDPS preferences to "Display NDPS Details"
4. Value Syntax no longer displayed by default. To enable then set
option in the NDPS preferences to "Display NDPS Details"
5. Utilize SPX End of Message within NDPS/SPX Fragment packets
6. Numerous Bug fixes
7. Add Print Program Function 0x23 (Add Event Profile 2)
8. Add Print Program Function 0x24 (List Event Profiles 2)
9. Create consolidation functions to elliminate redundant code
10. Remove some unused variable definitions
svn path=/trunk/; revision=7519
message box popped up if you try to add a new capture filter but haven't
specified a filter name or string, as there is no such button for
capture filters.
svn path=/trunk/; revision=7517
dissector - including the ONC RPC-over-TCP record marking code, which is
also used by NDMP.
That means that the NDMP dissector can, like the ONC RPC dissector, put
into the Info column items for all the NDMP messages dissected for a
frame; make it do so.
svn path=/trunk/; revision=7516
the protocol tree, and no other dissector for a DCE RPC-based protocol
does to itself - get rid of the code to do so here.
svn path=/trunk/; revision=7514
null) to the "fragment_items" structure, and don't pass that value into
"process_reassembled_data()", just have it use the value in the
"fragment_items" structure passed to it.
Make "process_reassembled_data()" capable of handling reassembly done by
"fragment_add_seq_check()", and use it in the ATP and 802.11 dissectors;
give them "reassembled_in" fields. Make "process_reassembled_data()"
handle only the case of a completed reassembly (fd_head != NULL) so that
we can use it in those dissectors without gunking the code up too much.
svn path=/trunk/; revision=7513
all of the frames that make it up, so Ethereal can show, for all but the
final frame, the frame in which it was reassembled. (Tethereal can't,
as it's a one-pass program.)
svn path=/trunk/; revision=7511
fragment having been added already. In protocols using the ONC
RPC-over-TCP record-marking mechanism (RPC-over-TCP and NDMP), there can
be more than one record-marking-layer fragment in a single TCP segment,
and thus can be more than one fragment in a frame being added to a given
higher-level packet.
svn path=/trunk/; revision=7508
issue for CLNP, with its 16-bit IDs, which could be duplicated in a
sufficiently large capture even if CLNP implementations don't
deliberately reuse IDs; less of an issue for IPv6, with its 32-bit IDs
and with its prohibition on reuse:
For every packet that is to be fragmented, the source node generates
an Identification value. The Identification must be different than
that of any other fragmented packet sent recently* with the same
Source Address and Destination Address. If a Routing header is
present, the Destination Address of concern is that of the final
destination.
* "recently" means within the maximum likely lifetime of a packet,
including transit time from source to destination and time spent
awaiting reassembly with other fragments of the same packet.
However, it is not required that a source node know the maximum
packet lifetime. Rather, it is assumed that the requirement can
be met by maintaining the Identification value as a simple, 32-
bit, "wrap-around" counter, incremented each time a packet must
be fragmented. It is an implementation choice whether to
maintain a single counter for the node or multiple counters,
e.g., one for each of the node's possible source addresses, or
one for each active (source address, destination address)
combination.
but perhaps we'll ultimately be able to get rid of the old
"fragment_add()" entirely and rename "fragment_add_check()" to
"fragment_add()").
svn path=/trunk/; revision=7507
for reassembled frames - in Tethereal, there's only one frame_data
structure used for all frames. Instead, use the frame number itself as
the key.
Add a "fragment_add_check()" routine, for fragments where there's a
fragment offset rather than a fragment sequence number, which does the
same sort of thing as "fragment_add_seq_check()" - i.e., once reassembly
is done, it puts the reassembled fragment into a separate hash table, so
that there're only incomplete reassemblies in the fragment hash table.
That's necessary in order to handle cases where the packet ID field can
be reused.
Use that routine for IPv4 fragment reassembly - IP IDs can be reused (in
fact, RFC 791 suggests that doing so might be a feature:
It is appropriate for some higher level protocols to choose the
identifier. For example, TCP protocol modules may retransmit an
identical TCP segment, and the probability for correct reception
would be enhanced if the retransmission carried the same identifier
as the original transmission since fragments of either datagram
could be used to construct a correct TCP segment.
and RFC 1122 says that it's permitted to do so, although it also says
"we believe that retransmitting the same Identification field is not
useful":
3.2.1.5 Identification: RFC-791 Section 3.2
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
the copy.
DISCUSSION:
Some Internet protocol experts have maintained that
when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
congested gateway might use the IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
fragments filling reassembly gaps, while other
mechanisms (e.g., TCP repacketizing upon
retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
useful. Also, a connectionless transport protocol like
UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
and, in any case, I've seen that in at least one capture, and it
confuses the current reassembly code).
Unfortunately, that means that fragments other than the last fragment
can't be tagged with the frame number in which the reassembly was done;
see the comment in packet-ip.c for a discussion of that problem.
svn path=/trunk/; revision=7506
entry for the reassembled packet; don't look at it when checking to see
if we've already seen a fragment (its "frame" field isn't initialized,
so we shouldn't check it in any case).
svn path=/trunk/; revision=7498
An RTP information type of 0 is an update.
The compatibility flags are a bunch of flag bits; show them as such.
Fix some bitfield strings.
Sequence numbers in RTP are 4 bytes, not 2 bytes.
svn path=/trunk/; revision=7494
SRTP requests don't look the way the stuff I found appears to say they
look.
Fix some incorrect uses of "tvb_get_ntohl()" to fetch 16-bit values to
use "tvb_get_ntohs()" instead.
Fix some strings for flag bits.
svn path=/trunk/; revision=7492
Add Vines Echo.
Add some additional class values.
Use the length field in the Vines IP header to set the length of the
packet.
Adjust the byte order of all multi-byte integer fields in the IPC and
SPP headers.
svn path=/trunk/; revision=7491
if the PDU was short.
This was most noticeable in NFS Read Replies not generating tap events and
thus NFS RTT statistics did not count the Read procedure.
svn path=/trunk/; revision=7490
called from the frame where the ip packet was reassembled instead of from each fragment.
For fragments, put [Reassembled in #xx] in the summary pane so it is easy
to see which fragments are successfully reassembled and which are not.
For fragments, add a "This fragment is reassembled in:xx" to the tree
pane so and make it FT_FRAMENUM so it is easy to jump top the reassembled ip packet.
svn path=/trunk/; revision=7489
Shuffle the routines for subprotocols of VINES ARP into numerical order
by protocol number.
The 32-bit net/16-bit subnet fields in the VINES IP header structure
doesn't work, as the net has to be aligned on a 32-bit boundary; replace
it with a 6-byte address field.
svn path=/trunk/; revision=7482
Show the meaning of most of the bits in the transport control field.
Show lengths, windows, sequence numbers, and the like in decimal (that's
how Sniffer Pro shows them).
svn path=/trunk/; revision=7479
This solves a problem introduced by the recent rewrite of dcerpc-over-smb
reassembly which caused the last fragment for each dcerpc pdu to be duplicated and flagged as overlapping fragment.
This
svn path=/trunk/; revision=7478
SPP packet type in the Info column rather than the Protocol column.
Give the Vines protocol number field a value_string table.
Nobody asks for the Vines IP dissector by name, so it doesn't have to be
registered by name.
svn path=/trunk/; revision=7477
in the packet when doing reassembly checks, as is done in other places
where we do TCP segment reassembly.
The return value of "tvb_reported_length_remaining()" can be negative -
it's a "gint"; assign it to a "gint", so that if we go past the end of
the packet in the main loop, we break out of that loop (and do so
elsewhere, just for cleanliness' sake).
Get rid the check in the loop to make sure we make no more than 20
iterations - all the routines that parse packets should either advance
the offset by at least one byte or return a "desegmentation required"
indication; the former means we make progress and eventually exit the
loop, the latter means we immediately exit the loop.
Use "int" variables, not "guint" variables, for packet offsets.
svn path=/trunk/; revision=7475
check, for each item, when it's past the end of the page before putting
it into the protocol tree, and advance the offset through the page as we
do so.
If the identifier codeset is ASCII, display the item as text rather than
as binary data.
svn path=/trunk/; revision=7473
Guy Harris