Wireshark · Ethereal-dev: [Ethereal-dev] RE: [Ethereal-users] BUG: 802.1ab (a.k.a LLDP) - Chassis IDTLV = IPAddress

["STAN Knap" <sknap1@xxxxxxxxxx>]

Title: 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 >>