PfSense on a Riverbed Steelhead

stephenw10

Ok, so unless you can see any jumpers that might set them then, as I said two years ago, you will have to start poking at GPIOs to try to find what controls them. You might find a clue in the RIOS boot logs or filesystem.

Steve

Okijames

Regarding GPIOs, rather than poking around thi maybe this can be of use. Using ipmitool under Linux, these commands are said to enable inpath nics. Never tried it myself.

ipmitool -v raw 0x3e 0x20 0x80 0x7f 0x00 0x00
ipmitool -v raw 0x3e 0x20 0x80 0x7f 0x01 0x00

I think the above alters some i2c registers to do the trick. Try it under Linux first. If it works, try a FreeBSD method for setting such registers.

I took a look at the, again Linux based, approach used by rbMode on github. That guy's script refers to SMBUS and I can't figure how how SMBUS addresses relate to the ipmitool addresses.

Okijames

Quick note: Riverbed used Silicom bypass nics in their larger appliances. Silicom has FreeBSD drivers with source code on their web site. The source code might provide insight into methods for enabling your bypass nics. URL for Silicom 2port bypass nic here....

https://www.silicom-usa.com/pr/server-adapters/networking-bypass-adapters/gigabit-ethernet-bypass-networking-server-adapters/pe2g2bpi80-bypass-card/

stephenw10

Hmm, yeah that's interesting. It could almost certainly be done just using shell script then. Just need to figure out the smbus addresses......

ipmitool is already installed though and takes the same input as Linux so should would if that data in correct. Though it still requires an IPMI device of some kind in raw mode.
Anyone able to test it?

pauloalb

@Okijames said in PfSense on a Riverbed Steelhead:

ipmitool -v raw 0x3e 0x20 0x80 0x7f 0x01 0x00

Just tried it on my riverbed 250 and unfortunetly it did not work. Error is:

Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No such file or directory

There is a python script that i have tested to work but only on linux, Debian in my case. Pfsense's FreeBSD no luck so far.
Maybe the script can help : Script

stephenw10

What happened when you ran rbmode in pfSense? What error?

You probably have to load the smbus drivers for that to work:

kldload ichsmb
kldload smb

Steve

pauloalb

@stephenw10 said in PfSense on a Riverbed Steelhead:

kldload smb

Hello,

Thank you stephenw10 for your help.
First the script imports smbus module but cant find it. I had to install pip and then smbus2 and change the script. That error went away.
I executed the kldload commands with "success".

After that rbmode gave this error:

[2.3.5-RELEASE][root@pfSense.localdomain]/usr/local/sbin: rbmode u
Setting mode to universal

Traceback (most recent call last):
File "/usr/local/sbin/rbmode", line 78, in <module>
main()
File "/usr/local/sbin/rbmode", line 70, in main
setMode(args.mode)
File "/usr/local/sbin/rbmode", line 38, in setMode
s = smbus2.SMBus(0)
File "/usr/local/lib/python2.7/site-packages/smbus2/smbus2.py", line 279, in init
self.open(bus)
File "/usr/local/lib/python2.7/site-packages/smbus2/smbus2.py", line 308, in open
self.fd = os.open(filepath, os.O_RDWR)
OSError: [Errno 2] No such file or directory: '/dev/i2c-0'

Indeed there is no /dev/i2x-0 but there is a /dev/smb0 so i replaced the reference in smbus2.py from i2c to smb but then another error occurred after re-executing rbmode:

IOError: [Errno 25] Inappropriate ioctl for device

Note: I got this script to work on Debian flavour of linux with success.

My knowledge of python is very very low as is FreeBSD so i am stuck at the moment...

Okijames

FWIWI tried compiling the Silicom drivers on a FreeBSD 10.3 (to match pfSense 2.3.5) and turns out the bpmod.ko kernel module (note this is pre-built, NOT actually available as source code in the driver package) won't work, it complains about not finding a Silicom card, as expected I guess...

stephenw10

With those smb modules loaded try running: smbmsg -p

That should return all the available smbus devices available. But it also might hang the bus or even the whole box so be ready to power cycle it. It will probably list some things though. Hopefully including 0x24.

