PfSense on a Riverbed Steelhead

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. :)

stephenw10

@stephenw10 said in PfSense on a Riverbed Steelhead:

I would guess ~30W

@Okijames said in PfSense on a Riverbed Steelhead:

currently idling at ~27W

Ha.

freska99

@pauloalb

I have a Riverbed 1050L with 2 InPath or 4Gbe NICs and am trying to enable them for PfSense, except the I2C Layout looks a bit different. I have been probing with i2ctools.

[root@localhost~]# i2cdetect -l
i2c-3 i2c nvkm-0000:08:00.0-bus-0005 I2C adapter
i2c-10 i2c nvkm-0000:08:00.0-aux-000c I2C adapter
i2c-1 i2c nvkm-0000:08:00.0-bus-0001 I2C adapter
i2c-8 i2c nvkm-0000:08:00.0-aux-000a I2C adapter
i2c-6 i2c nvkm-0000:08:00.0-bus-0008 I2C adapter
i2c-4 i2c nvkm-0000:08:00.0-bus-0006 I2C adapter
i2c-11 i2c nvkm-0000:08:00.0-aux-000d I2C adapter
i2c-2 i2c nvkm-0000:08:00.0-bus-0002 I2C adapter
i2c-0 i2c nvkm-0000:08:00.0-bus-0000 I2C adapter
i2c-9 i2c nvkm-0000:08:00.0-aux-000b I2C adapter
i2c-7 i2c nvkm-0000:08:00.0-bus-0009 I2C adapter
i2c-5 i2c nvkm-0000:08:00.0-bus-0007 I2C adapter
i2c-12 smbus SMBus I801 adapter at 0400 SMBus adapter <<---- I am assuming it is i2c-12 or the SMBUS

However I found several slave addresses:

[root@localhost ~]# i2cdetect -y 12
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 19 1a 1b 1c 1d -- 1f
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2f
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- 48 49 4a 4b 4c 4d 4e 4f
50: 50 -- 52 -- 54 55 56 57 58 -- -- -- -- -- -- --
60: 60 61 -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[root@localhost ~]#

No 0x24, but 0x48 appears with the following:

[root@localhost ~]# i2cdump -y 12 0x48
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 27 00 4b 50 XX XX XX XX XX XX XX XX XX XX XX XX '.KPXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

From the command:
smbmsg -s 0x48 -c 0x55 -06 0x03 0xfc 0x01 0xfe 0x66 0x99
I gather it means write 6 Bytes to SMBUS address 0x48 with initial command byte of 0x55 the data "0x03 0xfc 0x01 0xfe 0x66 0x99"

But in my case or for the RB1050L, it looks like 0x48 is only 4Bytes wide, and the command sends anywhere from 6Bytes for "Universal Mode" and 8Bytes for "Bypass/NoLine"

Can anyone that has this working please provide a dump of their 0x48 of their SMBUS so we can see what data should be there? Will the data we write show up at that address location? I don't feel comfortable writing things to random addresses that can potentially damage something.

Okijames

For the add-on cards you're probably best off using native drivers from the manufacturer. Silicom was a popular supplier, and they offer FreeBSD drivers, see if you can find your card here...

https://www.silicom-usa.com/cats/server-adapters/networking-bypass-adapters/gigabit-ethernet-bypass-networking-server-adapters/

freska99

@Okijames The InPath NICs in the Riverbed 1050 which I have, are actually embedded into the motherboard.

Okijames

@freska99 Oops, sorry memory isn't what it used to be. :)

So the problem from here is multifold. We would need to know several things, some easier than others...

-What CPU chipset / smbus controller is in use? Clues in dmesg and/or physically looking at the chips

-What's the command structure for said chipset? Find Intel docs

-Find the correct smbus address for bypass control. As you've done above, it is a moderate amount of poking/guessing.

-Guess the correct byte sequence to flip the relays. This seems pretty difficult! The numbers for the 250/550 were taken from code in another project. I have no idea how the original author figured out the correct byte sequence. Guessing he had inside knowledge.

Okijames

FWIW I'm assuming you tried looking for settings in the BIOS. Wishful thinking, but the 570/770 do have such BIOS settings so maybe...

Or setting the nics to stop failing to bypass in RIOS?

no interface <interface-name> fail-to-bypass enable

Okijames

Whatever you do, please find and read the chipset docs before poking around with the smb read or write commands. I somehow permanently set my 550's 1.66GHz CPU to 1.33GHz. No telling what else I could have screwed up if, for example, I randomly guessed byte sequences :)

freska99

@Okijames Thanks for the quick reply:

The board looks like a modified Tyan server board running with Intel ICHx SMBUS controller with Intel Xeon 2Core 1.88GHz, I was able to read from the SMBUS using ICHx drivers in both Linux and under RWEverything in Windows (although in Windows the address is 2x or double the HEX value given to the i2cdump command for some odd reason)

Yes I already tried looking in the BIOs there are only options to enable / disable the PRI/AUX Interfaces. The command 'no interface <interface> fail-to-bypass enable' has also been tried. All it does is causes the ports to go into "BLOCK MODE" so it will neither bypass nor work (under the OS it shows as Ethernet Disconnected). The BYP/BLK LED is turned on. Bypass causes the same issue with Ethernet Cable Disconnected except the relays form a physical path from one physical port to the other.

The real question I am trying to answer is what is the address of the microcontroller driving the relays. I am thinking that there might be a "signature" or "fingerprint" if someone dumped the contents of address 0x48 from the 250/550, that the contents might be similar to what I have on the 1050 so I can co-relate the correct address.

