http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1455
------- Comment #6 from jhilman@xxxxxxxxxxxx 2007-04-10 10:13 GMT -------
(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.
--
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.
