Actually using “unsupported” SFP transceivers on HPE Aruba

Thu, Jan 9, 2025

Aruba 3810M, connected with two direct-attach cables. Both port status LEDs are green.

SFP+ transceivers that claimed to be HPE Aruba compatible were getting rejected by my 3810M switch because of their proprietary authentication system, even when it is supposed to be disabled. I found a hack that made them work again by patching a byte in the transceiver EEPROM.

---

Straight to the point:

• Configure the switch
  • Log into the console, enter configuration mode: config
  • Disable HPIDv2 enforcement: allow-unsupported-transceiver confirm
  • Make this change persistent: write memory
• Configure the transceivers
  • Back up the EEPROM, then overwrite it with the known good dump.
• Plug the transceiver into the switch. It should now work.

KNOWN GOOD DUMP, WITHOUT HPIDV2 INDICATOR

root@OpenWrt:/etc# ./i2csfp sfp2 eepromdump
0x50:
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f   0123456789abcdef
00: 03 04 07 10 00 00 00 00 00 00 00 00 67 00 00 00   ............g...
10: 08 03 00 1e 4c 69 67 65 6e 74 20 50 68 6f 74 6f   ....Ligent Photo
20: 6e 69 63 73 00 00 00 00 4c 54 46 38 35 30 32 2d   nics....LTF8502-
30: 42 43 20 20 20 20 20 20 31 20 20 20 03 52 00 f5   BC      1   .R..
40: 00 1a 14 14 43 4e 38 34 4b 42 56 32 36 36 20 20   ....CN84KBV266
50: 20 20 20 20 31 38 30 33 33 31 20 20 68 f0 03 4b       180331  h..K
60: 48 50 a0 00 80 50 20 20 4a 39 31 35 30 44 20 31   HP...P  J9150D 1
70: 39 39 30 2d 34 33 39 31 1f 20 20 00 00 00 00 00   990-4391.  .....
80: 10 64 03 25 d2 90 3a 6b 16 23 c8 f1 77 04 70 ee   .d.%..:k.#..w.p.
90: c2 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
a0: 00 00 48 50 20 50 72 6f 43 75 72 76 65 20 50 72   ..HP ProCurve Pr
b0: 6f 70 72 69 65 74 61 72 79 20 74 72 61 64 65 20   oprietary trade
c0: 73 65 63 72 65 74 20 2d 20 63 6f 70 79 69 6e 67   secret - copying
d0: 20 69 73 20 70 72 6f 68 69 62 69 74 65 64 20 77    is prohibited w
e0: 69 74 68 6f 75 74 20 70 65 72 6d 69 73 73 69 6f   ithout permissio
f0: 6e 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00   n...............

---

Context

Innards of an original J9150D transceiver.

HPE Aruba 3810M/2930M switches are notoriously picky about third-party transceivers.

Original Aruba transceivers have a little microcontroller on board that handles authentication, and this is really the key difference between them and third-party transceivers. The switches are supposed to have an option, allow-unsupported-transceiver, that allows non-HP transceivers to be used. In practice though, this has never worked for me in the past.

I first ran into this issue when I bought a pair of generic 10G bidirectional singlemode transceivers. I messaged the Aliexpress store that the transceivers were intended for use in HPE Aruba switches, and the seller dutifully configured them so that they would present themselves as a HPE J9151A transceiver. The J9151A transceiver is explicitly listed as compatible with the 3810M switch, yet when I inserted it into the switch, the amber error indicator lit up, even with allow-unsupported-transceiver active.

root@OpenWrt:/etc# ./i2csfp sfp2 eepromdump
0x50:
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f   0123456789abcdef
00: 03 04 07 20 00 00 00 00 00 00 00 00 67 00 14 c8   ... ........g...
10: 00 00 00 00 50 41 43 42 54 45 43 48 20 20 20 20   ....PACBTECH
20: 20 20 20 20 00 00 0b 40 50 41 43 2d 31 30 47 2d       ...@PAC-10G-
30: 31 30 42 20 20 20 20 20 30 30 30 30 05 32 00 06   10B     0000.2..
40: 00 1a 00 00 50 41 43 32 30 32 33 59 31 32 31 36   ....PAC2023Y1216
50: 32 20 20 20 32 33 31 32 32 32 20 20 68 f0 03 31   2   231222  h..1
60: 48 50 a0 00 80 50 20 20 4a 39 31 35 31 41 20 31   HP...P  J9151A 1
70: 39 39 30 2d 34 30 36 39 20 20 20 32 20 20 20 20   990-4069   2
80: 10 23 9d ba a0 b6 0b af 53 14 f4 ca b9 b0 9f e9   .#......S.......
90: d6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
a0: 00 00 48 50 20 50 72 6f 43 75 72 76 65 20 50 72   ..HP ProCurve Pr
b0: 6f 70 72 69 65 74 61 72 79 20 74 72 61 64 65 20   oprietary trade
c0: 73 65 63 72 65 74 20 2d 20 63 6f 70 79 69 6e 67   secret - copying
d0: 20 69 73 20 70 72 6f 68 69 62 69 74 65 64 20 77    is prohibited w
e0: 69 74 68 6f 75 74 20 70 65 72 6d 69 73 73 69 6f   ithout permissio
f0: 6e 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00   n...............

EEPROM dump of the transceiver from Aliexpress.

Strange.

The SFP specs says that the transceiver side of the module should behave as though an at24 EEPROM was attached to the i2c bus, and in fact many transceivers have a physical at24c02 tucked somewhere on their boards. This is also how many third-party vendors “code” their modules to support specific vendors — they have a large collection of memory dumps from official transceivers, and they simply write those values verbatim onto the new transceiver EEPROM.

I had a spare DAC with a writable EEPROM along with some original HPE J9150D transceivers, and I figured that I should try copying the original HPE values and pasting it as-is into the DAC. In theory, my DAC should show up exactly like the original HPE device. However, when I connected the modified DAC, the fault indicator lit up again.

HPIDv2

I dug around and found out about the existence of “HPIDv2”, which is a challenge-response authentication scheme from HP. From what I can tell, the switch will first write a 16-byte challenge onto the emulated EEPROM. The transceiver computes the key and replaces those challenge values. Finally, this response is read back and validated by the switch.

Crucially, there is also a byte that indicates that a device is compliant with HPIDv2. What if the switch is throwing an error because the transceiver claimed to be compliant, but actually failed the authentication (or got stuck waiting for a response)?

I flashed the DAC again, this time replacing the HPIDver byte at position 0x7B from 0x32 to 0x00. This time, when the DAC was installed, the status indicator blinked green! This probably explains why the Aliexpress transceivers failed to start, as they probably left the HPIDv2 indicator untouched when they copied from their original EEPROM dump.

The EEPROM dump right at the top of this post is the exact same dump that I used in this working DAC. This will only work for simpler SFP+ transceivers, and will almost certainly not work on “smart” RJ45/GPON transceivers. A quick litmus test for whether a transceiver will work is probably “can this transceiver also do TOSLINK”.

I’m mighty curious about HPIDv2. There’s little documentation on it, yet vendors like FS are able to sell J9150D-compatible parts without mentioning anything about allow-unsupported-transceiver . If you think that you might be able to glitch and dump the C8051F336, please get in touch and I’ll be happy to desolder the IC from my original transceiver and send it to you on a postcard.