I will try taking a look inside for what specific chips are being used tomorrow. I am quite paranoid about writing anything to SMBUS especially when hardware models/revisions do not match the python script or what others are discussing, so more research is needed.

stephenw10

One of the problem you have here is that a lot of smbus devices are auto-addressing. The controller we were looking at appears at a different address in FreeBSD than it does in Linux. Your may well also.

Steve

Okijames

@freska99 The only process I can think if is laborious but that only makes your eventual success that much sweeter right?

-1 RTFM: Get the chipset docs and determine the proper commands for READING the smbus settings. Note that first and subsequent read operations may return different results. The smbus is touchy! The read operations may actually cause changes, though I think they are temporary.
I hope not, but you might literally have to reboot after reading each address.

-2 Get a baseline: Scan and READ your smbus infra under Linux and FreeBSD. Document and compare the (probably different) addresses, current settings etc. Do your best to "align" the addresses, accounting for OS and driver differences. Linux seems to have better tools, but you'll eventually have to translate to BSD for pfSense. Note: I am assuming that both of the inpathx_y are setup identically with regard to their "fail-to-bypass" setting. If not, set them identically and redo this step.

-3 First test: Boot back into RIOS and disable link state propagation with "no in-path lsp enable". Why? First you don't want LSP anyway, read the support docs if curious. Second, it might make 2 or 4 of your smbus addresses disappear. On my 550 it made 0x64 and 0x66 disappear. Fewer devices to scan and probe. Unfortunately it also caused me to guess that 0x60 (the next closest address seems logical right?) was the relay control address, but NOOO, it was ) 0X48. I issued the smb write command to 0x60, and 0x5c, resulting in a seemingly permanent slower clock rate for my CPU. :(
Anyway... Boot back to Linux/BSD, take note of the address disappearance. This should help with the whole "aligning" of addresses under the different OSs.

-4 Setup a diff: Luckily you have a 4port on-board bypass nic, so 2 sets of" inpathx_y" port pairs under RIOS. Boot back to RIOS and setup inpaths with opposite configs, for example...

interface inpath0_0 fail-to-bypass enable
no interface inpath0_1 fail-to-bypass enable
write mem

-5 Scan for diffs: Boot back to Linux/BSD. Hopefully you will find that register settings under one of the smbus addresses has changed. Make note of the register settings that appear to equate to the different bypass states.
You may want to try one more diff with inpath interfaces enabled and disabled with...

in-path interface inpathx_y enable
no in-path interface inpathx_y enable
write mem

-6 Apply your discovered register settings under BSD. Success?

Not 100% sure but I think the "normal" nic behavior you want under pfSense equates to the following RIOS settings...

in-path interface inpathx_y enable (enables the nics)
no interface inpathx_y fail-to-bypass enable (disables fail-to-wire between ports)
no in-path lsp enable (does not propagate link down state to between ports)

The nics might then need to be configured and "up"ed under pfSense. You may need to drop to shell to do this.

freska99

@Okijames I have started looking into the manuals regarding the chips I found inside the box and doing some of your suggestions. Of interest are the following:

The InPath NICs have 2 Intel controllers under heatsink, each controllers handles two ports
Next to each of these controllers are ATMEL 932 25160AN EEPROMs using being addressed thru SPI Serial Interface
(The Primary and AUX NICs also have one controller each but they use ATMEL 952 25640AN EEPROMs instead)
Found an I2C / SMBUS TMP75 Temperature Sensor, looking into this to narrow down addresses based in its output
Found Three of these Chips: PCA9556 Octal SMBUS & i2C Registered Interface
Found PA9516A NXP 5-Channel I2C Bus Hub
Found two unknown chips on either sides of and right next to the relays labelled "4965 AD .W03B"
Didn't find anything that is suggestive of a Microcontroller like the nxp lpc932a1fa located in other models

Also was looking into the code under RIOs and it looks like a lot of it is written in Python. Came across one interesting file called "hw_ctl.py". It states sequence for bypass as:

elif val == 'bypass':
    set_val(turn_on(curr, range(7)), 0x32)
    set_val(turn_off(curr, 6), 0x32)
  set_val(turn_on(curr, 6), 0x32)
    curr = get_curr(0x32)
    set_val(0xff, 0x30)
    set_val(rest, 0x30)

Function of: set_val(new_value, register_to_read_or_write_to)

To Read the registers:

curr = popen("%s %s 0x1 0x0 2> /dev/null" % (ipmi_cmd, reg)).readline()[:-1]
There there is a comment that if "curr" is empty the message "could not talk to i2c device" is displayed

To set the registers with a sequence for bypass, disconnect, normal etc..

popen("%s %s 0x0 0x1 %s 2> /dev/null" % (ipmi_cmd, reg, hex(new)))

The reg variable is named "rest = 0x30" and "curr=0x32" not sure how they differ

The popen function just opens a tool, in this case "impitool", the ipmi_cmd variable is:
/sbin/ipmitool raw 0x6 0x52 0x7

So to read the value of the NICs i think it would be
ipmitool raw 0x6 0x52 0x7 0x32 0x1 0x0 (curr register)
ipmitool raw 0x6 0x52 0x7 0x30 0x1 0x0 (rest register)

The syntax would be:
ipmitool raw 0x6 0x52 0x7 <register> <read=0x1 0x0 | write=0x0 0x1> [new value if writing]

I will next try to break into the shell of RIOS and test these commands and scripts. The device does have an IPMI IP Addresses so I might even able to set the states thru the network. We will see.