pfSense » pfSense Docs

Has that been tested and confirmed? I remember some discussion around that back when the driver was first brought in, but I don't recall if anyone confirmed it to be the case and I'm not turning up anything specific when searching on slack.

It's been tested by a customer, along with SW and CL.

At best, the ix and igc ports on both the 6100 and 4100 will fail back to autoselect if they are hard-set, linking at whichever speed is auto-negotiated. If the other side is hard-set, the ports will fail in different ways, but the result is the same - traffic will not flow.

Which makes this language on the pfSense interface config pages, though correct, probably in need of some adjustment for these devices:

Explicitly set speed and duplex mode for this interface.
WARNING: MUST be set to autoselect (automatically negotiate speed) unless the port this interface connects to has its speed and duplex forced.

Note looks good, however when we tested this, the issue happened on the ix ports as well (see #note-3).

Marcos M wrote in #note-8:

Note looks good, however when we tested this, the issue happened on the ix ports as well (see #note-3).

All ix or just ix on 4100/6100? If only on 4100/6100, is it just the copper/RJ45 combo ports, or all ix ports on the 6100? Since the SFP would be locked to the speed of the module it's not clear how it might behave if the fiber module supports multiple speeds on the 10G SFP ports of the 6100. I'm curious if anyone has testing the behavior on SFP with a 1G/10G module on both ends and trying to force it to 1G. The GUI does offer a choice of limiting the media speed like it does for traditional ports.

For ix, it's the same on the 4100/5100/6100. I only see testing history on the RJ-45 ix ports, not SFP.

This should be better now:

https://gitlab.netgate.com/docs/pfsense-platforms/-/commit/ce3288bce4b70211f1296deddaa2c51a76c3927b

While there I also added notes about copper SFPs:

https://gitlab.netgate.com/docs/pfsense-platforms/-/commit/2e583df39e401b2821d109b5359c47deee46c248

(Which replaced some items in an alternate branch I cleaned up).