Recently I came across these Riverbed-labeled quad-port i350 ‘bypass’ NICs up on eBay. They are unusually cheap, but seem to be at the edge of their manufacturer support lifetime and are somewhat confusing to actually utilize as a standard NIC. I will explain these to the best of my understanding, as well as how to both configure the card as a bog-standard i350 NIC or use the bypass capability for (very basic) failover purposes without configuring any additional software on the host.
Firstly, some disambiguation. Silicom is the manufacturer, it just seems that one of their major OEM customers for this particular product was Riverbed. The Silicom / Dell labeled variants are seemingly identical to the Riverbed labeled variants, though. Here is the product page. This contains information and driver downloads, though they are somewhat scattered and the English writing in the manual(s) is unfortunately very stilted, so it’s easy to misinterpret or miss what you’re looking for.
The ‘bypass’ capability of this card is referring to a capability to switch the card into a mode where it bridges network ports under certain conditions. More specifically, by default, the card is configured to connect port 1 to port 2, and port 3 to port 4 at all times, but it can be configured to, for example, act as a normal 4-port NIC while the host is up, then bridge the sets of ports together when the host is powered down, just as a very basic example. When you plug the card into a computer, you will likely see the network interfaces show up as expected, but if you plug a cable into them, the interface will not be able to get an IP address. This is normal, due to the fact that it is configured in bypass mode by default. As is, it just acts as a fancy looking two port Cat5 coupler. To configure the card, you will need a driver/module and a utility, “bpctl(_util)”. (I guess you might get one that has a configuration left over, I guess, if yours acts differently I wouldn’t be too worried - should work all the same)
Silicom provides these drivers, but they are somewhat stashed away. On their website, there is a download link on the page for these cards, but all the links except the ‘full CD’ one are broken, and that only contains the Linux drivers, for some reason. However, if you look in the URL of the broken links, you’ll see it’s attempting to get stuff from an FTP server: ftp://drivers@silicom.ftptoday.com/drivers/. So, fire up whatever FTP client you have hanging around, and grab them down from there. If you are prompted for a password, it is ‘all’. The archive that you want is “PxGxBP-SD_CD.zip”, which contains drivers for all supported OSes. I have taken the liberty of rehosting it on the Internet Archive, since.. who knows when these links are going to fully rot? The files in this archive were published 04/04/23, so if you check the FTP and the archive is newer than that, use that instead - and please, also back it up on the IA as well.
On Linux, these drivers are provided as source code. I personally had trouble building the module, it’s not updated for 6.x kernels and doesn’t build. I have read of a couple people building on more recent distros, but I am too much of a dumbass with a compiler to tell what the spew of differing compiler errors I’ve got across multiple distros with the 6.x kernel series really even means. Something to do with SMBus functions not being defined properly. There is another variant of these programs maintained by an outfit ‘RedBorder’ here, but I have not tried this yet. They seem to have redone the makefiles pretty significantly as well. It’s meant for RHEL9, which by my understanding is a 5.x kernel distro, so it might have the same issues, anyway.
I eventually went the route of booting up a Windows PE iso (to be specific, Hirens Boot Disk PE) to install the bypass module’s driver and use the bypass control utility, since settings seemed to persist across reboots according to most reports online (it does). Either way, the bpctl_util command acts fairly similarly on all platforms.
Firstly, if you are configuring on Windows, run bp.exe install. This will install the necessary driver for bpctl_util. On *nix platforms, load the kernel module. You then may need to run bpctl_util start before these commands will work.
Basic NIC
bpctl_util -d 1 set_std_nic
bpctl_util -d 3 set_std_nic
That’s all. Devices 2 and 4 are considered “slaves” (bleh) and are paired with interfaces 1 and 3. If you try to run these commands on them, you will get an error. Feel free to test, though, for all I know, your card won’t be configured this way. You may also be able to run simply bpctl_util all set_std_nic, but that seemingly did not work for me on Windows.
If this works, you’ll hear some clicking coming from inside the computer with each command (relays - fun!). Plug a network cable into all of your ports to ensure the interfaces get IPs properly. They should grab them down from DHCP just fine (if available) at this point.
Basic failover
bpctl_util -d 1 set_bypass_pwup off
bpctl_util -d 3 set_bypass_pwup off
This will disable the bypass mode when the computer is booted, but retain the default setting of entering bypass mode when power is turned off, bridging ports 1/2 and 3/4 when the host goes down. Example implementation: Modem <—> Firewall <—> Wireless router. Assuming you connect the modem and router via one of the pairs of ports, when the firewall goes down, the modem will be bridged to the wireless router.
Just as with the last commands, you should hear some relays clicking and the ports will work as normal. However, if you shut down the PC, you will hear the relays click again, and will be able to route a connection through the pairs of ports.
Other shit
There’s a lot that you can poke at with this bpctl_util. Unfourtunately, I’m not sure how much of the functionality works without the kernel module (assuming it’s being used in a Linux device here), so I have not poked at it yet. Just look at the readme included, and run the bpctl_util with no parameters (or ‘help’) to get a full list of the commands and options.
The kernel module seems to be just talking to the card over SMBus, so it’s probably possible to do stuff without the driver, or make a userspace driver for directly configuring and managing the bypass relays. I personally don’t care to reverse engineer this crap, since it’s working how I want to (basic failover) after configuration via Windows PE. Heck, they have a BSD version of the module, presumably for those running PF/OPNsense or some other BSD firewall, and that presumably still works fine as well.
Search terms, for finding on used websites: riverbed bypass, 410-00115-01 (low profile), 410-00047-01 (regular profile). Those search terms will turn up the ‘Riverbed’ labeled variants. For Dell/Silicom branded variants: PE2G4BPI35LA-SD / PE2G4BPI35A-SD, 1FT3W. The Riverbed labeled variants seem to be least expensive. There are other variants of these cards that use different Intel chips, but since these i350 cards are so cheap on their own and significantly more power efficient, I see no need to link people to those.
>> Home