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.
