From: David W S. <dws...@ov...> - 2012-11-15 04:24:32
|
I am in possession of two Symantec 5420 Firewall appliances that contain an Iwill G478 motherboard and in Symantec's case, one of the optional Crypto Accelerators, a Broadcom BCM5823 is standard. Iwill themselves made a barebones appliance from this board only the Crypto Accelerator was an option and you had more choices than just the BCM5823. I believe HiFn was an option as well as one other. I started a special build tree for this appliance aside from the Cobalt stuff and managed to make an LFS that downloads the bcm58xx driver from Sourceforge and builds it. It builds two utilities that can read /dev/cryptonet, a separate libubsec.so that resides in /usr/lib NOT /usr/lib/engines. The driver package comes with a start script that loads the driver and makes the device node /dev/cryptonet. This script is copied to /etc/rc.d/bcm58xx. I had to do a minor patch to the driver source to make it look for the correct kernel otherwise it looks for the build host version. Beside the typical end user using rc.event.local to start it, what would be the logical place to start this script? It IS a service that can be started and stopped as most services can be. The other question is, does having this operating gain anything? Now that I have it building, loading and working, will the system use it? SHOULD the system use it if it even can? I thought since it is there I might as well build and load something to the bcm5823. It is an out of kernel driver as you might have concluded. Nobody pushed very hard for inclusion into the newer kernels as it needed updating to cover more than just the 5820 which was slower. This driver started as an outgrowth of the 2.4 kernel's bcm5820 driver to not only work with 2.6 and up but to cover newer faster chips. Here is the output of the two utilities which will only work if the driver is loaded and /dev/cryptonet is created as well as it's own /usr/lib/libubsec existing. It does not care about the same named library in the engines directory. Here we go, sorry about the email truncation: root@5420:~ # b58stats bcm58xx stats - (Public Key Ops): Dv| IKE| IKEfail| DHP| DHS| RPub| RPrv| DS| DV 1| 1| 0| 1| 0| 0| 0| 0| 0 | 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00 root@5420:~ # b58diag Card number 0 requested. 1 cards present in the system. Device type BCM5823 Revision 1. Driver version 2.10 succeeded. Side Facts: This appliance is a socket 478 and comes with a 2ghz Celeron and uses PC2100 ram, has six 82551 Intel Nics built in, has two usb ports which support USB2 and one com port. Com2 is used for the 16x2 lcd. It does have headers for VGA (standard adapter needs rewiring to work) Parallel and a header for led signals for all six nics, only eth0 is wired on this. A PCI slot exists on all of them but some appliances would need a slot cut into the back to use it. I have one with the cutout and mount already there as a facory option. I set my build to use the serial port at 115200 out of the box via extlinux and inittab. It can easily be installed via Virtual and a slaved USB drive and then set up via serial at first. It's a 1U appliance. I would never have a monitor attached unless there was something I could do in the bios which is doubtful. ACPI works perfectly on this. My motivation is that I need something that can use my Solos PCI Quad. The Cobalts work with the Pulsar but not with the Solos. There is reportedly an endian swap on the Cobalt PCI bus that causes some hardware not to work, eg PCI Wireless nics and the Solos. This swap was carried to the 5000 series before Sun Killed Cobalt. -- Dave Studeman http://www.raqcop.com |