This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Change a capture field. Specifically, change lldp.port.subtype == 3 to lldp.port.subtype == 5

0

Let me preface this by saying I am very new to Wireshark. That said what I want to do is to capture LLDP packets and display the name of the switchport interface. I believe I have narrowed it down to this field...

lldp.port.subtype

This field is defaulted in Wireshark to be...

lldp.port.subtype == 3

Which captures the MAC Address of the switchport. I want to capture the Interface name of the switchport which would require changing the field to...

lldp.port.subtype == 5

Which would give me the Interface name. How do I do this? Any help would be much appreciated.

asked 18 Nov '16, 10:08

BSB's gravatar image

BSB
6112
accept rate: 0%

Ok. I did a 4 minute capture of the network with the capture filter "ether proto 0x88cc". I uploaded it to Cloudshark. How do I attach it here? I hope this gives you enough information to figure out what is going on. Thank you again for your help.

(23 Nov '16, 10:47) BSB

2 Answers:

0

This field is defaulted in Wireshark to be...

It is not any default setting of Wireshark, it is what is really sent over the wire. Wireshark has captured the frame, and found an internally structured field "Port ID" in it, and the "port ID subtype" inside bears a value of 3. So Wireshark accordingly dissects the remaining bytes of "Port ID" as MAC address.

So to see a switch port name in the packet, the switch would have to populate the field that way.

The information you seek may be available in some other field, such as "port description".

answered 18 Nov '16, 10:34

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

edited 18 Nov '16, 10:39

Sindy,

Thank you for your quick response. All due respect but you are wrong. I have two programs that can capture LLDP packets.
1. Wireshark obviously and
2. lldp on the Linux OS, which I can query using lldpcli.

Wireshark gives me the below output...

Port Subtype = MAC address, Id: 2c:23:3a:3d:01:7a
    0000 010. .... .... = TLV Type: Port Id (2)
    .... ...0 0000 0111 = TLV Length: 7
    Port Id Subtype: MAC address (3)
    Port Id: HewlettP_3d:01:7a (2c:23:3a:3d:01:7a)
Port Description = User-Phone
    0000 100. .... .... = TLV Type: Port Description (4)
    .... ...0 0000 1010 = TLV Length: 10
     Port Description: User-Phone

lldpcli gives me this output...

Interface:    eth0, via: LLDP, RID: 1, Time: 0 day, 00:00:54
  Chassis: 
    ChassisID:    mac 2c:23:3a:3d:03:b1
    SysName:      HQ-BLD2BCSW55IRF_01
    SysDescr:     HP Comware Platform Software, Software Version 5.20.99 Release 5501P25
                  HP 5500-48G-PoE+-4SFP HI Switch with 2 Interface Slots
                  Copyright (c) 2010-2016 Hewlett Packard Enterprise Development LP
    MgmtIP:       10.10.33.254
    Capability:   Bridge, on
    Capability:   Router, on
  Port:
    PortID:       ifname GigabitEthernet1/0/18
    PortDescr:    User-Phone

If the switch only sent the LLDP packets one way then both programs would have to have
the same output. As you can see Wireshark lists port id as...

Port Id Subtype: MAC address (3)
    Port Id: HewlettP_3d:01:7a (2c:23:3a:3d:01:7a)

lldpcli lists port id as...

PortID:       ifname GigabitEthernet1/0/18
PortDescr:    User-Phone

This is information collected by these two different software packages on the same Ethernet
cable going to the same port on the same switch. Therefore there are 2 possibilities, one
Wireshark and lldpcli are asking the switch for different results, or the packet that is recieved
is decoded in one way by Wireshark and another way by lldpcli. Which brings me back to the
orginal question. How do I get Wireshark to ask or decode the packet for the Interface name
instead of the MAC address? The switch is obviously supplying both pieces of information.

(18 Nov '16, 16:14) BSB

We would have to see the capture file (the raw capture file, not Wireshark's dissection of it) in order to determine what the issue is here.

(18 Nov '16, 18:13) Guy Harris ♦♦

As @Guy Harris says, please capture according to the instruction below and then follow Step 3 of this capture file publishing tutorial so that we are all at the same page. For maximum possible privacy while preserving the information necessary for analysis, you can apply a display filter lldp and then use File->Export Specified Packets, choose All packets and Displayed to save only the LLDP frames. Or, instead, you may capture using a capture filter ether[12:2] = 0x88cc to avoid capturing any other kind of traffic.

But first let me say more clearly what I said before: Wireshark is a passive listener, it does not send any packets on its own. So what was on the wire, regardless how it got there, has been captured and dissected. It would be hard for me to believe that there was an error in capturing, I would have much less problems to believe that there was an error in dissection. But as Wireshark shows Port Id Subtype: MAC address (3) and the following six bytes cannot be read as ASCII "Gigabi" or any other ASCII string making sense as port description (,#:= which is the ASCII representation of 2c:23:3a:3d doesn't), while they do represent a valid MAC address whose beginning is similar to the device MAC shown by the lldpcli, I'd say both capturing and dissection work fine.

So please try to capture for longer time and then (or already during capturing) use a display filter lldp.port.subtype == 5 to show only LLDP frames which do contain port name in the Port ID field; there may be none, though.

Then, start another capture, and while capturing, issue the update command of the lldpcli. Now the same display filter as above, lldp.port.subtype == 5, should definitely show some matching LLDP frames, as the lldpd cannot source the information about the port name from anywhere else but the incoming frames.

(19 Nov '16, 00:10) sindy

BTW, what I could imagine would be that the frames actually matching lldp.port.subtype == 5 are present in the capture but dissected wrong, causing the subfield lldp.port.subtype not to be added to the dissection tree. So instead of the display filter expression above, use another one to find such frames: lldp and !(lldp.port.subtype == 3).

(19 Nov '16, 02:09) sindy

Ahh... That explains some things. As I said I am new to Wireshark and therefore prone to many mistakes. Let me attempt to make the scans you requested and then I will post them here. And I see as you explain it Wireshark does not send any packets it just listens. Ahh, so the problem must be what I called in "decoding" what you call "dissection" so dissection is the proper name for what is going on? And your explaination makes sense. Wireshark gets both pieces of information but only the MAC address is being dissected correctly. At least that is your guess currently. Let me capture some scans and post them so you can get a better look of what is going on. Thank you for your help so far!

(21 Nov '16, 11:49) BSB

Ok. I did a 4 minute capture of the network with the capture filter "ether proto 0x88cc". I uploaded it to Cloudshark. How do I attach it here? I hope this gives you enough information to figure out what is going on. Thank you again for your help.

(22 Nov '16, 13:58) BSB

@BSB: Simply paste the publicly accessible link in a comment.

(22 Nov '16, 14:47) Jaap ♦

Ok. I did a 4 minute capture of the network with the capture filter "ether proto 0x88cc". I uploaded it to Cloudshark. How do I attach it here? I hope this gives you enough information to figure out what is going on. Thank you again for your help.

(23 Nov '16, 09:41) BSB

How do I attach it here?

You don't; this site doesn't support arbitrary attachments. Instead, to quote @Jaap's answer when you previously asked this question, you "simply paste the publicly accessible link in a comment."

(23 Nov '16, 10:43) Guy Harris ♦♦

Alright. Sorry for the multiple postings. Getting used to this website and I posted 3 copies of the same post by mistake. Ok, post the publicly accessible link. @LLDP Scan If I did this correctly you should get to my scan.

(23 Nov '16, 11:00) BSB
showing 5 of 10 show 5 more comments

0

OK, so, in that capture, here's where the various lldpcli values come from:

 ChassisID: mac 2c:23:3a:3d:03:b1:

That comes from the first TLV, "Chassis Subtype".

 SysName: HQ-BLD2BCSW55IRF_01

That comes from the "System Name" TLV.

 SysDescr: HP Comware Platform Software, Software Version 5.20.99 Release 5501P25
                   HP 5500-48G-PoE+-4SFP HI Switch with 2 Interface Slots
                   Copyright (c) 2010-2016 Hewlett Packard Enterprise Development LP

That comes from the "System Description" TLV.

MgmtIP:       10.10.33.254

That comes from the "Management Address" TLV.

Capability:   Bridge, on
Capability:   Router, on

Those come from the "Capabilities" TLV.

Port:
  PortID:       ifname GigabitEthernet1/0/18
  PortDescr:    User-Phone

The PortID isn't in the capture; the PortDescr comes from the "Port Description" TLV.

It appears that Wireshark is dissecting the packet entirely correctly, and "ifname GigabitEthernet1/0/18" simply does not appear in the packets at all.

The lldpcli man page says

   configure [ports ethX [,...]] lldp portidsubtype local value
   [description description]
     Force port ID subtype. By default, lldpd will use the MAC address
     as port identifier and the interface name as port description,
     unless the interface has an alias. In this case, the interface 
     name will be used as port identifier and the description will be 
     the interface alias. With this command, you can force the port
     identifier to be the interface name (with ifname), the MAC
     address (with macaddress) or a local value (with value).  In the 
     latest case, the local value should be provided.  Optionally, a
     port description can also be provided after the local value.</code></pre><p>so it may be that lldpcli is getting the port ID from a configuration file rather than from an LLDP packet.</p></div><div class="answer-controls post-controls"></div><div class="post-update-info-container"><div class="post-update-info post-update-info-user"><p>answered <strong>23 Nov '16, 11:29</strong></p><img src="https://secure.gravatar.com/avatar/f93de7000747ab5efb5acd3034b2ebd7?s=32&amp;d=identicon&amp;r=g" class="gravatar" width="32" height="32" alt="Guy%20Harris&#39;s gravatar image" /><p><span>Guy Harris ♦♦</span><br />

17.4k335196
accept rate: 19%

@Guy Harris, are you sure that the lldpcli configure command affects the way how received LLDP frames are interpreted? I read it as choice of how the lldpd populates the LLDP frames it sends.

Basically I cannot even see any purpose in configuring a translation of the received values.

So @BSB, I suspect that if you would capture again without a capture filter, you would find some SNMP GETs which the lldpd would send to the management address found in the LLDP frames, in order to fetch the port names from the MIB of the switch. And that you would find the port name in the SNMP response of the switch. And it may well be that such SNMP GET is not sent each time a LLDP frame is received but only at the first occurrence of a yet unseen (Chassis Id, Port Id) tuple, so you may have to disconnect the cable and re-connect it; ideally, you’d do that at the switch side and connect the cable to another port, so that the lldpd has a reason to fetch additional information.

Quoting from lldpd’s home page:

-x Enable SNMP subagent. With this option, lldpd will enable an
SNMP subagent using AgentX protocol. This allows you to get
information about local system and remote systems through SNMP.
(23 Nov ‘16, 11:46) sindy

WOW. Not only do you give a fast response, that was very in depth and well written. It would have taken me months to figure that out. Thank you for that very informative response. So Wireshark only listens, collects, dissects and then displays the information of the packet received. Apparently lldpcli uses snmp to query the switch for the port information which it then presents as part of the lldpcli display. I see. Hmm… Ok so according to the rest of your explanation if I just run a capture without any capture filter I “might” find the “port id” in a SNMP packet. But definitely NOT in an LLDP packet. Am I correct in my read of your explanation?

(23 Nov ‘16, 12:09) BSB

That’s what I had in mind, yes. As @Guy Harris has pointed out, and as a display filter frame contains “GigabitEthernet” confirms by not matching any of the frames in the capture you’ve published, the “human-readable” port name shown by the lldpcli has not arrived via LLDP.

So it must have been obtained some other way, and the SNMP way is the most logical one, due to the intrinsically tight relationship between LLDP and SNMP.

(23 Nov ‘16, 13:01) sindy

Well I thank you both, Guy Harris and Sindy, for answering my question far faster than I had imagined. And for answering in a form I could understand. I greatly appreciate your time. So to get my information I need to move on to finding a snmp software that I can use on windows 10 to query the switch for the port id. Just taking a shot in the dark, you wouldn’t happen to know of any good snmp software by chance would you?

(23 Nov ‘16, 13:48) BSB