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 |
2 Answers:
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 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. Wireshark gives me the below output... lldpcli gives me this output... If the switch only sent the LLDP packets one way then both programs would have to have lldpcli lists port id as... This is information collected by these two different software packages on the same Ethernet (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 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 So please try to capture for longer time and then (or already during capturing) use a display filter Then, start another capture, and while capturing, issue the (19 Nov '16, 00:10) sindy BTW, what I could imagine would be that the frames actually matching (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
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 |
OK, so, in that capture, here's where the various lldpcli values come from: That comes from the first TLV, "Chassis Subtype". That comes from the "System Name" TLV. That comes from the "System Description" TLV. That comes from the "Management Address" TLV. Those come from the "Capabilities" TLV. 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 @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: (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 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 |
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.