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
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
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
This change allows you to add a new packet-*.c file and not cause a
recompilation of everything that #include's packet.h
Add the plugin_api.[ch] files ot the plugins/Makefile.am packaging list.
Add #define YY_NO_UNPUT 1 to the lex source so that the yyunput symbol
is not defined, squelching a compiler complaint when compiling the generated
C file.
svn path=/trunk/; revision=1637
"fd->cap_len" for the frame length - or to use macros such as
"BYTES_ARE_IN_FRAME()", "IS_DATA_IN_FRAME()", and "END_OF_FRAME", which
use "pi.captured_len" - so that they correctly handle frames where the
actual data length of the packet is less than the size of the raw frame,
e.g. with encapsulations such as ISL.
svn path=/trunk/; revision=1530
dynamically-assigned "ett_" integer values, assigned by
"proto_register_subtree_array()"; this:
obviates the need to update "packet.h" whenever you add a new
subtree type - you only have to add a call to
"proto_register_subtree_array()" to a "register" routine and an
array of pointers to "ett_", if they're not already there, and
add a pointer to the new "ett_" variable to the array, if they
are there;
would allow run-time-loaded dissectors to allocate subtree types
when they're loaded.
svn path=/trunk/; revision=1043
the base for numbers to be displayed in, bitmasks for bitfields, and blurbs
(which are one or two sentences describing the field).
proto_tree_add*() routines now automatically handle bitfields. You tell
it which header field you are adding, and just pass it the value of the
entire field, and the proto_tree routines will do the masking and shifting
for you.
This means that bitfields are more naturally filtered via dfilter now.
Added Phil Techau's support for signed integers in dfilters/proto_tree.
Added the beginning of the SNA dissector. It's not complete, but I'm
committing it now because it has example after example of how to use
bitfields with the new header_field_info struct and proto_tree routines.
It was the impetus to change how header_field_info works.
svn path=/trunk/; revision=815
but does not link. Perhaps someone who understands the MS tools can help
out. I made it link a few months ago, but with different version of glib/gtk+.
I can't remember how I made it link.
Most of the compatibility issues were resolved with adding
#ifdef HAVE_UNISTD_H the the source code. Please be sure to add this to all
future code.
svn path=/trunk/; revision=359
mechanism that is built into ethereal. Wiretap is now used to read all
file formats. Libpcap is used only for capturing.
svn path=/trunk/; revision=342
Guy Harris