I
have checked in a fix.
Brg
Anders
-----Ursprungligt meddelande-----
Från:
ethereal-dev-bounces@xxxxxxxxxxxx [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] För STAN Knap
Skickat: den 19 januari 2006 15:30
Till: Jim Young;
ethereal-dev@xxxxxxxxxxxx
Ämne: [Ethereal-dev] RE:
[Ethereal-users] BUG: 802.1ab (a.k.a LLDP) -Chassis IDTLV = IPAddress
Thank you Jim for taking an action
on this issue.
In case somebody wants to verify the IANA Address Family Numbers one can
get them from this link:
http://www.iana.org/assignments/ianaaddressfamilynumbers-mib
Thanks and regards,
Stan
-----Original Message-----
From: Jim Young [mailto:sysjhy@xxxxxxxxxxxxxxx]
Sent: Thursday, January 19, 2006 12:00 AM
To: ethereal-dev@xxxxxxxxxxxx
Cc: Knap, STAN [BVW:0000:EXCH]
Subject: RE: [Ethereal-users] BUG: 802.1ab (a.k.a LLDP) - Chassis IDTLV
= IPAddress
Hello Anders,
> anders.broman@xxxxxxxxxxxx
01/17/06 12:19 PM >>>
> Hi,
> Can you supply a small trace to verify any patch with?
>> On Behalf Of STAN Knap
>> Sent: den 17 januari 2006 17:16
[snip]
>> Namely, it considers the phone's Chassis ID TLV invalid and
stops
>> decoding the rest of the frame. Since the Chassis ID TLV is the
first
>> in the frame, no useful decoding is generated.
I constructed (by hand) a minimal
LLDPDU containing just the four
mandatory TLVs. In the sample LLDPDU, I encoded both the
Chassis ID TLV with a subtype 5 (Network Address) and the
Port ID TLV with a subtype 4 (Network Address). I then
encoded
the Network Address components according to the rules defined in
the LLDP spec, i.e. that the byte immediately following the Chassis
ID subtype and the Port ID subtype should indicate the "IANA
Network Address Family" and then be followed by the octets that
represent the actual network address. For an IPv4 address the
IANA Network address family code would have a value of 1 (as Stan
wrote) and then be followed by the four octets that comprise an
IPv4 address.
So if we start with the following:
tlv_type =
1;
/* Chassis_id */
tlv_length =
6;
/* Length of TLV Info string */
chassis_id_subtype = 5; /* Network Address */
iana_addr_family = 1; /* IPv4
Address */
ipv4_addr = 10.1.1.4;
I believe that the encoded LLDP
Chassis ID TLV would appear as
follows:
02 06 05 01 0a 01 01 04
And if we start with:
tlv_type =
2;
/* Port_id */
tlv_length =
6;
/* Length of TLV Info string */
port_id_subtype = 4; /*
Network Address */
iana_addr_family = 1; /* IPv4
Address */
ipv4_addr = 10.1.1.5;
I believe that the encoded LLDP Port
ID TLV would appear as
follows:
04 06 04 01 0a 01 01 05
I've attached a sample trace file
containing this minimal LLDPDU
as the file "lldp.ip.ip.pcap".
As Stan reported, when Ethereal
tries to parse a TLV such as the
example above, it aborts the dissection and reports an invalid
length error.
I've looked at the packet-lldp.c source
and see at least three
"problems":
1) When parsing a Chassis ID
with a subtype of 5 ("network address") the current source does not
expect (nor does it test for) the IANA
network address family byte.
The current packet-lldp.c dissector
assumes that a "network address" represents an IPv4 or IPv6
address
if the reported TLV length is 5 or 17 respectively. This
assumption is
false. If the subtype value is 5 (network address) then the
subtype
byte will be followed by an IANA network address family octet.
Immediately following the IANA network address family octet are the
octets that represent the network address. An IANA network address
family value of 1 indicates an IPv4 address. An IANA network
address
family value of 2 indicates an IPv6 address.
Since there are 22 other possible
(but perhaps less likely Network
Address values defined as well), I've included all the possible IANA
Network Address values in the attachment
"ianaNetworkAddressValues.c".
2) This same defect is present
in the Port ID TLV which also supports
a Network Address subtype. In the Port ID TLV case, the Network
Address is indicated when the Port ID subtype is 4. Whatever fix
is
implemented for the Chassis ID subtype 5 will also need to be applied
to the case of Port ID subtype 4.
3) Because of the design of
the LLDP TLV header, it should be possible to continue dissecting additional
TLVs even if there is some assumed problem with the current TLV. In other
words, the dissection of the current LLDP packet does not necessarily have to
abort because of a problem like the one detected above.
If nobody else submits a patch I'll
try to submit my own fix for issues
#1 and #2 sometime (late) next week.
In the meantime I hope someone finds
this information and/or the
attachments useful.
Best regards,
Jim Young
<< File: lldp.ip.ip.pcap
>> << File: ianaNetworkAddressValues.c >>