The smbus python tools appear to be more like raw i2c tools. The actual output command in rbmode appears to write to a device at 0x24 with subaddress (or smbus command) 0x55 and whatever the output of that checksum function is. My python sucks!

Steve

You can probably do that easily enough with smbmsg.

Okijames

root@:~ # kldload ichsmb
ichsmb0: <Intel 631xESB/6321ESB (ESB2) SMBus controller> port 0x540-0x55f irq 19 at device 31.3 on pci0
smbus0: <System Management Bus> on ichsmb0
root@:~ # kldload smb
smb0: <SMBus generic I/O> on smbus0
root@:~ # smbmsg -p
Probing for devices on /dev/smb0:
Device @0x10: w
Device @0x48: rw
Device @0x5c: rw
Device @0x60: rw
Device @0x64: rw
Device @0x66: rw
ichsmb0: device timeout, status=0x41
ichsmb0: device timeout, status=0x41
ichsmb0: device timeout, status=0x41
ichsmb0: device timeout, status=0x41

Okijames

That's what I get, and then the "device timeout" messages continue forever. Rerunning smbmsg -p shows nothing but the timeout messages, so pretty much need to reboot after running once. No x24 addresses of course! curses...

stephenw10

Hmm. Have you also seen that script work in Linux?

I could imagine the device might come up at a different address in FreeBSD perhaps...

Okijames

@pauloalb Since you got the script to work under Linux...

What were the values for "calcCheckSums" in this bit of the script?

s.write_block_data(0x24, 0x55, calcChecksums(cmd_0))
time.sleep(0.1)
s.write_block_data(0x24, 0x55, calcChecksums(cmd_1))

This would give us clues as to what we should give smbmsg to send the same values under BSD. Changing the 0x24 address location per what we see from using "smbmsg -p" .

Okijames

Per some docs...

write_block_data(i2c_addr, register, data, force=None)
Write a block of byte data to a given register.
Parameters
• i2c_addr (int) – i2c address
• register (int) – Start register
• data (list) – List of bytes
• force (Boolean) –

So I'm thinking the smbmsg equivalent could be something like this per my smbus scan...

smbmsg -s 0x48 -c 0x55 -o 3 0x?? 0x?? 0x??

With the ?? pieces being the values the rbmod script calculates in the above bit of python.

stephenw10

With some extra print calls and no actual smbus writes:

steve@steve-MMLP7AP-00 ~/Documents $ sudo ./rbmode.py u
[sudo] password for steve:      
Setting mode to universal
[3, None]
[3, 1]
[3, 252, 1, 254, 102, 153]
[3, 0]
[3, 252, 0, 255, 102, 153]

So I expect the required smbmsg command to be something like:

smbmsg -s 0x24 -c 0x55 -o 6 0x03 0xfc 0x01 0xfe 0x66 0x99
smbmsg -s 0x24 -c 0x55 -o 6 0x03 0xfc 0x00 0xff 0x66 0x99

BUT I'm unsure how the checksum applies. i2c doesn't have a checksum but the script calculates the checksum from the data because smbus does. So if smbmsg does the checksum for us it might be:

smbmsg -s 0x24 -c 0x55 -o 2 0x03 0x01
smbmsg -s 0x24 -c 0x55 -o 2 0x03 0x00

That all depends on 0x24 being the real device address....

Steve

Okijames

Considering this comment was in the rbmode script all along...

universal

port 0: 06-03-fc-01-fe-66-99 -> 0x03, 0x01

port 1: 06-03-fc-00-ff-66-99 -> 0x03, 0x00

Lines up precisely with your converted output and possible smbmsg commands...

smbmsg -s 0x24 -c 0x55 -o 6 0x03 0xfc 0x01 0xfe 0x66 0x99
smbmsg -s 0x24 -c 0x55 -o 6 0x03 0xfc 0x00 0xff 0x66 0x99

I guess the info was staring us in the face this whole time :)

Now will it work? smbmsg syntax is cryptic, but will give it a go.

Thanks!

Okijames

Huge thanks to Steve, his print output of rbmode filled in the final pieces!

