Barracuda 310 NICs
-
I think you're right about the NIC LEDs being on J4/5.
That chip appears to be a 'Dual precision monostable multivibrator'. More research needed! I was expecting a timer of some sort and perhaps that can be configured as such. Your decription of how it functions indicates a timer. Here's what I would think happens. In 'Active' mode the box sends a signal every, say, 4 seconds that resets the timer such that it never reaches it's trigger point. If the box fails completely or the OS crashes it stops sending the pulses and the by-pass is triggered. In 'Hard Bypass' mode the box may have to set the bypass manually.
Both pins 5 and 6 are outputs so they could be doing different things. It's possible that one goes low and the other goes high to indicate the action would ever that might be. Anyway it should be fairly easy to measure it or discover it experimentally.
You are looking for 5V DC signal levels. Neither of those pins in ground, pins 18-25 are all ground but you can probably just use the metal chassis. Test between the case and pin 5 and then pin 6 in various modes if you can. Bare in mind that it might only signal every 5 seconds so test for at least that long.That site you linked to describes exactly what I had in mind. The fact that they used the parallel port for this may seem crude but it makes it very much easier for us. ;)
The reset button appears to have a number of functions it can perform depending on how long you hold it down for. Are you sure it's not connected to the parallel port?
Steve
-
Yeah I am not too sure what that Dual Precision thing is… But it may just be there for looks :) It could also be the relays that are time or relay for that matter as out of the 4 of them, it only sounds like 1 is doing something.
I've put a multimeter (set at 6V) on the pins and here are the results:
Pin 5 (blue) - Upon power, spikes to about 0.83V then drops immediately while posting. Then bounces around 0.02-0.03 after post and during Barracuda boot. Once the OS is fully booted, the pin jumps to 0.83V.
Pin 6 (black) - Constantly stays at 0V and once the OS is booted, goes up to 0.03V
Pin 7 - 1.18V constant
Pin 8 - 1.18V constant
Pin 9 - 1.18V
Pin 10 - 0.83V <-This one you were right on. It is the reset button, as when I take the multimeter off this pin, the system says rebooting, please wait... and reboots.Also, as for the modes, on my system I only have Active and Audit. They apparently only change how the filtration happens. I've also looked in the BIOS, and the Parallel Port Mode is Normal and the Address is 378.
Hope that helps!
Thanks again Steve.
Max
-
So it looks to me like pin 5 is our likely suspect. Even if it's not there's only two pins to choose from and two states on each so 4 possible tests. Since you didn't see it pulse at all I have to assume there's no proper watchdog action and that the software simply sets it to non bypass mode unless the box power fails. That does mean that if the OS crashed it wouldn't go back to bypass mode yet the timer seems to suggest it could. :-\ Maybe it was planned and never implemented for some reason. The whole thing looks like a bit of an afterthought. ::)
Ok so the box has 3 NICs yes so you can access pfSense via the rear NIC?
So whilst testing the hardware in the Watchguard boxes I 'wrote' (borrowed mostly!) two small programs to read and write directly the input output space. Download them to your box when it's running pfSense like so:
[2.2-BETA][root@pfSense.localdomain]/root: fetch -o /tmp https://sites.google.com/site/pfsensefirebox/home/readio /tmp/readio 100% of 6207 B 5193 kBps 00m00s [2.2-BETA][root@pfSense.localdomain]/root: fetch -o /tmp https://sites.google.com/site/pfsensefirebox/home/writeio /tmp/writeio 100% of 6136 B 5532 kBps 00m00sThen change the permissions on the files:
[2.2-BETA][root@pfSense.localdomain]/root: cd /tmp [2.2-BETA][root@pfSense.localdomain]/tmp: chmod 0755 readio [2.2-BETA][root@pfSense.localdomain]/tmp: chmod 0755 writeioNow you can use those to integrate the parallel port and change it. There almost no error checking in those and they can write to anywhere. So be careful! Since we have put them in /tmp they will be lost if you reboot.
The parallel port is at 0x378 as you said but it actually spans 3 registers, see: http://en.wikipedia.org/wiki/Parallel_port#Port_addresses
Pins 5 and 6 are on the base address, 0x378, on bits 3 and 4. So:[2.2-BETA][root@pfSense.localdomain]/tmp: ./readio 0x378 Reading 378 :37So on my box I see 37. This is actually a hexidecimal number representing an 8bit register.
3= 0011 and 7=0111 so the register is reading 00110111. The bits are numbered 0-7 with 7 being the most significant bit (furthest left) so on my box bit 3 is 0 and bit 4 is 1. That means pin 5 is low.To set pin 5 high we change bit 3 to 1. So the register reads 0011111 which is in hex 0x3f. To write that back we can use writeio:
[2.2-BETA][root@pfSense.localdomain]/tmp: ./writeio 0x378 0x3f Setting 378 to 3fAt that point you hopefully hear relays click and have access to the front ports. :)
Obviously you'll have to use whatever values your parallel port registers are set to.
Steve
-
You, kind sir, are a genius! That has worked to a T! :) Really appreciate your help with this.
Now I maybe "overstaying my welcome", but I have seen your Watchguard posts and looks like you have written a script to get an activity light on the LED's. Would it be possible on the cuda as well? Right now I have 2 LED's (Traffic and "Spyware Download") out of the 3 that are always on and might look neater if they were activity lights of sort… :D
Also, the LED in the left hand corner (red) turns off as soon as the NIC board gets enabled with the 0x3f command.
-
Thanks for saying so but really I'm no genius. The only reason I know any of this is because it's so similar to what we did on the Watchguard box and that took me days, weeks even when I first did it. ;)
Anyway controlling the LEDs will probably be easy. Are the wires to the front panel connected directly to the LEDs are via some logic chip?
Perhaps I didn't make this clear but the values I read from my box are very unlikely (but not impossible!) to be the same as on your box. You need to read the 0x378 register first and then modify it and write it back. Did your box coincidentally return '37' also?
Being able to read the reset button would require a lot more effort so lets ignore that, at least for now.
So we have the 5 output lines:
| Pin | Bit in 0x378 | Function |
| 5 | 3 | Enable NIC Bypass relays. 1=bypass disabled |
| 6 | 4 | ? |
| 7 | 5 | Red LED? |
| 8 | 6 | Yellow LED ? |
| 9 | 7 | Green LED ? |This assumes the connections are the same as in the spam filter references in the blog post above which seems reasonable.
You wrote 0x3f, 00111111 and that switched the NICs and turned off the red LED. The other LEDs remain on? That implies an inverted logic which is common. One side on the LED is supplied with ~3V and you switch it on by pulling the other side to 0V, logic low.
If you write out 0xff all the leds should turn off.
There's a problem here though because you wrote both bits 3 and 4 to high we don't actually know which pin is switching the NIC relays.
Reboot the box and read in the initial value at 0x378. You'll have to re-fetch the two programs.
Steve
-
Hey Steve,
Sorry work has got in the way over the last few. I have read the IO port without doing amy writing and I get back a zero '0' with no modifications.
You are correct. The parallel port wires go into some sort of a board, where the LED's are soldered on to.
-
No problem. So we need to narrow down which pins do what by writing to one bit at a time.
First try just pin 5 to make sure the relays are controlled by that. Try:./writeio 0x378 0x08If that's true then we can leave that connected and try the leds.
Try setting pin 9 to high:./writeio 0x378 0x88and pin 8:
./writeio 0x378 0x48and pin 7:
./writeio 0x378 0x28Did any of that do anything useful? :)
Steve
-
Yes, that has actually worked well. :D So to start with, when the cuda boots up, I have (looking from left to right) LED 1,2,3 ON, HDD blinks (as it should) and Power solid.
When I issue:
./writeio 0x378 0x08Relays click and the front ports come on. LED 1,2,3 are all on as per boot.
./writeio 0x378 0x88LED 3 turns off.
./writeio 0x378 0x48LED 2 turns off and LED 3 turns on
./writeio 0x378 0x28LED 1 Turns off and LED 2 turns on.
Hope that helps. Thanks again.
M
-
Ok, that's what we expected, great. :)
Still don't know what pin 6 does though. I would guess it's for 'patting the watchdog' if it's used. Probably not important here.
I'll try to knock together some code in the morning. We can probably use much of the code given in the linked site above.Steve
-
Ok, that's what we expected, great. :)
Still don't know what pin 6 does though. I would guess it's for 'patting the watchdog' if it's used. Probably not important here.
I'll try to knock together some code in the morning. We can probably use much of the code given in the linked site above.Steve
Awesome, thanks so much! Appreciate the help.
-
Right, try this. See attached files. They have a .png extension because the forum only allows certain types, just remove it. Set the file permissions.
I find it amusing that in his blog post Jim Barstow apologises for his code claiming he's not a C programmer. He's got plenty on me! ;) Any real programmer would cringe at my code but it seems to work. It has limited error checking. It can't do more then one thing at once so if you want to change two LEDs you have to call it twice, for example:./BCHW32 red on ./BCHW32 green offLet me know if that works at all. I spent some time late last night trying to debug something before I realised that the laptop I was testing on didn't have a parallel port. ::)
Steve
-
I actually have an application that could take advantage of this daughterboard and a Load Balancer 340 coming in the mail sometime in the next 2 weeks. The front nics in the 340 are just plain connectors with no watchdog circuit http://imgur.com/hcsuwTB I would be down to trade my plain board for anyone's board with the relays/watchdog circuit. If you are not good at soldering, just clip the black/blue wire from your parallel port and separate them with electrical tape. I don't want anyone damaging their motherboard! I have enabled forum members to email me, so hit me up. Thanks in advance!
-
Never heard back from Maxpol, maybe my code set fire to his box. ;)
Steve
-
Your code is good, I've basically done exactly the same thing on my own 310 - annoyingly, I was probably working it out myself around the time this thread was happening, I never thought to look on here, despite knowing you (stephen) as a helpful guy from my previous experimentation with a Lanner unit. The Barracuda came up for £1 on eBay about 5 minutes from home, so I figured it was worth a try.
cron410, where are you located? If you're in the US then you're probably out of luck, but if you're located in the UK then I could look into disconnecting my watchdog circuit from my 310 - it's an older revision than the one pictured here (pretty sure mine uses a PATA disk, from memory) but given that Barracuda have written the firmware to apply to all hardware revisions I would imagine that the behaviour is identical to this unit. I'm certainly 99% sure I've used the same values as maxpol did to activate my front ports and de-activate the LEDs (red disappears after bootloader, yellow disappears after fully booted, leaving only the green as a "everything's OK" indicator).
I intend to get pfSense working and pop it back on eBay as a fully-featured average-spec firewall rather than just a web filter but given that I don't really have time to write anything in the UI specifically for toggling the front ports on and off from the web interface, I don't 100% need the NIC module at this point in time.
-
I need your help. I am a victim of purchasing a barracuda 310 and the front NIC's are now working. I followed you procedure and I am getting a funny number back.
I did this : ./readio 0x378
And I am getting back: Reading 378 :0
I changed the parallel port in bios to a different number and ran ./readio and I keep getting back xxx:0
Now I'm not good with numbers but I know 0 means nothing. So I did ./writeio 0x378 0x0 and nothing happen.
Please I hope you get this message or anyone that can help me. I just purchased this off ebay and its a shame I may have to junk it.
Many Thanks!
-
I got it to work read on in the topic. I issue this command ./writeio 0x378 0x08 the LAN/WAN ports started to work .
But when I rebooted the box I had to fetch and redo the instructions. The lan ports are dead again after reboot.
What should I do?
Thanks
-
Sorry I figured that out I just loaded Shell pkg and added the command in it and rebooted and it works. All is well.
Thanks much!
-
So all good then? Glad you got it working. :)
You should be able to use the BCHW program rather than using writeIO to set the bits directly.
Steve
-
Once again Stephenw10 you are the man. I didn't see the post for BCHW. I just set it on the barracuda 310 and it works like a charm.
Thanks for letting me know and getting back to me so fast.
Many tanks!
-
Steven,
Sorry I know this is an old post but your the only person I can find that seems to have figured out the barracuda nic issue. Your programs work great for pfSense but I am trying to use them in Debian and apparently they are not compatible.. Is this something you could possibly recompile for debian/ubuntu?
Or point me in the direction of a comparable program to do the same?? I know nothing of programming or I would attempt to do it myself..
Thanks
