07/23/08 IPCop 1.4.21 came out right on the heels of 1.4.20. Since it is a minor update, the IPCop 1.4.21 update will work just fine in Raqcop 1.4.20. Of course, if you are doing a fresh install, the flash images, install cdrom and vmdk image are 1.4.21.
07/22/08 Raqcop 1.4.20 is here. It refines the lcd verbosity during boot and has better fsck management as far as being more automated and not needing user intervention. Also we now have CF install images that are gzipped in the raqcop-flash-image-install folder. Same credentials. Kernel cleanups in addition to the IPCop 1.4.20 kernel update to 2.4.36 is here as well, we only need to support two ide drivers embedded in the kernel between the Gen III (3000 series) and Raq 550 which is one of the two Gen V (5000 series) units. Removed the keyboard and floppy drivers since we don't have these to load drivers for anyway. This in no way affects your ability to use usb floppy drives. Tom 'wintermute' Eichstaedt's Sysinfo245 is part of this now as it is very useful. This release will also support and run on the extremely noisy Raq550 with limited LCD support thus far. I deliberately do not support the Raq XTR since it is huge, noisy, has four hot swap drive bays and should be used to make a server with, not a firewall appliance. More details are in the respective folders.
06/11/08 Of course the latest stable 1.4.18 build has quite a few improvements in the area of lcd usefulness, it displays programs and services as the machine boots as well as landing on a bandwidth meter. The lcd program is self contained in a single perl file /usr/local/sbin/lcd and you may want to edit the bandwidth settings for your connection as well as the device to monitor. I set it at 100mbs and on eth0, you may want to change it to your red device and up and down speed in kilobits per second of your isp. WinSCP with the built in editor works great for this as well as the built in nano editor via command line.
02/25/08 The latest CVS build uses a single driverless Perl lcd script as an LCD Program rather than all the cruft of the dated Cobalt Panel utilities. This needs work as well but it's all in one file, not 30 files. Had been experimenting with LCDproc as well but it needs a better character map to keep unicode from occasionally garbaging the lcd display which is ascii, otherwise LCDproc is a nice candidate.
12/02/07 IPCop 1.4.18 is stable now so I built a version for us here and uploaded the appropriate images for either a VMWare install or WinImage direct image ready to be used and booted from install. Even as the front panel buttons are still inactive when IPCop is up and running, the LCD displays the hostname and ip address. The underlying IPCop is the stable version so it can be used full time. The raqcop-1.4.18-build-tree folder is nothing more than an already modified build tree to allow one to build their own images and play with or further improve what I have done so far. Basically, make.sh prefetch, make.sh gettoolchain and make.sh build and it will build for you no problem. If using a 64 bit build host, simply open a 32 bit terminal and go to the build tree provided you have some 32 bit compatibility libraries installed. The toolchain, once in your cache folder that contains all the sources used to build, basically takes care of stage1 in the build process so you don't rely on the gcc versions of the build host. Once you have compiled the first go around, the ccache will speed up further builds. On a Dual Core Athlon 64 3800+ machine running openSuSE 10.3 64 bit, it takes me just over an hour to build now. We have 1.4.18 for Cobalts before the masses even have the generic 386 version! BTW, do not use the e100new driver. It really isn't that good on the 2.4 kernel and locks up. This is not a Cobalt issue necessarily. The e100 that is used when you boot up is the actual 2.4.34 kernel included version and as such it works with the kernel just fine.
11/26/07 I have managed to patch the e100 drivers, both the kernel one and the 3.5.17 version which is built as e100new.o.gz by the IPCop dev team for the soon to be IPCop 1.4.18 so both drivers can coexist. For some reason, when hooking a floppy to my test Raq4i and doing a backup, it sets the driver for green as e100. To make life easier for all of us and since the kernel devs keep threatening to remove the eepro100 driver which is pretty old by now and not included in a default ipcop compile anyway, I managed to patch both the kernel and the 3.5.17 version of the e100 drivers to ignore the checksum error which is quite normal for the 82559ER chips used in many devices like the Cobalt so theoretically, if one installs either to VMWare and uses the floppy image to restore default settings and passwords I set up or uses Winimage to restore from the dynamically expanding VMWare image I uploaded, it should boot and have network access on first boot with ssh enabled. The e100new.o.gz can be edited in to the ethernet settings file for next boot. Using an addon called sysinfo, the built in ethernet ports actually show the true status such as full duplex and 100base. The eepro100 drivers didn't really show much info about itself and the e100 kernel driver, isn't very self telling either. None of this shows on the default network status page. I only assumed the other two drivers connected at 100base since my switch showed that. The new e100new.o.gz shows up nicely in the system information dropdown if added to ipcop.
I now have the Cobalt-ized ipcop installation cd to be completely self contained thus eliminating all the extra steps to prepare a 20 gig Seagate standard Cobalt HD for plugging back into the Cobalt and booting up.
For people who have access to a Windows machine, Winimage which I included in the WinImage_Install directory, now allows one to restore a dynamically expanding or fixed image VMware image to a physical disk, last version only did fixed sizes unless it was in WinImage format. The improvements since the last version are phenomenal. WinImage will also convert a dynamically expanding disk image (considerably smaller for an IPCop install) to a fixed sized image and will convert between a VMWare image (VMDK) and a WinImage VHD image. You now only need to create a fixed size image if using Linux and the dd command to write the image to the 20GB hard drive, I'll look for a way to install/expand the dynamic image in Linux, I'm sure there is a way by a single command line. I have included a default dynamic VMWare HD image which also has the default passwords I set up, turns out that the VMWare dynamic image is much smaller than a dynamic WinImage image and the program can image from both types, this makes it less painful to upload here. It's all in the VMWare_Install folder.
I now put the extra fluff in the extras folder, mainly lcd sources and binaries from various places that I used in the learning process thus far.