First a bit of a caveat: I did this with FreeBSD 12.1. I used a full install of a current FreeBSD version to improve chances of stuff working, have access to extra tools, drivers, etc. that are not in pfSense, let alone and old version of pfSense.

One thing to note BTW is 12.1 installed from a USB key inserted in the front panel directly to an internal SATA without issue. FreeBSD 10.3 and pfSense 2.3.5 based on same were unable to install directly to an internal SATA.

So anyway...

Success! Instant relay click and nic link lights with the first smbmsg command below! LAN0_0 (em0) and WAN0_0 (em1) both working!

Note they nics did require an "ifconfig emX up" before they could be used but that's to be expected.

smbmsg -s 0x48 -c 0x55 -o 6 0x03 0xfc 0x01 0xfe 0x66 0x99
smbmsg -s 0x48 -c 0x55 -o 6 0x03 0xfc 0x00 0xff 0x66 0x99

The second command doesn't seem to do anything but does not return an error. I rebooted, which does reset the relays, and tried the second command alone, still doesn't seem to do anything, good or bad.

So next steps would entail getting the following on pfSense, if it's not already there...

-ichsmb.ko
-smb.ko
-smbmsg

Then alter boot-up config to load the kernel modules and issue the smbmsg commands automatically.

I won't be doing any of the pfSense bits cause I don't actually want to run a 32bit box. It just always bugged me that half the nics wouldn't work without the original software.

Anybody want to buy one? :)

