Riverbed Steelhead 550 - gpio
-
Does anyone know how to get /dev/gpio set up to run on a nanobsd image on a Steelhead? I'm interested because there's reference to being able to re-enable the WAN and LAN port NICs on a Steelhead via GPIO.
Threads:
https://forum.pfsense.org/index.php?topic=68045.0
and
https://forum.pfsense.org/index.php?topic=48906.0In the latter thread, user wacij (https://forum.pfsense.org/index.php?action=profile;u=139213) comments he was able to get these other two ports enabled, but never described how he accomplished it aside from stating
That was the issue, it wasn't the LAN by-pass but the LAN by-pass by GPIO option that needed to be disabled. I am getting link lights now. I will test them out later to make sure they work.
So, if anyone has pointers I'd love to hear them.
2.2.4-RELEASE (i386)
built on Sat Jul 25 19:56:41 CDT 2015
FreeBSD pfSense.sditx.com 10.1-RELEASE-p15 FreeBSD 10.1-RELEASE-p15 #0 c5ab052(releng/10.1)-dirty: Sat Jul 25 20:29:48 CDT 2015 root@pfs22-i386-builder:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_wrap.10.i386 i386 -
That's a shame - was hoping someone had a thought about how to go about this. :-\
-
One thing for certain - there's no option that I can see anywhere in BIOS that would impact this. It almost has to be something handled via GPIO, but I haven't had time to try to retrofit a GPIO driver into the nanobsd pfsense.
-
I left a previous post about an ebayer with the two ports duct taped off. It would appear I was wrong. I could have sworn there were two jumpers..It appears theat SHA250- is the same as SHA550? Just a different license I think.
-
I don't have a 250 to compare to this old 550 to be certain, but as I recall they were slightly different. The 1xx and 2xx series had a jumper onboard which could be used to enable/disable the bypass feature on those two ports. The sole jumper on the 550 mainboard has no impact on them from my testing.
While it does make sense that the port bridging could be controlled via software (and clearly that must be the case), I don't believe there's been any confirmation of a second person ever getting that working on this platform. So far it's just the 1 person posting they did it, and nothing from them explaining how beyond referencing that they used GPIO to disable the bridging.
Ultimately, you still get a usable device - it's just two ports of the four that are wasted until this can be sorted out. :o
-
Hallo, now I had the same problem with the Riverbed Steelhead 250 / 550 NIC LAN WAN ports.
And after several programming and testing I have a wrote a little C-Program for my Debian v8 to
activate the relay for the WAN-LAN bypass.My little driver can switch three states:
- bypass -> wan-lan directly connected
- no connect -> like open cable
- connect -> normal use als a NIC for WAN an LAN ports
So I need some one to test it.
-
My little driver can switch three states:
- bypass -> wan-lan directly connected
- no connect -> like open cable
- connect -> normal use als a NIC for WAN an LAN ports
So I need some one to test it.
Can you post your program here? I have a Steelhead 250 and would like to test it out.
-
I don't have a 250 to compare to this old 550 to be certain, but as I recall they were slightly different.
Very minor differences: dual-core Xeon Sossaman instead of single-core Celeron, and maybe 2Gb of RAM instead of 1Gb, plus software licensing (different No of connections, etc.) They are nice little server-class machines. I do love Intel 3100 chipset, the first and the only Intel chipset of its kind.
Bypass and disconnect features are controlled by a dedicated uC - NXP LPC932A1FDH, which resides on the SMBus. I do some sniffing while tinkering with the original software (att.).
It would be nice to control the bypass functionality, but which usage scenarios could be implemented? Simple "nobypass" after power-on? Or more complex scenarios?