Wireshark-bugs: [Wireshark-bugs] [Bug 1455] LLDPDU MAC-PHY TLV PMD Auto-Neg field is being analy
Date: Thu, 9 Aug 2007 15:22:39 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1455





------- Comment #22 from jhilman@xxxxxxxxxxxx  2007-08-09 15:22 GMT -------
This is the response I got back when I emailed the IEEE group for follow up.


John -

We're working on it.

Regards,
Tony

At 16:12 06/08/2007, Hilman, John wrote:
>IEEE 802.1: ballots on P802.1Qat, P802.1AS due August 22
>---
>
>Please read the following and respond with whether this is a true 
>assessment of the standard or is this incorrect.  Thank you.
>
>
>IEEE Std 802.1AB-2005
>
>
>
>
>
>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.
>
>
>
>
>
>---- IEEE 802.1 Email List ----
>DELETE THIS FOOTER from copies, forwards, & replies.
>Working Group 802.1 Web pages:
>                         http://www.ieee802.org/1/ Ballot due dates:
>     August 22, P802.1Qat/D0.9 (www.ieee802.org/1/pages/802.1at.html)
>      August 22, P802.1AS/D1.0 (www.ieee802.org/1/pages/802.1as.html)
>List subscriber pages:
>            http://www.ieee802.org/1/email-pages/vntb1206.html


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.