ashokn 2000/03/12 23:19:53 CST
Modified files:
. packet-rsvp.c
Log:
New workaround for not using (ulong *) to dereference memory in RSVP.
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@xxxxxxxxx>
To: gharris@xxxxxxxxxxxx
Cc: ethereal-dev@xxxxxxxx
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
Revision Changes Path
1.17 +17 -7 ethereal/packet-rsvp.c
