Unlocking Any Brand SFP modules on Intel X710

[blunden]

Hello,

Have a couple quad port Intel X710 based NICs[Silicom
PE310G4I71L[PE310G4i71L-XR][0] on the way. And a have few questions.

1. So need to run the xl710_unlock command on each port / interface,
correct; four times in my case on each NIC?

2. Do we need to repeat the above, after updating the driver?

3. So after running the xl710_unlock command, any no name brand or brand
name transceivers should work; without buying specific Intel coded
transceivers? Like the following transceivers:

Ubiquiti UACC-CM-RJ45-MG[1] and
FS SFP-10G-T100 Generic[2].

Or transceivers coded for a specific switch, like Cisco, Mikrotik,
etc...?

Thank You


[0] https://www.silicom-usa.com/pr/serv...tworking-adapters/pe310g4i71l-server-adapter/
[1] SFP+ to RJ45 Adapter - Ubiquiti Store
[2] https://www.fs.com/products/154925.html

1. Yes, as far as I recall.

2. No. It modifies the card's EEPROM.My understanding is that this is configurable because Intel and its OEMs want the ability to disable the vendor lock on certain models.

3. The transceivers still need to have a properly configured EEPROM. If they do, then they should generelly work regardless of vendor, yes. Basically it does the same thing as the allow_unsupported_sfp argument supported by Intel's drivers, but for all platforms.

If you're buying the one from FS.com, you might as well buy the Intel programmed one just in case.

Note that the Ubiquiti one apparently has a hardware design flaw that prevents it from working if plugged in before boot on at least some switches (switches that keep the interface disabled until they have fully booted, if I recall correctly). I don't know if it affects any NICs though.

 

[SlowmoDK]

Hello,

Have a couple quad port Intel X710 based NICs[Silicom
PE310G4I71L[PE310G4i71L-XR][0] on the way. And a have few questions.

1. So need to run the xl710_unlock command on each port / interface,
correct; four times in my case on each NIC?

2. Do we need to repeat the above, after updating the driver?

3. So after running the xl710_unlock command, any no name brand or brand
name transceivers should work; without buying specific Intel coded
transceivers? Like the following transceivers:

Ubiquiti UACC-CM-RJ45-MG[1] and
FS SFP-10G-T100 Generic[2].

Or transceivers coded for a specific switch, like Cisco, Mikrotik,
etc...?

Thank You


[0] https://www.silicom-usa.com/pr/serv...tworking-adapters/pe310g4i71l-server-adapter/
[1] SFP+ to RJ45 Adapter - Ubiquiti Store
[2] https://www.fs.com/products/154925.html

I have the EU version of this card Silicom PE310G4L71LBEU-XR

And i have no problems using different branded transceivers, no unlock needed, with the latest silicom/intel firmware

also silicom support was very helpful in providing me with links to firmware

 

[ProximusAl]

I have a Minisforum MS-01 which has the X710 inside, and it appears to work fine with different SFP+ brands.

 

[blunden]

I have a Minisforum MS-01 which has the X710 inside, and it appears to work fine with different SFP+ brands.

Yes, because Minisforum disables the vendor lock from the factory on the NIC they use.

Most X710 NICs don't ship like that though, causing these unlocking tools to be needed.

 

[dialeantiv]

1. Yes, as far as I recall.

Alright, just wanted to make sure.

2. No. It modifies the card's EEPROM.My understanding is that this is
configurable because Intel and its OEMs want the ability to disable the
vendor lock on certain models.

Asked Silicom about this and this was their response:

"You should use the latest drivers from Intel, the driver does not
update the FW."

3. The transceivers still need to have a properly configured EEPROM. If
they do, then they should generelly work regardless of vendor, yes.
Basically it does the same thing as the allow_unsupported_sfp argument
supported by Intel's drivers, but for all platforms.

If you're buying the one from FS.com, you might as well buy the Intel
programmed one just in case.

Yes, if we go with fs.com transceiver will most likely get the Intel
coded one. But thought of getting a different coded transceiver for
any future compatibility, so it can used not only with Intel. Since the
Intel NIC will be unlocked.

Note that the Ubiquiti one apparently has a hardware design flaw that
prevents it from working if plugged in before boot on at least some
switches (switches that keep the interface disabled until they have
fully booted, if I recall correctly). I don't know if it affects any
NICs though.

Good to know about possible issues with Ubiquiti transceiver.
Will look into this.

Those two transceivers have low power consumption:

1.9W for Ubiquiti
1.8W for FS

The reason we are considering them. The Ubiquiti transceiver has a much
lower price point of $65 vs $139 for the fs.com one. But unsure if the
Ubiquiti transceiver will work, need to find out.

Thank You

I have the EU version of this card Silicom PE310G4L71LBEU-XR

And i have no problems using different branded transceivers, no unlock
needed, with the latest silicom/intel firmware

also silicom support was very helpful in providing me with links to firmware

Asked Silicom about this and this was their response:

"We are not blocking the use of other transceivers but we can not
guarantee the proper operation when using other TR."


One of the reasons went with this Silicom NIC, was that the driver is
easily updated. Unlike other OEM NICs based on X710. As they confirmed
that we can just use the stock Intel drivers.

And like you said, Silicom's support is great. Will be buying from them
again.

Thank You

 

[blunden]

@dialeantiv Not sure where your latest response went, but I felt the need to clarify that all OEM cards use the same Intel drivers (they include all the different OEM PCI-E device IDs in their driver).

It's only the firmware updates that are OEM specific, the updates that Intel call "NVM updates". You can trick the installer to flash generic Intel firmware on them too though, although I haven't tried that yet on my Dell card.

 

[dialeantiv]

@dialeantiv Not sure where your latest response
went, but I felt the need to clarify that all OEM cards use the same
Intel drivers (they include all the different OEM PCI-E device IDs in
their driver).


It's only the firmware updates that are OEM specific, the updates that
Intel call "NVM updates". You can trick the installer to flash generic
Intel firmware on them too though, although I haven't tried that yet on
my Dell card.

The reason that made the comment on OEMs and drivers, is because Intel
states as much on their site[0]. Unless am misunderstanding, that is
what Intel says:

About Intel drivers

If you purchased an OEM branded server or appliance, contact your OEM
for a SW driver version that is compatible with your exact FW version.
Using SW and FW versions that have not been validated to work together
will affect performance, feature availability, and system stability.

See list of manufacturers’ Support websites.

For example, updating the driver for Cisco based X710 NICs is difficult
unless you are in their eco system. Of course not all vendors do this,
Silicom is a good example.

Hope this clarifies what had said before. If am misunderstanding please
explain further.

Thank You

[0] Intel® Ethernet Adapter Complete Driver Pack

 

[blunden]

The reason that made the comment on OEMs and drivers, is because Intel
states as much on their site[0]. Unless am misunderstanding, that is
what Intel says:



For example, updating the driver for Cisco based X710 NICs is difficult
unless you are in their eco system. Of course not all vendors do this,
Silicom is a good example.

Hope this clarifies what had said before. If am misunderstanding please
explain further.

Thank You

[0] Intel® Ethernet Adapter Complete Driver Pack

What they are saying is that you should match the firmware and driver versions, which is also their recommendation for their own cards. You can usually see what the Intel firmware version number is for each OEM firmware update. It does not prevent you from using Intel's driver downloads.

Dell also release their firmware updates without a support contract or login being required. If you OEM doesn't, you can cross-flash it to generic Intel firmware instead.

I do however agree that it's good to see OEMs that disable the vendor lock from the factory and don't require firmware updates to be run on only their own servers (which is apparently a thing for some devices and OEMs). I'm all for supporting them, assuming the pricing is somewhat reasonable.

 

[blunden]

Good to know about possible issues with Ubiquiti transceiver.
Will look into this.

The compatibility issue was mentioned in the thread below. I happend to find it again so I figured I might as well post the link here.

https://forums.servethehome.com/index.php?threads/fs-com-100m-sfp-10g-t100-ubiquiti-uacc-cm-rj45-mg.41494/

 

[dialeantiv]

The compatibility issue was mentioned in the thread below. I happend to find it again so I figured I might as well post the link here.

https://forums.servethehome.com/index.php?threads/fs-com-100m-sfp-10g-t100-ubiquiti-uacc-cm-rj45-mg.41494/

Sorry for the late reply. Thank you for this. To avoid any potential issues
will most likely go with the fs.com transceiver, even thought it is over
twice the price.

 

[Fmfranz]

Is there a way to revert the changes made by the unlock tool? My x710 doesnt report anything anymore to dmesg after unlock

 

[krby]

Just a bump to this post: has anyone managed to get it working or figure out how to allow 1Gb SFP to work in addition to the 10Gb SFP+ modules?
I ask because I want to use a fibre SFP provided by my ISP that runs at 1Gb and getting a 10Gb version is nigh on impossible / expensive (1Gb 1310/1550nm BiDi SFP).

My Intel X710 is in a Protectli Vault 6 box and I've engaged their support but they seem a little stumped by it. Initially, the NVM firmware version was quite old and didn't even recognise the SFP. Now I updated to the latest 9.40, it does, but refuses to bring the link up, producing ixl1_set_link: Error getting phy capabilities -37, aq error: 8 error messages. Having played aroud with different SFPs, I've come to realise that it'll only work with 10Gb SFP+ modules, the irong being that if I use a 10Gb Base-T SFP with a 1Gb link on the other end, the link comes up at 1Gb and works, but if I use a 1Gb Base-T SFP, it doesn't work at all.

I'm in a similar situation. I've got a new Protectli 6630 with a X710 and a passive SFP+ DAC cable that I'm trying to connect to an SFP (not SFP+) port on a UniFi switch. I know it will connect at only 1G, I'm fine with that for now. I'm hoping to use the switch's SFP ports to free up some Ethernet ports.

 

[blunden]

Is there a way to revert the changes made by the unlock tool? My x710 doesnt report anything anymore to dmesg after unlock

I suppose you could look at the code to see what bits it changed and possibly write those with ethtool or a modified version of the unlock tool. Not sure how to solve the fact that it doesn't get detected though. It is not detected in any way, even as an unknown device with a different device ID?

I'm in a similar situation. I've got a new Protectli 6630 with a X710 and a passive SFP+ DAC cable that I'm trying to connect to an SFP (not SFP+) port on a UniFi switch. I know it will connect at only 1G, I'm fine with that for now. I'm hoping to use the switch's SFP ports to free up some Ethernet ports.

Is it possible to force the speed of the port down to 1G?

 

[krby]

I suppose you could look at the code to see what bits it changed and possibly write those with ethtool or a modified version of the unlock tool. Not sure how to solve the fact that it doesn't get detected though. It is not detected in any way, even as an unknown device with a different device ID?

Is it possible to force the speed of the port down to 1G?

The X710 is detected just fine, the cable is even detected, but I can't get a link. I'm using pfSense on the SFP+/10G side and in the webUI the only option under auto negotiation is to either auto or select 10G-Twinax. Maybe if don't let the 1G side autonegotiate? Or, maybe I can find a speed setting with freebsd's sysctl.

 

[blunden]

The X710 is detected just fine, the cable is even detected, but I can't get a link. I'm using pfSense on the SFP+/10G side and in the webUI the only option under auto negotiation is to either auto or select 10G-Twinax. Maybe if don't let the 1G side autonegotiate? Or, maybe I can find a speed setting with freebsd's sysctl.

That first question was not aimed at you.

I would expect you to have to force it down to 1G on both ends. The EEPROM of the DAC probably doesn't report 1G as a supported speed.

 

[krby]

That first question was not aimed at you.

Ahh, my bad.

I would expect you to have to force it down to 1G on both ends. The EEPROM of the DAC probably doesn't report 1G as a supported speed.

So here's the output from ifconfig with the DAC inserted.

[2.7.2-RELEASE][admin@pfSense.lan]/root: ifconfig -vvvmm ixl1
ixl1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        capabilities=4f507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether 64:62:66:22:c5:66
        media: Ethernet autoselect
        status: no carrier
        supported media:
                media autoselect
                media 10Gbase-LR
                media 10Gbase-SR
                media 10Gbase-Twinax
                media 1000baseLX
                media 1000baseSX
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        plugged: SFP/SFP+/SFP28 1X Copper Passive (Copper pigtail)
        vendor: Protectli PN: WPP-PC192-3010 SN: HS23121400020 DATE: 2023-12-25

        SFF8472 DUMP (0xA0 0..127 range):
         03 04 21 01 00 00 00 41 04 80 d5 06 67 00 00 00
         00 00 01 00 50 72 6f 74 65 63 74 6c 69 20 20 20
         20 20 20 20 00 00 00 00 57 50 50 2d 50 43 31 39
         32 2d 33 30 31 30 20 20 31 20 20 20 01 00 00 dd
         00 00 00 00 48 53 32 33 31 32 31 34 30 30 30 32
         30 20 20 20 32 33 31 32 32 35 20 20 00 00 00 89
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Since it's a DAC, I thought Twinax would be the closest, but that's 10G.

It turns out that selecting anything but "autoselect" in the pfSense webUI or with ifconfig leads to
> ixl1: Media change is not supported.

 

[blunden]

Ahh, my bad.




So here's the output from ifconfig with the DAC inserted.

[2.7.2-RELEASE][admin@pfSense.lan]/root: ifconfig -vvvmm ixl1
ixl1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4e100bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        capabilities=4f507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,NETMAP,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether 64:62:66:22:c5:66
        media: Ethernet autoselect
        status: no carrier
        supported media:
                media autoselect
                media 10Gbase-LR
                media 10Gbase-SR
                media 10Gbase-Twinax
                media 1000baseLX
                media 1000baseSX
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        plugged: SFP/SFP+/SFP28 1X Copper Passive (Copper pigtail)
        vendor: Protectli PN: WPP-PC192-3010 SN: HS23121400020 DATE: 2023-12-25

        SFF8472 DUMP (0xA0 0..127 range):
         03 04 21 01 00 00 00 41 04 80 d5 06 67 00 00 00
         00 00 01 00 50 72 6f 74 65 63 74 6c 69 20 20 20
         20 20 20 20 00 00 00 00 57 50 50 2d 50 43 31 39
         32 2d 33 30 31 30 20 20 31 20 20 20 01 00 00 dd
         00 00 00 00 48 53 32 33 31 32 31 34 30 30 30 32
         30 20 20 20 32 33 31 32 32 35 20 20 00 00 00 89
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Since it's a DAC, I thought Twinax would be the closest, but that's 10G.

Oh, it does. Good. I would still kind of expect to possibly have to force it on both ends when trying to use a lower speed. Did you try that yet?

 

[krby]

I stealth edited my post above.
It turns out that selecting anything but "autoselect" in the pfSense webUI or with ifconfig leads to this in dmesg
ixl1: Media change is not supported.

But wait! Some progress. With sysctl and some google-fu I found
sysctl dev.ixl.1.advertise_speed

The pfSense docs mentions this a bit-field. The stock config had this set to 6 (x02 & 0x4 = 0x6) which means 1G and 10G respetively. When I force this setting to 0x2 (1G), then dmseg gives me:
ixl1: Link failed because an unqualified module was detected!

I spent some time searching the IXL driver manpage and code and there's definitely not a sysctl OID for unsupported modules like other Intel cards have.

 

[krby]

Huh, looking at this page from Intel, they claim non-Intel DAC cables should work (without needing to be unlocked?)

Which direct attach cables are compatible?

* Intel validated cables are listed in the Intel® Product Compatibility Tool.
* SFP+ passive or active limiting direct attach copper cables that comply with the SFF-8431 v4.1 and SFF-8472 v10.4 specifications.
* SFF-8472 identifier must have value 03h (SFP or SFP Plus). You can verify the value with the cable manufacturer.

 

[blunden]

Huh, looking at this page from Intel, they claim non-Intel DAC cables should work (without needing to be unlocked?)

Yes, I get the feeling that DACs are exempt from vendor locking on Intel NICs because it would cause too many compatibility issues with enterprise networking equipment if they weren't.

If they were to require Intel coded DACs, it probably wouldn't work with switches that do vendor locking. The only cables that would the reliably work would be the ones where the different ends can have different vendor coding, basically pushing people towards FS.com, FlexOptix, etc.

I think I read somewhere that 1 Gb fiber transceivers also aren't vendor locked. I don't remember the source though, so I'd double check that before taking any action based on that information.