I think I have 2 250s and 2 550s. The 550s for sure (because that's been my box for all this hackery) have a Xeon Sossaman and 4GB ECC RAM. IIRC the 250s have a Celeron and 2GB ECC RAM. No USB DOMs, no HDDs, no software.

stephenw10

The modules are there in pfSense, just not loaded. To run that you would need to add to /boot/loader.conf.local:

ichsmb_load=yes
smb_load=yes

Then run that smbmsg with a shellcmd at boot. Pretty easy.
Of course not if that is 32bit hardware though.

I assume the second line is for larger models that have two pairs of ports.

The fact that code was already in the comments there was confusing. The way it's written looked like they got the i2c output from original OS maybe. The extracted the actual commands from it. But then recreate the same string by calculating the checksum... odd.

Steve

pauloalb

Special thanks to @stephenw10 and @okijames and everyone that helped.

I am on my lunch break so i couldn't test this much but i call this a SUCCESS! Both nics do light up and show activity.

I am running this on a Rivebed Steelhead 250 with pfSense 2.3.5 running from a flash drive plugged in the front of the device with no hdd and no subonModule internal flash plugged in.

The exact sequence that worked for me, gathering all the bits from previous messages is this:

kldload ichsmb
kldload smb
ifconfig em0 up
ifconfig em1 up
smbmsg -s 0x48 -c 0x55 -o 6 0x03 0xfc 0x01 0xfe 0x66 0x99
smbmsg -s 0x48 -c 0x55 -o 6 0x03 0xfc 0x00 0xff 0x66 0x99

Thanks again for the fantastic comunity support and engagement from everyone

pauloalb

stephenw10

Nice!

Interesting that it's apparently at a different address in FreeBSD/pfSense.

I wouldn't expect you to have to ifconfig up the interface assuming it is assigned and enabled. Usually in that sort of setup the relays disconnect the physical ports but the OS can always see the NIC chip.

Steve

Okijames

@stephenw10

Yeah, different drivers so different reference address I guess.

You're right re "ifconfig up" requirement, under pfSense anyway. Going through the nic assignment process and ticking the "Enabled" box gets them up and running.

Okijames

Ok I wrote a full soup-to-nuts howto on this whole thing but it keeps getting flagged as spam and won't post. Any pointers?

The issue seems to be the text related to shellcmd entries in the pfSense config file. I literally dare not include it here or this post would be blocked. :(

stephenw10

Try again. I upvoted your posts so you have the required rep level, 5, that should avoid the filter.

It looks like you wrote this and then deleted it a number of times. I could try to recover those?

Steve

Okijames

@stephenw10 Thanks for the upvote and please delete those other posts. I'll try posting the whole thing right now...

Okijames

@stephenw10 No joy, still getting flagged as spam.

stephenw10

Hmm, maybe a combination of the IP you're coming from? Maybe remove any links you have in the post?

Okijames

@stephenw10 There are not links :) . Just this piece seems to be the problem.

	<shellcmd>smbmsg -s 0x48 -c 0x55 -o 6 0x03 0xfc 0x01 0xfe 0x66 0x99</shellcmd>
</system>

Okijames

Ok that's weird :)

Okijames

Here’s what I hope is a full soup-to-nuts process for getting pfSense 2.3.5 up and running on these boxes with all 4 nics active…

Prep work and nic mapping info:
-Remove the internal USBDOM boot device, label it and keep it safe incase you ever want to run as a Steelhead again
-Remove the internal HDD (remove the whole drive cage, just 3 screws and lift the cage straight up and out)
-Optional: Label and put the original HDD aside and keep it safe incase you ever want to run as a Steelhead again

-Nic mapping in pfSense compared to front panel labeling:
em0 = LAN0_0
em1 = WAN0_0
em2 = Primary
em3 = Aux

BIOS setup:
-Connect to serial port using 9600 8,none,1 then power up

-Hit Delete key during BIOS initialization, use “minnow” when prompted for a password and change these settings…

-Exit Menu -> Load Optimal Defaults (do this first)

-Advanced Setting Menu -> Configure Remote access -> Serial Port Mode “115200 8,n,1”

-Optional: Boot Menu -> Quick Boot “Disabled” (this will give you more time to hit the Delete key and plug USB devices in in the future)

-Boot Menu -> Boot Settings Config -> USBDOM Boot Only “Disabled”

-Boot Menu -> Boot Device Priority (should not need to be changed, but take note and adjust if needed)

-Exit Menu -> Save Changes and Exit -> Hit Enter twice to save changes

Note regarding the roundabout installation instructions below:
Unfortunately attempting to install pfSense 2.3.5 directly to an internal SATA drive fails, getting stuck with messagings like…
(ada0:ahcich0:0:0:0): CAM status: Command timeout
(ada0:ahcich0:0:0:0): Retrying command
FWIW newer versions of FreeBSD have no such issue, v12.1 for example installs directly to an internal SATA drive just fine.

pfSense 2.3.5 Installation:
-Switch your serial port terminal settings to 115200 8, none, 1 (you should never have to crawl at 9600 again)

-Insert a USB key with the installer in the top USB port on the front panel (shows as da0 in pfSense)

-Connect a SATA drive via USB-to-SATA adapter to the bottom USB port on the front panel (shows as da1 in pfSense)
—Note my SATA drive would not power up from a cold start, I had to plug it in after power-up, during the memory count

-Power up and the box should automatically boot from the USB key
—If not, leave the USB key and SATA drive connected, reboot into the BIOS and set to boot off the USB key and reboot

-Hit “I” to launch the Installer or let it boot automatically

-Install pfSense per standard instructions (Quick/Easy Install worked for me)

-Choose “Embedded kernel (no VGA console, keyboard”) when prompted

-Reboot when prompted and power down

-Remove the USB key

-Move the SATA drive to the top slot of the internal drive cage and this will now show up as ada0
—Note if you install a 2nd drive in the bottom bay it will show up as ada1

-Power-up and pfSense should boot from the internal SATA drive

-Configure the LAN and WAN ports to em2 and em3 (my recommendation is em2=LAN em3=WAN)
—Why not use em0 and em1 for LAN and WAN? Because em0 and em1 CAN be set to bypass/bridge mode which causes them to act as a hard wired crossover coupler. This is the normal mode of these nics when running Steelhead software. In that state, EVERYTHING will pass between them like a wire, regardless of power being on or off. Not good for a firewall unless you have a special need for this capability.
—Special note regarding POE and em0/em1: These boxes have a design defect related to POE so you MUST use the supplied 2-port dongle if you intend to connect em0 and em1 to POE ports. Doing so without the dongle risks damaging your POE devices.
—If you want to play with the bypass/bridge mode, just issue the below command at a shell prompt… Final word of warning, DO NOT connect both ports to the same switch when you do this. It’s the same as doing so with a crossover cable.
smbmsg -s 0x48 -c 0x55 -o 8 0x02 0xfd 0x01 0xfe 0x00 0xff 0x88 0x77

Automatically enable em0 and em1 so you can use them as normal nics:
-Drop to shell and add the following to /boot/loader.conf.local to load the smbus drivers
ichsmb_load=“YES”
smb_load=“YES”

-Follow pfSense docs to modify your config.xml to with shellcmd to issue the following smbmsg command just above the </system> line…

	<shellcmd>smbmsg -s 0x48 -c 0x55 -o 6 0x03 0xfc 0x01 0xfe 0x66 0x99</shellcmd>
</system>

-Basic workflow for modifying your config.xml if you don’t want to read the docs, do the following via the Web UI…
1: Main Menu-> Diagnostics -> Backup & Restore Menu -> Download configuration as XML (it will download via your browser)
2: Edit the downloaded file adding the smbmsd command just above the existing line containing </system>, save the edited file
3: Click the Choose File button, select the edited file, click the Restore Configuration button
4: pfSense should restore the file and automatically reboot

Upon reboot, and toward the end of the boot process you should hear a nice “click” sound from the bypass relays, enabling em0 and em1, and you should have 4 usable nics under pfSense

stephenw10

Ha. Maybe the few more upvotes I gave you.... though the level is set at 5.

You can use the shellcmd package to add that without manually editing the config.

Okijames

@stephenw10 Just glad it worked! Roger on using shellcmd package, I have not tried it.

pauloalb

Excelent tutorial @Okijames ! I am currently running pfSense235 from a usb stick and as i can now access all ports, i will make an hdd install and follow it to configure the steelhead 250 i got.

A little off topic but this unit came with 1gb pc2-3200 ecc rec ram stick and an empty dimm slot. You have any idea of that is the max ram this can take using both slots?

cheers,
Paulo

Okijames

@pauloalb Max RAM I have tried is 4GB in my 550s using 2 2GB pc2-3200 ECC sticks. The 250/550 are based on the same "Minnow" chassis and motherboard so will likely be ok with 4GB too.

Okijames

So this thread prompted me to dig though boxes in the o'l garage and I found a Steelhead 770. Decent specs on this puppy.

-CPU Xeon E3-1125C v2 (4core 2.5Ghz)
-RAM 4GB with 2 x 2GB DDR3 ECC sticks in two of four available slots.
-2 2.5" SATA drives (320GB 72K HDD, 160GB Intel DC S3500 SSD)
-NICS 6 Intel Gigabit NICs total
-2 "normal" NICs as Primary and Aux,
-4 (2 pairs) bypass type NICs.
-NIC bypass control is available in the BIOS plain as day

Installation of pfSense 2.4.4 was a breeze. All 6 NICs show up, no smbus shenanigans needed.

I'm happy with my APU2 for pfSense, but this thing is just begging to replace it. Someone stop me! :)

johnpoz

@Okijames said in PfSense on a Riverbed Steelhead:

Steelhead 770

Only drawback to a box like that might be power consumption.. Its going to how much higher than your APU2?

And fans - how much louder is it going to be?

stephenw10

Yeah hard to beat the APU2 in terms of power consumption and noise.
But it's probably not that bad. I would guess ~30W. No clue about noise. I they gave the cooling setup right it need not be loud but...

Steve

Okijames

Thanks @johnpoz!

Yeah, 3-4x on the power consumption. Fans, though pretty quiet, are 100% louder than the fanless APU2.

Thinking I'll bump up the RAM and disk capacity and use it to experiment with various Container platforms.

johnpoz

Is it a SD770? From quick look those are about 50W idle - so more like 5-6x your apu2, and noise looks like about 45dba.. While not all that bad - sure isn't quiet..

Okijames

CX-770 currently idling at ~27W, not bad. And honestly the fans are pretty quiet, faint background noise sitting right next to me on a desk. Might be near silent if I replaced them with some nice Noctuas.

Under load though, I'm sure it wouldn't be quite so pleasant.

Okijames

2 Noctua NF-A4x20 PWM ordered. :)