[j-nsp] Junos 12.3 more strict about 3rd party optics?

[Chuck Anderson]

On Wed, Jun 11, 2014 at 03:49:16PM +0100, Phil Mayers wrote:
> On 11/06/14 15:01, Chuck Anderson wrote:
> 
> >Jun 10 11:40:54  ex4200 chassism[1293]: XCVR: Unit 0, SFP+ of type 0 EEPROM is Mis Programmed!!
> 
> Yeah, this was the one that caught my eye. I wonder if it's choking
> on unknown values in the EEPROM.

After much investigation, and thanks to Juniper not locking down
access to the internal debugging tools on JUNOS, I was able to
determine that bytes 3-10 of the SFP ID EEPROM of optic I'm using are
coded as all 0's.  My reading of the SFF-8472 MSA says that this is
invalid:

"Transceiver Compliance Codes [Address A0h, Bytes 3-10]

The following bit significant indicators define the electronic or
optical interfaces that are supported by the transceiver. At least one
bit shall be set in this field."

The top half of byte 3 is defined as follows, and I would expect any
MSA Ethernet optic to have at least one of these bits set, even
CWDM/DWDM optics:

Byte	  Bit	 Description
3	  7	 10G Base-ER
3	  6	 10G Base-LRM
3	  5	 10G Base-LR
3	  4	 10G Base-SR

My optic vendor doesn't agree and says that those bits only refer to
"grey" optics--standard wavelengths 850nm or 1310nm, and says that it
is VALID to have no bits set all all in bytes 3-10.  I'm guessing that
the SFP driver in EX4200 doesn't like this, but the one in MX doesn't
care.

I tried changing the values using "xcvrpeek" and "xcvrpoke" (and
"i2cpeek"/"i2cpoke").  Reads work fine, writes fail with -EIO in dmesg
and the values don't change when read back.  I guess the optic is
"locked" from writing changes to the EEPROM without some sort of OEM
password or something.