proto_tree_add_protocol_format(). I had converted them incorrectly
when I changed them from their original proto_tree_add_item_format().
svn path=/trunk/; revision=1717
cross-checking, and by replacing "proto_tree_add_item_format()" by
multiple routines to add items of various types.
Make the arguments of "proto_tree_add_bytes_format()" and
"proto_tree_add_string_format()" that specify the bytes or the string be
"const" pointers, so that one can pass a "const" pointer without
complaints from the compiler.
Squelch a (bogus, but the compiler isn't in a position to know that)
complaint about an uninitialized variable.
svn path=/trunk/; revision=1716
for mpls.label and replace them with proto_tree_add_uint_format() and
proto_tree_add_item(). In the mpls proto_registration, associated
the val_string with mpls.label.
svn path=/trunk/; revision=1715
Here's the email I wrote to Guy with info on this:
Subject: Re: [ethereal-dev] Checked in support for MPLS
From: Ashok Narayanan <ashokn@cisco.com>
To: gharris@flashcom.net
Cc: ethereal-dev@zing.org
Date: Mon, 13 Mar 2000 00:10:38 -0500
X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Biscayne)
Guy,
> The code in that was fetching some fields by casting pointers into the
> packet to "ulong *" and dereferencing the resulting pointer - this is
> bad for three reasons:
>
> "ulong" is not a system-declared data type on all platforms
> (it's not on FreeBSD 3.4, at least, for example);
>
> casting an arbitrary pointer into a frame to point to something
> longer than 1 byte, and dereferencing it, is dangerous, as
> there's no guarantee that said pointer is properly aligned on
> machines that require alignment (such as SPARC, Alpha, and MIPS,
> and possibly at least some other RISC processors);
I agree with both these points.
> the data in an RSVP packet is presumably big-endian in any case,
> so you should use "pntohl()" to access it, rather than just
> blithely dereferencing it;
This is the exact problem which a direct cast attempts to work
around. A tree of type FT_IPv4 apparently has a network-to-host
conversion built into the proto_tree_add_item call. When you added the
pntohl, you inserted a second network-to-host conversion - the result
is that all the IP addresses are reversed. Here's an excerpt from
tethereal....
1) ~/sniffer/test/ethereal> ./tethereal -n -r ../../sniffs/mpls_te.cap -R 'rsvp.path'
3 8.024159 17.3.3.3 -> 16.2.2.2 RSVP PATH Message
15 31.589751 17.3.3.3 -> 16.2.2.2 RSVP PATH Message
22 47.072205 17.3.3.3 -> 16.2.2.2 RSVP PATH Message
<snip>
2) ~/sniffer/test/ethereal> ./tethereal -n -r ../../sniffs/mpls_te.cap -R 'rsvp.path' -V
Frame 3 (306 on wire, 306 captured)
<snip>
Ethernet II
<snip>
Internet Protocol
<snip>
Source: 17.3.3.3 (17.3.3.3)
Destination: 16.2.2.2 (16.2.2.2) <======== Destination is 16.2.2.2
Options: (4 bytes)
Unknown (0x94) (4 bytes)
Resource ReserVation Protocol (RSVP)
RSVP Header
RSVP Version: 1
Flags: 00
Message Type: PATH Message (1)
Message Checksum
Sending TTL: 254
Message length: 264
SESSION: 1
Length: 16
Class number: 1 - SESSION object
C-type: 7 - IPv4 LSP
Destination address: 2.2.2.16 (2.2.2.16) <======== Destination is reversed
Tunnel ID: 1
Extended tunnel ID: 285410051
I'm looking around in the filtering code (which I don't really
understand), to see if I can find a quick fix to the problem. If you
or Gilbert knows what's happening, you may want to fix it. But as it
stands now, using pntohl() in a proto_tree_add_item() call is broken.
A slightly better workaround is to do something like this:
memcpy(&ip_addr, pd[offset2], 4);
proto_tree_add_item(....., ip_addr);
but this is still ugly. I'll implement this workaround and check in
the code (since as it stands now, RSVP decoding is broken). However,
the underlying issue needs to be resolved.
-Ashok
svn path=/trunk/; revision=1714
proto_tree_add_protocol_format()
proto_tree_add_uint_format()
proto_tree_add_ipxnet_format()
proto_tree_add_ipv4_format()
proto_tree_add_ipv6_format()
proto_tree_add_bytes_format()
proto_tree_add_string_format()
proto_tree_add_ether_format()
proto_tree_add_time_format()
proto_tree_add_double_format()
proto_tree_add_boolean_format()
If using GCC 2.x, we can check the print-format against the variable args
passed in. Regardless of compiler, we can now check at run-time that the
field type passed into the function corresponds to what that function
expects (FT_UINT, FT_BOOLEAN, etc.)
Note that proto_tree_add_protocol_format() does not require a value field,
since the value of a protocol is always NULL. It's more intuitive w/o the
vestigial argument.
Fixed a proto_tree_add_item_format-related bug in packet-isis-hello.c
Fixed a variable usage bug in packet-v120.c. (ett_* was used instead of hf_*)
Checked in Guy's fix for the function declearation for proto_tree_add_text()
and proto_tree_add_notext().
svn path=/trunk/; revision=1713
the stuff we write to the temporary file, so don't bother writing it.
Keep track of the two sides of the TCP stream by keeping track of the
source address *and* port, so that we correctly handle connections
between two ports on the same machine.
svn path=/trunk/; revision=1712
the row for that frame, and using that to get the frame for the selected
row in "select_packet()", revives the crash caused by the GtkCList
selecting the first row added to the list as it's added, i.e. before we
get a chance to set the data for that row, in this case.
Introduce a workaround for this instance of that crash.
svn path=/trunk/; revision=1711
Get rid of the paragraph about C++-style comments at the beginning of
the document, as it also appears in section 1.1.1 "Comments".
Add a section on how to extract data from packets, which explains the
"pd" and "offset" arguments to a dissector, and notes that you should
not just blithely cast pointers into the packet data to 2-byte or 4-byte
integral types and dereference them, as the pointer may not be aligned,
and the field may not have the same byte order as the processor on which
Ethereal is running (in fact, it's probably *guaranteed* not to on at
least one machine, as Ethereal runs on both big-endian and little-endian
platforms...).
svn path=/trunk/; revision=1710
casting an arbitrary pointer into a frame to point to something
longer than 1 byte, and dereferencing it, is dangerous, as
there's no guarantee that said pointer is properly aligned on
machines that require alignment;
the data in an RSVP packet is presumably big-endian in any case,
so you should use "pntohl()" to access it, rather than just
blithely dereferencing it;
so use "pntohl()" to extract fields from an RSVP packet rather than
casting pointers to "ulong *" and dereferencing them.
svn path=/trunk/; revision=1709
is being added
- MPLS Traffic Engineering extensions for RSVP
- MPLS-encapsulated IP packets on Ethernet
- OSPF Extensions for MPLS (including generic opaque LSA
support for OSPF)
THe following features will be committed at a later date (if I get around
to writing them :-)
- Label Distribution Protocol (LDP)
- IS-IS Extensions for MPLS
svn path=/trunk/; revision=1707
which means we're already doing a "do something to the last row in the
packet list" operation on every frame we add to the list, so adding a
call to "gtk_clist_set_row_data()" won't make matters worse.
In addition, we already set one column in a row on a "change time
format" operation, so finding the row for a frame by calling
"gtk_clist_find_row_from_data()" doesn't turn a constant-time operation
into a linear-time operation, it just cranks the proportionality
constant up - it was quadratic before, alas, and it's still quadratic.
Adding calls to "gtk_clist_find_row_from_data()" to the "Find Frame" and
"Go To Frame" code does add an extra linear operation there, but those
operations shouldn't be common - and "Go To Frame", going to the last
frame on an ~100,000-frame big capture file, was quick, at least on my
450 MHz Pentium II machine, so maybe it won't be too bad.
And "select_packet()" either has to search the frame table for the frame
with the specified row number, or has to call "gtk_clist_get_row_data()"
to do that - the first is linear in the position of the frame in the
frame table, and the latter is linear in its position in the CList, and
the latter is less than or equal to the former, so the only thing making
it worse would be a change in the proportionality constant.
So it probably won't hurt performance by much.
Furthermore, if we add the ability to sort the display on an arbitrary
column, or to delete frames from the display - both of which are in the
wish list - storing the row number of the frame in the "frame_data"
structure won't necessarily work, as the row number can change out from
under us.
Therefore, reinstate the old way of doing things, where we associate
with each row a pointer to the "frame_data" structure for the row, using
"gtk_clist_set_row_data()".
svn path=/trunk/; revision=1703
they get from the packets are 16-bit unsigned quantities, which fit
comfortable within an "int" on all platforms we support. That
eliminates the some additional format/argument mismatches.
svn path=/trunk/; revision=1700
Reorganize "icqv5_cmd_send_text_code()" a bit so that it only puts an
item into the tree if it's present in the packet.
svn path=/trunk/; revision=1697
a fashion as not to cause GCC to whine about format/argument mismatches
if "proto.h" is tweaked to declare "proto_tree_add_text()" with an
"__attribute__((format (printf, ...))" clause.
svn path=/trunk/; revision=1693
"save session" feature in many Windows-based telnet apps. CRT, by VanDyke,
in particular, will put in newlines at 80 columns.
svn path=/trunk/; revision=1692
switch (xxx) {
...
default:
}
but Microsoft Visual C++ 6.0 insists that there be a statement following
the "default:" label, and other compilers may do the same - put in a
"break;" statement.
svn path=/trunk/; revision=1681
Ethernet; used for communication with Siemens S5 PLC's over Ethernet),
and his changes to display OSI COTP TSAPs that consist solely of
printable characters as text rather than as hex data and to decode the
version number resource in COTP.
svn path=/trunk/; revision=1677
the "Follow TCP Stream" displays; that means we can use the same GTK+
calls to set the scrollbar placement on them that is used to set it on
other widgets.
Keep a list of all the GtkScrolledWindows whose scrollbar placement we
control with the GUI preference item for that, and change them all when
the GUI preference item is changed (which means that the GUI preference
item now applies to the "Follow TCP Stream" window as well as to the
hex/ASCII panes).
svn path=/trunk/; revision=1676
destroy the data structure for that window, rather than doing so when
the "tree-unselect-row" signal catcher is unhooked from the tree view.
svn path=/trunk/; revision=1672
Gilbert Ramirez