LLDPDU MAC-PHY TLV PMD Auto-Neg field is being analyzed incorrectly
This issue was migrated from bug 1455 in our old bug tracker.
Original bug information:
Reporter: John M Hilman
Status: VERIFIED NOTABUG
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: 0.99.5
Attachments:
extreme-ayava-lldpdu.pcap: Trace file with two LLDPDUs, one Extreme, one Avaya.
bug1455.patch: Proposed patch IF bug 1455 is confirmed.
Activity
Build Information:
Version 0.99.5 (SVN Rev 20677)
When capturing a single LLDPDU with the Wireshark product, and the MAC-PHY TLV enabled for Tx from the DUT, I'm capturing data which shows that the PMD Auto-Negotiation Advertised Capability field with a value of 0x0136, or 0000 0001 0011 0110. According to the table outlined in RFC3636 (pg.41), the advertised capibilities should be as follows: bOther(0), -- other or unknown this--> b10baseT(1), -- 10BASE-T half duplex mode this--> b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 this--> b100baseTX(4), -- 100BASE-TX half duplex mode this--> b100baseTXFD(5), -- 100BASE-TX full duplex mode b100baseT2(6), -- 100BASE-T2 half duplex mode b100baseT2FD(7), -- 100BASE-T2 full duplex mode this--> bfdxPause(8), -- PAUSE for full-duplex links bfdxAPause(9), -- Asymmetric PAUSE for full-duplex -- links bfdxSPause(10), -- Symmetric PAUSE for full-duplex -- links bfdxBPause(11), -- Asymmetric and Symmetric PAUSE for -- full-duplex links b1000baseX(12), -- 1000BASE-X, -LX, -SX, -CX half -- duplex mode b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full -- duplex mode b1000baseT(14), -- 1000BASE-T half duplex mode b1000baseTFD(15) -- 1000BASE-T full duplex mode However, Wireshark is showing: bOther(0), -- other or unknown b10baseT(1), -- 10BASE-T half duplex mode b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 b100baseTX(4), -- 100BASE-TX half duplex mode b100baseTXFD(5), -- 100BASE-TX full duplex mode b100baseT2(6), -- 100BASE-T2 half duplex mode this--> b100baseT2FD(7), -- 100BASE-T2 full duplex mode bfdxPause(8), -- PAUSE for full-duplex links this--> bfdxAPause(9), -- Asymmetric PAUSE for full-duplex -- links this--> bfdxSPause(10), -- Symmetric PAUSE for full-duplex -- links bfdxBPause(11), -- Asymmetric and Symmetric PAUSE for -- full-duplex links b1000baseX(12), -- 1000BASE-X, -LX, -SX, -CX half -- duplex mode this--> b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full -- duplex mode this--> b1000baseT(14), -- 1000BASE-T half duplex mode b1000baseTFD(15) -- 1000BASE-T full duplex mode This would be: 0110 0110 1000 0000 or 0x6680added uigtk version0.x labels
-
(In reply to comment #1) > Sounds like a big endian/little endian problem. > packet-lldp.c line 1352 reads the value with ntohs() > Not an LE-BE issue an MSB->LSB inversion. 0000 0001 0011 0110 0011 0110 0000 0001 LE<->BE would be this 0000 0001 0110 1100 this is what we got (MSB<->LSB confussion) -
Hello John, You wouldn't by some chance be looking at LLDPDU generated by an Avaya IP phone? I've attached a small trace that includes two LLDPDUs, one from an Extreme Summit S300-24 switch the other from it's peer an Avaya 4621SW IP phone. I had a 10base-T hub between the switch and phone which explains why the two devices are only communicating with each other at 10-half. The pmd auto-negotiation advertised capability bits from the Extreme LLDPDU switch parses as expected, but for the Avaya phone the bits appears to be inverted. The trace shows the short for the Avaya's pmd auto-negotiation advertised capability as 0x0536. I suspect that Avaya is generating this value incorrectly. If I invert the bits of this short from 0x0536 to x6CA0 then the parsed value makes more sense. Assuming 0x6ca0: 0110 1100 1010 0000 xx xx x x 42 84 8 2 0x4000 /* b10baseT(1), -- 10BASE-T half duplex mode */ 0x2000 /* b10baseTFD(2), -- 10BASE-T full duplex mode */ 0x0800 /* b100baseTX(4), -- 100BASE-TX half duplex mode */ 0x0400 /* b100baseTXFD(5), -- 100BASE-TX full duplex mode */ 0x0080 /* bFdxPause(8), -- PAUSE for full-duplex links */ 0x0020 /* bFdxSPause(10), -- Symmetric PAUSE for full-duplex links */ Of course Extreme could have it wrong. I submitted this particular piece of code to packet-lldp.c. At the time the only LLDPDUs I had were generated by Extreme switches (both XOS and Extremeware based devices). But the code seemed pretty straight forward to me so my guess is that your LLDPDU and my Avaya LLDPDU are generated incorrectly. I'll be checking with the Avaya tomorrow. -
IEEE Std 802.1AB-2005 says: G.2.2 PMD auto-negotiation advertised capability field The PMD auto-negotiation advertised capability field shall contain an integer value as defined by the ifMauAutoNegCapAdvertisedBits object in IETF RFC 3636. RFC 3636 says: ifMauAutoNegCapAdvertisedBits OBJECT-TYPE SYNTAX BITS { bOther(0), -- other or unknown b10baseT(1), -- 10BASE-T half duplex mode b10baseTFD(2), -- 10BASE-T full duplex mode b100baseT4(3), -- 100BASE-T4 b100baseTX(4), -- 100BASE-TX half duplex mode b100baseTXFD(5), -- 100BASE-TX full duplex mode b100baseT2(6), -- 100BASE-T2 half duplex mode b100baseT2FD(7), -- 100BASE-T2 full duplex mode bFdxPause(8), -- PAUSE for full-duplex links bFdxAPause(9), -- Asymmetric PAUSE for full-duplex -- links bFdxSPause(10), -- Symmetric PAUSE for full-duplex -- links bFdxBPause(11), -- Asymmetric and Symmetric PAUSE for -- full-duplex links b1000baseX(12), -- 1000BASE-X, -LX, -SX, -CX half -- duplex mode b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full -- duplex mode b1000baseT(14), -- 1000BASE-T half duplex mode b1000baseTFD(15) -- 1000BASE-T full duplex mode } RFC 1906 says: (3) When encoding an object whose syntax is described using the BITS construct, the value is encoded as an OCTET STRING, in which all the named bits in (the definition of) the bitstring, commencing with the first bit and proceeding to the last bit, are placed in bits 8 to 1 of the first octet, followed by bits 8 to 1 of each subsequent octet in turn, followed by as many bits as are needed of the final subsequent octet, commencing with bit 8. Remaining bits, if any, of the final octet are set to zero on generation and ignored on receipt. ITU-T Recommendation X.690 says: 6.2 For the purposes of this Recommendation | International Standard only, the bits of an octet are numbered from 8 to 1, where bit 8 is the "most significant bit", and bit 1 is the "least significant bit". From this, I conclude that bOther is the MSB of the first octet, b10baseT is the next octet down, and so on. That would make a field value of 0x0136 as being: b100baseT2FD, bfdxSPause, bfdxBPause, b1000baseXFD, b1000baseT I.e., at least as I read the standards in question, Wireshark is dissecting the packet correctly, and if that's not what the folks at Avaya intended, they misread the standard. -
(In reply to comment #5) > IEEE Std 802.1AB-2005 says: > G.2.2 PMD auto-negotiation advertised capability field > The PMD auto-negotiation advertised capability field shall contain an integer > value as defined by the > ifMauAutoNegCapAdvertisedBits object in IETF RFC 3636. > RFC 3636 says: > ifMauAutoNegCapAdvertisedBits OBJECT-TYPE > SYNTAX BITS { > bOther(0), -- other or unknown > b10baseT(1), -- 10BASE-T half duplex mode > b10baseTFD(2), -- 10BASE-T full duplex mode > b100baseT4(3), -- 100BASE-T4 > b100baseTX(4), -- 100BASE-TX half duplex mode > b100baseTXFD(5), -- 100BASE-TX full duplex mode > b100baseT2(6), -- 100BASE-T2 half duplex mode > b100baseT2FD(7), -- 100BASE-T2 full duplex mode > bFdxPause(8), -- PAUSE for full-duplex links > bFdxAPause(9), -- Asymmetric PAUSE for full-duplex > -- links > bFdxSPause(10), -- Symmetric PAUSE for full-duplex > -- links > bFdxBPause(11), -- Asymmetric and Symmetric PAUSE for > -- full-duplex links > b1000baseX(12), -- 1000BASE-X, -LX, -SX, -CX half > -- duplex mode > b1000baseXFD(13), -- 1000BASE-X, -LX, -SX, -CX full > -- duplex mode > b1000baseT(14), -- 1000BASE-T half duplex mode > b1000baseTFD(15) -- 1000BASE-T full duplex mode > } > RFC 1906 says: > (3) When encoding an object whose syntax is described using the BITS > construct, the value is encoded as an OCTET STRING, in which all > the named bits in (the definition of) the bitstring, commencing > with the first bit and proceeding to the last bit, are placed in > bits 8 to 1 of the first octet, followed by bits 8 to 1 of each > subsequent octet in turn, followed by as many bits as are needed of > the final subsequent octet, commencing with bit 8. Remaining bits, > if any, of the final octet are set to zero on generation and > ignored on receipt. > ITU-T Recommendation X.690 says: > 6.2 For the purposes of this Recommendation | International Standard only, the > bits of an octet are numbered from > 8 to 1, where bit 8 is the "most significant bit", and bit 1 is the "least > significant bit". > From this, I conclude that bOther is the MSB of the first octet, b10baseT is > the next octet down, and so on. That would make a field value of 0x0136 as > being: > b100baseT2FD, bfdxSPause, bfdxBPause, b1000baseXFD, b1000baseT > I.e., at least as I read the standards in question, Wireshark is dissecting the > packet correctly, and if that's not what the folks at Avaya intended, they > misread the standard. Ths wasn't an Avaya phone I was testing, so aparently someone else is mis-reading the standard as well. I'm going to copy your posting along with the posting and two packet traces provided by Jim and pass it on to our engineers to take a look into this matter. My initial thoughts were that "WE" were wrong and the sniffer was to blame, but as it's explained to me I'm rethinking that position. Thanks. -
This is what I get for starting work at 5:30 A.M. I meant to say that my initial reaction was that we had it wrong and the sniffer was NOT to blame... but I was influenced to think otherwise. Now I'm rethinking that position. > Ths wasn't an Avaya phone I was testing, so aparently someone else is > mis-reading the standard as well. I'm going to copy your posting along with > the posting and two packet traces provided by Jim and pass it on to our > engineers to take a look into this matter. My initial thoughts were that "WE" > were wrong and the sniffer was to blame, but as it's explained to me I'm > rethinking that position. Thanks. -
OK... now that I've had a chance to look and think about this... The way this is being looked at is by the bits. There are 16 bits for this field in the TLV numbered 0-15 counting from right to left. So the way this looks on our systtem is: xxxx xxxx xxxx xxxx or: 15 14 13 12 : 11 10 9 8 : 7 6 5 4 : 3 2 1 0 so when we have 0x0136: 0000 0001 0011 0110 x xx xx 0 1 3 6 This is not correct? -
> There are 16 bits for this field in the TLV numbered 0-15 counting from right to left. As I read RFC 3636, the SNMP field that the 802.1AB-2005 spec says is the model for the LLDP field has "SYNTAX BITS", and, as I read RFC 1906, a "SYNTAX BITS" field in SNMP is an OCTET STRING, i.e. a sequence of bytes, and the bits from the enumeration are put in order from the first bit of the first octet through the last bit of the first octet, and then, if there's a second octet, in order from the first bit of the second octet through the last bit of the second octet, etc.. I.e. the first bit in the enumeration is in the topmost bit of the first octet, and the next up-to-7 bits are in the rest of the bits of the octet, and any 9th bit is in the topmost bit of the second octet, etc.. This means that the field isn't a 16-bit integral value - it's two octets in sequence. I.e., if something is fetched as big-endian and displays as 0x0136, it would be the two bytes 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 0 0 1 1 0 1 1 0 which correspond in sequence to 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 The values in the enumeration are, in order: bOther(0), b10baseT(1), b10baseTFD(2), b100baseT4(3), b100baseTX(4), b100baseTXFD(5), b100baseT2(6), b100baseT2FD(7), bFdxPause(8), bFdxAPause(9), bFdxSPause(10), bFdxBPause(11), b1000baseX(12), b1000baseXFD(13), b1000baseT(14), b1000baseTFD(15) so the values corresponding to the bits that are set are: b100baseT2FD bFdxSPause bFdxBPause b1000baseXFD b1000baseT -
(In reply to comment #9) I've called upon one of our experts and his response: "IEEE 802.1AB-2007 specifies that the field contain an integer value, not an octet-string. There are existing TLV’s which specify octet-strings as the data payload, so there is precedent in the standard for this description. On the other hand, the standard does specify how bits are to be encoded into integer fields. This is consistently applied across all other bit-fields within the standard." I agree with this, since I have looked at and decoded each supported TLV type and according to Wireshark, each of these other TLV's is consistent with this statement. -
Hello John, In comment #10 are you arguing that Wireshark's decode of the LLDP PMD auto-neg field right or wrong? If Wireshark is correct, there is no bug, and your vendor and Avaya will need to be convinced to fix the way they generate the PMD Auto-Neg field. If Wireshark is incorrect, then Wireshark will need to be fixed and Extreme and HP[1] will need to be convinced to fix the way they generate the PMD Auto-Neg field. [1] Interestingly there is an sample LLDP-MED trace included on the Wireshark SampleCaptures page. http://wiki.wireshark.org/SampleCaptures?acton=AttachFile&do=get&target=lldpmed_civicloc.pcap The LLDP-MED frame within lldpmed_civicloc.pcap looks to have been generated by an HP Procurve switch. Both HP and Extreme appear to be in agreement on how to generate the LLDP 802.3 PMD Auto-Negotiation Advertised Capability field. This doesn't make them right, just consistent. ;-) -
I don't see any 802.1AB-2007 on the shop.ieee.org Web site. The page at http://www.ieee802.org/1/pages/802.1AB-rev.html mentions some 2007 802.1AB drafts. Is the engineer in question referring to one of the drafts? All 802.1AB-2005 says is that it's "an integer value as defined by the ifMauAutoNegCapAdvertisedBits object in IETF RFC 3636." RFC 3636 declares ifMauAutoNegCapAdvertisedBits as "OBJECT-TYPE SYNTAX BITS", and RFC 1906 says that's done as an OCTET STRING. Perhaps the intent is to clarify this in 802.1AB-2007, which would, I think, be a Good Thing, especially given that the evidence appears to be that hardware exists that interprets the standard in both ways (0 means bottommost bit and 0 means topmost bit). -
(In reply to comment #11) Hi Jim, While Guy does make some valid points... and the RFC trail he's blazing is exactly as he says it is, I do have to side with my engineer contact. As he says, there are many cases in the 802.1AB-2005 standard where octets are called for specifically, and many cases where integer strings are called for specifically, and in those cases; the right information is being reported on the decodes. So to suggest anything other than the integer string the standard calls for regardless of the references to outside sources would be contracting the rest of the standard, would it not? I think that Guy is correct in that he was refering to a 2007 draft of the standard since there is no actual 802.1AB-2007 document as of yet. I also believe this should be clarified so that everyone knows what page to be on. So in short... I believe that Wireshark, HP, and Extreme are interpreting the standard incorrectly, and that Avaya, and my particular vendor is correct. I'd also be interested to see how other vendors are interpreting this part of the standard. -
Hello John, As you suggested in comment #13 this really needs to be clarified. The IEEE has a web page specfically devoted to questions of specification interpretation: http://standards.ieee.org/reading/ieee/interp/ There's even an email address available to perhaps expedite the process. Do you think you or your engineer would be up to submitting a request for interpretation to the IEEE? A Wireshark fix (if it should be necessary) shoudn't be very difficult, but we really need to know for sure what's broke before we fix it. ;-) My late-night bleary-eyed re-reading of the 2005 LLDP spec has me even more uncertain of what is correct. Section 9 talks about how bits are to be numbered within an octet and how larger than one octet sequences are to be layed out. The fact is that multiple interpretations are now currently deployed. I have alerted both Avaya and Extreme of this discrepency but they have not yet responded. Interestingly here's how an Extreme S300-24 switch running EW7.6.3b6 currently parses the PMD Auto-neg field received from an Avaya 4621SW running v2.8 firmware when connected directly to one another. [snip] > Extended TLV Info 802.3 OUI (hex value) = 00-12-0f > -MAC PHY Configuration & Status > -Auto-negotiation Support & Status : Supported, enabled > -Advertised capability bits (hex value): 536 > 100baseTXFD > 100baseT2FD > fdxSPause > fdxBPause > 1000baseXFD > b1000baseT > -Operational MAU Type : 16 [snip] -
Created attachment 644 Proposed patch IF bug #1455 (closed) is confirmed.
Attached is a proposed patch to resolve bug #1455 (closed) if Wireshark's dissection of the LLDP 802.3 PMD Auto-Negotiation Advertised Capability field is determined to be wrong.
-
Hello John,
I've received some feedback from Avaya. The problem is still being researched and the emails are "just informational" but Avaya's initial conclusion is that "... it looks like it is an Avaya issue" which implies that Wireshark (and Extreme) are correct.
I'm still awaiting feedback from Extreme.
-
I have filed a request for interpretation of the standard. I'll get an answer in July. Until then, we have the proposed fix if needed. When the response comes in, we can go forward from there, which will either be a fix for Wireshark, or a fix for Avaya and the other vendor in question. Thanks for your time and contributions, gentlemen. John Here is the response from my submission. Dear Mr. Hilman: A response to your inquiry will be provided on or about 31 July. Thank you, Rona Gertz _______________________________ Rona I. Gertz Manager, IEEE-SA Governance IEEE Standards Activities r.gertz@ieee.org +1 732 562 3808 (phone); +1 732 562 1571 (fax) IEEE Standards web site:http://standards.ieee.org/ -
Hello John,
Thanks for pursuing this issue with the IEEE.
I have been notified that engineers at both Extreme and Avaya are now aware of the difference in their interpretation and implementation of the 802.3 MAC/PHY Configuration/Status TLV's PMD auto-negotiation advertised capability field and are investigating the issue.
I also made them aware that this issue will most likely need to be clarified by the IEEE itself since neither vendor's interpretation is unique; there are multiple vendors with the "0 means bottommost bit" and multiple vendors with the "0 means topmost bit".
Thanks again John (and Guy Harris!).
Jim Y.
Please register or sign in to reply