["Jim Young" <sysjhy@xxxxxxxxxxxxxxx>]

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

Attachment: lldp.ip.ip.pcap
Description: Binary data

Attachment: ianaNetworkAddressValues.c
Description: Binary data