Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense on a Riverbed Steelhead

    Hardware
    19
    154
    61.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      pauloalb
      last edited by pauloalb

      Hello everyone,

      I recently got a Rivebed Steelhead 250L identical to the on the image.
      There is a jumper that (J20) located beside the connection between the power supply and the motherboard.
      Just tried it now and it resets the bios settings :( not the bypass ports.

      I am trying to get ESXI or PFsense or FreeNAS to work on it now.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        So you also have ports stuck in by-pass mode? No BIOS access?

        Steve

        P 1 Reply Last reply Reply Quote 0
        • P
          pauloalb @stephenw10
          last edited by

          @stephenw10 Thanks for the reply. Yes they are not turning on. I do have bios access ( pressing del on startup) but no option there to change any setting regarding network.

          Tried:
          Fail-to-Block CLI commands:
          • no interface <interface-name> fail-to-bypass enable: Sets the interface to block when there is a failure.
          • interface <interface-name> fail-to-bypass enable: Sets the interface to bypass when there is a failure.

          Curious that i hear no clicks when i execute the commands, maybe power is already applied.

          When running on RIOS, these commands do turn the lights off/on on the ports. After reboot and boot from pfsense on usb, the ports remain off. Pfsense detects all ports but only AUX and Primary usable.

          I have tried also to install ESXI / Freenas on this appliance with no success even booting.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • O
              Okijames
              last edited by 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.

              O 1 Reply Last reply Reply Quote 0
              • O
                Okijames @Okijames
                last edited by

                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/

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by 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?

                  1 Reply Last reply Reply Quote 0
                  • P
                    pauloalb
                    last edited by

                    @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

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by 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

                      P 1 Reply Last reply Reply Quote 0
                      • P
                        pauloalb @stephenw10
                        last edited by

                        @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...

                        O 1 Reply Last reply Reply Quote 0
                        • O
                          Okijames
                          last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • O
                              Okijames
                              last edited by

                              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

                              1 Reply Last reply Reply Quote 0
                              • O
                                Okijames
                                last edited by

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

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • O
                                    Okijames @pauloalb
                                    last edited by

                                    @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" .

                                    O 1 Reply Last reply Reply Quote 1
                                    • O
                                      Okijames @Okijames
                                      last edited by

                                      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.

                                      1 Reply Last reply Reply Quote 1
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by 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

                                        O 1 Reply Last reply Reply Quote 0
                                        • O
                                          Okijames @stephenw10
                                          last edited by

                                          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!

                                          O 1 Reply Last reply Reply Quote 1
                                          • O
                                            Okijames @Okijames
                                            last edited by

                                            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.

                                            1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post