packets we have data.
Similar to oncrpc rtt stats smb rtt stats will also open a small window
where a filter string can be specified.
Only those packets matching the filter will be considered in calculating
the rtt statistics.
svn path=/trunk/; revision=7528
Make it possible to use subsecond granularity for the measurement intervals.
io,stat is updated to accept the interval to be specified with ms resolution.
Example
-z io,stat,0.001,smb
to generate 1ms statistics for all SMB traffic.
svn path=/trunk/; revision=7527
used for some other protocol.
Put in some information about an RMON draft that gives some information
about various protocol numbers in various protocols.
svn path=/trunk/; revision=7525
- fix the bug by dissecting the Flags field in RRO IPv4/IPv6/label sub-object
(The 1.80 version of packet-rsvp.c dissects the wrong field in a packet.)
- erase unnecessary commas when displaying RRO IPv4 sub-object
- add support for displaying the error value, written explanation in ERROR
object
- add support for draft-ietf-mpls-nodeid-subobject-00.txt
svn path=/trunk/; revision=7524
"{Match,Prepare}" pop-up menu items, should be enabled only if we have a
field selected.
The main menu item "/Tools/Statistics" should be enabled only if we have
a capture.
The packet list "Show Packet In New Window" pop-up menu item should be
enabled only if there's a packet selected.
svn path=/trunk/; revision=7523
the submenu widget, not the menu item widget. For items with submenus,
set the sensitivity on the menu item widget, not the submenu widget, so
that the menu item is grayed out when not sensitive.
svn path=/trunk/; revision=7522
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
Ronnie Sahlberg